1661 lines
61 KiB
Plaintext
1661 lines
61 KiB
Plaintext
|
||
Informal standard M. Nilsson
|
||
Document: id3v2-00.txt 26th March 1998
|
||
|
||
|
||
ID3 tag version 2
|
||
|
||
Status of this document
|
||
|
||
This document is an Informal standard and is released so that
|
||
implementors could have a set standard before the formal standard is
|
||
set. The formal standard will use another version 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.
|
||
|
||
|
||
Abstract
|
||
|
||
The recent gain of popularity for MPEG layer III audio files on the
|
||
internet forced a standardised way of storing information about an
|
||
audio file within itself to determinate its origin and contents.
|
||
|
||
Today the most accepted way to do this is with the so called ID3 tag,
|
||
which is simple but very limited and in some cases very unsuitable.
|
||
The ID3 tag has very limited space in every field, very limited
|
||
numbers of fields, not expandable or upgradeable and is placed at the
|
||
end of a the file, which is unsuitable for streaming audio. This draft
|
||
is an attempt to answer these issues with a new version of the ID3
|
||
tag.
|
||
|
||
|
||
1. Table of contents
|
||
|
||
2. Conventions in this document
|
||
3. ID3v2 overview
|
||
3.1. ID3v2 header
|
||
3.2. ID3v2 frames overview
|
||
4. Declared ID3v2 frames
|
||
4.1. Unique file identifier
|
||
4.2. Text information frames
|
||
4.2.1. Text information frames - details
|
||
4.2.2. User defined text information frame
|
||
4.3. URL link frames
|
||
4.3.1. URL link frames - details
|
||
4.3.2. User defined URL link frame
|
||
4.4. Involved people list
|
||
4.5. Music CD Identifier
|
||
4.6. Event timing codes
|
||
4.7. MPEG location lookup table
|
||
4.8. Synced tempo codes
|
||
4.9. Unsychronised lyrics/text transcription
|
||
4.10. Synchronised lyrics/text
|
||
4.11. Comments
|
||
4.12. Relative volume adjustment
|
||
4.13. Equalisation
|
||
4.14. Reverb
|
||
4.15. Attached picture
|
||
4.16. General encapsulated object
|
||
4.17. Play counter
|
||
4.18. Popularimeter
|
||
4.19. Recommended buffer size
|
||
4.20. Encrypted meta frame
|
||
4.21. Audio encryption
|
||
4.22. Linked information
|
||
5. The 'unsynchronisation scheme'
|
||
6. Copyright
|
||
7. References
|
||
8. Appendix
|
||
A. Appendix A - ID3-Tag Specification V1.1
|
||
A.1. Overview
|
||
A.2. ID3v1 Implementation
|
||
A.3. Genre List
|
||
A.4. Track addition - ID3v1.1
|
||
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
|
||
expandable.
|
||
|
||
The first criterion is met by the simple fact that the MPEG [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's 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 to files
|
||
encoded with MPEG-2 layer I, MPEG-2 layer II, MPEG-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:
|
||
|
||
ID3/file identifier "ID3"
|
||
ID3 version $02 00
|
||
ID3 flags %xx000000
|
||
ID3 size 4 * %0xxxxxxx
|
||
|
||
The first three bytes of the tag are always "ID3" to indicate that
|
||
this is an ID3 tag, directly followed by the two version bytes. The
|
||
first byte of ID3 version is it's major version, while the second byte
|
||
is its revision number. All revisions are backwards compatible while
|
||
major versions are not. If software with ID3v2 and below support
|
||
should encounter version three or higher it should simply ignore the
|
||
whole tag. Version and revision will never be $FF.
|
||
|
||
The first bit (bit 7) in the 'ID3 flags' is indicating whether or not
|
||
unsynchronisation is used (see section 5 for details); a set bit
|
||
indicates usage.
|
||
|
||
The second bit (bit 6) is indicating whether or not compression is
|
||
used; a set bit indicates usage. Since no compression scheme has been
|
||
decided yet, the ID3 decoder (for now) should just ignore the entire
|
||
tag if the compression bit is set.
|
||
|
||
The ID3 tag size is encoded with four bytes where the first 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 ID3 tag size is the size of the complete tag after
|
||
unsychronisation, including padding, excluding the header (total tag
|
||
size - 10). The reason to use 28 bits (representing up to 256MB) for
|
||
size description is that we don't want to run out of space here.
|
||
|
||
A 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 frames overview
|
||
|
||
The headers of the frames are similar in their construction. They
|
||
consist of one three character identifier (capital A-Z and 0-9) and
|
||
one three byte size field, making a total of six bytes. The header is
|
||
excluded from the size. Identifiers beginning with "X", "Y" and "Z"
|
||
are for experimental use and free for everyone to use. 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 three character frame identifier is followed by a three byte size
|
||
descriptor, making a total header size of six bytes in every frame.
|
||
The size is calculated as framesize excluding frame identifier and
|
||
size descriptor (frame size - 6).
|
||
|
||
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:
|
||
UFI, MCI, TT2 ...
|
||
|
||
A tag must contain at least one frame. A frame must be at least 1 byte
|
||
big, excluding the 6-byte header.
|
||
|
||
If nothing else is said a string is represented as ISO-8859-1
|
||
[ISO-8859-1] characters in the range $20 - $FF. All unicode strings
|
||
[UNICODE] use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). All
|
||
numeric strings 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.
|
||
|
||
The three byte language field is used to describe the language of the
|
||
frame's content, according to ISO-639-2 [ISO-639-2].
|
||
|
||
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 ID3 standard. This
|
||
is reflected by the revision number in the header of the tag.
|
||
|
||
|
||
4. Declared ID3v2 frames
|
||
|
||
The following frames are declared in this draft.
|
||
|
||
4.19 BUF Recommended buffer size
|
||
|
||
4.17 CNT Play counter
|
||
4.11 COM Comments
|
||
4.21 CRA Audio encryption
|
||
4.20 CRM Encrypted meta frame
|
||
|
||
4.6 ETC Event timing codes
|
||
4.13 EQU Equalization
|
||
|
||
4.16 GEO General encapsulated object
|
||
|
||
4.4 IPL Involved people list
|
||
|
||
4.22 LNK Linked information
|
||
|
||
4.5 MCI Music CD Identifier
|
||
4.7 MLL MPEG location lookup table
|
||
|
||
4.15 PIC Attached picture
|
||
4.18 POP Popularimeter
|
||
|
||
4.14 REV Reverb
|
||
4.12 RVA Relative volume adjustment
|
||
|
||
4.10 SLT Synchronized lyric/text
|
||
4.8 STC Synced tempo codes
|
||
|
||
4.2.1 TAL Album/Movie/Show title
|
||
4.2.1 TBP BPM (Beats Per Minute)
|
||
4.2.1 TCM Composer
|
||
4.2.1 TCO Content type
|
||
4.2.1 TCR Copyright message
|
||
4.2.1 TDA Date
|
||
4.2.1 TDY Playlist delay
|
||
4.2.1 TEN Encoded by
|
||
4.2.1 TFT File type
|
||
4.2.1 TIM Time
|
||
4.2.1 TKE Initial key
|
||
4.2.1 TLA Language(s)
|
||
4.2.1 TLE Length
|
||
4.2.1 TMT Media type
|
||
4.2.1 TOA Original artist(s)/performer(s)
|
||
4.2.1 TOF Original filename
|
||
4.2.1 TOL Original Lyricist(s)/text writer(s)
|
||
4.2.1 TOR Original release year
|
||
4.2.1 TOT Original album/Movie/Show title
|
||
4.2.1 TP1 Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group
|
||
4.2.1 TP2 Band/Orchestra/Accompaniment
|
||
4.2.1 TP3 Conductor/Performer refinement
|
||
4.2.1 TP4 Interpreted, remixed, or otherwise modified by
|
||
4.2.1 TPA Part of a set
|
||
4.2.1 TPB Publisher
|
||
4.2.1 TRC ISRC (International Standard Recording Code)
|
||
4.2.1 TRD Recording dates
|
||
4.2.1 TRK Track number/Position in set
|
||
4.2.1 TSI Size
|
||
4.2.1 TSS Software/hardware and settings used for encoding
|
||
4.2.1 TT1 Content group description
|
||
4.2.1 TT2 Title/Songname/Content description
|
||
4.2.1 TT3 Subtitle/Description refinement
|
||
4.2.1 TXT Lyricist/text writer
|
||
4.2.2 TXX User defined text information frame
|
||
4.2.1 TYE Year
|
||
|
||
4.1 UFI Unique file identifier
|
||
4.9 ULT Unsychronized lyric/text transcription
|
||
|
||
4.3.1 WAF Official audio file webpage
|
||
4.3.1 WAR Official artist/performer webpage
|
||
4.3.1 WAS Official audio source webpage
|
||
4.3.1 WCM Commercial information
|
||
4.3.1 WCP Copyright/Legal information
|
||
4.3.1 WPB Publishers official webpage
|
||
4.3.2 WXX 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 [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. If a $00 is found directly after
|
||
the 'Frame size' the whole frame should be ignored, and preferably be
|
||
removed. The 'Owner identifier' is then followed by the actual
|
||
identifier, which may be up to 64 bytes. There may be more than one
|
||
"UFI" frame in a tag, but only one with the same 'Owner identifier'.
|
||
|
||
Unique file identifier "UFI"
|
||
Frame size $xx xx xx
|
||
Owner identifier <textstring> $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 the text information frames have the
|
||
following format:
|
||
|
||
Text information identifier "T00" - "TZZ" , excluding "TXX",
|
||
described in 4.2.2.
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Information <textstring>
|
||
|
||
|
||
4.2.1. Text information frames - details
|
||
|
||
TT1
|
||
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").
|
||
|
||
TT2
|
||
The 'Title/Songname/Content description' frame is the actual name of
|
||
the piece (e.g. "Adagio", "Hurricane Donna").
|
||
|
||
TT3
|
||
The 'Subtitle/Description refinement' frame is used for information
|
||
directly related to the contents title (e.g. "Op. 16" or "Performed
|
||
live at wembley").
|
||
|
||
TP1
|
||
The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is
|
||
used for the main artist(s). They are seperated with the "/"
|
||
character.
|
||
|
||
TP2
|
||
The 'Band/Orchestra/Accompaniment' frame is used for additional
|
||
information about the performers in the recording.
|
||
|
||
TP3
|
||
The 'Conductor' frame is used for the name of the conductor.
|
||
|
||
TP4
|
||
The 'Interpreted, remixed, or otherwise modified by' frame contains
|
||
more information about the people behind a remix and similar
|
||
interpretations of another existing piece.
|
||
|
||
TCM
|
||
The 'Composer(s)' frame is intended for the name of the composer(s).
|
||
They are seperated with the "/" character.
|
||
|
||
TXT
|
||
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.
|
||
|
||
TLA
|
||
The 'Language(s)' frame should contain the languages of the text or
|
||
lyrics in the audio file. 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.
|
||
|
||
TCO
|
||
The content type, which previously (in ID3v1.1, see appendix A) 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 (section A.3.) 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
|
||
|
||
TAL
|
||
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.
|
||
|
||
TPA
|
||
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 "TAL" 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".
|
||
|
||
TRK
|
||
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".
|
||
|
||
TRC
|
||
The 'ISRC' frame should contian the International Standard Recording
|
||
Code [ISRC].
|
||
|
||
TYE
|
||
The 'Year' frame is a numeric string with a year of the recording.
|
||
This frames is always four characters long (until the year 10000).
|
||
|
||
TDA
|
||
The 'Date' frame is a numeric string in the DDMM format containing
|
||
the date for the recording. This field is always four characters
|
||
long.
|
||
|
||
TIM
|
||
The 'Time' frame is a numeric string in the HHMM format containing
|
||
the time for the recording. This field is always four characters
|
||
long.
|
||
|
||
TRD
|
||
The 'Recording dates' frame is a intended to be used as complement to
|
||
the "TYE", "TDA" and "TIM" frames. E.g. "4th-7th June, 12th June" in
|
||
combination with the "TYE" frame.
|
||
|
||
TMT
|
||
The 'Media type' frame describes from which media the sound
|
||
originated. This may be a textstring 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/S)" 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)
|
||
|
||
TFT
|
||
The 'File type' frame indicates which type of audio this tag defines.
|
||
The following type and refinements are defined:
|
||
|
||
MPG MPEG Audio
|
||
/1 MPEG 2 layer I
|
||
/2 MPEG 2 layer II
|
||
/3 MPEG 2 layer III
|
||
/2.5 MPEG 2.5
|
||
/AAC Advanced audio compression
|
||
|
||
but other types may be used, not for these types though. This is used
|
||
in a similar way to the predefined types in the "TMT" frame, but
|
||
without parenthesis. If this frame is not present audio type is
|
||
assumed to be "MPG".
|
||
|
||
TBP
|
||
BPM is short for beats per minute, and is easily computed by
|
||
dividing the number of beats in a musical piece with its length. To
|
||
get a more accurate result, do the BPM calculation on the main-part
|
||
only. To acquire best result measure the time between each beat and
|
||
calculate individual BPM for each beat and use the median value as
|
||
result. BPM is an integer and represented as a numerical string.
|
||
|
||
TCR
|
||
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 " (C) " ", where (C) is one
|
||
character showing a C in a circle.
|
||
|
||
TPB
|
||
The 'Publisher' frame simply contains the name of the label or
|
||
publisher.
|
||
|
||
TEN
|
||
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.
|
||
|
||
TSS
|
||
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.
|
||
|
||
TOF
|
||
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.
|
||
|
||
TLE
|
||
The 'Length' frame contains the length of the audiofile in
|
||
milliseconds, represented as a numeric string.
|
||
|
||
TSI
|
||
The 'Size' frame contains the size of the audiofile in bytes
|
||
excluding the tag, represented as a numeric string.
|
||
|
||
TDY
|
||
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.
|
||
|
||
TKE
|
||
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.
|
||
|
||
TOT
|
||
The 'Original album/Movie/Show title' frame is intended for the title
|
||
of the original recording(/source of sound), if for example the music
|
||
in the file should be a cover of a previously released song.
|
||
|
||
TOA
|
||
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.
|
||
|
||
TOL
|
||
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.
|
||
|
||
TOR
|
||
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 "TDY" frame.
|
||
|
||
|
||
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"xx 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
|
||
"TXX" frame in each tag, but only one with the same description.
|
||
|
||
User defined... "TXX"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Description <textstring> $00 (00)
|
||
Value <textstring>
|
||
|
||
|
||
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 [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
|
||
frames have the following format:
|
||
|
||
URL link frame "W00" - "WZZ" , excluding "WXX"
|
||
(described in 4.3.2.)
|
||
Frame size $xx xx xx
|
||
URL <textstring>
|
||
|
||
|
||
4.3.1. URL link frames - details
|
||
|
||
WAF
|
||
The 'Official audio file webpage' frame is a URL pointing at a file
|
||
specific webpage.
|
||
|
||
WAR
|
||
The 'Official artist/performer webpage' frame is a URL pointing at
|
||
the artists official webpage. There may be more than one "WAR" frame
|
||
in a tag if the audio contains more than one performer.
|
||
|
||
WAS
|
||
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.
|
||
|
||
WCM
|
||
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 "WCM" frame in a tag.
|
||
|
||
WCP
|
||
The 'Copyright/Legal information' frame is a URL pointing at a
|
||
webpage where the terms of use and ownership of the file is described.
|
||
|
||
WPB
|
||
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 [URL] links concerning the audiofile in
|
||
a similar way to the other "W"xx 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
|
||
[ISO-8859-1]. There may be more than one "WXX" frame in each tag, but
|
||
only one with the same description.
|
||
|
||
User defined... "WXX"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Description <textstring> $00 (00)
|
||
URL <textstring>
|
||
|
||
|
||
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 "IPL" frame in each tag.
|
||
|
||
Involved people list "IPL"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
People list strings <textstrings>
|
||
|
||
|
||
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 [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 making a
|
||
maximum of 804 bytes. This frame requires a present and valid "TRK"
|
||
frame. There may only be one "MCI" frame in each tag.
|
||
|
||
Music CD identifier "MCI"
|
||
Frame size $xx xx xx
|
||
CD TOC <binary data>
|
||
|
||
|
||
4.6. Event timing codes
|
||
|
||
This frame allows synchronisation with key events in a song or sound.
|
||
The head is:
|
||
|
||
Event timing codes "ETC"
|
||
Frame size $xx xx xx
|
||
Time stamp format $xx
|
||
|
||
Where time stamp format is:
|
||
|
||
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
||
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
||
|
||
Abolute 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 begins
|
||
$07 refrain begins
|
||
$08 interlude
|
||
$09 theme start
|
||
$0A variation
|
||
$0B key change
|
||
$0C time change
|
||
$0D unwanted noise (Snap, Crackle & Pop)
|
||
|
||
$0E-$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)
|
||
|
||
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 "ETC" frame in each tag.
|
||
|
||
|
||
4.7. MPEG location lookup table
|
||
|
||
To increase performance and accuracy of jumps within a MPEG [MPEG]
|
||
audio file, frames with timecodes in different locations in the file
|
||
might be useful. The ID3 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 "MLL" frame in each tag.
|
||
|
||
Location lookup table "MLL"
|
||
ID3 frame size $xx xx xx
|
||
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. Synced 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 "STC" frame in each tag.
|
||
|
||
Synced tempo codes "STC"
|
||
Frame size $xx xx xx
|
||
Time stamp format $xx
|
||
Tempo data <binary data>
|
||
|
||
Where time stamp format is:
|
||
|
||
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
||
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
||
|
||
Abolute 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. Maximum length for the descriptor is 64
|
||
bytes. There may be more than one lyrics/text frame in each tag, but
|
||
only one with the same language and content descriptor.
|
||
|
||
Unsynced lyrics/text "ULT"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Language $xx xx xx
|
||
Content descriptor <textstring> $00 (00)
|
||
Lyrics/text <textstring>
|
||
|
||
|
||
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.
|
||
|
||
Synced lyrics/text "SLT"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Language $xx xx xx
|
||
Time stamp format $xx
|
||
Content type $xx
|
||
Content descriptor <textstring> $00 (00)
|
||
|
||
|
||
Encoding: $00 ISO-8859-1 [ISO-8859-1] character set is used => $00
|
||
is sync identifier.
|
||
$01 Unicode [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")
|
||
|
||
Time stamp format is:
|
||
|
||
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
||
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
||
|
||
Abolute 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 characters are allowed in all "SLT" 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 "ULT" passage
|
||
|
||
"Strangers in the night" $0A "Exchanging glances"
|
||
|
||
would be "SLT" 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 "SLT" frame in each tag, but only one with
|
||
the same language and content descriptor.
|
||
|
||
|
||
4.11. Comments
|
||
|
||
This frame replaces the old 30-character comment field in ID3v1. It
|
||
consists of a frame head 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.
|
||
|
||
Comment "COM"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Language $xx xx xx
|
||
Short content description <textstring> $00 (00)
|
||
The actual text <textstring>
|
||
|
||
|
||
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 completely omitted. There may only be one "RVA" frame in each
|
||
tag.
|
||
|
||
Relative volume adjustment "RVA"
|
||
Frame size $xx xx xx
|
||
Increment/decrement %000000xx
|
||
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 [MPEG] 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.
|
||
|
||
|
||
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 "EQU" frame in each tag.
|
||
|
||
Equalisation "EQU"
|
||
Frame size $xx xx xx
|
||
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 [MPEG] 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. Adjustments
|
||
with the value $00 should be omitted. 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, yet 50% 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 "REV" frame in each tag.
|
||
|
||
Reverb settings "REV"
|
||
Frame size $00 00 0C
|
||
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 preferably "PNG" [PNG] or "JPG" [JFIF]. 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 "PIC" 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 a
|
||
possibility to put only a link to the image file by using the 'image
|
||
format' "-->" and having a complete URL [URL] instead of picture data.
|
||
The use of linked files should however be used restrictively since
|
||
there is the risk of separation of files.
|
||
|
||
Attached picture "PIC"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
Image format $xx xx xx
|
||
Picture type $xx
|
||
Description <textstring> $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' [MIME] and 'Filename'
|
||
for the encapsulated object, both represented as terminated strings
|
||
encoded with ISO 8859-1 [ISO-8859-1]. The filename is case sensitive.
|
||
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.
|
||
MIME type is always an ISO-8859-1 text string. There may be more than
|
||
one "GEO" frame in each tag, but only one with the same content
|
||
descriptor.
|
||
|
||
General encapsulated object "GEO"
|
||
Frame size $xx xx xx
|
||
Text encoding $xx
|
||
MIME type <textstring> $00
|
||
Filename <textstring> $00 (00)
|
||
Content description <textstring> $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 "CNT" 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.
|
||
|
||
Play counter "CNT"
|
||
Frame size $xx xx xx
|
||
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 persons 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 ("CNT").
|
||
There may be more than one "POP" frame in each tag, but only one with
|
||
the same email address.
|
||
|
||
Popularimeter "POP"
|
||
Frame size $xx xx xx
|
||
Email to user <textstring> $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 [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 is currently not
|
||
recommended since this could render unpredictable behaviour from
|
||
present software/hardware. The 'Buffer size' should be kept to a
|
||
minimum. There may only be one "BUF" frame in each tag.
|
||
|
||
Recommended buffer size "BUF"
|
||
Frame size $xx xx xx
|
||
Buffer size $xx xx xx
|
||
Embedded info flag %0000000x
|
||
Offset to next tag $xx xx xx xx
|
||
|
||
|
||
4.20. Encrypted meta frame
|
||
|
||
This frame contains one or more encrypted frames. This enables
|
||
protection of copyrighted information such as pictures and text, that
|
||
people might want to pay extra for. Since standardisation of such an
|
||
encryption scheme is beyond this document, all "CRM" frames begin with
|
||
a terminated string with a URL [URL] containing an email address, or a
|
||
link to a location where an email adress can be found, that belongs to
|
||
the organisation responsible for this specific encrypted meta frame.
|
||
|
||
Questions regarding the encrypted frame should be sent to the
|
||
indicated email address. If a $00 is found directly after the 'Frame
|
||
size', the whole frame should be ignored, and preferably be removed.
|
||
The 'Owner identifier' is then followed by a short content description
|
||
and explanation as to why it's encrypted. After the
|
||
'content/explanation' description, the actual encrypted block follows.
|
||
|
||
When an ID3v2 decoder encounters a "CRM" frame, it should send the
|
||
datablock to the 'plugin' with the corresponding 'owner identifier'
|
||
and expect to receive either a datablock with one or several ID3v2
|
||
frames after each other or an error. There may be more than one "CRM"
|
||
frames in a tag, but only one with the same 'owner identifier'.
|
||
|
||
Encrypted meta frame "CRM"
|
||
Frame size $xx xx xx
|
||
Owner identifier <textstring> $00 (00)
|
||
Content/explanation <textstring> $00 (00)
|
||
Encrypted datablock <binary data>
|
||
|
||
|
||
4.21. Audio encryption
|
||
|
||
This frame indicates if the actual audio stream is encrypted, and by
|
||
whom. Since standardisation of such encrypion scheme is beyond this
|
||
document, all "CRA" 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 "CRA" frames in a tag, but only one with the same 'Owner
|
||
identifier'.
|
||
|
||
Audio encryption "CRA"
|
||
Frame size $xx xx xx
|
||
Owner identifier <textstring> $00 (00)
|
||
Preview start $xx xx
|
||
Preview length $xx xx
|
||
Encryption info <binary data>
|
||
|
||
|
||
4.22. 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 [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 "LNK" 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 "REV" frame allowed, whether it's linked or not).
|
||
|
||
Linked information "LNK"
|
||
Frame size $xx xx xx
|
||
Frame identifier $xx xx xx
|
||
URL <textstring> $00 (00)
|
||
Additional ID data <textstring(s)>
|
||
|
||
Frames that may be linked and need no additional data are "IPL",
|
||
"MCI", "ETC", "LLT", "STC", "RVA", "EQU", "REV", "BUF", the text
|
||
information frames and the URL link frames.
|
||
|
||
The "TXX", "PIC", "GEO", "CRM" and "CRA" frames may be linked with the
|
||
content descriptor as additional ID data.
|
||
|
||
The "COM", "SLT" and "ULT" frames may be linked with three bytes of
|
||
language descriptor directly followed by a content descriptor as
|
||
additional ID data.
|
||
|
||
|
||
5. The 'unsynchronisation scheme'
|
||
|
||
The only purpose of the 'unsychronisation 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 unsynchonisation.
|
||
|
||
To indicate usage of the unsynchronisation, the first bit in 'ID3
|
||
flags' should be set. This bit should only be set if the tag
|
||
contained 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 unsyncronisation scheme should be applied *afterwards*. When
|
||
decoding a compressed, 'unsyncronised' file, the 'unsyncronisation
|
||
scheme' should be parsed first, compression afterwards.
|
||
|
||
|
||
6. Copyright
|
||
|
||
Copyright (C) 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
|
||
|
||
<url:http://www.cddb.com>
|
||
|
||
[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-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
|
||
|
||
<url: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.
|
||
|
||
<url: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
|
||
|
||
<url: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
|
||
|
||
<url:http://www.unicode.org>
|
||
|
||
[URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource
|
||
Locators (URL).", RFC 1738, December 1994.
|
||
|
||
<url:ftp://ftp.isi.edu/in-notes/rfc1738.txt>
|
||
|
||
|
||
8. Appendix
|
||
|
||
|
||
A. Appendix A - ID3-Tag Specification V1.1
|
||
|
||
ID3-Tag Specification V1.1 (12 dec 1997) by Michael Mutschler
|
||
<amiga2@info2.rus.uni-stuttgart.de>, edited for space and clarity
|
||
reasons.
|
||
|
||
|
||
A.1. Overview
|
||
|
||
The ID3-Tag is an information field for MPEG Layer 3 audio files.
|
||
Since a standalone MP3 doesn't provide a method of storing other
|
||
information than those directly needed for replay reasons, the
|
||
ID3-tag was invented by Eric Kemp in 1996.
|
||
|
||
A revision from ID3v1 to ID3v1.1 was made by Michael Mutschler to
|
||
support track number information is described in A.4.
|
||
|
||
|
||
A.2. ID3v1 Implementation
|
||
|
||
The Information is stored in the last 128 bytes of an MP3. The Tag
|
||
has got the following fields, and the offsets given here, are from
|
||
0-127.
|
||
|
||
Field Length Offsets
|
||
Tag 3 0-2
|
||
Songname 30 3-32
|
||
Artist 30 33-62
|
||
Album 30 63-92
|
||
Year 4 93-96
|
||
Comment 30 97-126
|
||
Genre 1 127
|
||
|
||
|
||
The string-fields contain ASCII-data, coded in ISO-Latin 1 codepage.
|
||
Strings which are smaller than the field length are padded with zero-
|
||
bytes.
|
||
|
||
Tag: The tag is valid if this field contains the string "TAG". This
|
||
has to be uppercase!
|
||
|
||
Songname: This field contains the title of the MP3 (string as
|
||
above).
|
||
|
||
Artist: This field contains the artist of the MP3 (string as above).
|
||
|
||
Album: this field contains the album where the MP3 comes from
|
||
(string as above).
|
||
|
||
Year: this field contains the year when this song has originally
|
||
been released (string as above).
|
||
|
||
Comment: this field contains a comment for the MP3 (string as
|
||
above). Revision to this field has been made in ID3v1.1. See
|
||
A.4.
|
||
|
||
Genre: this byte contains the offset of a genre in a predefined
|
||
list the byte is treated as an unsigned byte. The offset is
|
||
starting from 0. See A.3.
|
||
|
||
|
||
A.3. Genre List
|
||
|
||
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
|
||
|
||
|
||
A.4. Track addition - ID3v1.1
|
||
|
||
In ID3v1.1, Michael Mutschler revised the specification of the
|
||
comment field in order to implement the track number. The new format
|
||
of the comment field is a 28 character string followed by a mandatory
|
||
null ($00) character and the original album tracknumber stored as an
|
||
unsigned byte-size integer. In such cases where the 29th byte is not
|
||
the null character or when the 30th is a null character, the
|
||
tracknumber is to be considered undefined.
|
||
|
||
|
||
9. Author's Address
|
||
|
||
Martin Nilsson
|
||
Rydsv<73>gen 246 C. 30
|
||
S-584 34 Link<6E>ping
|
||
Sweden
|
||
|
||
Email: nilsson@id3.org
|
||
|
||
Co-authors:
|
||
|
||
Johan Sundstr<74>m Email: johan@id3.org
|
||
|
||
|