mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-09 05:38:58 +00:00
1942 lines
73 KiB
Text
1942 lines
73 KiB
Text
* id3v2.3.0
|
|
|
|
Informal Standard
|
|
Document: id3v2.3
|
|
M. Nilsson
|
|
3rd February 1999
|
|
|
|
|
|
1. ID3 tag version 2.3.0
|
|
|
|
|
|
1.1. Status of this document
|
|
|
|
This document is an informal standard and replaces the id3v2.2.0 standard. The
|
|
informal standard is released so that implementors could have a set standard
|
|
before a formal standard is set. The formal standard will use another version
|
|
or revision number if not identical to what is described in this document. The
|
|
contents in this document may change for clarifications but never for added or
|
|
altered functionallity.
|
|
Distribution of this document is unlimited.
|
|
|
|
1.2. Abstract
|
|
|
|
This document describes the ID3v2.3.0 standard, which is a more developed
|
|
version of the ID3v2 informal standard (version [:id3v2-00: 2.2.0]), evolved
|
|
from the ID3 tagging system. The ID3v2 offers a flexible way of storing
|
|
information about an audio file within itself to determine its origin and
|
|
contents. The information may be technical information, such as equalisation
|
|
curves, as well as related meta information, such as title, performer,
|
|
copyright etc.
|
|
Contents
|
|
|
|
1. ID3_tag_version_2.3.0
|
|
|
|
1. Status_of_this_document
|
|
2. Abstract
|
|
|
|
2. Conventions_in_this_document
|
|
3. ID3v2_overview
|
|
|
|
1. ID3v2_header
|
|
2. ID3v2_extended_header
|
|
3. ID3v2_frame_overview
|
|
|
|
1. Frame_header_flags
|
|
|
|
4. Default_flags
|
|
|
|
4. Declared_ID3v2_frames
|
|
|
|
1. Unique_file_identifier
|
|
2. Text_information_frames
|
|
|
|
1. Text_information_frames_-_details
|
|
2. User_defined_text_information_frame
|
|
|
|
3. URL_link_frames
|
|
|
|
1. URL_link_frames_-_details
|
|
2. User_defined_URL_link_frame
|
|
|
|
4. Involved_people_list
|
|
5. Music_CD_identifier
|
|
6. Event_timing_codes
|
|
7. MPEG_location_lookup_table
|
|
8. Synchronised_tempo_codes
|
|
9. Unsychronised_lyrics/text_transcription
|
|
10. Synchronised_lyrics/text
|
|
11. Comments
|
|
12. Relative_volume_adjustment
|
|
13. Equalisation
|
|
14. Reverb
|
|
15. Attached_picture
|
|
16. General_encapsulated_object
|
|
17. Play_counter
|
|
18. Popularimeter
|
|
19. Recommended_buffer_size
|
|
20. Audio_encryption
|
|
21. Linked_information
|
|
22. Position_synchronisation_frame
|
|
23. Terms_of_use_frame
|
|
24. Ownership_frame
|
|
25. Commercial_frame
|
|
26. Encryption_method_registration
|
|
27. Group_identification_registration
|
|
28. Private_frame
|
|
|
|
5. The_unsynchronisation_scheme
|
|
6. Copyright
|
|
7. References
|
|
8. Appendix
|
|
|
|
1. Appendix_A_-_Genre_List_from_ID3v1
|
|
|
|
9. Author's_Address
|
|
|
|
|
|
|
|
2. Conventions in this document
|
|
|
|
In the examples, text within "" is a text string exactly as it appears in a
|
|
file. Numbers preceded with $ are hexadecimal and numbers preceded with % are
|
|
binary. $xx is used to indicate a byte with unknown content. %x is used to
|
|
indicate a bit with unknown content. The most significant bit (MSB) of a byte
|
|
is called 'bit 7' and the least significant bit (LSB) is called 'bit 0'.
|
|
A tag is the whole tag described in this document. A frame is a block of
|
|
information in the tag. The tag consists of a header, frames and 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 0-9 only.
|
|
|
|
|
|
3. ID3v2 overview
|
|
|
|
The two biggest design goals were to be able to implement ID3v2 without
|
|
disturbing old software too much and that ID3v2 should be as flexible and
|
|
expandable as possible.
|
|
The first criterion is met by the simple fact that the MPEG decoding software
|
|
uses a syncsignal, embedded in the audiostream, to 'lock on to' the audio.
|
|
Since the ID3v2 tag doesn't contain a valid syncsignal, no software will
|
|
attempt to play the tag. If, for any reason, coincidence make a syncsignal
|
|
appear within the tag it will be taken care of by the 'unsynchronisation
|
|
scheme' described in section_5.
|
|
The second criterion has made a more noticeable impact on the design of the
|
|
ID3v2 tag. It is constructed as a container for several information blocks,
|
|
called frames, whose format need not be known to the software that encounters
|
|
them. At the start of every frame there is an identifier that explains the
|
|
frames' format and content, and a size descriptor that allows software to skip
|
|
unknown frames.
|
|
If a total revision of the ID3v2 tag should be needed, there is a version
|
|
number and a size descriptor in the ID3v2 header.
|
|
The ID3 tag described in this document is mainly targeted at files encoded with
|
|
MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III and MPEG-2.5, but may
|
|
work with other types of encoded audio.
|
|
The bitorder in ID3v2 is most significant bit first (MSB). The byteorder in
|
|
multibyte numbers is most significant byte first (e.g. $12345678 would be
|
|
encoded $12 34 56 78).
|
|
It is permitted to include padding after all the final frame (at the end of the
|
|
ID3 tag), making the size of all the frames together smaller than the size
|
|
given in the head of the tag. A possible purpose of this padding is to allow
|
|
for adding a few additional frames or enlarge existing frames within the tag
|
|
without having to rewrite the entire file. The value of the padding bytes must
|
|
be $00.
|
|
|
|
3.1. ID3v2 header
|
|
|
|
The ID3v2 tag header, which should be the first information in the file, is 10
|
|
bytes as follows:
|
|
|
|
ID3v2/file identifier "ID3"
|
|
ID3v2 version $03 00
|
|
ID3v2 flags %abc00000
|
|
ID3v2 size 4 * %0xxxxxxx
|
|
|
|
The first three bytes of the tag are always "ID3" to indicate that this is an
|
|
ID3v2 tag, directly followed by the two version bytes. The first byte of ID3v2
|
|
version is it's major version, while the second byte is its revision number. In
|
|
this case this is ID3v2.3.0. All revisions are backwards compatible while major
|
|
versions are not. If software with ID3v2.2.0 and below support should encounter
|
|
version three or higher it should simply ignore the whole tag. Version and
|
|
revision will never be $FF.
|
|
The version is followed by one the ID3v2 flags field, of which currently only
|
|
three flags are used.
|
|
|
|
|
|
a - Unsynchronisation
|
|
Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is
|
|
used (see section_5 for details); a set bit indicates usage.
|
|
|
|
b - Extended header
|
|
The second bit (bit 6) indicates whether or not the header is followed by
|
|
an extended header. The extended header is described in section_3.2.
|
|
|
|
c - Experimental indicator
|
|
The third bit (bit 5) should be used as an 'experimental indicator'. This
|
|
flag should always be set when the tag is in an experimental stage.
|
|
|
|
All the other flags should be cleared. If one of these undefined flags are set
|
|
that might mean that the tag is not readable for a parser that does not know
|
|
the flags function.
|
|
The ID3v2 tag size is encoded with four bytes where the most significant bit
|
|
(bit 7) is set to zero in every byte, making a total of 28 bits. The zeroed
|
|
bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01.
|
|
The ID3v2 tag size is the size of the complete tag after unsychronisation,
|
|
including padding, excluding the header but not excluding the extended header
|
|
(total tag size - 10). Only 28 bits (representing up to 256MB) are used in the
|
|
size description to avoid the introduction of 'false syncsignals'.
|
|
An ID3v2 tag can be detected with the following pattern:
|
|
|
|
$49 44 33 yy yy xx zz zz zz zz
|
|
|
|
Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80.
|
|
|
|
3.2. ID3v2 extended header
|
|
|
|
The extended header contains information that is not vital to the correct
|
|
parsing of the tag information, hence the extended header is optional.
|
|
|
|
Extended header size $xx xx xx xx
|
|
Extended Flags $xx xx
|
|
Size of padding $xx xx xx xx
|
|
|
|
Where the 'Extended header size', currently 6 or 10 bytes, excludes itself. The
|
|
'Size of padding' is simply the total tag size excluding the frames and the
|
|
headers, in other words the padding. The extended header is considered separate
|
|
from the header proper, and as such is subject to unsynchronisation.
|
|
The extended flags are a secondary flag set which describes further attributes
|
|
of the tag. These attributes are currently defined as follows
|
|
|
|
%x0000000 00000000
|
|
|
|
|
|
|
|
x - CRC data present
|
|
If this flag is set four bytes of CRC-32 data is appended to the extended
|
|
header. The CRC should be calculated before unsynchronisation on the data
|
|
between the extended header and the padding, i.e. the frames and only the
|
|
frames.
|
|
|
|
Total frame CRC $xx xx xx xx
|
|
|
|
|
|
|
|
3.3. ID3v2 frame overview
|
|
|
|
As the tag consists of a tag header and a tag body with one or more frames, all
|
|
the frames consists of a frame header followed by one or more fields containing
|
|
the actual information. The layout of the frame header:
|
|
|
|
Frame ID $xx xx xx xx (four characters)
|
|
Size $xx xx xx xx
|
|
Flags $xx xx
|
|
|
|
The frame ID made out of the characters capital A-Z and 0-9. Identifiers
|
|
beginning with "X", "Y" and "Z" are for experimental use and free for everyone
|
|
to use, without the need to set the experimental bit in the tag header. Have 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, making a total header size of
|
|
ten bytes in every frame. The size is calculated as frame size excluding frame
|
|
header (frame size - 10).
|
|
In the frame header the size descriptor is followed by two flags bytes. These
|
|
flags are described in section_3.3.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 a string is represented as ISO-8859-1 characters in the
|
|
range $20 - $FF. Such strings are represented as <text string>, or <full text
|
|
string> if newlines are allowed, in the frame descriptions. All Unicode strings
|
|
use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must
|
|
begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order.
|
|
All numeric strings and URLs are always encoded as ISO-8859-1. Terminated
|
|
strings are terminated with $00 if encoded with ISO-8859-1 and $00 00 if
|
|
encoded as unicode. If nothing else is said newline character is forbidden. In
|
|
ISO-8859-1 a new line is represented, when allowed, with $0A only. Frames that
|
|
allow different types of text encoding have a text encoding description byte
|
|
directly after the frame size. If ISO-8859-1 is used this byte should be $00,
|
|
if Unicode is used it should be $01. Strings dependent on encoding is
|
|
represented as <text string according to encoding>, or <full text string
|
|
according to encoding> if newlines are allowed. Any empty Unicode strings which
|
|
are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE
|
|
00 00 or $FE FF 00 00).
|
|
The three byte language field is used to describe the language of the frame's
|
|
content, according to ISO-639-2.
|
|
All URLs 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.3.1. Frame header flags
|
|
|
|
In the frame header the size descriptor is followed by two flags bytes. All
|
|
unused flags must be cleared. The first byte is for 'status messages' and the
|
|
second byte is for encoding purposes. If an unknown flag is set in the first
|
|
byte the frame may not be changed without the bit cleared. If an unknown flag
|
|
is set in the second byte it is likely to not be readable. The flags field is
|
|
defined as follows.
|
|
|
|
%abc00000 %ijk00000
|
|
|
|
|
|
|
|
a - Tag alter preservation
|
|
This flag tells the software 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 software 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 is
|
|
intended to be read only. Changing the contents might break something,
|
|
e.g. a signature. If the contents are changed, without knowledge in why
|
|
the frame was flagged read only and without taking the proper means to
|
|
compensate, e.g. recalculating the signature, the bit should be cleared.
|
|
|
|
i - Compression
|
|
This flag indicates whether or not the frame is compressed.
|
|
|
|
0 Frame is not compressed.
|
|
1 Frame is compressed using [#ZLIB zlib] with 4 bytes for
|
|
'decompressed size' appended to the frame header.
|
|
|
|
|
|
j - Encryption
|
|
This flag indicates wether or not the frame is enrypted. If set one byte
|
|
indicating with which method it was encrypted will be appended to the
|
|
frame header. See section_4.26. for more information about encryption
|
|
method registration.
|
|
|
|
0 Frame is not encrypted.
|
|
1 Frame is encrypted.
|
|
|
|
|
|
k - 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
|
|
header. Every frame with the same group identifier belongs to the same
|
|
group.
|
|
|
|
0 Frame does not contain group information
|
|
1 Frame contains group information
|
|
|
|
|
|
Some flags indicates that the frame header is extended with additional
|
|
information. This information will be added to the frame header in the same
|
|
order as the flags indicating the additions. I.e. the four bytes of
|
|
decompressed size will preceed the encryption method byte. These additions to
|
|
the frame header, while not included in the frame header size but are included
|
|
in the 'frame size' field, are not subject to encryption or compression.
|
|
|
|
3.4. Default flags
|
|
|
|
The default settings for the frames described in this document can be divided
|
|
into the following classes. The flags may be set differently if found more
|
|
suitable by the software.
|
|
|
|
1. Discarded if tag is altered, discarded if file is altered.
|
|
|
|
o None.
|
|
|
|
2. Discarded if tag is altered, preserved if file is altered.
|
|
|
|
o None.
|
|
|
|
3. Preserved if tag is altered, discarded if file is altered.
|
|
|
|
o AENC, ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ
|
|
|
|
4. Preserved if tag is altered, preserved if file is altered.
|
|
|
|
o The rest of the frames.
|
|
|
|
|
|
|
|
|
|
4. Declared ID3v2 frames
|
|
|
|
The following frames are declared in this draft.
|
|
|
|
4.20 AENC [#sec4.20 Audio encryption]
|
|
4.15 APIC [#sec4.15 Attached picture]
|
|
4.11 COMM [#sec4.11 Comments]
|
|
4.25 COMR [#sec4.25 Commercial frame]
|
|
4.26 ENCR [#sec4.26 Encryption method registration]
|
|
4.13 EQUA [#sec4.13 Equalization]
|
|
4.6 ETCO [#sec4.6 Event timing codes]
|
|
4.16 GEOB [#sec4.16 General encapsulated object]
|
|
4.27 GRID [#sec4.27 Group identification registration]
|
|
4.4 IPLS [#sec4.4 Involved people list]
|
|
4.21 LINK [#sec4.21 Linked information]
|
|
4.5 MCDI [#sec4.5 Music CD identifier]
|
|
4.7 MLLT [#sec4.7 MPEG location lookup table]
|
|
4.24 OWNE [#sec4.24 Ownership frame]
|
|
4.28 PRIV [#sec4.28 Private frame]
|
|
4.17 PCNT [#sec4.17 Play counter]
|
|
4.18 POPM [#sec4.18 Popularimeter]
|
|
4.22 POSS [#sec4.22 Position synchronisation frame]
|
|
4.19 RBUF [#sec4.19 Recommended buffer size]
|
|
4.12 RVAD [#sec4.12 Relative volume adjustment]
|
|
4.14 RVRB [#sec4.14 Reverb]
|
|
4.10 SYLT [#sec4.10 Synchronized lyric/text]
|
|
4.8 SYTC [#sec4.8 Synchronized tempo codes]
|
|
4.2.1 TALB [#TALB Album/Movie/Show title]
|
|
4.2.1 TBPM [#TBPM BPM (beats per minute)]
|
|
4.2.1 TCOM [#TCOM Composer]
|
|
4.2.1 TCON [#TCON Content type]
|
|
4.2.1 TCOP [#TCOP Copyright message]
|
|
4.2.1 TDAT [#TDAT Date]
|
|
4.2.1 TDLY [#TDLY Playlist delay]
|
|
4.2.1 TENC [#TENC Encoded by]
|
|
4.2.1 TEXT [#TEXT Lyricist/Text writer]
|
|
4.2.1 TFLT [#TFLT File type]
|
|
4.2.1 TIME [#TIME Time]
|
|
4.2.1 TIT1 [#TIT1 Content group description]
|
|
4.2.1 TIT2 [#TIT2 Title/songname/content description]
|
|
4.2.1 TIT3 [#TIT3 Subtitle/Description refinement]
|
|
4.2.1 TKEY [#TKEY Initial key]
|
|
4.2.1 TLAN [#TLAN Language(s)]
|
|
4.2.1 TLEN [#TLEN Length]
|
|
4.2.1 TMED [#TMED Media type]
|
|
4.2.1 TOAL [#TOAL Original album/movie/show title]
|
|
4.2.1 TOFN [#TOFN Original filename]
|
|
4.2.1 TOLY [#TOLY Original lyricist(s)/text writer(s)]
|
|
4.2.1 TOPE [#TOPE Original artist(s)/performer(s)]
|
|
4.2.1 TORY [#TORY Original release year]
|
|
4.2.1 TOWN [#TOWN File owner/licensee]
|
|
4.2.1 TPE1 [#TPE1 Lead performer(s)/Soloist(s)]
|
|
4.2.1 TPE2 [#TPE2 Band/orchestra/accompaniment]
|
|
4.2.1 TPE3 [#TPE3 Conductor/performer refinement]
|
|
4.2.1 TPE4 [#TPE4 Interpreted, remixed, or otherwise modified by]
|
|
4.2.1 TPOS [#TPOS Part of a set]
|
|
4.2.1 TPUB [#TPUB Publisher]
|
|
4.2.1 TRCK [#TRCK Track number/Position in set]
|
|
4.2.1 TRDA [#TRDA Recording dates]
|
|
4.2.1 TRSN [#TRSN Internet radio station name]
|
|
4.2.1 TRSO [#TRSO Internet radio station owner]
|
|
4.2.1 TSIZ [#TSIZ Size]
|
|
4.2.1 TSRC [#TSRC ISRC (international standard recording code)]
|
|
4.2.1 TSSE [#TSEE Software/Hardware and settings used for encoding]
|
|
4.2.1 TYER [#TYER Year]
|
|
4.2.2 TXXX [#TXXX User defined text information frame]
|
|
4.1 UFID [#sec4.1 Unique file identifier]
|
|
4.23 USER [#sec4.23 Terms of use]
|
|
4.9 USLT [#sec4.9 Unsychronized lyric/text transcription]
|
|
4.3.1 WCOM [#WCOM Commercial information]
|
|
4.3.1 WCOP [#WCOP Copyright/Legal information]
|
|
4.3.1 WOAF [#WOAF Official audio file webpage]
|
|
4.3.1 WOAR [#WOAR Official artist/performer webpage]
|
|
4.3.1 WOAS [#WOAS Official audio source webpage]
|
|
4.3.1 WORS [#WORS Official internet radio station homepage]
|
|
4.3.1 WPAY [#WPAY Payment]
|
|
4.3.1 WPUB [#WPUB Publishers official webpage]
|
|
4.3.2 WXXX [#WXXX User defined URL link frame]
|
|
|
|
|
|
4.1. Unique file identifier
|
|
|
|
This frame's purpose is to be able to identify the audio file in a database
|
|
that may contain more information relevant to the content. Since
|
|
standardisation of such a database is beyond this document, all frames begin
|
|
with a null-terminated string with a URL containing an email address, or a link
|
|
to a location where an email address can be found, that belongs to the
|
|
organisation responsible for this specific database implementation. Questions
|
|
regarding the database should be sent to the indicated email address. The URL
|
|
should not be used for the actual database queries. The string "http://
|
|
www.id3.org/dummy/ufid.html" should be used for tests. Software that isn't told
|
|
otherwise may safely remove such frames. The 'Owner identifier' must be non-
|
|
empty (more than just a termination). The 'Owner identifier' is then followed
|
|
by the actual identifier, which may be up to 64 bytes. There may be more than
|
|
one "UFID" frame in a tag, but only one with the same 'Owner identifier'.
|
|
|
|
<Header for 'Unique file identifier', ID: "UFID">
|
|
Owner identifier <text string> $00
|
|
Identifier <up to 64 bytes binary data>
|
|
|
|
|
|
4.2. Text information frames
|
|
|
|
The text information frames are the most important frames, containing
|
|
information like artist, album and more. There may only be one text information
|
|
frame of its kind in an tag. If the textstring is followed by a termination
|
|
($00 (00)) all the following information should be ignored and not be
|
|
displayed. All text frame identifiers begin with "T". Only text frame
|
|
identifiers begin with "T", with the exception of the "TXXX" frame. All the
|
|
text information frames have the following format:
|
|
|
|
<Header for 'Text information frame', ID: "T000" - "TZZZ", excluding "TXXX"
|
|
described in 4.2.2.>
|
|
Text encoding $xx
|
|
Information <text string according to encoding>
|
|
|
|
|
|
4.2.1. Text information frames - details
|
|
|
|
|
|
|
|
TALB
|
|
The 'Album/Movie/Show title' frame is intended for the title of the
|
|
recording(/source of sound) which the audio in the file is taken from.
|
|
|
|
|
|
|
|
TBPM
|
|
The 'BPM' frame contains the number of beats per minute in the mainpart
|
|
of the audio. The BPM is an integer and represented as a numerical
|
|
string.
|
|
|
|
|
|
|
|
TCOM
|
|
The 'Composer(s)' frame is intended for the name of the composer(s). They
|
|
are seperated with the "/" character.
|
|
|
|
|
|
|
|
TCON
|
|
The 'Content type', which previously was stored as a one byte numeric
|
|
value only, is now a numeric string. You may use one or several of the
|
|
types as ID3v1.1 did or, since the category list would be impossible to
|
|
maintain with accurate and up to date categories, define your own.
|
|
|
|
References to the ID3v1 genres can be made by, as first byte, enter "("
|
|
followed by a number from the genres list (appendix A) and ended with a
|
|
")" character. This is optionally followed by a refinement, e.g. "(21)"
|
|
or "(4)Eurodisco". Several references can be made in the same frame, e.g.
|
|
"(51)(39)". If the refinement should begin with a "(" character it should
|
|
be replaced with "((", e.g. "((I can figure out any genre)" or "(55)((I
|
|
think...)". The following new content types is defined in ID3v2 and is
|
|
implemented in the same way as the numerig content types, e.g. "(RX)".
|
|
|
|
RX Remix
|
|
CR Cover
|
|
|
|
|
|
|
|
|
|
TCOP
|
|
The 'Copyright message' frame, which must begin with a year and a space
|
|
character (making five characters), is intended for the copyright holder
|
|
of the original sound, not the audio file itself. The absence of this
|
|
frame means only that the copyright information is unavailable or has
|
|
been removed, and must not be interpreted to mean that the sound is
|
|
public domain. Every time this field is displayed the field must be
|
|
preceded with "Copyright © ".
|
|
|
|
|
|
|
|
TDAT
|
|
The 'Date' frame is a numeric string in the DDMM format containing the
|
|
date for the recording. This field is always four characters long.
|
|
|
|
|
|
|
|
TDLY
|
|
The 'Playlist delay' defines the numbers of milliseconds of silence
|
|
between every song in a playlist. The player should use the "ETC" frame,
|
|
if present, to skip initial silence and silence at the end of the audio
|
|
to match the 'Playlist delay' time. The time is represented as a numeric
|
|
string.
|
|
|
|
|
|
|
|
TENC
|
|
The 'Encoded by' frame contains the name of the person or organisation
|
|
that encoded the audio file. This field may contain a copyright message,
|
|
if the audio file also is copyrighted by the encoder.
|
|
|
|
|
|
|
|
TEXT
|
|
The 'Lyricist(s)/Text writer(s)' frame is intended for the writer(s) of
|
|
the text or lyrics in the recording. They are seperated with the "/
|
|
" character.
|
|
|
|
|
|
|
|
TFLT
|
|
The 'File type' frame indicates which type of audio this tag defines. The
|
|
following type and refinements are defined:
|
|
|
|
MPG MPEG Audio
|
|
/1 MPEG 1/2 layer I
|
|
/2 MPEG 1/2 layer II
|
|
/3 MPEG 1/2 layer III
|
|
/2.5 MPEG 2.5
|
|
/AAC Advanced audio compression
|
|
VQF Transform-domain Weighted Interleave Vector Quantization
|
|
PCM Pulse Code Modulated audio
|
|
|
|
|
|
but other types may be used, not for these types though. This is used in a
|
|
similar way to the predefined types in the "TMED" frame, but without
|
|
parentheses. If this frame is not present audio type is assumed to be "MPG".
|
|
|
|
|
|
TIME
|
|
The 'Time' frame is a numeric string in the HHMM format containing the
|
|
time for the recording. This field is always four characters long.
|
|
|
|
|
|
|
|
TIT1
|
|
The 'Content group description' frame is used if the sound belongs to a
|
|
larger category of sounds/music. For example, classical music is often
|
|
sorted in different musical sections (e.g. "Piano Concerto", "Weather -
|
|
Hurricane").
|
|
|
|
|
|
|
|
TIT2
|
|
The 'Title/Songname/Content description' frame is the actual name of the
|
|
piece (e.g. "Adagio", "Hurricane Donna").
|
|
|
|
|
|
|
|
TIT3
|
|
The 'Subtitle/Description refinement' frame is used for information
|
|
directly related to the contents title (e.g. "Op. 16" or "Performed live
|
|
at Wembley").
|
|
|
|
|
|
|
|
TKEY
|
|
The 'Initial key' frame contains the musical key in which the sound
|
|
starts. It is represented as a string with a maximum length of three
|
|
characters. The ground keys are represented with "A","B","C","D","E", "F"
|
|
and "G" and halfkeys represented with "b" and "#". Minor is represented
|
|
as "m". Example "Cbm". Off key is represented with an "o" only.
|
|
|
|
|
|
|
|
TLAN
|
|
The 'Language(s)' frame should contain the languages of the text or
|
|
lyrics spoken or sung in the audio. The language is represented with
|
|
three characters according to ISO-639-2. If more than one language is
|
|
used in the text their language codes should follow according to their
|
|
usage.
|
|
|
|
|
|
|
|
TLEN
|
|
The 'Length' frame contains the length of the audiofile in milliseconds,
|
|
represented as a numeric string.
|
|
|
|
|
|
|
|
TMED
|
|
The 'Media type' frame describes from which media the sound originated.
|
|
This may be a text string or a reference to the predefined media types
|
|
found in the list below. References are made within "(" and ")" and are
|
|
optionally followed by a text refinement, e.g. "(MC) with four channels".
|
|
If a text refinement should begin with a "(" character it should be
|
|
replaced with "((" in the same way as in the "TCO" frame. Predefined
|
|
refinements is appended after the media type, e.g. "(CD/A)" or "(VID/PAL/
|
|
VHS)".
|
|
|
|
DIG Other digital media
|
|
/A Analog transfer from media
|
|
|
|
ANA Other analog media
|
|
/WAC Wax cylinder
|
|
/8CA 8-track tape cassette
|
|
|
|
CD CD
|
|
/A Analog transfer from media
|
|
/DD DDD
|
|
/AD ADD
|
|
/AA AAD
|
|
|
|
LD Laserdisc
|
|
/A Analog transfer from media
|
|
|
|
TT Turntable records
|
|
/33 33.33 rpm
|
|
/45 45 rpm
|
|
/71 71.29 rpm
|
|
/76 76.59 rpm
|
|
/78 78.26 rpm
|
|
/80 80 rpm
|
|
|
|
MD MiniDisc
|
|
/A Analog transfer from media
|
|
|
|
DAT DAT
|
|
/A Analog transfer from media
|
|
/1 standard, 48 kHz/16 bits, linear
|
|
/2 mode 2, 32 kHz/16 bits, linear
|
|
/3 mode 3, 32 kHz/12 bits, nonlinear, low speed
|
|
/4 mode 4, 32 kHz/12 bits, 4 channels
|
|
/5 mode 5, 44.1 kHz/16 bits, linear
|
|
/6 mode 6, 44.1 kHz/16 bits, 'wide track' play
|
|
|
|
DCC DCC
|
|
/A Analog transfer from media
|
|
|
|
DVD DVD
|
|
/A Analog transfer from media
|
|
|
|
TV Television
|
|
/PAL PAL
|
|
/NTSC NTSC
|
|
/SECAM SECAM
|
|
|
|
VID Video
|
|
/PAL PAL
|
|
/NTSC NTSC
|
|
/SECAM SECAM
|
|
/VHS VHS
|
|
/SVHS S-VHS
|
|
/BETA BETAMAX
|
|
|
|
RAD Radio
|
|
/FM FM
|
|
/AM AM
|
|
/LW LW
|
|
/MW MW
|
|
|
|
TEL Telephone
|
|
/I ISDN
|
|
|
|
MC MC (normal cassette)
|
|
/4 4.75 cm/s (normal speed for a two sided cassette)
|
|
/9 9.5 cm/s
|
|
/I Type I cassette (ferric/normal)
|
|
/II Type II cassette (chrome)
|
|
/III Type III cassette (ferric chrome)
|
|
/IV Type IV cassette (metal)
|
|
|
|
REE Reel
|
|
/9 9.5 cm/s
|
|
/19 19 cm/s
|
|
/38 38 cm/s
|
|
/76 76 cm/s
|
|
/I Type I cassette (ferric/normal)
|
|
/II Type II cassette (chrome)
|
|
/III Type III cassette (ferric chrome)
|
|
/IV Type IV cassette (metal)
|
|
|
|
|
|
|
|
|
|
TOAL
|
|
The 'Original album/movie/show title' frame is intended for the title of
|
|
the original recording (or source of sound), if for example the music in
|
|
the file should be a cover of a previously released song.
|
|
|
|
|
|
|
|
TOFN
|
|
The 'Original filename' frame contains the preferred filename for the
|
|
file, since some media doesn't allow the desired length of the filename.
|
|
The filename is case sensitive and includes its suffix.
|
|
|
|
|
|
|
|
TOLY
|
|
The 'Original lyricist(s)/text writer(s)' frame is intended for the text
|
|
writer(s) of the original recording, if for example the music in the file
|
|
should be a cover of a previously released song. The text writers are
|
|
seperated with the "/" character.
|
|
|
|
|
|
|
|
TOPE
|
|
The 'Original artist(s)/performer(s)' frame is intended for the performer
|
|
(s) of the original recording, if for example the music in the file
|
|
should be a cover of a previously released song. The performers are
|
|
seperated with the "/" character.
|
|
|
|
|
|
|
|
TORY
|
|
The 'Original release year' frame is intended for the year when the
|
|
original recording, if for example the music in the file should be a
|
|
cover of a previously released song, was released. The field is formatted
|
|
as in the "TYER" frame.
|
|
|
|
|
|
|
|
TOWN
|
|
The 'File owner/licensee' frame contains the name of the owner or
|
|
licensee of the file and it's contents.
|
|
|
|
|
|
|
|
TPE1
|
|
The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is
|
|
used for the main artist(s). They are seperated with the "/" character.
|
|
|
|
|
|
|
|
TPE2
|
|
The 'Band/Orchestra/Accompaniment' frame is used for additional
|
|
information about the performers in the recording.
|
|
|
|
|
|
|
|
TPE3
|
|
The 'Conductor' frame is used for the name of the conductor.
|
|
|
|
|
|
|
|
TPE4
|
|
The 'Interpreted, remixed, or otherwise modified by' frame contains more
|
|
information about the people behind a remix and similar interpretations
|
|
of another existing piece.
|
|
|
|
|
|
|
|
TPOS
|
|
The 'Part of a set' frame is a numeric string that describes which part
|
|
of a set the audio came from. This frame is used if the source described
|
|
in the "TALB" frame is divided into several mediums, e.g. a double CD.
|
|
The value may be extended with a "/" character and a numeric string
|
|
containing the total number of parts in the set. E.g. "1/2".
|
|
|
|
|
|
|
|
TPUB
|
|
The 'Publisher' frame simply contains the name of the label or publisher.
|
|
|
|
|
|
|
|
TRCK
|
|
The 'Track number/Position in set' frame is a numeric string containing
|
|
the order number of the audio-file on its original recording. This may be
|
|
extended with a "/" character and a numeric string containing the total
|
|
numer of tracks/elements on the original recording. E.g. "4/9".
|
|
|
|
|
|
|
|
TRDA
|
|
The 'Recording dates' frame is a intended to be used as complement to the
|
|
"TYER", "TDAT" and "TIME" frames. E.g. "4th-7th June, 12th June" in
|
|
combination with the "TYER" frame.
|
|
|
|
|
|
|
|
TRSN
|
|
The 'Internet radio station name' frame contains the name of the internet
|
|
radio station from which the audio is streamed.
|
|
|
|
|
|
|
|
TRSO
|
|
The 'Internet radio station owner' frame contains the name of the owner
|
|
of the internet radio station from which the audio is streamed.
|
|
|
|
|
|
|
|
TSIZ
|
|
The 'Size' frame contains the size of the audiofile in bytes, excluding
|
|
the ID3v2 tag, represented as a numeric string.
|
|
|
|
|
|
|
|
TSRC
|
|
The 'ISRC' frame should contain the International Standard Recording Code
|
|
(ISRC) (12 characters).
|
|
|
|
|
|
|
|
TSSE
|
|
The 'Software/Hardware and settings used for encoding' frame includes the
|
|
used audio encoder and its settings when the file was encoded. Hardware
|
|
refers to hardware encoders, not the computer on which a program was run.
|
|
|
|
|
|
|
|
TYER
|
|
The 'Year' frame is a numeric string with a year of the recording. This
|
|
frames is always four characters long (until the year 10000).
|
|
|
|
|
|
4.2.2. User defined text information frame
|
|
|
|
This frame is intended for one-string text information concerning the audiofile
|
|
in a similar way to the other "T"-frames. The frame body consists of a
|
|
description of the string, represented as a terminated string, followed by the
|
|
actual string. There may be more than one "TXXX" frame in each tag, but only
|
|
one with the same description.
|
|
|
|
<Header for 'User defined text information frame', ID: "TXXX">
|
|
Text encoding $xx
|
|
Description <text string according to encoding> $00 (00)
|
|
Value <text string according to encoding>
|
|
|
|
|
|
4.3. URL link frames
|
|
|
|
With these frames dynamic data such as webpages with touring information, price
|
|
information or plain ordinary news can be added to the tag. There may only be
|
|
one URL link frame of its kind in an tag, except when stated otherwise in the
|
|
frame description. If the textstring is followed by a termination ($00 (00))
|
|
all the following information should be ignored and not be displayed. All URL
|
|
link frame identifiers begins with "W". Only URL link frame identifiers begins
|
|
with "W". All URL link frames have the following format:
|
|
|
|
<Header for 'URL link frame', ID: "W000" - "WZZZ", excluding "WXXX" described
|
|
in 4.3.2.>
|
|
URL <text string>
|
|
|
|
|
|
4.3.1. URL link frames - details
|
|
|
|
|
|
|
|
WCOM
|
|
The 'Commercial information' frame is a URL pointing at a webpage with
|
|
information such as where the album can be bought. There may be more than
|
|
one "WCOM" frame in a tag, but not with the same content.
|
|
|
|
|
|
|
|
WCOP
|
|
The 'Copyright/Legal information' frame is a URL pointing at a webpage
|
|
where the terms of use and ownership of the file is described.
|
|
|
|
|
|
|
|
WOAF
|
|
The 'Official audio file webpage' frame is a URL pointing at a file
|
|
specific webpage.
|
|
|
|
|
|
|
|
WOAR
|
|
The 'Official artist/performer webpage' frame is a URL pointing at the
|
|
artists official webpage. There may be more than one "WOAR" frame in a
|
|
tag if the audio contains more than one performer, but not with the same
|
|
content.
|
|
|
|
|
|
|
|
WOAS
|
|
The 'Official audio source webpage' frame is a URL pointing at the
|
|
official webpage for the source of the audio file, e.g. a movie.
|
|
|
|
|
|
|
|
WORS
|
|
The 'Official internet radio station homepage' contains a URL pointing at
|
|
the homepage of the internet radio station.
|
|
|
|
|
|
|
|
WPAY
|
|
The 'Payment' frame is a URL pointing at a webpage that will handle the
|
|
process of paying for this file.
|
|
|
|
|
|
|
|
WPUB
|
|
The 'Publishers official webpage' frame is a URL pointing at the official
|
|
wepage for the publisher.
|
|
|
|
|
|
4.3.2. User defined URL link frame
|
|
|
|
This frame is intended for URL links concerning the audiofile in a similar way
|
|
to the other "W"-frames. The frame body consists of a description of the
|
|
string, represented as a terminated string, followed by the actual URL. The URL
|
|
is always encoded with ISO-8859-1. There may be more than one "WXXX" frame in
|
|
each tag, but only one with the same description.
|
|
|
|
<Header for 'User defined URL link frame', ID: "WXXX">
|
|
Text encoding $xx
|
|
Description <text string according to encoding> $00 (00)
|
|
URL <text string>
|
|
|
|
|
|
4.4. Involved people list
|
|
|
|
Since there might be a lot of people contributing to an audio file in various
|
|
ways, such as musicians and technicians, the 'Text information frames' are
|
|
often insufficient to list everyone involved in a project. The 'Involved people
|
|
list' is a frame containing the names of those involved, and how they were
|
|
involved. The body simply contains a terminated string with the involvement
|
|
directly followed by a terminated string with the involvee followed by a new
|
|
involvement and so on. There may only be one "IPLS" frame in each tag.
|
|
|
|
<Header for 'Involved people list', ID: "IPLS">
|
|
Text encoding $xx
|
|
People list strings <text strings according to encoding>
|
|
|
|
|
|
4.5. Music CD identifier
|
|
|
|
This frame is intended for music that comes from a CD, so that the CD can be
|
|
identified in databases such as the CDDB. The frame consists of a binary dump
|
|
of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and
|
|
then 8 bytes/track on the CD plus 8 bytes for the 'lead out' making a maximum
|
|
of 804 bytes. The offset to the beginning of every track on the CD should be
|
|
described with a four bytes absolute CD-frame address per track, and not with
|
|
absolute time. This frame requires a present and valid "TRCK" frame, even if
|
|
the CD's only got one track. There may only be one "MCDI" frame in each tag.
|
|
|
|
<Header for 'Music CD identifier', ID: "MCDI">
|
|
CD TOC <binary data>
|
|
|
|
|
|
4.6. Event timing codes
|
|
|
|
This frame allows synchronisation with key events in a song or sound. The
|
|
header is:
|
|
|
|
<Header for 'Event timing codes', ID: "ETCO">
|
|
Time stamp format $xx
|
|
|
|
Where time stamp format is:
|
|
|
|
$01 Absolute time, 32 bit sized, using MPEG frames as unit
|
|
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
|
|
Absolute time means that every stamp contains the time from the beginning of the
|
|
file.
|
|
Followed by a list of key events in the following format:
|
|
|
|
Type of event $xx
|
|
Time stamp $xx (xx ...)
|
|
|
|
The 'Time stamp' is set to zero if directly at the beginning of the sound or
|
|
after the previous event. All events should be sorted in chronological order.
|
|
The type of event is as follows:
|
|
|
|
$00 padding (has no meaning)
|
|
$01 end of initial silence
|
|
$02 intro start
|
|
$03 mainpart start
|
|
$04 outro start
|
|
$05 outro end
|
|
$06 verse start
|
|
$07 refrain start
|
|
$08 interlude start
|
|
$09 theme start
|
|
$0A variation start
|
|
$0B key change
|
|
$0C time change
|
|
$0D momentary unwanted noise (Snap, Crackle & Pop)
|
|
$0E sustained noise
|
|
$0F sustained noise end
|
|
$10 intro end
|
|
$11 mainpart end
|
|
$12 verse end
|
|
$13 refrain end
|
|
$14 theme end
|
|
$15-$DF reserved for future use
|
|
$E0-$EF not predefined sync 0-F
|
|
$F0-$FC reserved for future use
|
|
$FD audio end (start of silence)
|
|
$FE audio file ends
|
|
$FF one more byte of events follows (all the following bytes with the
|
|
value $FF have the same function)
|
|
|
|
Terminating the start events such as "intro start" is not required. The 'Not
|
|
predefined sync's ($E0-EF) are for user events. You might want to synchronise
|
|
your music to something, like setting of an explosion on-stage, turning on your
|
|
screensaver etc.
|
|
There may only be one "ETCO" frame in each tag.
|
|
|
|
4.7. MPEG location lookup table
|
|
|
|
To increase performance and accuracy of jumps within a MPEG audio file, frames
|
|
with timecodes in different locations in the file might be useful. The ID3v2
|
|
frame includes references that the software can use to calculate positions in
|
|
the file. After the frame header is a descriptor of how much the 'frame
|
|
counter' should increase for every reference. If this value is two then the
|
|
first reference points out the second frame, the 2nd reference the 4th frame,
|
|
the 3rd reference the 6th frame etc. In a similar way the 'bytes between
|
|
reference' and 'milliseconds between reference' points out bytes and
|
|
milliseconds respectively.
|
|
Each reference consists of two parts; a certain number of bits, as defined in
|
|
'bits for bytes deviation', that describes the difference between what is said
|
|
in 'bytes between reference' and the reality and a certain number of bits, as
|
|
defined in 'bits for milliseconds deviation', that describes the difference
|
|
between what is said in 'milliseconds between reference' and the reality. The
|
|
number of bits in every reference, i.e. 'bits for bytes deviation'+'bits for
|
|
milliseconds deviation', must be a multiple of four. There may only be one
|
|
"MLLT" frame in each tag.
|
|
|
|
<Header for 'Location lookup table', ID: "MLLT">
|
|
MPEG frames between reference $xx xx
|
|
Bytes between reference $xx xx xx
|
|
Milliseconds between reference $xx xx xx
|
|
Bits for bytes deviation $xx
|
|
Bits for milliseconds dev. $xx
|
|
|
|
Then for every reference the following data is included;
|
|
|
|
Deviation in bytes %xxx....
|
|
Deviation in milliseconds %xxx....
|
|
|
|
|
|
4.8. Synchronised tempo codes
|
|
|
|
For a more accurate description of the tempo of a musical piece this frame
|
|
might be used. After the header follows one byte describing which time stamp
|
|
format should be used. Then follows one or more tempo codes. Each tempo code
|
|
consists of one tempo part and one time part. The tempo is in BPM described
|
|
with one or two bytes. If the first byte has the value $FF, one more byte
|
|
follows, which is added to the first giving a range from 2 - 510 BPM, since $00
|
|
and $01 is reserved. $00 is used to describe a beat-free time period, which is
|
|
not the same as a music-free time period. $01 is used to indicate one single
|
|
beat-stroke followed by a beat-free period.
|
|
The tempo descriptor is followed by a time stamp. Every time the tempo in the
|
|
music changes, a tempo descriptor may indicate this for the player. All tempo
|
|
descriptors should be sorted in chronological order. The first beat-stroke in a
|
|
time-period is at the same time as the beat description occurs. There may only
|
|
be one "SYTC" frame in each tag.
|
|
|
|
<Header for 'Synchronised tempo codes', ID: "SYTC">
|
|
Time stamp format $xx
|
|
Tempo data <binary data>
|
|
|
|
Where time stamp format is:
|
|
|
|
$01 Absolute time, 32 bit sized, using MPEG frames as unit
|
|
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
|
|
Absolute time means that every stamp contains the time from the beginning of the
|
|
file.
|
|
|
|
4.9. Unsychronised lyrics/text transcription
|
|
|
|
This frame contains the lyrics of the song or a text transcription of other
|
|
vocal activities. The head includes an encoding descriptor and a content
|
|
descriptor. The body consists of the actual text. The 'Content descriptor' is a
|
|
terminated string. If no descriptor is entered, 'Content descriptor' is $00
|
|
(00) only. Newline characters are allowed in the text. There may be more than
|
|
one 'Unsynchronised lyrics/text transcription' frame in each tag, but only one
|
|
with the same language and content descriptor.
|
|
|
|
<Header for 'Unsynchronised lyrics/text transcription', ID: "USLT">
|
|
Text encoding $xx
|
|
Language $xx xx xx
|
|
Content descriptor <text string according to encoding> $00 (00)
|
|
Lyrics/text <full text string according to encoding>
|
|
|
|
|
|
4.10. Synchronised lyrics/text
|
|
|
|
This is another way of incorporating the words, said or sung lyrics, in the
|
|
audio file as text, this time, however, in sync with the audio. It might also
|
|
be used to describing events e.g. occurring on a stage or on the screen in sync
|
|
with the audio. The header includes a content descriptor, represented with as
|
|
terminated textstring. If no descriptor is entered, 'Content descriptor' is $00
|
|
(00) only.
|
|
|
|
<Header for 'Synchronised lyrics/text', ID: "SYLT">
|
|
Text encoding $xx
|
|
Language $xx xx xx
|
|
Time stamp format $xx
|
|
Content type $xx
|
|
Content descriptor <text string according to encoding> $00 (00)
|
|
|
|
Encoding:
|
|
|
|
$00 ISO-8859-1 character set is used => $00 is sync identifier.
|
|
$01 Unicode character set is used => $00 00 is sync identifier.
|
|
|
|
Content type:
|
|
|
|
$00 is other
|
|
$01 is lyrics
|
|
$02 is text transcription
|
|
$03 is movement/part name (e.g. "Adagio")
|
|
$04 is events (e.g. "Don Quijote enters the stage")
|
|
$05 is chord (e.g. "Bb F Fsus")
|
|
$06 is trivia/'pop up' information
|
|
|
|
Time stamp format is:
|
|
|
|
$01 Absolute time, 32 bit sized, using MPEG frames as unit
|
|
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
|
|
Absolute time means that every stamp contains the time from the beginning of the
|
|
file.
|
|
The text that follows the frame header differs from that of the unsynchronised
|
|
lyrics/text transcription in one major way. Each syllable (or whatever size of
|
|
text is considered to be convenient by the encoder) is a null terminated string
|
|
followed by a time stamp denoting where in the sound file it belongs. Each sync
|
|
thus has the following structure:
|
|
|
|
Terminated text to be synced (typically a syllable)
|
|
Sync identifier (terminator to above string) $00 (00)
|
|
Time stamp $xx (xx ...)
|
|
|
|
The 'time stamp' is set to zero or the whole sync is omitted if located
|
|
directly at the beginning of the sound. All time stamps should be sorted in
|
|
chronological order. The sync can be considered as a validator of the
|
|
subsequent string.
|
|
Newline ($0A) characters are allowed in all "SYLT" frames and should be used
|
|
after every entry (name, event etc.) in a frame with the content type $03 -
|
|
$04.
|
|
A few considerations regarding whitespace characters: Whitespace separating
|
|
words should mark the beginning of a new word, thus occurring in front of the
|
|
first syllable of a new word. This is also valid for new line characters. A
|
|
syllable followed by a comma should not be broken apart with a sync (both the
|
|
syllable and the comma should be before the sync).
|
|
An example: The "USLT" passage
|
|
|
|
"Strangers in the night" $0A "Exchanging glances"
|
|
|
|
would be "SYLT" encoded as:
|
|
|
|
"Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00
|
|
xx xx " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx
|
|
"ing" $00 xx xx "glan" $00 xx xx "ces" $00 xx xx
|
|
|
|
There may be more than one "SYLT" frame in each tag, but only one with the same
|
|
language and content descriptor.
|
|
|
|
4.11. Comments
|
|
|
|
This frame is indended for any kind of full text information that does not fit
|
|
in any other frame. It consists of a frame header followed by encoding,
|
|
language and content descriptors and is ended with the actual comment as a text
|
|
string. Newline characters are allowed in the comment text string. There may be
|
|
more than one comment frame in each tag, but only one with the same language
|
|
and content descriptor.
|
|
|
|
<Header for 'Comment', ID: "COMM">
|
|
Text encoding $xx
|
|
Language $xx xx xx
|
|
Short content descrip. <text string according to encoding> $00 (00)
|
|
The actual text <full text string according to encoding>
|
|
|
|
|
|
4.12. Relative volume adjustment
|
|
|
|
This is a more subjective function than the previous ones. It allows the user
|
|
to say how much he wants to increase/decrease the volume on each channel while
|
|
the file is played. The purpose is to be able to align all files to a reference
|
|
volume, so that you don't have to change the volume constantly. This frame may
|
|
also be used to balance adjust the audio. If the volume peak levels are known
|
|
then this could be described with the 'Peak volume right' and 'Peak volume
|
|
left' field. If Peakvolume is not known these fields could be left zeroed or,
|
|
if no other data follows, be completely omitted. There may only be one "RVAD"
|
|
frame in each tag.
|
|
|
|
<Header for 'Relative volume adjustment', ID: "RVAD">
|
|
Increment/decrement %00xxxxxx
|
|
Bits used for volume descr. $xx
|
|
Relative volume change, right $xx xx (xx ...)
|
|
Relative volume change, left $xx xx (xx ...)
|
|
Peak volume right $xx xx (xx ...)
|
|
Peak volume left $xx xx (xx ...)
|
|
|
|
In the increment/decrement field bit 0 is used to indicate the right channel
|
|
and bit 1 is used to indicate the left channel. 1 is increment and 0 is
|
|
decrement.
|
|
The 'bits used for volume description' field is normally $10 (16 bits) for MPEG
|
|
2 layer I, II and III and MPEG 2.5. This value may not be $00. The volume is
|
|
always represented with whole bytes, padded in the beginning (highest bits)
|
|
when 'bits used for volume description' is not a multiple of eight.
|
|
This datablock is then optionally followed by a volume definition for the left
|
|
and right back channels. If this information is appended to the frame the first
|
|
two channels will be treated as front channels. In the increment/decrement
|
|
field bit 2 is used to indicate the right back channel and bit 3 for the left
|
|
back channel.
|
|
|
|
Relative volume change, right back $xx xx (xx ...)
|
|
Relative volume change, left back $xx xx (xx ...)
|
|
Peak volume right back $xx xx (xx ...)
|
|
Peak volume left back $xx xx (xx ...)
|
|
|
|
If the center channel adjustment is present the following is appended to the
|
|
existing frame, after the left and right back channels. The center channel is
|
|
represented by bit 4 in the increase/decrease field.
|
|
|
|
Relative volume change, center $xx xx (xx ...)
|
|
Peak volume center $xx xx (xx ...)
|
|
|
|
If the bass channel adjustment is present the following is appended to the
|
|
existing frame, after the center channel. The bass channel is represented by
|
|
bit 5 in the increase/decrease field.
|
|
|
|
Relative volume change, bass $xx xx (xx ...)
|
|
Peak volume bass $xx xx (xx ...)
|
|
|
|
|
|
4.13. Equalisation
|
|
|
|
This is another subjective, alignment frame. It allows the user to predefine an
|
|
equalisation curve within the audio file. There may only be one "EQUA" frame in
|
|
each tag.
|
|
|
|
<Header of 'Equalisation', ID: "EQUA">
|
|
Adjustment bits $xx
|
|
|
|
The 'adjustment bits' field defines the number of bits used for representation
|
|
of the adjustment. This is normally $10 (16 bits) for MPEG 2 layer I, II and
|
|
III and MPEG 2.5. This value may not be $00.
|
|
This is followed by 2 bytes + ('adjustment bits' rounded up to the nearest
|
|
byte) for every equalisation band in the following format, giving a frequency
|
|
range of 0 - 32767Hz:
|
|
|
|
Increment/decrement %x (MSB of the Frequency)
|
|
Frequency (lower 15 bits)
|
|
Adjustment $xx (xx ...)
|
|
|
|
The increment/decrement bit is 1 for increment and 0 for decrement. The
|
|
equalisation bands should be ordered increasingly with reference to frequency.
|
|
All frequencies don't have to be declared. The equalisation curve in the
|
|
reading software should be interpolated between the values in this frame. Three
|
|
equal adjustments for three subsequent frequencies. A frequency should only be
|
|
described once in the frame.
|
|
|
|
4.14. Reverb
|
|
|
|
Yet another subjective one. You may here adjust echoes of different kinds.
|
|
Reverb left/right is the delay between every bounce in ms. Reverb bounces left/
|
|
right is the number of bounces that should be made. $FF equals an infinite
|
|
number of bounces. Feedback is the amount of volume that should be returned to
|
|
the next echo bounce. $00 is 0%, $FF is 100%. If this value were $7F, there
|
|
would be 50% volume reduction on the first bounce, 50% of that on the second
|
|
and so on. Left to left means the sound from the left bounce to be played in
|
|
the left speaker, while left to right means sound from the left bounce to be
|
|
played in the right speaker.
|
|
'Premix left to right' is the amount of left sound to be mixed in the right
|
|
before any reverb is applied, where $00 id 0% and $FF is 100%. 'Premix right to
|
|
left' does the same thing, but right to left. Setting both premix to $FF would
|
|
result in a mono output (if the reverb is applied symmetric). There may only be
|
|
one "RVRB" frame in each tag.
|
|
|
|
<Header for 'Reverb', ID: "RVRB">
|
|
Reverb left (ms) $xx xx
|
|
Reverb right (ms) $xx xx
|
|
Reverb bounces, left $xx
|
|
Reverb bounces, right $xx
|
|
Reverb feedback, left to left $xx
|
|
Reverb feedback, left to right $xx
|
|
Reverb feedback, right to right $xx
|
|
Reverb feedback, right to left $xx
|
|
Premix left to right $xx
|
|
Premix right to left $xx
|
|
|
|
|
|
4.15. Attached picture
|
|
|
|
This frame contains a picture directly related to the audio file. Image format
|
|
is the MIME type and subtype for the image. In the event that the MIME media
|
|
type name is omitted, "image/" will be implied. The "image/png" or "image/jpeg"
|
|
picture format should be used when interoperability is wanted. Description is a
|
|
short description of the picture, represented as a terminated textstring. The
|
|
description has a maximum length of 64 characters, but may be empty. There may
|
|
be several pictures attached to one file, each in their individual "APIC"
|
|
frame, but only one with the same content descriptor. There may only be one
|
|
picture with the picture type declared as picture type $01 and $02
|
|
respectively. There is the possibility to put only a link to the image file by
|
|
using the 'MIME type' "-->" and having a complete URL instead of picture data.
|
|
The use of linked files should however be used sparingly since there is the
|
|
risk of separation of files.
|
|
|
|
<Header for 'Attached picture', ID: "APIC">
|
|
Text encoding $xx
|
|
MIME type <text string> $00
|
|
Picture type $xx
|
|
Description <text string according to encoding> $00 (00)
|
|
Picture data <binary data>
|
|
|
|
Picture type:
|
|
|
|
$00 Other
|
|
$01 32x32 pixels 'file icon' (PNG only)
|
|
$02 Other file icon
|
|
$03 Cover (front)
|
|
$04 Cover (back)
|
|
$05 Leaflet page
|
|
$06 Media (e.g. lable side of CD)
|
|
$07 Lead artist/lead performer/soloist
|
|
$08 Artist/performer
|
|
$09 Conductor
|
|
$0A Band/Orchestra
|
|
$0B Composer
|
|
$0C Lyricist/text writer
|
|
$0D Recording Location
|
|
$0E During recording
|
|
$0F During performance
|
|
$10 Movie/video screen capture
|
|
$11 A bright coloured fish
|
|
$12 Illustration
|
|
$13 Band/artist logotype
|
|
$14 Publisher/Studio logotype
|
|
|
|
|
|
4.16. General encapsulated object
|
|
|
|
In this frame any type of file can be encapsulated. After the header, 'Frame
|
|
size' and 'Encoding' follows 'MIME type' represented as as a terminated string
|
|
encoded with ISO-8859-1. The filename is case sensitive and is encoded as
|
|
'Encoding'. Then follows a content description as terminated string, encoded as
|
|
'Encoding'. The last thing in the frame is the actual object. The first two
|
|
strings may be omitted, leaving only their terminations. There may be more than
|
|
one "GEOB" frame in each tag, but only one with the same content descriptor.
|
|
|
|
<Header for 'General encapsulated object', ID: "GEOB">
|
|
Text encoding $xx
|
|
MIME type <text string> $00
|
|
Filename <text string according to encoding> $00 (00)
|
|
Content description $00 (00)
|
|
Encapsulated object <binary data>
|
|
|
|
|
|
4.17. Play counter
|
|
|
|
This is simply a counter of the number of times a file has been played. The
|
|
value is increased by one every time the file begins to play. There may only be
|
|
one "PCNT" frame in each tag. When the counter reaches all one's, one byte is
|
|
inserted in front of the counter thus making the counter eight bits bigger. The
|
|
counter must be at least 32-bits long to begin with.
|
|
|
|
<Header for 'Play counter', ID: "PCNT">
|
|
Counter $xx xx xx xx (xx ...)
|
|
|
|
|
|
4.18. Popularimeter
|
|
|
|
The purpose of this frame is to specify how good an audio file is. Many
|
|
interesting applications could be found to this frame such as a playlist that
|
|
features better audiofiles more often than others or it could be used to
|
|
profile a person's taste and find other 'good' files by comparing people's
|
|
profiles. The frame is very simple. It contains the email address to the user,
|
|
one rating byte and a four byte play counter, intended to be increased with one
|
|
for every time the file is played. The email is a terminated string. The rating
|
|
is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no personal counter
|
|
is wanted it may be omitted. When the counter reaches all one's, one byte is
|
|
inserted in front of the counter thus making the counter eight bits bigger in
|
|
the same away as the play counter ("PCNT"). There may be more than one "POPM"
|
|
frame in each tag, but only one with the same email address.
|
|
|
|
<Header for 'Popularimeter', ID: "POPM">
|
|
Email to user <text string> $00
|
|
Rating $xx
|
|
Counter $xx xx xx xx (xx ...)
|
|
|
|
|
|
4.19. Recommended buffer size
|
|
|
|
Sometimes the server from which a audio file is streamed is aware of
|
|
transmission or coding problems resulting in interruptions in the audio stream.
|
|
In these cases, the size of the buffer can be recommended by the server using
|
|
this frame. If the 'embedded info flag' is true (1) then this indicates that an
|
|
ID3 tag with the maximum size described in 'Buffer size' may occur in the
|
|
audiostream. In such case the tag should reside between two MPEG frames, if the
|
|
audio is MPEG encoded. If the position of the next tag is known, 'offset to
|
|
next tag' may be used. The offset is calculated from the end of tag in which
|
|
this frame resides to the first byte of the header in the next. This field may
|
|
be omitted. Embedded tags are generally not recommended since this could render
|
|
unpredictable behaviour from present software/hardware.
|
|
For applications like streaming audio it might be an idea to embed tags into
|
|
the audio stream though. If the clients connects to individual connections like
|
|
HTTP and there is a possibility to begin every transmission with a tag, then
|
|
this tag should include a 'recommended buffer size' frame. If the client is
|
|
connected to a arbitrary point in the stream, such as radio or multicast, then
|
|
the 'recommended buffer size' frame should be included in every tag. Every tag
|
|
that is picked up after the initial/first tag is to be considered as an update
|
|
of the previous one. E.g. if there is a "TIT2" frame in the first received tag
|
|
and one in the second tag, then the first should be 'replaced' with the second.
|
|
The 'Buffer size' should be kept to a minimum. There may only be one "RBUF"
|
|
frame in each tag.
|
|
|
|
<Header for 'Recommended buffer size', ID: "RBUF">
|
|
Buffer size $xx xx xx
|
|
Embedded info flag %0000000x
|
|
Offset to next tag $xx xx xx xx
|
|
|
|
|
|
4.20. Audio encryption
|
|
|
|
This frame indicates if the actual audio stream is encrypted, and by whom.
|
|
Since standardisation of such encryption scheme is beyond this document, all
|
|
"AENC" frames begin with a terminated string with a URL containing an email
|
|
address, or a link to a location where an email address can be found, that
|
|
belongs to the organisation responsible for this specific encrypted audio file.
|
|
Questions regarding the encrypted audio should be sent to the email address
|
|
specified. If a $00 is found directly after the 'Frame size' and the audiofile
|
|
indeed is encrypted, the whole file may be considered useless.
|
|
After the 'Owner identifier', a pointer to an unencrypted part of the audio can
|
|
be specified. The 'Preview start' and 'Preview length' is described in frames.
|
|
If no part is unencrypted, these fields should be left zeroed. After the
|
|
'preview length' field follows optionally a datablock required for decryption
|
|
of the audio. There may be more than one "AENC" frames in a tag, but only one
|
|
with the same 'Owner identifier'.
|
|
|
|
<Header for 'Audio encryption', ID: "AENC">
|
|
Owner identifier <text string> $00
|
|
Preview start $xx xx
|
|
Preview length $xx xx
|
|
Encryption info <binary data>
|
|
|
|
|
|
4.21. Linked information
|
|
|
|
To keep space waste as low as possible this frame may be used to link
|
|
information from another ID3v2 tag that might reside in another audio file or
|
|
alone in a binary file. It is recommended that this method is only used when
|
|
the files are stored on a CD-ROM or other circumstances when the risk of file
|
|
seperation is low. The frame contains a frame identifier, which is the frame
|
|
that should be linked into this tag, a URL field, where a reference to the file
|
|
where the frame is given, and additional ID data, if needed. Data should be
|
|
retrieved from the first tag found in the file to which this link points. There
|
|
may be more than one "LINK" frame in a tag, but only one with the same
|
|
contents. A linked frame is to be considered as part of the tag and has the
|
|
same restrictions as if it was a physical part of the tag (i.e. only one "RVRB"
|
|
frame allowed, whether it's linked or not).
|
|
|
|
<Header for 'Linked information', ID: "LINK">
|
|
Frame identifier $xx xx xx
|
|
URL <text string> $00
|
|
ID and additional data <text string(s)>
|
|
|
|
Frames that may be linked and need no additional data are "IPLS", "MCID",
|
|
"ETCO", "MLLT", "SYTC", "RVAD", "EQUA", "RVRB", "RBUF", the text information
|
|
frames and the URL link frames.
|
|
The "TXXX", "APIC", "GEOB" and "AENC" frames may be linked with the content
|
|
descriptor as additional ID data.
|
|
The "COMM", "SYLT" and "USLT" frames may be linked with three bytes of language
|
|
descriptor directly followed by a content descriptor as additional ID data.
|
|
|
|
4.22. Position synchronisation frame
|
|
|
|
This frame delivers information to the listener of how far into the audio
|
|
stream he picked up; in effect, it states the time offset of the first frame in
|
|
the stream. The frame layout is:
|
|
|
|
<Head for 'Position synchronisation', ID: "POSS">
|
|
Time stamp format $xx
|
|
Position $xx (xx ...)
|
|
|
|
Where time stamp format is:
|
|
|
|
$01 Absolute time, 32 bit sized, using MPEG frames as unit
|
|
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
|
|
and position is where in the audio the listener starts to receive, i.e. the
|
|
beginning of the next frame. If this frame is used in the beginning of a file
|
|
the value is always 0. There may only be one "POSS" frame in each tag.
|
|
|
|
4.23. Terms of use frame
|
|
|
|
This frame contains a brief description of the terms of use and ownership of
|
|
the file. More detailed information concerning the legal terms might be
|
|
available through the "WCOP" frame. Newlines are allowed in the text. There may
|
|
only be one "USER" frame in a tag.
|
|
|
|
<Header for 'Terms of use frame', ID: "USER">
|
|
Text encoding $xx
|
|
Language $xx xx xx
|
|
The actual text <text string according to encoding>
|
|
|
|
|
|
4.24. Ownership frame
|
|
|
|
The ownership frame might be used as a reminder of a made transaction or, if
|
|
signed, as proof. Note that the "USER" and "TOWN" frames are good to use in
|
|
conjunction with this one. The frame begins, after the frame ID, size and
|
|
encoding fields, with a 'price payed' field. The first three characters of this
|
|
field contains the currency used for the transaction, encoded according to ISO-
|
|
4217 alphabetic currency code. Concatenated to this is the actual price payed,
|
|
as a numerical string using "." as the decimal separator. Next is an 8
|
|
character date string (YYYYMMDD) followed by a string with the name of the
|
|
seller as the last field in the frame. There may only be one "OWNE" frame in a
|
|
tag.
|
|
|
|
<Header for 'Ownership frame', ID: "OWNE">
|
|
Text encoding $xx
|
|
Price payed <text string> $00
|
|
Date of purch. <text string>
|
|
Seller <text string according to encoding>
|
|
|
|
|
|
4.25. Commercial frame
|
|
|
|
This frame enables several competing offers in the same tag by bundling all
|
|
needed information. That makes this frame rather complex but it's an easier
|
|
solution than if one tries to achieve the same result with several frames. The
|
|
frame begins, after the frame ID, size and encoding fields, with a price string
|
|
field. A price is constructed by one three character currency code, encoded
|
|
according to ISO-4217 alphabetic currency code, followed by a numerical value
|
|
where "." is used as decimal seperator. In the price string several prices may
|
|
be concatenated, seperated by a "/" character, but there may only be one
|
|
currency of each type.
|
|
The price string is followed by an 8 character date string in the format
|
|
YYYYMMDD, describing for how long the price is valid. After that is a contact
|
|
URL, with which the user can contact the seller, followed by a one byte
|
|
'received as' field. It describes how the audio is delivered when bought
|
|
according to the following list:
|
|
|
|
$00 Other
|
|
$01 Standard CD album with other songs
|
|
$02 Compressed audio on CD
|
|
$03 File over the Internet
|
|
$04 Stream over the Internet
|
|
$05 As note sheets
|
|
$06 As note sheets in a book with other sheets
|
|
$07 Music on other media
|
|
$08 Non-musical merchandise
|
|
|
|
Next follows a terminated string with the name of the seller followed by a
|
|
terminated string with a short description of the product. The last thing is
|
|
the ability to include a company logotype. The first of them is the 'Picture
|
|
MIME type' field containing information about which picture format is used. In
|
|
the event that the MIME media type name is omitted, "image/" will be implied.
|
|
Currently only "image/png" and "image/jpeg" are allowed. This format string is
|
|
followed by the binary picture data. This two last fields may be omitted if no
|
|
picture is to attach.
|
|
|
|
<Header for 'Commercial frame', ID: "COMR">
|
|
Text encoding $xx
|
|
Price string <text string> $00
|
|
Valid until <text string>
|
|
Contact URL <text string> $00
|
|
Received as $xx
|
|
Name of seller <text string according to encoding> $00 (00)
|
|
Description <text string according to encoding> $00 (00)
|
|
Picture MIME type <string> $00
|
|
Seller logo <binary data>
|
|
|
|
|
|
4.26. Encryption method registration
|
|
|
|
To identify with which method a frame has been encrypted the encryption method
|
|
must be registered in the tag with this frame. The 'Owner identifier' is a
|
|
null-terminated string with a URL containing an email address, or a link to a
|
|
location where an email address can be found, that belongs to the organisation
|
|
responsible for this specific encryption method. Questions regarding the
|
|
encryption method should be sent to the indicated email address. The 'Method
|
|
symbol' contains a value that is associated with this method throughout the
|
|
whole tag. Values below $80 are reserved. The 'Method symbol' may optionally be
|
|
followed by encryption specific data. There may be several "ENCR" frames in a
|
|
tag but only one containing the same symbol and only one containing the same
|
|
owner identifier. The method must be used somewhere in the tag. See section
|
|
3.3.1, flag j for more information.
|
|
|
|
<Header for 'Encryption method registration', ID: "ENCR">
|
|
Owner identifier <text string> $00
|
|
Method symbol $xx
|
|
Encryption data <binary data>
|
|
|
|
|
|
4.27. Group identification registration
|
|
|
|
This frame enables grouping of otherwise unrelated frames. This can be used
|
|
when some frames are to be signed. To identify which frames belongs to a set of
|
|
frames a group identifier must be registered in the tag with this frame. The
|
|
'Owner identifier' is a null-terminated string with a URL containing an email
|
|
address, or a link to a location where an email address can be found, that
|
|
belongs to the organisation responsible for this grouping. Questions regarding
|
|
the grouping should be sent to the indicated email address. The 'Group symbol'
|
|
contains a value that associates the frame with this group throughout the whole
|
|
tag. Values below $80 are reserved. The 'Group symbol' may optionally be
|
|
followed by some group specific data, e.g. a digital signature. There may be
|
|
several "GRID" frames in a tag but only one containing the same symbol and only
|
|
one containing the same owner identifier. The group symbol must be used
|
|
somewhere in the tag. See section_3.3.1, flag j for more information.
|
|
|
|
<Header for 'Group ID registration', ID: "GRID">
|
|
Owner identifier <text string> $00
|
|
Group symbol $xx
|
|
Group dependent data <binary data>
|
|
|
|
|
|
4.28. Private frame
|
|
|
|
This frame is used to contain information from a software producer that its
|
|
program uses and does not fit into the other frames. The frame consists of an
|
|
'Owner identifier' string and the binary data. The 'Owner identifier' is a
|
|
null-terminated string with a URL containing an email address, or a link to a
|
|
location where an email address can be found, that belongs to the organisation
|
|
responsible for the frame. Questions regarding the frame should be sent to the
|
|
indicated email address. The tag may contain more than one "PRIV" frame but
|
|
only with different contents. It is recommended to keep the number of "PRIV"
|
|
frames as low as possible.
|
|
|
|
<Header for 'Private frame', ID: "PRIV">
|
|
Owner identifier <text string> $00
|
|
The private data <binary data>
|
|
|
|
|
|
|
|
5. The unsynchronisation scheme
|
|
|
|
The only purpose of the 'unsynchronisation scheme' is to make the ID3v2 tag as
|
|
compatible as possible with existing software. There is no use in
|
|
'unsynchronising' tags if the file is only to be processed by new software.
|
|
Unsynchronisation may only be made with MPEG 2 layer I, II and III and MPEG 2.5
|
|
files.
|
|
Whenever a false synchronisation is found within the tag, one zeroed byte is
|
|
inserted after the first false synchronisation byte. The format of a correct
|
|
sync 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 won't 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 first bit in 'ID3 flags' should
|
|
be set. This bit should only be set if the tag contains a, now corrected, false
|
|
synchronisation. The bit should only be clear if the tag does not contain any
|
|
false synchronisations.
|
|
Do bear in mind, that if a compression scheme is used by the encoder, the
|
|
unsynchronisation scheme should be applied *afterwards*. When decoding a
|
|
compressed, 'unsynchronised' file, the 'unsynchronisation scheme' should be
|
|
parsed first, decompression afterwards.
|
|
If the last byte in the tag is $FF, and there is a need to eliminate false
|
|
synchronisations in the tag, at least one byte of padding should be added.
|
|
|
|
|
|
6. Copyright
|
|
|
|
Copyright © Martin Nilsson 1998. 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. References
|
|
|
|
[CDDB] Compact Disc Data Base http://www.cddb.com
|
|
|
|
[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-4217] ISO 4217:1995. Codes for the representation of currencies and
|
|
funds. Technical committee / subcommittee: TC 68
|
|
|
|
[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
|
|
|
|
[ISRC] ISO 3901:1986 International Standard Recording Code (ISRC). Technical
|
|
committee / subcommittee: TC 46 / SC 9
|
|
|
|
[JFIF] JPEG File Interchange Format, version 1.02, http://www.w3.org/Graphics/
|
|
JPEG/jfif.txt
|
|
|
|
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions
|
|
(MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.,
|
|
ftp://ftp.isi.edu/in-notes/rfc2045.txt
|
|
|
|
[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, http://www.w3.org/TR/REC-png-
|
|
multi.html
|
|
|
|
[UNICODE] ISO/IEC 10646-1:1993. Universal Multiple-Octet Coded Character Set
|
|
(UCS), Part 1: Architecture and Basic Multilingual Plane. Technical committee /
|
|
subcommittee: JTC 1 / SC 2, http://www.unicode.org
|
|
|
|
[URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource
|
|
Locators (URL).", RFC 1738, December 1994., ftp://ftp.isi.edu/in-notes/
|
|
rfc1738.txt
|
|
|
|
[ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB Compressed
|
|
Data Format Specification version 3.3", RFC 1950, May 1996., url:ftp://
|
|
ftp.isi.edu/in-notes/rfc1950.txt
|
|
|
|
|
|
|
|
8. Appendix
|
|
|
|
|
|
8.1. Appendix A - Genre List from ID3v1
|
|
|
|
The following genres is defined in ID3v1
|
|
|
|
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
|
|
|
|
The following genres are Winamp extensions
|
|
|
|
80. Folk
|
|
81. Folk-Rock
|
|
82. National Folk
|
|
83. Swing
|
|
84. Fast Fusion
|
|
85. Bebob
|
|
86. Latin
|
|
87. Revival
|
|
88. Celtic
|
|
89. Bluegrass
|
|
90. Avantgarde
|
|
91. Gothic Rock
|
|
92. Progressive Rock
|
|
93. Psychedelic Rock
|
|
94. Symphonic Rock
|
|
95. Slow Rock
|
|
96. Big Band
|
|
97. Chorus
|
|
98. Easy Listening
|
|
99. Acoustic
|
|
100. Humour
|
|
101. Speech
|
|
102. Chanson
|
|
103. Opera
|
|
104. Chamber Music
|
|
105. Sonata
|
|
106. Symphony
|
|
107. Booty Bass
|
|
108. Primus
|
|
109. Porn Groove
|
|
110. Satire
|
|
111. Slow Jam
|
|
112. Club
|
|
113. Tango
|
|
114. Samba
|
|
115. Folklore
|
|
116. Ballad
|
|
117. Power Ballad
|
|
118. Rhythmic Soul
|
|
119. Freestyle
|
|
120. Duet
|
|
121. Punk Rock
|
|
122. Drum Solo
|
|
123. A capella
|
|
124. Euro-House
|
|
125. Dance Hall
|
|
|
|
|
|
|
|
9. Author's Address
|
|
|
|
Written by
|
|
Martin Nilsson
|
|
Rydsven 246 C. 30
|
|
S-584 34 Linkoping
|
|
Sweden
|
|
|
|
Email: nilsson at id3.org
|
|
|
|
Edited by
|
|
Dirk Mahoney
|
|
57 Pechey Street
|
|
Chermside Q
|
|
Australia 4032
|
|
|
|
Email: dirk at id3.org
|
|
|
|
Johan Sundstrom
|
|
Alsttersgatan 5 A. 34
|
|
S-584 35 Linkoping
|
|
Sweden
|
|
|
|
Email: johan at id3.org
|
|
id3v2.3.0 (last edited 2006-12-18 06:25:16 by DanONeill)
|