The Network Information Center...
Because everything else just ends in .COM
Send Comments and Suggestions to:
hostmaster@alternic.org
Internet Engineering Task Force M. Nilsson
INTERNET DRAFT 1 December 2000
Document: draft-nilsson-id3-00.txt
Expires 1 June 2001
The MPEG audio meta data format ID3
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is an informational description of the not formally
standardized MPEG audio meta data format ID3.
1. Conventions in this document
This document does not use the keywords described in RFC 2119
[RFC 2119], since this is not the definition of the ID3 tag. Hence,
when this document states "recommended", it should be interpreted as
recommendation for increased compatibility.
2. History
The audio compression defined as layer I, layer II and layer III in
the MPEG-1 [MPEG-1] and MPEG-2 [MPEG-2] standards is a popular method
of compressing audio with a low quality loss. The MPEG data in itself
can only contain very little meta information, like if the audio is
copy protected or not.
To enable a richer experience and not having to rely on filenames to
identify performer and title of MPEG audio, Eric Kemp created the
tagging format ID3, presented with his program "Studio3" in 1996. By
adding a small chunk of extra data in the end of the file one could
get the MP3 file to carry information about the audio and not just
the audio itself. The placement of the tag, as the data was called,
was probably chosen as there were little chance that it should
disturb decoders.
3. Tag layout
The original ID3 tag, now also referred to as ID3v1, layout is the
following:
3 bytes Identifier
30 bytes Songname
30 bytes Artist
30 bytes Album
4 bytes Year
30 bytes Comment
1 byte Genre
A later modification to ID3v1 made by Michael Mutschler, sometimes
also called ID3v1.1, has the following layout:
3 bytes Identifier
30 bytes Songname
30 bytes Artist
30 bytes Album
4 bytes Year
28 bytes Comment
1 byte Null
1 byte Track number
1 byte Genre
Both ID3v1 and ID3v1.1 adds up to 128 bytes. If the content of a field
is of lesser size than the field size, e.g. 30 characters, it should
be null terminated.
For the text fields, songname, artist, album and comment, different
programs uses different character encodings, where the most used and
recommended encoding is ISO-8859-1 [ISO-8859-1], but one should not be
surprised if one encounters a different character encoding.
3.1. Identifier
The ID3 tag identifier is the three byte string "TAG" encoded with
ISO-8859-1 [ISO-8859-1].
3.2. Songname
The name/title of the audio.
3.3. Artist
Presumably intended for the name of the performing artist, but also
often used for composer in cases like classical music and movie music.
3.4. Album
The album from which the audio originated. This is sometimes a URL
[URL] to an online music archive.
3.5. Year
This is a numeric string which presumably should be used for the year
the audio was first released. Other existing uses are composition
year, recording year and re-release year. The original release year
is the recommended use. The numbers should always be encoded with
ISO-8859-1 [ISO-8859-1].
3.6. Comment
This field has given a lot of different uses, although seldom for
actual comments since its size limitation to 30 characters. In ID3v1.1
it is even more limited with a maximum text length of 28 characters,
but according to Michael Mutschler that is not a problem since it was
too limited from the beginning. Examples of uses for the comment filed
includes CRC of the original PCM audio as well as URL [URL] to a
relevant web page.
3.7. Null
In ID3v1.1 this byte is required to have the binary value zero (0x00).
3.8. Track number
In ID3v1.1 this byte indicate the track number that the song had on
the album it came from. The track number is a binary value between 1
and 255 (0x01 - 0xFF). In such cases where the 29:th byte is not null
or when the 30:th byte is null, the track number is to be considered
undefined. It is recommended that this value never is set to 255
(0xFF). See the security considerations for details.
3.9. Genre
The genre is a one byte value referring to an item in a predefined
list of genres.
4. Genres
While ID3 makes no claims to have a complete solution for genre
taxonomy it provides a list that includes all major western genres as
well as several convenient non-genres (oldies, vocal and instrumental
to name a few). Some programs have added more genres above the value
79 that are not supported by all ID3 software, and hence not
recommended.
0. Blues
1. Classic Rock
2. Country
3. Dance
4. Disco
5. Funk
6. Grunge
7. Hip-Hop
8. Jazz
9. Metal
10. New Age
11. Oldies
12. Other
13. Pop
14. R&B
15. Rap
16. Reggae
17. Rock
18. Techno
19. Industrial
20. Alternative
21. Ska
22. Death Metal
23. Pranks
24. Soundtrack
25. Euro-Techno
26. Ambient
27. Trip-Hop
28. Vocal
29. Jazz+Funk
30. Fusion
31. Trance
32. Classical
33. Instrumental
34. Acid
35. House
36. Game
37. Sound Clip
38. Gospel
39. Noise
40. AlternRock
41. Bass
42. Soul
43. Punk
44. Space
45. Meditative
46. Instrumental Pop
47. Instrumental Rock
48. Ethnic
49. Gothic
50. Darkwave
51. Techno-Industrial
52. Electronic
53. Pop-Folk
54. Eurodance
55. Dream
56. Southern Rock
57. Comedy
58. Cult
59. Gangsta
60. Top 40
61. Christian Rap
62. Pop/Funk
63. Jungle
64. Native American
65. Cabaret
66. New Wave
67. Psychadelic
68. Rave
69. Showtunes
70. Trailer
71. Lo-Fi
72. Tribal
73. Acid Punk
74. Acid Jazz
75. Polka
76. Retro
77. Musical
78. Rock & Roll
79. Hard Rock
5. Security considerations
Since no formal standardization of ID3v1 exists all applications must
be very fault tolerant and not expect a tag to be "well formed".
Another factor to consider is that the ID3 tag is appended to the MPEG
file and thus represents an unknown binary block for an ID3 unaware
MPEG player. The problem is greatly reduced by the fact that an ID3
block is smaller than an MPEG block, but the risk can be further
reduced. By ensuring that the tag does not include a byte with all
bits set (0xFF) there will be no possibility that the player will find
a MPEG header by mistake, since a MPEG block begins with one and a
half byte of set bits. The year and genre field is already restricted
so that they can not be 0xFF. By disallowing the character represented
by 0xFF and disallowing the track number to be greater than 254 there
is no possibility for a false synchronization in the tag.
6. References
[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
[MPEG-1]
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
[MPEG-2]
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)
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[URL] T. Berners-Lee, L. Masinter & M. McCahill, 'Uniform Resource
Locators (URL)', RFC 1738, December 1994.
7. Authors Address
Martin Nilsson
Rydsv„gen 246 C. 30
S-584 34 Link÷ping
Sweden
Email: nilsson@id3.org
8. Full Copyright Statement
Copyright (C) The Internet Society (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 implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE 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."