· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
ID3 tag version 2.4.0 structure ¹ø¿ª



ÆäÀÌÁöÀ̸§ÀÌ ÀÌ»óÇϸé ÁÁ°Ô ¹Ù²ãÁÖ¼¼¿ä.

Informal standard                                             M. Nilsson
Document: id3v2.4.0-structure.txt                      1st November 2000


                 !ID3 tag version 2.4.0 - Main Structure

ÀÌ ¹®¼­ÀÇ »óÅÂ

ÀÌ ¹®¼­´Â ºñ°ø½Ä Ç¥ÁØÀÌ°í ID3v2ÀÇ Ç¥ÁØÀÎ ID3v2.3.0À» ´ëüÇÑ´Ù. °ø½Ä Ç¥ÁØÀº ³»¿ëÀÌ °°´õ¶óµµ ´Ù¸¥ ¸®¹öÀü¸¦ »ç¿ë ÇÒ °ÍÀÌ´Ù. ÀÌ ¹®¼­ÀÇ ³»¿ëÀ» Á¤È®È÷ ´Ùµë±â À§ÇØ ¹Ù²ð¼öµµ ÀÖÁö¸¸, ±â´É¸é¿¡¼­´Â Àý´ë Ãß°¡µÇ°Å³ª ¹Ù²î´Â ÀÏÀº ¾øÀ»°ÍÀÌ´Ù.

ÀÌ ¹®¼­ÀÇ ¹èÆ÷¿¡´Â Á¦ÇÑÀÌ ¾ø´Ù.


¿ä¾à

ÀÌ ¹®¼­´Â ID3v2 ºñ°ø½Ä Ç¥ÁØÀÎ ID3v2.4.0ÀÇ ±âº» ±¸Á¶¸¦ ¼³¸íÇÑ´Ù. ID3v2´Â À½¾Ç ÆÄÀÏ ÀÚü¾È¿¡¼­ °­·ÂÇÑ ¿Àµð¿À ¸ÞŸ Á¤º¸ÀÇ À¯¿¬ÇÑ ¹æ¹ýÀ» Á¦°øÇÑ´Ù. Á¤º¸¶õ ÀÌ퀠¶óÀÌÁ® Á¾·ù¿Í ±â¼úÃø¸é°ú Á¦¸ñ, ¾ÆƼ½ºÆ®, ÀúÀÛ±Ç µîÀÌ µÉ ¼ö ÀÖ´Ù.

ID3v2.4.0Àº ¼ÒÇÁÆ®¿þ¾î ´ëÀÀÀÌ ½±°Ô ÀÌ·ç¾îÁú ¼ö ÀÖµµ·Ï ID3v2.3.0°ú °¡´ÉÇÑ ºñ½ÁÇÏ°Ô µÇ¾î ÀÖ´Ù.




1. ¹®¼­¸¦ º¸±âÀü¿¡ ¾Ë¾ÆµÑ °Í


"" ¾ÈÀÇ ¹®Àڴ ű׾ȿ¡ Á¤È®È÷ ±×´ë·Î ³ªÅ¸³ª´Â ¹®ÀÚ¿­ÀÌ´Ù. $ µÚ ¼ýÀÚµéÀº 16Áø¼ö(hexadecimal)ÀÌ°í, % µÚ ¼ýÀÚµéÀº ÀÌÁø¼ö(binary)ÀÌ´Ù. $xx´Â ¾Ë¼ö¾ø´Â ³»¿ëÀÇ ÇÑ ¹ÙÀÌÆ®¸¦ °¡¸®Å³ ¶§ ¾²ÀδÙ. %x´Â ¾Ë¼ö¾ø´Â ³»¿ëÀÇ ÇÑ ºñÆ®¸¦ °¡¸®Å³ ¶§ ¾²ÀδÙ. ÇÑ ¹ÙÀÌÆ®ÀÇ ÃÖ»óÀ§ºñÆ®(MSB)´Â 'bit 7'À̶ó°í ÇÏ°í, ÃÖÇÏÀ§ºñÆ®(LSB)´Â 'bit 0'¶ó ÇÑ´Ù.

'ű×'¶ó ÇÔÀº ÀÌ ¹®¼­¿¡¼­ ¼³¸íÇÏ´Â Àüü ű×ÀÌ´Ù. 'ÇÁ·¡ÀÓ'¶ó ÇÔÀº ÅÂ±×¾È Á¤º¸ÀÇ ÇÑ ºÎºÐ(block)ÀÌ´Ù. ű״ ÇØ´õ Çϳª, ÇÁ·¡ÀÓ ¿©·µ ±×¸®°í ÇÊ¿ä¿¡ µû¸¥ ä¿ì±â(optional padding)·Î ±¸¼ºµÈ´Ù. A field is a piece of information; one value, a string etc. A numeric string is a string that consists of the characters "0123456789" only.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 KEYWORDS.


2. ID3v2 °³¿ä


