"" 안의 문자는 태그안에 정확히 그대로 나타나는 문자열이다. $ 뒤 숫자들은 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.

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 섹션을 보라.

!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(반동기화?????)

b - 확장 헤더(Extended header)

c - 시험용 지시자(Experimental indicator)

d - 끝맺음(Footer present)

사용하지 않는 플래그는 %0000 이어야(MUST) 한다. 만약 그렇지 않으면, 플래그의 기능을 모르는 파서는 태그를 읽지 못 할 수도 있다.

ID3v2 태그 크기는 28bit의 유효한 크기를 가진 32 bit synchsafe integer로 저장된다. (최대 256MB = 2의 28승). synchsafe integer는 아래에서 설명한다.

ID3v2 태그 크기는 unsynchronisation뒤의 확장 헤더, 패딩, 프래임의 합이다. 만약 끝맺음(footer)를 사용하다면 크기는 (전체 크기 - 20) 바이트이고, 사용 안하면 (전체 크기 - 10) 바이트이다.

ID3v2 태그는 아래의 패턴으로 찾을 수 있다.

     $49 44 33 yy yy xx zz zz zz zz

yy는 %FF 보다 작고, xx는 플래그이고, zz는 $80보다 작다.

확장 헤더는 태그 구조안에서 더 자세한 것을 담고있는 정보를 가지고 있다. 하지만 확장 헤더는 선택적이기 때문에 정보를 정확히 읽어들이는 것은 중요치 않다.

     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

c - CRC data present

        Flag data length       $05
        Total frame CRC    5 * %0xxxxxxx

d - 태그 규정

        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 픽셀이다.

ID3 태그의 끝에 있는 마지막 프래임 뒤로 패딩을 넣는 것은 선택(OPTIONAL)이고, 모든 프레임의 크기의 합이 태그 헤더안의 값보다 작게 만든다. 패딩의 사용목적은 파일 전체를 다시 쓰는 일없이 태그안에 추가로 몇개의 프래임을 더하거나 존재하는 프래임을 크게하는 것이다. 패딩 값은 $00 이다. 프레임 사이, 태그 헤더와 프래임사이에는 패딩이 들어가서는 안된다(MUST NOT). 또한, 태그 footer가 있을 시에도 패딩은 있어서는 안된다(MUST NOT).

파일의 끝에서 부터 ID3v2 태그를 찾을 때 속도를 높이기 위해 footer를 태그 뒤에 붙일 수 있다. 오디오 데이터 뒤에 위치한 태그처럼 덧붙여진 태그(appended tag)는 footer가 필요(REQUIRED)하다. footer는 identifier만 다른 헤더의 복사본이다.

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

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:

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:

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.

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):

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.

a - Tag alter preservation

b - File alter preservation

c - Read only

h - Grouping identity

k - Compression

m - Encryption
n - Unsynchronisation

p - Data length indicator

ID3v2 태그의 기본 위치는 오디오 앞이여서 데이터를 읽을 때 연주기에게 도움이 된다. 하지만 오디오 뒤에 넣거나, 앞뒤 모두 넣는 것도 가능하다. 태그 새로 넣는 것을 결정할때, 아래 순서대로 고려해야(SHOULD) 한다.

1. 태그를 앞에.
   
   
2. 중요한 정보앞에 태그를 넣고, 두번째 태그를 파일끝의 모든 종류의 다른 태그 앞에 넣는다. 첫 태그에는 SEEK 프래임이 있어야 한다.
3. 태그를 파일끝의 모든 종류의 다른 태그 앞에 넣는다.

2,3번에서 다른 태그 없을 경우, 태그를 간단히 넣을 수 있다. ID3v2 태그를 찾는 추천 방법 :

1. Section 2.1를 참고하여 앞에 붙은 태그를 찼는다.
   
   
2. SEEK 프래임을 찾았다면, 그것을 찾는데 사용한다.
   
   
3. 태그 footer를 찾아, 파일 뒤에서 부터 검색한다.
   
   

확장 헤더안에 update 플래그가 존재하지 않는 이상, 새로운 버전의 태그가 발견될때 마다 이전 버전의 태그는 버려야한다.

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.

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:

and should be replaced with:

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.

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:

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.

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 ISO/IEC 13818-3:1995 'Generic coding of moving pictures and associated audio information, Part 3: Audio.' Technical committee / subcommittee: JTC 1 / SC 29 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.

Written by