· 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를 잘 몰라서 대충 다듬었습니다. 틈틈히 번역해야죠.

저작권은 읽어 봤는데 문제 없는거 같습니다.

관심있는 주제라 감히 손대보았습니다. --



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.0315 sec