ID3v2´Â ÀϹÝÀûÀÎ ¿Àµð¿À ÅÂ±× Æ÷¸ËÀ¸·Î, ¿Àµð¿À ÆÄÀÏÀÌ ¿Àµð¿À¿¡ ´ëÇÑ ¸ÞŸ ÀڷḦ ³»ÀåÇÒ ¼ö ÀÖ°Ô ÇÑ´Ù. º» ¹®¼­°¡ ¼³¸íÇÏ´Â ID3 ű״ MPEG-1/2 layer I¿Í MPEG-1/2 layer II, MPEG-1/2 layer III, MPEG-2.5·Î ÀÎÄÚµåÇÑ ÆÄÀÏÀ» ÁÖ¸ñÀûÀ¸·Î Çϳª, ´Ù¸¥ Á¾·ùÀÇ ÀÎÄÚµåµÈ ¿Àµð¿À¿¡³ª ¿Àµð¿À ¸ÞŸ µ¥ÀÌŸ¸¦ À§ÇÑ µ¶¸³Àû Æ÷¸ËÀ¸·Îµµ »ç¿ëÇÒ ¼ö ÀÖ´Ù.

ID3v2´Â »õ·Î¿î ¸ÞŸ Á¤º¸¿¡ ´ëÇÑ ÇÊ¿ä°¡ »ý°åÀ» ¶§ ´ëÀÀÇÒ ÇÒ ¼ö ÀÖµµ·Ï °¡´ÉÇÑÇÑ À¯¿¬ÇÏ°í È®Àå¿¡ ¿ëÀÇÇÏ°Ô ¼³°èµÇ¾ú´Ù. À̸¦ À§ÇØ ID3v2´Â ÇÁ·¹ÀÓ(frame)À̶ó ºÒ¸®¿ì´Â ¿©·¯ Á¤º¸ µ¢¾î¸®µéÀ» ´ã´Â ÄÁÅ×À̳ÊÀÇ ¿ªÇÒÀ» ÇÑ´Ù. ¸ðµç ÇÁ·¹ÀÓÀÇ Æ÷¸ËÀÌ ±×°ÍµéÀ» Á¶¿ìÇÏ´Â ¼ÒÇÁÆ®¿þ¾î¿¡°Ô ¾Ë·ÁÁú ÇÊ¿ä°¡ ÀÖ´Â °ÍÀº ¾Æ´Ï´Ù. °¢ ÇÁ·¹ÀÓÀº ¹Ì¸® Á¤ÀÇµÈ Àڱ⸸ÀÇ ¸íĪ(identifier)°ú Å©±â Áö½ÃÀÚ(size descripter)·Î ½ÃÀÛÇϴµ¥, ÀÌ Á¤º¸·Î ¼ÒÇÁÆ®¿þ¾î´Â ÀÚ½ÅÀÌ ¸ð¸£´Â ÇÁ·¹ÀÓÀÌ ÀÖÀ» ¶§ ÇØ´ç ÇÁ·¹ÀÓ°ú Ç÷¡±× Çʵå Çϳª¸¦ ¹«½ÃÇÏ°í Áö³ª°¥ ¼ö ÀÖ´Ù.

ID3v2 ³»ÀÇ ºñÆ®¼ø¼­(bitorder)´Â ÃÖ»óÀ§ºñÆ®(MSB) ¿ì¼±ÀÌ´Ù. ¿©·¯ ¹ÙÀÌÆ®¸¦ »ç¿ëÇÏ´Â ¼ýÀÚÀÇ ¹ÙÀÌÆ®¼ø¼­´Â ÃÖ»óÀ§¹ÙÀÌÆ® ¿ì¼±ÀÌ´Ù. (¿¹¸¦ µé¾î $12345678Àº $12 34 56 78·Î ÀÎÄÚµåµÉ °ÍÀÌ´Ù.) ÀÌ ¹æ½ÄÀº ºò¿£µð¾È(big endian)°ú ³×Æ®¿öÅ©¹ÙÀÌÆ®¼ø¼­(network byte order)·Îµµ ¾Ë·ÁÁ® ÀÖ´Ù.

ű×ÀÇ Àüü ±¸Á¶´Â ´ÙÀ½°ú °°´Ù.

     +-----------------------------+
     |       Çì´õ (10¹ÙÀÌÆ®)       |
     +-----------------------------+
     |          È®Àå Çì´õ          |
     |     (°¡º¯ ±æÀÌ, ºÒÇʼö)     |
     +-----------------------------+
     |     ÇÁ·¹ÀÓµé (°¡º¯ ±æÀÌ)    |
     +-----------------------------+
     | padding (°¡º¯ ±æÀÌ, ºÒÇʼö) |
     +-----------------------------+
     |  footer (10¹ÙÀÌÆ®, ºÒÇʼö)  |
     +-----------------------------+

ÀϹÝÀûÀ¸·Î, padding and footer are mutually exclusive. ÀÚ¼¼ÇÑ ³»¿ëÀº 3.3, 3.4 ±×¸®°í 3.5 ¼½¼ÇÀ» º¸¶ó.


2.1. ID3v2 header


!ID3v2ÀÇ Ã¹ºÎºÐÀº ¾Æ·¡¿Í °°Àº 10¹ÙÀÌÆ® ÅÂ±× Çì´õÀÌ´Ù:
     ID3v2/file identifier      "ID3"
     ID3v2 version              $04 00
     ID3v2 flags                %abcd0000
     ID3v2 size             4 * %0xxxxxxx

ű×ÀÇ Ã¹ ¼¼ ¹ÙÀÌÆ®´Â Ç×»ó ID3v2¶ó ¾Ë·ÁÁÖ´Â "ID3"ÀÌ°í, ¹Ù·Î µÎ ¹ÙÀÌÆ®ÀÇ ¹öÀüÀÌ ºÙ´Â´Ù. ID3v2 ¹öÀüÀÇ Ã¹ ¹ÙÀÌÆ®´Â major versionÀÌ°í, µÑ° ¹ÙÀÌÆ®´Â revision numberÀÌ´Ù. À§ ¿¹Á¦´Â ID3v2.4.0 ÀÌ´Ù. major versionsÀº ÇÏÀ§ ȣȯÀ» °¡ÁöÁö ¾Ê´Â ¹Ý¸é, ¸ðµç revisionÀº ÇÏÀ§ ȣȯÀ» °¡Áø´Ù.(¿ªÁÖ(moonhyunjin) ÀÌ°ÍÀÌ http://www.mpx.cz/mp3manager/tags.htm ¿¡¼­´Â ID3v2¸¦ ¹Ý´ëÇÏ´Â ÀÌÀ¯Áß Çϳª´Ù.) ¸¸¾à ID3v2.4.0 ÀÌÇϸ¦ Áö¿øÇÏ´Â ¼ÒÇÁÆ®¿þ¾î°¡ 5ÀÌ»óÀ» ¸¸³ª¸é, °£´ÜÈ÷ ÅÂ±× Àüü¸¦ ¹«½ÃÇÏ¸é µÈ´Ù. major, revisionÀº Àý´ë $FF°¡ µÉ ¼ö ¾ø´Ù.


ID3v2 Ç÷¡±× Çʵå(flags field)´Â ¹öÀü µÚ¿¡ ³ª¿À¸é ÇöÀç 4°³°¡ ¾²ÀÌ°í ÀÖ´Ù.


a - Unsynchronisation(¹Ýµ¿±âÈ­?????)

'ID3v2 Ç÷¡±×'ÀÇ Bit 7Àº unsynchronisation°¡ ¸ðµç ÇÁ·¡ÀÓ¿¡ Àû¿ëµÇ´Â ¾Æ´ÑÁö °¡¸®Å²´Ù. (ÀÚ¼¼ÇÑ°Ç [http]¾Æ·¡ ¼³¸í); Ç¥±âµÇ¸é »ç¿ëÇÑ´Ù´Â ¶æÀÌ´Ù.


b - È®Àå Çì´õ(Extended header)

µÎ¹ø° ºñÆ®(bit 6)´Â Çì´õµÚ¿¡ È®Àå Çì´õ°¡ ÀÖ´ÂÁö ¾ø´ÂÁö ¾Ë·ÁÁØ´Ù. È®Àå Çì´õ´Â [http]¾Æ·¡¿¡¼­ ¼³¸íÇÑ´Ù. Ç¥±âµÇ¸é È®Àå Çì´õ°¡ ÀÖ´Ù´Â ¶æÀÌ´Ù.


c - ½ÃÇè¿ë Áö½ÃÀÚ(Experimental indicator)

¼¼¹ø° ºñÆ®(bit 5)´Â ½ÃÇè¿ë Áö½ÃÀÚ·Î ¾²ÀδÙ. űװ¡ ½ÃÇè¿ë À϶§´Â ÀÌ Ç÷¡±×°¡ Ç¥±âµÇ¾ß(SHALL) ÇÑ´Ù.


d - ³¡¸ÎÀ½(Footer present)

Bit 4´Â ű×ÀÇ ³¡ÀÓÀ» ¸»ÇÏ´Â ³¡¸ÎÀ½À» °¡¸®Å²´Ù. Ç¥±âµÇ¸é »ç¿ëÇÑ´Ù´Â ¶æÀÌ´Ù.

»ç¿ëÇÏÁö ¾Ê´Â Ç÷¡±×´Â %0000 À̾î¾ß(MUST) ÇÑ´Ù. ¸¸¾à ±×·¸Áö ¾ÊÀ¸¸é, Ç÷¡±×ÀÇ ±â´ÉÀ» ¸ð¸£´Â Æļ­´Â ű׸¦ ÀÐÁö ¸ø ÇÒ ¼öµµ ÀÖ´Ù.

ID3v2 ÅÂ±× Å©±â´Â 28bitÀÇ À¯È¿ÇÑ Å©±â¸¦ °¡Áø 32 bit synchsafe integer·Î ÀúÀåµÈ´Ù. (ÃÖ´ë 256MB = 2ÀÇ 28½Â). synchsafe integer´Â [http]¾Æ·¡¿¡¼­ ¼³¸íÇÑ´Ù.

ID3v2 ÅÂ±× Å©±â´Â unsynchronisationµÚÀÇ È®Àå Çì´õ, Æеù, ÇÁ·¡ÀÓÀÇ ÇÕÀÌ´Ù. ¸¸¾à ³¡¸ÎÀ½(footer)¸¦ »ç¿ëÇÏ´Ù¸é Å©±â´Â (Àüü Å©±â - 20) ¹ÙÀÌÆ®ÀÌ°í, »ç¿ë ¾ÈÇϸé (Àüü Å©±â - 10) ¹ÙÀÌÆ®ÀÌ´Ù.

ID3v2 ű״ ¾Æ·¡ÀÇ ÆÐÅÏÀ¸·Î ãÀ» ¼ö ÀÖ´Ù.
     $49 44 33 yy yy xx zz zz zz zz
yy´Â %FF º¸´Ù ÀÛ°í, xx´Â Ç÷¡±×ÀÌ°í, zz´Â $80º¸´Ù ÀÛ´Ù.


2.2. È®Àå Çì´õ


È®Àå Çì´õ´Â ÅÂ±× ±¸Á¶¾È¿¡¼­ ´õ ÀÚ¼¼ÇÑ °ÍÀ» ´ã°íÀÖ´Â Á¤º¸¸¦ °¡Áö°í ÀÖ´Ù. ÇÏÁö¸¸ È®Àå Çì´õ´Â ¼±ÅÃÀûÀ̱⠶§¹®¿¡ Á¤º¸¸¦ Á¤È®È÷ ÀоîµéÀÌ´Â °ÍÀº Áß¿äÄ¡ ¾Ê´Ù.
     Extended header size   4 * %0xxxxxxx
     Number of flag bytes       $01
     Extended Flags             $xx

'Extended header size'´Â 32 bit synchsafe integer·Î ÀúÀåµÇ´Â Àüü È®ÀåÇì´õ Å©±âÀÌ´Ù. ±×·¯¹Ç·Î È®Àå Çì´õ´Â Àý´ë 6¹ÙÀÌÆ®º¸´Ù ÀÛÀº Å©±â¸¦ °¡ÁöÁö ¾Ê´Â´Ù.

'number of flag bytes'¿¡ ÀÇÇØ Å©±â°¡ Á¤ÇØÁø 'extended flags'´Â ¾Æ·¡¿Í °°ÀÌ Á¤ÀÇÇÑ´Ù.
     %0bcd0000

È®ÀåÇì´õ ¾ÈÀÇ °¢°¢ÀÇ Ç÷¡±×´Â Ç÷¡±× ¼ø¼­´ë·Î Á¤·ÄµÈ µ¥ÀÌÅÍ°¡ µû¶óºÙ´Â´Ù. (¿¹¸¦ µé¾î, b,c Ç÷¡±×°¡ ÄÑÁö¸é µ¥ÀÌÅÍ b,c¼øÀ¸·Î ¾´´Ù) Ç÷¡±×¸¦ ²ô¸é ¾Æ¹« µ¥ÀÌÅ͵µ °¡ÁöÁö ¸øÇÑ´Ù. ¸ðµç ¾Ë¼ö¾ø´Â Ç÷¡±×´Â ²¨Á®ÀÖ¾î¾ß(MUST) ÇÏ°í, µþ·ÁÀÖ´Â µ¥ÀÌÅÍ´Â µ¥ÀÌÅ͸¦ ű׸¦ ¼öÁ¤ÇÒ¶§ Á¦°ÅµÈ´Ù.

¸ðµç ÄÑÁ®ÀÖ´Â Ç÷¡±×ÀÇ 0¿¡¼­ 128±îÁöÀÇ($00 - $7f) Å©±â¸¦ °¡Áö´Â ±æÀÌ ¹ÙÀÌÆ®·Î ½ÃÀÛÇÑ´Ù. ¹Ù·Î µÚ¿¡ ³ª¿À´Â µ¥ÀÌÅÍ´Â ¹Ù·Î ¾Õ¿¡ ÀÖ´Â ¹ÙÀÌÆ®¿¡ ¾²ÀÎ ±æÀÌ´Â °°´Ù. ¸¸¾à Ç÷¡±×¿¡ µþ¸° µ¥ÀÌÅÍ°¡ ¾øÀ¸¸é ±æÀÌ ¹ÙÀÌÆ® $00 ÀÌ´Ù.


b - űװ¡ °»½ÅµÇ¾úÀ½ b - Tag is an update

¸¸¾à ÀÌ Ç÷¡±×°¡ ÄÑÁ®ÀÖÀ¸¸é, ÇöÀç ű״ ÀÌÀü ÆÄÀÏÀ̳ª ½Ã½ºÅÛ¿¡ ÀÖ´ø ű׸¦ °»½ÅÇß´Ù´Â ¶æÀÌ´Ù. ¸¸¾à ƯÀÌÇÏ°Ô Á¤ÀÇµÈ ÇÁ·¹ÀÓÀ» ÇöÀç Åױ׿¡¼­ ãÀ¸¸é, ÀÌÀü ű׿¡ ÀÖ´ø ÇÁ·¡ÀÓÀ» °»½ÅÇϴ°ÍÀÌ´Ù. ÀÌ Ç÷¡±×´Â µþ¸° µ¥ÀÌÅÍ°¡ ¾ø´Ù.

Flag data length $00

c - CRC data present

If this flag is set, a CRC-32 ISO-3309 data is included in the extended header. The CRC is calculated on all the data between the header and footer as indicated by the header's tag length field, minus the extended header. Note that this includes the padding (if there is any), but excludes the footer. The CRC-32 is stored as an 35 bit synchsafe integer, leaving the upper four bits always zeroed.
        Flag data length       $05
        Total frame CRC    5 * %0xxxxxxx

d - ÅÂ±× ±ÔÁ¤

For some applications it might be desired to restrict a tag in more ways than imposed by the ID3v2 specification. Note that the presence of these restrictions does not affect how the tag is decoded, merely how it was restricted before encoding. If this flag is set the tag is restricted as follows:
        Flag data length       $01
        Restrictions           %ppqrrstt

p - ÅÂ±× Å©±â ±ÔÁ¤
       00   No more than 128 frames and 1 MB total tag size.
       01   No more than 64 frames and 128 KB total tag size.
       10   No more than 32 frames and 40 KB total tag size.
       11   No more than 32 frames and 4 KB total tag size.

q - ¹®ÀÚ ÀÎÄÚµù ±ÔÁ¤
       0    Á¦ÇÑ ¾øÀ½
       1    ISO-8859-1 [ISO-8859-1] ¶Ç´Â UTF-8 [UTF-8] À¸·Î¸¸ µÇ¾ú´Ù.

r - ¹®ÀÚ ÇÊµå ±æÀÌ ±ÔÁ¤
       00   Á¦ÇÑ ¾øÀ½
       01   1024ÀÚ ÀÌÇÏ.
       10   128ÀÚ ÀÌÇÏ.
       11   30ÀÚ ÀÌÇÏ.

Note that nothing is said about how many bytes is used to represent those characters, since it is encoding dependent. If a text frame consists of more than one string, the sum of the strungs is restricted as stated.

s - ±×¸² ÀÎÄÚµù ±ÔÁ¤
       0   Á¦ÇÑ ¾øÀ½
       1   ¿ÀÁ÷ PNG [PNG] ¶Ç´Â JPEG [JFIF] À¸·Î¸¸ ÀÎÄÚµù.

t - ±×¸² Å©±â ±ÔÁ¤
       00  Á¦ÇÑ ¾øÀ½
       01  ¸ðµç ±×¸²Àº 256x256 Çȼ¿ º¸´Ù ÀÛ´Ù.
       10  ¸ðµç ±×¸²Àº 64x64 Çȼ¿ º¸´Ù ÀÛ´Ù.
       11  ´Ù¸¥°ÍÀ» ÇÊ¿ä·Î ÇÏÁö ¾Ê´ÂÇÑ, ¸ðµç ±×¸²Àº Á¤È®È÷ 64x64 Çȼ¿ÀÌ´Ù.


2.3. Padding


ID3 ű×ÀÇ ³¡¿¡ ÀÖ´Â ¸¶Áö¸· ÇÁ·¡ÀÓ µÚ·Î ÆеùÀ» ³Ö´Â °ÍÀº ¼±ÅÃ(OPTIONAL)ÀÌ°í, ¸ðµç ÇÁ·¹ÀÓÀÇ Å©±âÀÇ ÇÕÀÌ ÅÂ±× Çì´õ¾ÈÀÇ °ªº¸´Ù ÀÛ°Ô ¸¸µç´Ù. ÆеùÀÇ »ç¿ë¸ñÀûÀº ÆÄÀÏ Àüü¸¦ ´Ù½Ã ¾²´Â ÀϾøÀÌ Å±׾ȿ¡ Ãß°¡·Î ¸î°³ÀÇ ÇÁ·¡ÀÓÀ» ´õÇϰųª Á¸ÀçÇÏ´Â ÇÁ·¡ÀÓÀ» Å©°ÔÇÏ´Â °ÍÀÌ´Ù. Æеù °ªÀº $00 ÀÌ´Ù. ÇÁ·¹ÀÓ »çÀÌ, ÅÂ±× Çì´õ¿Í ÇÁ·¡ÀÓ»çÀÌ¿¡´Â ÆеùÀÌ µé¾î°¡¼­´Â ¾ÈµÈ´Ù(MUST NOT). ¶ÇÇÑ, ÅÂ±× footer°¡ ÀÖÀ» ½Ã¿¡µµ ÆеùÀº À־´Â ¾ÈµÈ´Ù(MUST NOT).


2.4. ID3v2 footer


ÆÄÀÏÀÇ ³¡¿¡¼­ ºÎÅÍ ID3v2 ű׸¦ ãÀ» ¶§ ¼Óµµ¸¦ ³ôÀ̱â À§ÇØ footer¸¦ ÅÂ±× µÚ¿¡ ºÙÀÏ ¼ö ÀÖ´Ù. ¿Àµð¿À µ¥ÀÌÅÍ µÚ¿¡ À§Ä¡ÇÑ Å±×ó·³ µ¡ºÙ¿©Áø ű×(appended tag)´Â footer°¡ ÇÊ¿ä(REQUIRED)ÇÏ´Ù. footer´Â identifier¸¸ ´Ù¸¥ Çì´õÀÇ º¹»çº»ÀÌ´Ù.

     ID3v2 identifier           "3DI"
     ID3v2 version              $04 00
     ID3v2 flags                %abcd0000
     ID3v2 size             4 * %0xxxxxxx


3. ID3v2 frame overview


All ID3v2 frames consists of one frame header followed by one or more fields containing the actual information. The header is always 10 bytes and laid out as follows:

Frame ID $xx xx xx xx (four characters) Size 4 * %0xxxxxxx Flags $xx xx

The frame ID is made out of the characters capital A-Z and 0-9. Identifiers beginning with "X", "Y" and "Z" are for experimental frames and free for everyone to use, without the need to set the experimental bit in the tag header. Bear in mind that someone else might have used the same identifier as you. All other identifiers are either used or reserved for future use.

The frame ID is followed by a size descriptor containing the size of the data in the final frame, after encryption, compression and unsynchronisation. The size is excluding the frame header ('total frame size' - 10 bytes) and stored as a 32 bit synchsafe integer.

In the frame header the size descriptor is followed by two flag bytes. These flags are described in section 4.1.

There is no fixed order of the frames' appearance in the tag, although it is desired that the frames are arranged in order of significance concerning the recognition of the file. An example of such order: UFID, TIT2, MCDI, TRCK ...

A tag MUST contain at least one frame. A frame must be at least 1 byte big, excluding the header.

If nothing else is said, strings, including numeric strings and URLs URL, are represented as ISO-8859-1 ISO-8859-1 characters in the range $20 - $FF. Such strings are represented in frame descriptions as <text string>, or <full text string> if newlines are allowed. If nothing else is said newline character is forbidden. In ISO-8859-1 a newline is represented, when allowed, with $0A only.

Frames that allow different types of text encoding contains a text encoding description byte. Possible encodings:

$00 ISO-8859-1 ISO-8859-1. Terminated with $00. $01 UTF-16 UTF-16 encoded Unicode UNICODE with BOM. All
strings in the same frame SHALL have the same byteorder. Terminated with $00 00.
$02 UTF-16BE UTF-16 encoded Unicode UNICODE without BOM.
Terminated with $00 00.
$03 UTF-8 UTF-8 encoded Unicode UNICODE. Terminated with $00.

Strings dependent on encoding are represented in frame descriptions as <text string according to encoding>, or according to encoding> if newlines are allowed. Any empty strings of type $01 which are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).

The timestamp fields are based on a subset of ISO 8601. When being as precise as possible the format of a time string is yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of 24), ":", minutes, ":", seconds), but the precision may be reduced by removing as many time indicators as wanted. Hence valid timestamps are yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use the slash character as described in 8601, and for multiple non- contiguous dates, use multiple strings, if allowed by the frame definition.

The three byte language field, present in several frames, is used to describe the language of the frame's content, according to ISO-639-2 ISO-639-2. The language should be represented in lower case. If the language is not known the string "XXX" should be used.

All URLs URL MAY be relative, e.g. "picture.png", "../doc.txt".

If a frame is longer than it should be, e.g. having more fields than specified in this document, that indicates that additions to the frame have been made in a later version of the ID3v2 standard. This is reflected by the revision number in the header of the tag.


3.1. Frame header flags


In the frame header the size descriptor is followed by two flag bytes. All unused flags MUST be cleared. The first byte is for 'status messages' and the second byte is a format description. If an unknown flag is set in the first byte the frame MUST NOT be changed without that bit cleared. If an unknown flag is set in the second byte the frame is likely to not be readable. Some flags in the second byte indicates that extra information is added to the header. These fields of extra information is ordered as the flags that indicates them. The flags field is defined as follows (l and o left out because ther resemblence to one and zero):

%0abc0000 %0h00kmnp

Some frame format flags indicate that additional information fields are added to the frame. This information is added after the frame header and before the frame data in the same order as the flags that indicates them. I.e. the four bytes of decompressed size will precede the encryption method byte. These additions affects the 'frame size' field, but are not subject to encryption or compression.
The default status flags setting for a frame is, unless stated otherwise, 'preserved if tag is altered' and 'preserved if file is altered', i.e. %00000000.


3.1.1. Frame status flags


a - Tag alter preservation

This flag tells the tag parser what to do with this frame if it is unknown and the tag is altered in any way. This applies to all kinds of alterations, including adding more padding and reordering the frames.

0 Frame should be preserved. 1 Frame should be discarded.


b - File alter preservation

This flag tells the tag parser what to do with this frame if it is unknown and the file, excluding the tag, is altered. This does not apply when the audio is completely replaced with other audio data.

0 Frame should be preserved. 1 Frame should be discarded.


c - Read only

This flag, if set, tells the software that the contents of this frame are intended to be read only. Changing the contents might break something, e.g. a signature. If the contents are changed, without knowledge of why the frame was flagged read only and without taking the proper means to compensate, e.g. recalculating the signature, the bit MUST be cleared.


3.1.2. Frame format flags


h - Grouping identity

This flag indicates whether or not this frame belongs in a group with other frames. If set, a group identifier byte is added to the frame. Every frame with the same group identifier belongs to the same group.

0 Frame does not contain group information 1 Frame contains group information


k - Compression

This flag indicates whether or not the frame is compressed. A 'Data Length Indicator' byte MUST be included in the frame.

0 Frame is not compressed. 1 Frame is compressed using zlib zlib deflate method.
If set, this requires the 'Data Length Indicator' bit to be set as well.


m - Encryption
This flag indicates whether or not the frame is encrypted. If set, one byte indicating with which method it was encrypted will be added to the frame. See description of the ENCR frame for more information about encryption method registration. Encryption should be done after compression. Whether or not setting this flag requires the presence of a 'Data Length Indicator' depends on the specific algorithm used.

0 Frame is not encrypted. 1 Frame is encrypted.

n - Unsynchronisation

This flag indicates whether or not unsynchronisation was applied to this frame. See section 6 for details on unsynchronisation. If this flag is set all data from the end of this header to the end of this frame has been unsynchronised. Although desirable, the presence of a 'Data Length Indicator' is not made mandatory by unsynchronisation.

0 Frame has not been unsynchronised. 1 Frame has been unsyrchronised.

p - Data length indicator

This flag indicates that a data length indicator has been added to the frame. The data length indicator is the value one would write as the 'Frame length' if all of the frame format flags were zeroed, represented as a 32 bit synchsafe integer.

0 There is no Data Length Indicator. 1 A data length Indicator has been added to the frame.


4. ÅÂ±× À§Ä¡


ID3v2 ű×ÀÇ ±âº» À§Ä¡´Â ¿Àµð¿À ¾ÕÀÌ¿©¼­ µ¥ÀÌÅ͸¦ ÀÐÀ» ¶§ ¿¬Áֱ⿡°Ô µµ¿òÀÌ µÈ´Ù. ÇÏÁö¸¸ ¿Àµð¿À µÚ¿¡ ³Ö°Å³ª, ¾ÕµÚ ¸ðµÎ ³Ö´Â °Íµµ °¡´ÉÇÏ´Ù. ÅÂ±× »õ·Î ³Ö´Â °ÍÀ» °áÁ¤ÇÒ¶§, ¾Æ·¡ ¼ø¼­´ë·Î °í·ÁÇؾß(SHOULD) ÇÑ´Ù.
  1. ű׸¦ ¾Õ¿¡.

  2. Áß¿äÇÑ Á¤º¸¾Õ¿¡ ű׸¦ ³Ö°í, µÎ¹ø° ű׸¦ ÆÄÀϳ¡ÀÇ ¸ðµç Á¾·ùÀÇ ´Ù¸¥ ÅÂ±× ¾Õ¿¡ ³Ö´Â´Ù. ù ű׿¡´Â SEEK ÇÁ·¡ÀÓÀÌ ÀÖ¾î¾ß ÇÑ´Ù.
  3. ű׸¦ ÆÄÀϳ¡ÀÇ ¸ðµç Á¾·ùÀÇ ´Ù¸¥ ÅÂ±× ¾Õ¿¡ ³Ö´Â´Ù.
2,3¹ø¿¡¼­ ´Ù¸¥ ÅÂ±× ¾øÀ» °æ¿ì, ű׸¦ °£´ÜÈ÷ ³ÖÀ» ¼ö ÀÖ´Ù. ID3v2 ű׸¦ ã´Â Ãßõ ¹æ¹ý :
  1. [http]Section 2.1¸¦ Âü°íÇÏ¿© ¾Õ¿¡ ºÙÀº ű׸¦ á´Â´Ù.

  2. SEEK ÇÁ·¡ÀÓÀ» ã¾Ò´Ù¸é, ±×°ÍÀ» ã´Âµ¥ »ç¿ëÇÑ´Ù.

  3. ÅÂ±× footer¸¦ ã¾Æ, ÆÄÀÏ µÚ¿¡¼­ ºÎÅÍ °Ë»öÇÑ´Ù.

È®Àå Çì´õ¾È¿¡ update Ç÷¡±×°¡ Á¸ÀçÇÏÁö ¾Ê´Â ÀÌ»ó, »õ·Î¿î ¹öÀüÀÇ Å±װ¡ ¹ß°ßµÉ¶§ ¸¶´Ù ÀÌÀü ¹öÀüÀÇ Å±״ ¹ö·Á¾ßÇÑ´Ù.


5. Unsynchronisation


The only purpose of unsynchronisation is to make the ID3v2 tag as compatible as possible with existing software and hardware. There is no use in 'unsynchronising' tags if the file is only to be processed only by ID3v2 aware software and hardware. Unsynchronisation is only useful with tags in MPEG 1/2 layer I, II and III, MPEG 2.5 and AAC files.


5.1. The unsynchronisation scheme


Whenever a false synchronisation is found within the tag, one zeroed byte is inserted after the first false synchronisation byte. The format of synchronisations that should be altered by ID3 encoders is as follows:

%11111111 111xxxxx

and should be replaced with:

%11111111 00000000 111xxxxx

This has the side effect that all $FF 00 combinations have to be altered, so they will not be affected by the decoding process. Therefore all the $FF 00 combinations have to be replaced with the $FF 00 00 combination during the unsynchronisation.

To indicate usage of the unsynchronisation, the unsynchronisation flag in the frame header should be set. This bit MUST be set if the frame was altered by the unsynchronisation and SHOULD NOT be set if unaltered. If all frames in the tag are unsynchronised the unsynchronisation flag in the tag header SHOULD be set. It MUST NOT be set if the tag has a frame which is not unsynchronised.

Assume the first byte of the audio to be $FF. The special case when the last byte of the last frame is $FF and no padding nor footer is used will then introduce a false synchronisation. This can be solved by adding a footer, adding padding or unsynchronising the frame and add $00 to the end of the frame data, thus adding more byte to the frame size than a normal unsynchronisation would. Although not preferred, it is allowed to apply the last method on all frames ending with $FF.

It is preferred that the tag is either completely unsynchronised or not unsynchronised at all. A completely unsynchronised tag has no false synchonisations in it, as defined above, and does not end with $FF. A completely non-unsynchronised tag contains no unsynchronised frames, and thus the unsynchronisation flag in the header is cleared.

Do bear in mind, that if compression or encryption is used, the unsynchronisation scheme MUST be applied afterwards. When decoding an unsynchronised frame, the unsynchronisation scheme MUST be reversed first, encryption and decompression afterwards.


5.2. Synchsafe integers


In some parts of the tag it is inconvenient to use the unsychronisation scheme because the size of unsynchronised data is not known in advance, which is particularly problematic with size descriptors. The solution in ID3v2 is to use synchsafe integers, in which there can never be any false synchs. Synchsafe integers are integers that keep its highest bit (bit 7) zeroed, making seven bits out of eight available. Thus a 32 bit synchsafe integer can store 28 bits of information.
Example:
255 (%11111111) encoded as a 16 bit synchsafe integer is 383 (%00000001 01111111).


6. ÀúÀÛ±Ç


Copyright (C) Martin Nilsson 2000. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that a reference to this document is included on all such copies and derivative works. However, this document itself may not be modified in any way and reissued as the original document.

The limited permissions granted above are perpetual and will not be revoked.

This document and the information contained herein is provided on an 'AS IS' basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


7. Âü°í


ID3v2 Martin Nilsson, 'ID3v2 informal standard'.

ISO-639-2 ISO/FDIS 639-2. 'Codes for the representation of names of languages, Part 2: Alpha-3 code.' Technical committee / subcommittee: TC 37 / SC 2

ISO-3309 ISO 3309 'Information Processing Systems--Data Communication High-Level Data Link Control Procedure--Frame Structure', IS 3309, October 1984, 3rd Edition.

ISO-8859-1 ISO/IEC DIS 8859-1. '8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1.' Technical committee / subcommittee: JTC 1 / SC 2

JFIF 'JPEG File Interchange Format, version 1.02'

KEYWORDS S. Bradner, 'Key words for use in RFCs to Indicate Requirement Levels', RFC 2119, March 1997.

MPEG ISO/IEC 11172-3:1993. 'Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s, Part 3: Audio.' Technical committee / subcommittee: JTC 1 / SC 29
and
ISO/IEC 13818-3:1995 'Generic coding of moving pictures and associated audio information, Part 3: Audio.' Technical committee / subcommittee: JTC 1 / SC 29
and
ISO/IEC DIS 13818-3 'Generic coding of moving pictures and associated audio information, Part 3: Audio (Revision of ISO/IEC 13818-3:1995)'

PNG 'Portable Network Graphics, version 1.0'

UNICODE The Unicode Consortium, 'The Unicode Standard Version 3.0', ISBN 0-201-61633-5.

<url:http://www.unicode.org/unicode/standard/versions/Unicode3.0.htm>

URL T. Berners-Lee, L. Masinter & M. McCahill, 'Uniform Resource Locators (URL)', RFC 1738, December 1994.

UTF-8 F. Yergeau, 'UTF-8, a transformation format of ISO 10646', RFC 2279, January 1998.
UTF-16 F. Yergeau, 'UTF-16, an encoding of ISO 10646', RFC 2781, February 2000.
ZLIB P. Deutsch, Aladdin Enterprises & J-L. Gailly, 'ZLIB Compressed Data Format Specification version 3.3', RFC 1950, May 1996.

8. ÀúÀÚ ÁÖ¼Ò


Written by

Martin Nilsson Rydsv�gen 246 C. 30 SE-584 34 Link�ping Sweden

Email: nilsson@id3.org

wiki¸¦ Àß ¸ô¶ó¼­ ´ëÃæ ´Ùµë¾ú½À´Ï´Ù. Æ´Æ´È÷ ¹ø¿ªÇؾßÁÒ.

ÀúÀÛ±ÇÀº ÀÐ¾î ºÃ´Âµ¥ ¹®Á¦ ¾ø´Â°Å °°½À´Ï´Ù.

°ü½ÉÀÖ´Â ÁÖÁ¦¶ó °¨È÷ ¼Õ´ëº¸¾Ò½À´Ï´Ù. -- ¼Ò¸®

ID
Password
Join
He who invents adages for others to peruse takes along rowboat when going on cruise.


sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2009-06-02 11:01:18
Processing time 0.0259 sec