id3 0.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/LICENSE.html +146 -0
- data/README +23 -0
- data/docs/Class_AudioFile.html +110 -0
- data/docs/Class_Frame.html +125 -0
- data/docs/Class_Tag1.html +121 -0
- data/docs/Class_Tag2.html +167 -0
- data/docs/ID3-Standards/id3v2-00.html +1669 -0
- data/docs/ID3-Standards/id3v2-00.txt +1660 -0
- data/docs/ID3-Standards/id3v2.3.0.html +2033 -0
- data/docs/ID3-Standards/id3v2.3.0.txt +2025 -0
- data/docs/ID3-Standards/id3v2.4.0-changes.html +159 -0
- data/docs/ID3-Standards/id3v2.4.0-changes.txt +149 -0
- data/docs/ID3-Standards/id3v2.4.0-frames.html +1743 -0
- data/docs/ID3-Standards/id3v2.4.0-frames.txt +1732 -0
- data/docs/ID3-Standards/id3v2.4.0-structure.html +742 -0
- data/docs/ID3-Standards/id3v2.4.0-structure.txt +732 -0
- data/docs/ID3_comparison.html +2121 -0
- data/docs/ID3_comparison2.html +2043 -0
- data/docs/ID3v2_frames_comparison.html +2121 -0
- data/docs/ID3v2_frames_comparison.txt +197 -0
- data/docs/ID3v2_frames_overview.txt +60 -0
- data/docs/Module_ID3.html +146 -0
- data/docs/id3.html +245 -0
- data/docs/index.html +252 -0
- data/index.html +8 -0
- data/lib/hexdump.rb +113 -0
- data/lib/id3.rb +1177 -0
- data/lib/invert_hash.rb +105 -0
- metadata +75 -0
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
2
|
+
<html><head>
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
|
|
8
|
+
<title>Class ID3::Tag2</title>
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
</head>
|
|
13
|
+
<body><br>
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
<br>
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
<br>
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
<h3>class ID3::Tag2</h3>
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
This class models version 2.x ID3-tags.<br>
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
<br>
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
<h4>
|
|
46
|
+
Provided Functionality:
|
|
47
|
+
</h4>
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
<ul>
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
<li>Reads and parses audio files for ID3-tags</li><li>Dumps information contained in the Tag2 object raw into a string<br>
|
|
59
|
+
</li>
|
|
60
|
+
|
|
61
|
+
<li>Writes audio files and attaches ID3-tags to them</li><li>Keeps track of complete path name to audio file</li><li>Keeps track of where the raw audio portion of an audio-file is<br>
|
|
62
|
+
</li>
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
<li>Top-level interface to ID3-tags</li>
|
|
66
|
+
</ul>
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
<h4>Instance Variables:</h4>
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
<ul>
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
<li>version # either nil, or a string wtih the version number</li><li>raw
|
|
84
|
+
# string containing the raw ID3 version 2 tag</li><li>rawflags # byte with the binary flags of the ID3 version 2 header</li>
|
|
85
|
+
<li>flags # parsed flags (accessible as a Hash)<br>
|
|
86
|
+
</li>
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
</ul>
|
|
90
|
+
|
|
91
|
+
|
|
92
|
+
|
|
93
|
+
|
|
94
|
+
|
|
95
|
+
|
|
96
|
+
<h4>Instance Methods:</h4>
|
|
97
|
+
|
|
98
|
+
|
|
99
|
+
|
|
100
|
+
<ul>
|
|
101
|
+
|
|
102
|
+
|
|
103
|
+
|
|
104
|
+
<li>new</li>
|
|
105
|
+
<li>read<br>
|
|
106
|
+
</li>
|
|
107
|
+
<li>write # not yet implemented.. <br>
|
|
108
|
+
</li>
|
|
109
|
+
<li>dump # dump the ID3 version 2 tag raw into a string</li>
|
|
110
|
+
|
|
111
|
+
</ul>
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
<br>
|
|
115
|
+
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
<h4>Hash-like Access:</h4>
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
|
|
122
|
+
|
|
123
|
+
|
|
124
|
+
When accessing a Tag2 object wtih the Hash syntax, you can access the
|
|
125
|
+
actual data (Frames) in the tag. Please note that there is only a very limited
|
|
126
|
+
number of valid keys, and that the class does not allow "inventing" new
|
|
127
|
+
keys (as those would not correspond to valid ID3-Frames and would not be defined in the ID3 definition)<br>
|
|
128
|
+
|
|
129
|
+
|
|
130
|
+
|
|
131
|
+
|
|
132
|
+
|
|
133
|
+
<br>
|
|
134
|
+
To see which symbolic names (keys) are allowed, please check <b> ID3::SUPPORTED_SYMBOLS[version].keys</b><br>
|
|
135
|
+
|
|
136
|
+
|
|
137
|
+
|
|
138
|
+
|
|
139
|
+
|
|
140
|
+
<h4>Examples:</h4>
|
|
141
|
+
|
|
142
|
+
|
|
143
|
+
|
|
144
|
+
|
|
145
|
+
|
|
146
|
+
<pre> > require 'id3'<br> => true<br><br> > t = ID3::Tag2.new<br> => {}<br><br> > t.read("mp3/d.mp3")<br> => true<br><br> > t.version<br> => "2.3.0"<br><br> > t.keys<br> => ["ARTIST", "SONGLEN", "CONTENTTYPE", "ALBUM", "TRACKNUM", "TITLE", "PICTURE", "MEDIATYPE"]<br><br> > t.raw.size<br> => 206561<br><br> > t['PICTURE'].raw.size<br> => 206419<br><br> > t.raw.size - t['PICTURE'].raw.size<br> => 142<br><br><br> <b># PLEASE NOTE: this is how you can delete huge pictures which are sometimes attached to your audio-files!</b><br><br> > t.delete('PICTURE')<br> <i>output omitted (returns the picture as a raw string, so you could save it)</i><br><br> > t.keys<br> => ["ARTIST", "SONGLEN", "CONTENTTYPE", "ALBUM", "TRACKNUM", "TITLE", "MEDIATYPE"]<br><br> > t<br> => {"ARTIST"=>{"encoding"=>0, "text"=>"Beatles"}, "SONGLEN"=>{"encoding"=>0, "text"=>"258847"}, "CONTENTTYPE"=>{"encoding"=>0, "text"=>"60's"}, "ALBUM"=>{"encoding"=>0, "text"=>"Abbey Road"}, "TRACKNUM"=>{"encoding"=>0, "text"=>"1"}, "TITLE"=>{"encoding"=>0, "text"=>"Come Together"}, "MEDIATYPE"=>{"encoding"=>0, "text"=>"DIG"}}<br><br> # the padding size is a bit larger, that's why we don't get 142, but 170 bytes<br><br> > t.dump.size<br> => 170<br><br><br> <b># PLEASE NOTE that the entries are now a complex datastructure (according to the definition of ID3-Frames)</b><br><br> > t['ARTIST']<br> => {"encoding"=>0, "text"=>"Beatles"}<br><br> > t['ARTIST']['text'] = "The Beatles"<br> => "The Beatles"<br><br> <b># PLEASE NOTE that you can not "invent" new Frame or field names:</b><br><br> > t['ARTIST']['myrating'] = 4<br> ArgumentError: You can not add new keys! The ID3-frame TPE1 has fixed entries!<br> valid key are: encoding,text<br><br> from ./id3.rb:562:in `[]='<br> from (irb):7<br><br> > t['MYFIELD'] = "does not work!"<br> ArgumentError: Incorrect ID3-field "MYFIELD" for ID3 version 2.3.0<br> valid fields are: PICTURE,FILEOWNER,CONDUCTOR,EVENTTIMING,DATE,CRYPTOREG,COMMENT,POPULARIMETER,GROUPINGREG,PUBLISHER,COPYRIGHT,EQUALIZATION,NETRADIOSTATION,ORIGFILENAME,WWWPUBLISHER,BUFFERSIZE,PLAYCOUNTER,ISRC,LYRICIST,RECORDINGDATES,SIZE,INVOLVEDPEOPLE,POSITIONSYNC,WWWCOMMERCIALINFO,PLAYLISTDELAY,ORIGLYRICIST,ALBUM,SYNCEDLYRICS,CONTENTTYPE,SONGLEN,MEDIATYPE,WWWPAYMENT,REVERB,COMPOSER,LINKEDINFO,CONTENTGROUP,BPM,ORIGYEAR,ORIGARTIST,UNIQUEFILEID,USERTEXT,FILETYPE,TIME,PRIVATE,SUBTITLE,TERMSOFUSE,BAND,WWWCOPYRIGHT,YEAR,INITIALKEY,SYNCEDTEMPO,PARTINSET,WWWUSER,AUDIOCRYPTO,MPEGLOOKUP,VOLUMEADJ,ORIGALBUM,CDID,ENCODEDBY,WWWAUDIOFILE,COMMERCIAL,TITLE,MIXARTIST,NETRADIOOWNER,TRACKNUM,WWWAUDIOSOURCE,GENERALOBJECT,WWWRADIOPAGE,LANGUAGE,ENCODERSETTINGS,WWWARTIST,ARTIST,UNSYNCEDLYRICS<br><br> from ./id3.rb:636:in `[]='<br> from (irb):8<br><br> <b># PLEASE NOTE that the raw tag is read only, and reflects the data that was read from the file!<br></b><br> > t.raw<br> <i>output omitted (returns a string with the raw ID3-v2-tag)<br></i> <br> > t.raw.hexdump<br> <i>output omitted (returns a hexdump of the raw ID3-v2-tag)</i><br> <br> > t.raw.size<br> => 206561<br><br> > t.dump<br> => "ID3\003\000\000\000\000\001 TPE1\000\000\000\t\000\000\000Beatles\000TLEN\000\000\000\010\000\000\000258847\000TCON\000\000\000\006\000\000\00060's\000TALB\000\000\000\f\000\000\000Abbey Road\000TRCK\000\000\000\003\000\000\0001\000TIT2\000\000\000\017\000\000\000Come Together\000TMED\000\000\000\005\000\000\000DIG\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"<br>i<br><br> > t.dump.hexdump<br><br> index 0 1 2 3 4 5 6 7 8 9 A B C D E F<br><br> 00000000 49443303 00000000 01205450 45310000 ID3...... TPE1..<br> 00000010 00090000 00426561 746c6573 00544c45 .....Beatles.TLE<br> 00000020 4e000000 08000000 32353838 34370054 N.......258847.T<br> 00000030 434f4e00 00000600 00003630 27730054 CON.......60's.T<br> 00000040 414c4200 00000c00 00004162 62657920 ALB.......Abbey<br> 00000050 526f6164 00545243 4b000000 03000000 Road.TRCK.......<br> 00000060 31005449 54320000 000f0000 00436f6d 1.TIT2.......Com<br> 00000070 6520546f 67657468 65720054 4d454400 e Together.TMED.<br> 00000080 00000500 00004449 47000000 00000000 ......DIG.......<br> 00000090 00000000 00000000 00000000 00000000 ................<br> 000000a0 00000000 00000000 0000 ..........<br> => nil<br><br> > t.dump.size<br> => 170<br><br> <br><br> <br> <br><br></pre>
|
|
147
|
+
|
|
148
|
+
|
|
149
|
+
|
|
150
|
+
|
|
151
|
+
<br>
|
|
152
|
+
|
|
153
|
+
|
|
154
|
+
|
|
155
|
+
<br>
|
|
156
|
+
|
|
157
|
+
|
|
158
|
+
|
|
159
|
+
|
|
160
|
+
|
|
161
|
+
<br>
|
|
162
|
+
|
|
163
|
+
|
|
164
|
+
|
|
165
|
+
|
|
166
|
+
|
|
167
|
+
</body></html>
|
|
@@ -0,0 +1,1669 @@
|
|
|
1
|
+
<HTML>
|
|
2
|
+
<HEAD>
|
|
3
|
+
<TITLE>ID3 tag version</TITLE>
|
|
4
|
+
</HEAD>
|
|
5
|
+
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" VLINK="#051271" LINK="#0000B1" ALINK="#A21600">
|
|
6
|
+
<PRE>
|
|
7
|
+
|
|
8
|
+
Informal standard M. Nilsson
|
|
9
|
+
Document: id3v2-00.txt 26th March 1998
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
ID3 tag version 2
|
|
13
|
+
|
|
14
|
+
Status of this document
|
|
15
|
+
|
|
16
|
+
This document is an Informal standard and is released so that
|
|
17
|
+
implementors could have a set standard before the formal standard is
|
|
18
|
+
set. The formal standard will use another version number if not
|
|
19
|
+
identical to what is described in this document. The contents in this
|
|
20
|
+
document may change for clarifications but never for added or altered
|
|
21
|
+
functionallity.
|
|
22
|
+
|
|
23
|
+
Distribution of this document is unlimited.
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
Abstract
|
|
27
|
+
|
|
28
|
+
The recent gain of popularity for MPEG layer III audio files on the
|
|
29
|
+
internet forced a standardised way of storing information about an
|
|
30
|
+
audio file within itself to determinate its origin and contents.
|
|
31
|
+
|
|
32
|
+
Today the most accepted way to do this is with the so called ID3 tag,
|
|
33
|
+
which is simple but very limited and in some cases very unsuitable.
|
|
34
|
+
The ID3 tag has very limited space in every field, very limited
|
|
35
|
+
numbers of fields, not expandable or upgradeable and is placed at the
|
|
36
|
+
end of a the file, which is unsuitable for streaming audio. This draft
|
|
37
|
+
is an attempt to answer these issues with a new version of the ID3
|
|
38
|
+
tag.
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
1. Table of contents
|
|
42
|
+
|
|
43
|
+
2. Conventions in this document
|
|
44
|
+
3. ID3v2 overview
|
|
45
|
+
3.1. ID3v2 header
|
|
46
|
+
3.2. ID3v2 frames overview
|
|
47
|
+
4. Declared ID3v2 frames
|
|
48
|
+
4.1. Unique file identifier
|
|
49
|
+
4.2. Text information frames
|
|
50
|
+
4.2.1. Text information frames - details
|
|
51
|
+
4.2.2. User defined text information frame
|
|
52
|
+
4.3. URL link frames
|
|
53
|
+
4.3.1. URL link frames - details
|
|
54
|
+
4.3.2. User defined URL link frame
|
|
55
|
+
4.4. Involved people list
|
|
56
|
+
4.5. Music CD Identifier
|
|
57
|
+
4.6. Event timing codes
|
|
58
|
+
4.7. MPEG location lookup table
|
|
59
|
+
4.8. Synced tempo codes
|
|
60
|
+
4.9. Unsychronised lyrics/text transcription
|
|
61
|
+
4.10. Synchronised lyrics/text
|
|
62
|
+
4.11. Comments
|
|
63
|
+
4.12. Relative volume adjustment
|
|
64
|
+
4.13. Equalisation
|
|
65
|
+
4.14. Reverb
|
|
66
|
+
4.15. Attached picture
|
|
67
|
+
4.16. General encapsulated object
|
|
68
|
+
4.17. Play counter
|
|
69
|
+
4.18. Popularimeter
|
|
70
|
+
4.19. Recommended buffer size
|
|
71
|
+
4.20. Encrypted meta frame
|
|
72
|
+
4.21. Audio encryption
|
|
73
|
+
4.22. Linked information
|
|
74
|
+
5. The 'unsynchronisation scheme'
|
|
75
|
+
6. Copyright
|
|
76
|
+
7. References
|
|
77
|
+
8. Appendix
|
|
78
|
+
A. Appendix A - ID3-Tag Specification V1.1
|
|
79
|
+
A.1. Overview
|
|
80
|
+
A.2. ID3v1 Implementation
|
|
81
|
+
A.3. Genre List
|
|
82
|
+
A.4. Track addition - ID3v1.1
|
|
83
|
+
9. Author's Address
|
|
84
|
+
|
|
85
|
+
|
|
86
|
+
2. Conventions in this document
|
|
87
|
+
|
|
88
|
+
In the examples, text within "" is a text string exactly as it appears
|
|
89
|
+
in a file. Numbers preceded with $ are hexadecimal and numbers
|
|
90
|
+
preceded with % are binary. $xx is used to indicate a byte with
|
|
91
|
+
unknown content. %x is used to indicate a bit with unknown content.
|
|
92
|
+
The most significant bit (MSB) of a byte is called 'bit 7' and the
|
|
93
|
+
least significant bit (LSB) is called 'bit 0'.
|
|
94
|
+
|
|
95
|
+
A tag is the whole tag described in this document. A frame is a block
|
|
96
|
+
of information in the tag. The tag consists of a header, frames and
|
|
97
|
+
optional padding. A field is a piece of information; one value, a
|
|
98
|
+
string etc. A numeric string is a string that consists of the
|
|
99
|
+
characters 0-9 only.
|
|
100
|
+
|
|
101
|
+
|
|
102
|
+
3. ID3v2 overview
|
|
103
|
+
|
|
104
|
+
The two biggest design goals were to be able to implement ID3v2
|
|
105
|
+
without disturbing old software too much and that ID3v2 should be
|
|
106
|
+
expandable.
|
|
107
|
+
|
|
108
|
+
The first criterion is met by the simple fact that the MPEG [MPEG]
|
|
109
|
+
decoding software uses a syncsignal, embedded in the audiostream, to
|
|
110
|
+
'lock on to' the audio. Since the ID3v2 tag doesn't contain a valid
|
|
111
|
+
syncsignal, no software will attempt to play the tag. If, for any
|
|
112
|
+
reason, coincidence make a syncsignal appear within the tag it will be
|
|
113
|
+
taken care of by the 'unsynchronisation scheme' described in section
|
|
114
|
+
5.
|
|
115
|
+
|
|
116
|
+
The second criterion has made a more noticeable impact on the design
|
|
117
|
+
of the ID3v2 tag. It is constructed as a container for several
|
|
118
|
+
information blocks, called frames, whose format need not be known to
|
|
119
|
+
the software that encounters them. At the start of every frame there
|
|
120
|
+
is an identifier that explains the frames's format and content, and a
|
|
121
|
+
size descriptor that allows software to skip unknown frames.
|
|
122
|
+
|
|
123
|
+
If a total revision of the ID3v2 tag should be needed, there is a
|
|
124
|
+
version number and a size descriptor in the ID3v2 header.
|
|
125
|
+
|
|
126
|
+
The ID3 tag described in this document is mainly targeted to files
|
|
127
|
+
encoded with MPEG-2 layer I, MPEG-2 layer II, MPEG-2 layer III and
|
|
128
|
+
MPEG-2.5, but may work with other types of encoded audio.
|
|
129
|
+
|
|
130
|
+
The bitorder in ID3v2 is most significant bit first (MSB). The
|
|
131
|
+
byteorder in multibyte numbers is most significant byte first (e.g.
|
|
132
|
+
$12345678 would be encoded $12 34 56 78).
|
|
133
|
+
|
|
134
|
+
It is permitted to include padding after all the final frame (at the
|
|
135
|
+
end of the ID3 tag), making the size of all the frames together
|
|
136
|
+
smaller than the size given in the head of the tag. A possible purpose
|
|
137
|
+
of this padding is to allow for adding a few additional frames or
|
|
138
|
+
enlarge existing frames within the tag without having to rewrite the
|
|
139
|
+
entire file. The value of the padding bytes must be $00.
|
|
140
|
+
|
|
141
|
+
|
|
142
|
+
3.1. ID3v2 header
|
|
143
|
+
|
|
144
|
+
The ID3v2 tag header, which should be the first information in the
|
|
145
|
+
file, is 10 bytes as follows:
|
|
146
|
+
|
|
147
|
+
ID3/file identifier "ID3"
|
|
148
|
+
ID3 version $02 00
|
|
149
|
+
ID3 flags %xx000000
|
|
150
|
+
ID3 size 4 * %0xxxxxxx
|
|
151
|
+
|
|
152
|
+
The first three bytes of the tag are always "ID3" to indicate that
|
|
153
|
+
this is an ID3 tag, directly followed by the two version bytes. The
|
|
154
|
+
first byte of ID3 version is it's major version, while the second byte
|
|
155
|
+
is its revision number. All revisions are backwards compatible while
|
|
156
|
+
major versions are not. If software with ID3v2 and below support
|
|
157
|
+
should encounter version three or higher it should simply ignore the
|
|
158
|
+
whole tag. Version and revision will never be $FF.
|
|
159
|
+
|
|
160
|
+
The first bit (bit 7) in the 'ID3 flags' is indicating whether or not
|
|
161
|
+
unsynchronisation is used (see section 5 for details); a set bit
|
|
162
|
+
indicates usage.
|
|
163
|
+
|
|
164
|
+
The second bit (bit 6) is indicating whether or not compression is
|
|
165
|
+
used; a set bit indicates usage. Since no compression scheme has been
|
|
166
|
+
decided yet, the ID3 decoder (for now) should just ignore the entire
|
|
167
|
+
tag if the compression bit is set.
|
|
168
|
+
|
|
169
|
+
The ID3 tag size is encoded with four bytes where the first bit (bit
|
|
170
|
+
7) is set to zero in every byte, making a total of 28 bits. The zeroed
|
|
171
|
+
bits are ignored, so a 257 bytes long tag is represented as $00 00 02
|
|
172
|
+
01.
|
|
173
|
+
|
|
174
|
+
The ID3 tag size is the size of the complete tag after
|
|
175
|
+
unsychronisation, including padding, excluding the header (total tag
|
|
176
|
+
size - 10). The reason to use 28 bits (representing up to 256MB) for
|
|
177
|
+
size description is that we don't want to run out of space here.
|
|
178
|
+
|
|
179
|
+
A ID3v2 tag can be detected with the following pattern:
|
|
180
|
+
$49 44 33 yy yy xx zz zz zz zz
|
|
181
|
+
Where yy is less than $FF, xx is the 'flags' byte and zz is less than
|
|
182
|
+
$80.
|
|
183
|
+
|
|
184
|
+
|
|
185
|
+
3.2. ID3v2 frames overview
|
|
186
|
+
|
|
187
|
+
The headers of the frames are similar in their construction. They
|
|
188
|
+
consist of one three character identifier (capital A-Z and 0-9) and
|
|
189
|
+
one three byte size field, making a total of six bytes. The header is
|
|
190
|
+
excluded from the size. Identifiers beginning with "X", "Y" and "Z"
|
|
191
|
+
are for experimental use and free for everyone to use. Have in mind
|
|
192
|
+
that someone else might have used the same identifier as you. All
|
|
193
|
+
other identifiers are either used or reserved for future use.
|
|
194
|
+
|
|
195
|
+
The three character frame identifier is followed by a three byte size
|
|
196
|
+
descriptor, making a total header size of six bytes in every frame.
|
|
197
|
+
The size is calculated as framesize excluding frame identifier and
|
|
198
|
+
size descriptor (frame size - 6).
|
|
199
|
+
|
|
200
|
+
There is no fixed order of the frames' appearance in the tag, although
|
|
201
|
+
it is desired that the frames are arranged in order of significance
|
|
202
|
+
concerning the recognition of the file. An example of such order:
|
|
203
|
+
UFI, MCI, TT2 ...
|
|
204
|
+
|
|
205
|
+
A tag must contain at least one frame. A frame must be at least 1 byte
|
|
206
|
+
big, excluding the 6-byte header.
|
|
207
|
+
|
|
208
|
+
If nothing else is said a string is represented as ISO-8859-1
|
|
209
|
+
[ISO-8859-1] characters in the range $20 - $FF. All unicode strings
|
|
210
|
+
[UNICODE] use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). All
|
|
211
|
+
numeric strings are always encoded as ISO-8859-1. Terminated strings
|
|
212
|
+
are terminated with $00 if encoded with ISO-8859-1 and $00 00 if
|
|
213
|
+
encoded as unicode. If nothing else is said newline character is
|
|
214
|
+
forbidden. In ISO-8859-1 a new line is represented, when allowed, with
|
|
215
|
+
$0A only. Frames that allow different types of text encoding have a
|
|
216
|
+
text encoding description byte directly after the frame size. If
|
|
217
|
+
ISO-8859-1 is used this byte should be $00, if unicode is used it
|
|
218
|
+
should be $01.
|
|
219
|
+
|
|
220
|
+
The three byte language field is used to describe the language of the
|
|
221
|
+
frame's content, according to ISO-639-2 [ISO-639-2].
|
|
222
|
+
|
|
223
|
+
All URLs [URL] may be relative, e.g. "picture.png", "../doc.txt".
|
|
224
|
+
|
|
225
|
+
If a frame is longer than it should be, e.g. having more fields than
|
|
226
|
+
specified in this document, that indicates that additions to the
|
|
227
|
+
frame have been made in a later version of the ID3 standard. This
|
|
228
|
+
is reflected by the revision number in the header of the tag.
|
|
229
|
+
|
|
230
|
+
|
|
231
|
+
4. Declared ID3v2 frames
|
|
232
|
+
|
|
233
|
+
The following frames are declared in this draft.
|
|
234
|
+
|
|
235
|
+
4.19 BUF Recommended buffer size
|
|
236
|
+
|
|
237
|
+
4.17 CNT Play counter
|
|
238
|
+
4.11 COM Comments
|
|
239
|
+
4.21 CRA Audio encryption
|
|
240
|
+
4.20 CRM Encrypted meta frame
|
|
241
|
+
|
|
242
|
+
4.6 ETC Event timing codes
|
|
243
|
+
4.13 EQU Equalization
|
|
244
|
+
|
|
245
|
+
4.16 GEO General encapsulated object
|
|
246
|
+
|
|
247
|
+
4.4 IPL Involved people list
|
|
248
|
+
|
|
249
|
+
4.22 LNK Linked information
|
|
250
|
+
|
|
251
|
+
4.5 MCI Music CD Identifier
|
|
252
|
+
4.7 MLL MPEG location lookup table
|
|
253
|
+
|
|
254
|
+
4.15 PIC Attached picture
|
|
255
|
+
4.18 POP Popularimeter
|
|
256
|
+
|
|
257
|
+
4.14 REV Reverb
|
|
258
|
+
4.12 RVA Relative volume adjustment
|
|
259
|
+
|
|
260
|
+
4.10 SLT Synchronized lyric/text
|
|
261
|
+
4.8 STC Synced tempo codes
|
|
262
|
+
|
|
263
|
+
4.2.1 TAL Album/Movie/Show title
|
|
264
|
+
4.2.1 TBP BPM (Beats Per Minute)
|
|
265
|
+
4.2.1 TCM Composer
|
|
266
|
+
4.2.1 TCO Content type
|
|
267
|
+
4.2.1 TCR Copyright message
|
|
268
|
+
4.2.1 TDA Date
|
|
269
|
+
4.2.1 TDY Playlist delay
|
|
270
|
+
4.2.1 TEN Encoded by
|
|
271
|
+
4.2.1 TFT File type
|
|
272
|
+
4.2.1 TIM Time
|
|
273
|
+
4.2.1 TKE Initial key
|
|
274
|
+
4.2.1 TLA Language(s)
|
|
275
|
+
4.2.1 TLE Length
|
|
276
|
+
4.2.1 TMT Media type
|
|
277
|
+
4.2.1 TOA Original artist(s)/performer(s)
|
|
278
|
+
4.2.1 TOF Original filename
|
|
279
|
+
4.2.1 TOL Original Lyricist(s)/text writer(s)
|
|
280
|
+
4.2.1 TOR Original release year
|
|
281
|
+
4.2.1 TOT Original album/Movie/Show title
|
|
282
|
+
4.2.1 TP1 Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group
|
|
283
|
+
4.2.1 TP2 Band/Orchestra/Accompaniment
|
|
284
|
+
4.2.1 TP3 Conductor/Performer refinement
|
|
285
|
+
4.2.1 TP4 Interpreted, remixed, or otherwise modified by
|
|
286
|
+
4.2.1 TPA Part of a set
|
|
287
|
+
4.2.1 TPB Publisher
|
|
288
|
+
4.2.1 TRC ISRC (International Standard Recording Code)
|
|
289
|
+
4.2.1 TRD Recording dates
|
|
290
|
+
4.2.1 TRK Track number/Position in set
|
|
291
|
+
4.2.1 TSI Size
|
|
292
|
+
4.2.1 TSS Software/hardware and settings used for encoding
|
|
293
|
+
4.2.1 TT1 Content group description
|
|
294
|
+
4.2.1 TT2 Title/Songname/Content description
|
|
295
|
+
4.2.1 TT3 Subtitle/Description refinement
|
|
296
|
+
4.2.1 TXT Lyricist/text writer
|
|
297
|
+
4.2.2 TXX User defined text information frame
|
|
298
|
+
4.2.1 TYE Year
|
|
299
|
+
|
|
300
|
+
4.1 UFI Unique file identifier
|
|
301
|
+
4.9 ULT Unsychronized lyric/text transcription
|
|
302
|
+
|
|
303
|
+
4.3.1 WAF Official audio file webpage
|
|
304
|
+
4.3.1 WAR Official artist/performer webpage
|
|
305
|
+
4.3.1 WAS Official audio source webpage
|
|
306
|
+
4.3.1 WCM Commercial information
|
|
307
|
+
4.3.1 WCP Copyright/Legal information
|
|
308
|
+
4.3.1 WPB Publishers official webpage
|
|
309
|
+
4.3.2 WXX User defined URL link frame
|
|
310
|
+
|
|
311
|
+
<A NAME=UFI>
|
|
312
|
+
4.1. Unique file identifier</A>
|
|
313
|
+
|
|
314
|
+
This frame's purpose is to be able to identify the audio file in a
|
|
315
|
+
database that may contain more information relevant to the content.
|
|
316
|
+
Since standardisation of such a database is beyond this document, all
|
|
317
|
+
frames begin with a null-terminated string with a URL [URL] containing
|
|
318
|
+
an email address, or a link to a location where an email address can
|
|
319
|
+
be found, that belongs to the organisation responsible for this
|
|
320
|
+
specific database implementation. Questions regarding the database
|
|
321
|
+
should be sent to the indicated email address. The URL should not be
|
|
322
|
+
used for the actual database queries. If a $00 is found directly after
|
|
323
|
+
the 'Frame size' the whole frame should be ignored, and preferably be
|
|
324
|
+
removed. The 'Owner identifier' is then followed by the actual
|
|
325
|
+
identifier, which may be up to 64 bytes. There may be more than one
|
|
326
|
+
"UFI" frame in a tag, but only one with the same 'Owner identifier'.
|
|
327
|
+
|
|
328
|
+
Unique file identifier "UFI"
|
|
329
|
+
Frame size $xx xx xx
|
|
330
|
+
Owner identifier <textstring> $00
|
|
331
|
+
Identifier <up to 64 bytes binary data>
|
|
332
|
+
|
|
333
|
+
<A NAME=TEXTFRAMES>
|
|
334
|
+
4.2. Text information frames</A>
|
|
335
|
+
|
|
336
|
+
The text information frames are the most important frames, containing
|
|
337
|
+
information like artist, album and more. There may only be one text
|
|
338
|
+
information frame of its kind in an tag. If the textstring is followed
|
|
339
|
+
by a termination ($00 (00)) all the following information should be
|
|
340
|
+
ignored and not be displayed. All the text information frames have the
|
|
341
|
+
following format:
|
|
342
|
+
|
|
343
|
+
Text information identifier "T00" - "TZZ" , excluding "TXX",
|
|
344
|
+
described in 4.2.2.
|
|
345
|
+
Frame size $xx xx xx
|
|
346
|
+
Text encoding $xx
|
|
347
|
+
Information <textstring>
|
|
348
|
+
|
|
349
|
+
|
|
350
|
+
4.2.1. Text information frames - details
|
|
351
|
+
|
|
352
|
+
<A NAME=TT1>TT1</A>
|
|
353
|
+
The 'Content group description' frame is used if the sound belongs to
|
|
354
|
+
a larger category of sounds/music. For example, classical music is
|
|
355
|
+
often sorted in different musical sections (e.g. "Piano Concerto",
|
|
356
|
+
"Weather - Hurricane").
|
|
357
|
+
|
|
358
|
+
<A NAME=TT2>TT2</A>
|
|
359
|
+
The 'Title/Songname/Content description' frame is the actual name of
|
|
360
|
+
the piece (e.g. "Adagio", "Hurricane Donna").
|
|
361
|
+
|
|
362
|
+
<A NAME=TT3>TT3</A>
|
|
363
|
+
The 'Subtitle/Description refinement' frame is used for information
|
|
364
|
+
directly related to the contents title (e.g. "Op. 16" or "Performed
|
|
365
|
+
live at wembley").
|
|
366
|
+
|
|
367
|
+
<A NAME=TP1>TP1</A>
|
|
368
|
+
The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is
|
|
369
|
+
used for the main artist(s). They are seperated with the "/"
|
|
370
|
+
character.
|
|
371
|
+
|
|
372
|
+
<A NAME=TP2>TP2</A>
|
|
373
|
+
The 'Band/Orchestra/Accompaniment' frame is used for additional
|
|
374
|
+
information about the performers in the recording.
|
|
375
|
+
|
|
376
|
+
<A NAME=TP3>TP3</A>
|
|
377
|
+
The 'Conductor' frame is used for the name of the conductor.
|
|
378
|
+
|
|
379
|
+
<A NAME=TP4>TP4</A>
|
|
380
|
+
The 'Interpreted, remixed, or otherwise modified by' frame contains
|
|
381
|
+
more information about the people behind a remix and similar
|
|
382
|
+
interpretations of another existing piece.
|
|
383
|
+
|
|
384
|
+
<A NAME=TCM>TCM</A>
|
|
385
|
+
The 'Composer(s)' frame is intended for the name of the composer(s).
|
|
386
|
+
They are seperated with the "/" character.
|
|
387
|
+
|
|
388
|
+
<A NAME=TXT>TXT</A>
|
|
389
|
+
The 'Lyricist(s)/text writer(s)' frame is intended for the writer(s)
|
|
390
|
+
of the text or lyrics in the recording. They are seperated with the
|
|
391
|
+
"/" character.
|
|
392
|
+
|
|
393
|
+
<A NAME=TLA>TLA</A>
|
|
394
|
+
The 'Language(s)' frame should contain the languages of the text or
|
|
395
|
+
lyrics in the audio file. The language is represented with three
|
|
396
|
+
characters according to ISO-639-2. If more than one language is used
|
|
397
|
+
in the text their language codes should follow according to their
|
|
398
|
+
usage.
|
|
399
|
+
|
|
400
|
+
<A NAME=TCO>TCO</A>
|
|
401
|
+
The content type, which previously (in ID3v1.1, see appendix A) was
|
|
402
|
+
stored as a one byte numeric value only, is now a numeric string. You
|
|
403
|
+
may use one or several of the types as ID3v1.1 did or, since the
|
|
404
|
+
category list would be impossible to maintain with accurate and up to
|
|
405
|
+
date categories, define your own.
|
|
406
|
+
References to the ID3v1 genres can be made by, as first byte, enter
|
|
407
|
+
"(" followed by a number from the genres list (section A.3.) and
|
|
408
|
+
ended with a ")" character. This is optionally followed by a
|
|
409
|
+
refinement, e.g. "(21)" or "(4)Eurodisco". Several references can be
|
|
410
|
+
made in the same frame, e.g. "(51)(39)". If the refinement should
|
|
411
|
+
begin with a "(" character it should be replaced with "((", e.g. "((I
|
|
412
|
+
can figure out any genre)" or "(55)((I think...)". The following new
|
|
413
|
+
content types is defined in ID3v2 and is implemented in the same way
|
|
414
|
+
as the numerig content types, e.g. "(RX)".
|
|
415
|
+
|
|
416
|
+
RX Remix
|
|
417
|
+
CR Cover
|
|
418
|
+
|
|
419
|
+
<A NAME=TAL>TAL</A>
|
|
420
|
+
The 'Album/Movie/Show title' frame is intended for the title of the
|
|
421
|
+
recording(/source of sound) which the audio in the file is taken from.
|
|
422
|
+
|
|
423
|
+
<A NAME=TPA>TPA</A>
|
|
424
|
+
The 'Part of a set' frame is a numeric string that describes which
|
|
425
|
+
part of a set the audio came from. This frame is used if the source
|
|
426
|
+
described in the "TAL" frame is divided into several mediums, e.g. a
|
|
427
|
+
double CD. The value may be extended with a "/" character and a
|
|
428
|
+
numeric string containing the total number of parts in the set. E.g.
|
|
429
|
+
"1/2".
|
|
430
|
+
|
|
431
|
+
<A NAME=TRK>TRK</A>
|
|
432
|
+
The 'Track number/Position in set' frame is a numeric string
|
|
433
|
+
containing the order number of the audio-file on its original
|
|
434
|
+
recording. This may be extended with a "/" character and a numeric
|
|
435
|
+
string containing the total numer of tracks/elements on the original
|
|
436
|
+
recording. E.g. "4/9".
|
|
437
|
+
|
|
438
|
+
<A NAME=TRC>TRC</A>
|
|
439
|
+
The 'ISRC' frame should contian the International Standard Recording
|
|
440
|
+
Code [ISRC].
|
|
441
|
+
|
|
442
|
+
<A NAME=TYE>TYE</A>
|
|
443
|
+
The 'Year' frame is a numeric string with a year of the recording.
|
|
444
|
+
This frames is always four characters long (until the year 10000).
|
|
445
|
+
|
|
446
|
+
<A NAME=TDA>TDA</A>
|
|
447
|
+
The 'Date' frame is a numeric string in the DDMM format containing
|
|
448
|
+
the date for the recording. This field is always four characters
|
|
449
|
+
long.
|
|
450
|
+
|
|
451
|
+
<A NAME=TIM>TIM</A>
|
|
452
|
+
The 'Time' frame is a numeric string in the HHMM format containing
|
|
453
|
+
the time for the recording. This field is always four characters
|
|
454
|
+
long.
|
|
455
|
+
|
|
456
|
+
<A NAME=TRD>TRD</A>
|
|
457
|
+
The 'Recording dates' frame is a intended to be used as complement to
|
|
458
|
+
the "TYE", "TDA" and "TIM" frames. E.g. "4th-7th June, 12th June" in
|
|
459
|
+
combination with the "TYE" frame.
|
|
460
|
+
|
|
461
|
+
<A NAME=TMT>TMT</A>
|
|
462
|
+
The 'Media type' frame describes from which media the sound
|
|
463
|
+
originated. This may be a textstring or a reference to the predefined
|
|
464
|
+
media types found in the list below. References are made within "("
|
|
465
|
+
and ")" and are optionally followed by a text refinement, e.g. "(MC)
|
|
466
|
+
with four channels". If a text refinement should begin with a "("
|
|
467
|
+
character it should be replaced with "((" in the same way as in the
|
|
468
|
+
"TCO" frame. Predefined refinements is appended after the media type,
|
|
469
|
+
e.g. "(CD/S)" or "(VID/PAL/VHS)".
|
|
470
|
+
|
|
471
|
+
DIG Other digital media
|
|
472
|
+
/A Analog transfer from media
|
|
473
|
+
|
|
474
|
+
ANA Other analog media
|
|
475
|
+
/WAC Wax cylinder
|
|
476
|
+
/8CA 8-track tape cassette
|
|
477
|
+
|
|
478
|
+
CD CD
|
|
479
|
+
/A Analog transfer from media
|
|
480
|
+
/DD DDD
|
|
481
|
+
/AD ADD
|
|
482
|
+
/AA AAD
|
|
483
|
+
|
|
484
|
+
LD Laserdisc
|
|
485
|
+
/A Analog transfer from media
|
|
486
|
+
|
|
487
|
+
TT Turntable records
|
|
488
|
+
/33 33.33 rpm
|
|
489
|
+
/45 45 rpm
|
|
490
|
+
/71 71.29 rpm
|
|
491
|
+
/76 76.59 rpm
|
|
492
|
+
/78 78.26 rpm
|
|
493
|
+
/80 80 rpm
|
|
494
|
+
|
|
495
|
+
MD MiniDisc
|
|
496
|
+
/A Analog transfer from media
|
|
497
|
+
|
|
498
|
+
DAT DAT
|
|
499
|
+
/A Analog transfer from media
|
|
500
|
+
/1 standard, 48 kHz/16 bits, linear
|
|
501
|
+
/2 mode 2, 32 kHz/16 bits, linear
|
|
502
|
+
/3 mode 3, 32 kHz/12 bits, nonlinear, low speed
|
|
503
|
+
/4 mode 4, 32 kHz/12 bits, 4 channels
|
|
504
|
+
/5 mode 5, 44.1 kHz/16 bits, linear
|
|
505
|
+
/6 mode 6, 44.1 kHz/16 bits, 'wide track' play
|
|
506
|
+
|
|
507
|
+
DCC DCC
|
|
508
|
+
/A Analog transfer from media
|
|
509
|
+
|
|
510
|
+
DVD DVD
|
|
511
|
+
/A Analog transfer from media
|
|
512
|
+
|
|
513
|
+
TV Television
|
|
514
|
+
/PAL PAL
|
|
515
|
+
/NTSC NTSC
|
|
516
|
+
/SECAM SECAM
|
|
517
|
+
|
|
518
|
+
VID Video
|
|
519
|
+
/PAL PAL
|
|
520
|
+
/NTSC NTSC
|
|
521
|
+
/SECAM SECAM
|
|
522
|
+
/VHS VHS
|
|
523
|
+
/SVHS S-VHS
|
|
524
|
+
/BETA BETAMAX
|
|
525
|
+
|
|
526
|
+
RAD Radio
|
|
527
|
+
/FM FM
|
|
528
|
+
/AM AM
|
|
529
|
+
/LW LW
|
|
530
|
+
/MW MW
|
|
531
|
+
|
|
532
|
+
TEL Telephone
|
|
533
|
+
/I ISDN
|
|
534
|
+
|
|
535
|
+
MC MC (normal cassette)
|
|
536
|
+
/4 4.75 cm/s (normal speed for a two sided cassette)
|
|
537
|
+
/9 9.5 cm/s
|
|
538
|
+
/I Type I cassette (ferric/normal)
|
|
539
|
+
/II Type II cassette (chrome)
|
|
540
|
+
/III Type III cassette (ferric chrome)
|
|
541
|
+
/IV Type IV cassette (metal)
|
|
542
|
+
|
|
543
|
+
REE Reel
|
|
544
|
+
/9 9.5 cm/s
|
|
545
|
+
/19 19 cm/s
|
|
546
|
+
/38 38 cm/s
|
|
547
|
+
/76 76 cm/s
|
|
548
|
+
/I Type I cassette (ferric/normal)
|
|
549
|
+
/II Type II cassette (chrome)
|
|
550
|
+
/III Type III cassette (ferric chrome)
|
|
551
|
+
/IV Type IV cassette (metal)
|
|
552
|
+
|
|
553
|
+
<A NAME=TFT>TFT</A>
|
|
554
|
+
The 'File type' frame indicates which type of audio this tag defines.
|
|
555
|
+
The following type and refinements are defined:
|
|
556
|
+
|
|
557
|
+
MPG MPEG Audio
|
|
558
|
+
/1 MPEG 2 layer I
|
|
559
|
+
/2 MPEG 2 layer II
|
|
560
|
+
/3 MPEG 2 layer III
|
|
561
|
+
/2.5 MPEG 2.5
|
|
562
|
+
/AAC Advanced audio compression
|
|
563
|
+
|
|
564
|
+
but other types may be used, not for these types though. This is used
|
|
565
|
+
in a similar way to the predefined types in the "TMT" frame, but
|
|
566
|
+
without parenthesis. If this frame is not present audio type is
|
|
567
|
+
assumed to be "MPG".
|
|
568
|
+
|
|
569
|
+
<A NAME=TBP>TBP</A>
|
|
570
|
+
BPM is short for beats per minute, and is easily computed by
|
|
571
|
+
dividing the number of beats in a musical piece with its length. To
|
|
572
|
+
get a more accurate result, do the BPM calculation on the main-part
|
|
573
|
+
only. To acquire best result measure the time between each beat and
|
|
574
|
+
calculate individual BPM for each beat and use the median value as
|
|
575
|
+
result. BPM is an integer and represented as a numerical string.
|
|
576
|
+
|
|
577
|
+
<A NAME=TCR>TCR</A>
|
|
578
|
+
The 'Copyright message' frame, which must begin with a year and a
|
|
579
|
+
space character (making five characters), is intended for the
|
|
580
|
+
copyright holder of the original sound, not the audio file itself. The
|
|
581
|
+
absence of this frame means only that the copyright information is
|
|
582
|
+
unavailable or has been removed, and must not be interpreted to mean
|
|
583
|
+
that the sound is public domain. Every time this field is displayed
|
|
584
|
+
the field must be preceded with "Copyright " (C) " ", where (C) is one
|
|
585
|
+
character showing a C in a circle.
|
|
586
|
+
|
|
587
|
+
<A NAME=TPB>TPB</A>
|
|
588
|
+
The 'Publisher' frame simply contains the name of the label or
|
|
589
|
+
publisher.
|
|
590
|
+
|
|
591
|
+
<A NAME=TEN>TEN</A>
|
|
592
|
+
The 'Encoded by' frame contains the name of the person or
|
|
593
|
+
organisation that encoded the audio file. This field may contain a
|
|
594
|
+
copyright message, if the audio file also is copyrighted by the
|
|
595
|
+
encoder.
|
|
596
|
+
|
|
597
|
+
<A NAME=TSS>TSS</A>
|
|
598
|
+
The 'Software/hardware and settings used for encoding' frame
|
|
599
|
+
includes the used audio encoder and its settings when the file was
|
|
600
|
+
encoded. Hardware refers to hardware encoders, not the computer on
|
|
601
|
+
which a program was run.
|
|
602
|
+
|
|
603
|
+
<A NAME=TOF>TOF</A>
|
|
604
|
+
The 'Original filename' frame contains the preferred filename for the
|
|
605
|
+
file, since some media doesn't allow the desired length of the
|
|
606
|
+
filename. The filename is case sensitive and includes its suffix.
|
|
607
|
+
|
|
608
|
+
<A NAME=TLE>TLE</A>
|
|
609
|
+
The 'Length' frame contains the length of the audiofile in
|
|
610
|
+
milliseconds, represented as a numeric string.
|
|
611
|
+
|
|
612
|
+
<A NAME=TSI>TSI</A>
|
|
613
|
+
The 'Size' frame contains the size of the audiofile in bytes
|
|
614
|
+
excluding the tag, represented as a numeric string.
|
|
615
|
+
|
|
616
|
+
<A NAME=TDY>TDY</A>
|
|
617
|
+
The 'Playlist delay' defines the numbers of milliseconds of silence
|
|
618
|
+
between every song in a playlist. The player should use the "ETC"
|
|
619
|
+
frame, if present, to skip initial silence and silence at the end of
|
|
620
|
+
the audio to match the 'Playlist delay' time. The time is represented
|
|
621
|
+
as a numeric string.
|
|
622
|
+
|
|
623
|
+
<A NAME=TKE>TKE</A>
|
|
624
|
+
The 'Initial key' frame contains the musical key in which the sound
|
|
625
|
+
starts. It is represented as a string with a maximum length of three
|
|
626
|
+
characters. The ground keys are represented with "A","B","C","D","E",
|
|
627
|
+
"F" and "G" and halfkeys represented with "b" and "#". Minor is
|
|
628
|
+
represented as "m". Example "Cbm". Off key is represented with an "o"
|
|
629
|
+
only.
|
|
630
|
+
|
|
631
|
+
<A NAME=TOT>TOT</A>
|
|
632
|
+
The 'Original album/Movie/Show title' frame is intended for the title
|
|
633
|
+
of the original recording(/source of sound), if for example the music
|
|
634
|
+
in the file should be a cover of a previously released song.
|
|
635
|
+
|
|
636
|
+
<A NAME=TOA>TOA</A>
|
|
637
|
+
The 'Original artist(s)/performer(s)' frame is intended for the
|
|
638
|
+
performer(s) of the original recording, if for example the music in
|
|
639
|
+
the file should be a cover of a previously released song. The
|
|
640
|
+
performers are seperated with the "/" character.
|
|
641
|
+
|
|
642
|
+
<A NAME=TOL>TOL</A>
|
|
643
|
+
The 'Original Lyricist(s)/text writer(s)' frame is intended for the
|
|
644
|
+
text writer(s) of the original recording, if for example the music in
|
|
645
|
+
the file should be a cover of a previously released song. The text
|
|
646
|
+
writers are seperated with the "/" character.
|
|
647
|
+
|
|
648
|
+
<A NAME=TOR>TOR</A>
|
|
649
|
+
The 'Original release year' frame is intended for the year when the
|
|
650
|
+
original recording, if for example the music in the file should be a
|
|
651
|
+
cover of a previously released song, was released. The field is
|
|
652
|
+
formatted as in the "TDY" frame.
|
|
653
|
+
|
|
654
|
+
<A NAME=TXX>
|
|
655
|
+
4.2.2. User defined text information frame</A>
|
|
656
|
+
|
|
657
|
+
This frame is intended for one-string text information concerning the
|
|
658
|
+
audiofile in a similar way to the other "T"xx frames. The frame body
|
|
659
|
+
consists of a description of the string, represented as a terminated
|
|
660
|
+
string, followed by the actual string. There may be more than one
|
|
661
|
+
"TXX" frame in each tag, but only one with the same description.
|
|
662
|
+
|
|
663
|
+
User defined... "TXX"
|
|
664
|
+
Frame size $xx xx xx
|
|
665
|
+
Text encoding $xx
|
|
666
|
+
Description <textstring> $00 (00)
|
|
667
|
+
Value <textstring>
|
|
668
|
+
|
|
669
|
+
|
|
670
|
+
4.3. URL link frames
|
|
671
|
+
|
|
672
|
+
With these frames dynamic data such as webpages with touring
|
|
673
|
+
information, price information or plain ordinary news can be added to
|
|
674
|
+
the tag. There may only be one URL [URL] link frame of its kind in an
|
|
675
|
+
tag, except when stated otherwise in the frame description. If the
|
|
676
|
+
textstring is followed by a termination ($00 (00)) all the following
|
|
677
|
+
information should be ignored and not be displayed. All URL link
|
|
678
|
+
frames have the following format:
|
|
679
|
+
|
|
680
|
+
URL link frame "W00" - "WZZ" , excluding "WXX"
|
|
681
|
+
(described in 4.3.2.)
|
|
682
|
+
Frame size $xx xx xx
|
|
683
|
+
URL <textstring>
|
|
684
|
+
|
|
685
|
+
|
|
686
|
+
4.3.1. URL link frames - details
|
|
687
|
+
|
|
688
|
+
<A NAME=WAF>WAF</A>
|
|
689
|
+
The 'Official audio file webpage' frame is a URL pointing at a file
|
|
690
|
+
specific webpage.
|
|
691
|
+
|
|
692
|
+
<A NAME=WAR>WAR</A>
|
|
693
|
+
The 'Official artist/performer webpage' frame is a URL pointing at
|
|
694
|
+
the artists official webpage. There may be more than one "WAR" frame
|
|
695
|
+
in a tag if the audio contains more than one performer.
|
|
696
|
+
|
|
697
|
+
<A NAME=WAS>WAS</A>
|
|
698
|
+
The 'Official audio source webpage' frame is a URL pointing at the
|
|
699
|
+
official webpage for the source of the audio file, e.g. a movie.
|
|
700
|
+
|
|
701
|
+
<A NAME=WCM>WCM</A>
|
|
702
|
+
The 'Commercial information' frame is a URL pointing at a webpage
|
|
703
|
+
with information such as where the album can be bought. There may be
|
|
704
|
+
more than one "WCM" frame in a tag.
|
|
705
|
+
|
|
706
|
+
<A NAME=WCP>WCP</A>
|
|
707
|
+
The 'Copyright/Legal information' frame is a URL pointing at a
|
|
708
|
+
webpage where the terms of use and ownership of the file is described.
|
|
709
|
+
|
|
710
|
+
<A NAME=WPB>WPB</A>
|
|
711
|
+
The 'Publishers official webpage' frame is a URL pointing at the
|
|
712
|
+
official wepage for the publisher.
|
|
713
|
+
|
|
714
|
+
<A NAME=WXX>
|
|
715
|
+
4.3.2. User defined URL link frame</A>
|
|
716
|
+
|
|
717
|
+
This frame is intended for URL [URL] links concerning the audiofile in
|
|
718
|
+
a similar way to the other "W"xx frames. The frame body consists of a
|
|
719
|
+
description of the string, represented as a terminated string,
|
|
720
|
+
followed by the actual URL. The URL is always encoded with ISO-8859-1
|
|
721
|
+
[ISO-8859-1]. There may be more than one "WXX" frame in each tag, but
|
|
722
|
+
only one with the same description.
|
|
723
|
+
|
|
724
|
+
User defined... "WXX"
|
|
725
|
+
Frame size $xx xx xx
|
|
726
|
+
Text encoding $xx
|
|
727
|
+
Description <textstring> $00 (00)
|
|
728
|
+
URL <textstring>
|
|
729
|
+
|
|
730
|
+
<A NAME=IPL>
|
|
731
|
+
4.4. Involved people list</A>
|
|
732
|
+
|
|
733
|
+
Since there might be a lot of people contributing to an audio file in
|
|
734
|
+
various ways, such as musicians and technicians, the 'Text
|
|
735
|
+
information frames' are often insufficient to list everyone involved
|
|
736
|
+
in a project. The 'Involved people list' is a frame containing the
|
|
737
|
+
names of those involved, and how they were involved. The body simply
|
|
738
|
+
contains a terminated string with the involvement directly followed by
|
|
739
|
+
a terminated string with the involvee followed by a new involvement
|
|
740
|
+
and so on. There may only be one "IPL" frame in each tag.
|
|
741
|
+
|
|
742
|
+
Involved people list "IPL"
|
|
743
|
+
Frame size $xx xx xx
|
|
744
|
+
Text encoding $xx
|
|
745
|
+
People list strings <textstrings>
|
|
746
|
+
|
|
747
|
+
<A NAME=MCI>
|
|
748
|
+
4.5. Music CD Identifier</A>
|
|
749
|
+
|
|
750
|
+
This frame is intended for music that comes from a CD, so that the CD
|
|
751
|
+
can be identified in databases such as the CDDB [CDDB]. The frame
|
|
752
|
+
consists of a binary dump of the Table Of Contents, TOC, from the CD,
|
|
753
|
+
which is a header of 4 bytes and then 8 bytes/track on the CD making a
|
|
754
|
+
maximum of 804 bytes. This frame requires a present and valid "TRK"
|
|
755
|
+
frame. There may only be one "MCI" frame in each tag.
|
|
756
|
+
|
|
757
|
+
Music CD identifier "MCI"
|
|
758
|
+
Frame size $xx xx xx
|
|
759
|
+
CD TOC <binary data>
|
|
760
|
+
|
|
761
|
+
<A NAME=ETC>
|
|
762
|
+
4.6. Event timing codes</A>
|
|
763
|
+
|
|
764
|
+
This frame allows synchronisation with key events in a song or sound.
|
|
765
|
+
The head is:
|
|
766
|
+
|
|
767
|
+
Event timing codes "ETC"
|
|
768
|
+
Frame size $xx xx xx
|
|
769
|
+
Time stamp format $xx
|
|
770
|
+
|
|
771
|
+
Where time stamp format is:
|
|
772
|
+
|
|
773
|
+
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
|
774
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
775
|
+
|
|
776
|
+
Abolute time means that every stamp contains the time from the
|
|
777
|
+
beginning of the file.
|
|
778
|
+
|
|
779
|
+
Followed by a list of key events in the following format:
|
|
780
|
+
|
|
781
|
+
Type of event $xx
|
|
782
|
+
Time stamp $xx (xx ...)
|
|
783
|
+
|
|
784
|
+
The 'Time stamp' is set to zero if directly at the beginning of the
|
|
785
|
+
sound or after the previous event. All events should be sorted in
|
|
786
|
+
chronological order. The type of event is as follows:
|
|
787
|
+
|
|
788
|
+
$00 padding (has no meaning)
|
|
789
|
+
$01 end of initial silence
|
|
790
|
+
$02 intro start
|
|
791
|
+
$03 mainpart start
|
|
792
|
+
$04 outro start
|
|
793
|
+
$05 outro end
|
|
794
|
+
$06 verse begins
|
|
795
|
+
$07 refrain begins
|
|
796
|
+
$08 interlude
|
|
797
|
+
$09 theme start
|
|
798
|
+
$0A variation
|
|
799
|
+
$0B key change
|
|
800
|
+
$0C time change
|
|
801
|
+
$0D unwanted noise (Snap, Crackle & Pop)
|
|
802
|
+
|
|
803
|
+
$0E-$DF reserved for future use
|
|
804
|
+
|
|
805
|
+
$E0-$EF not predefined sync 0-F
|
|
806
|
+
|
|
807
|
+
$F0-$FC reserved for future use
|
|
808
|
+
|
|
809
|
+
$FD audio end (start of silence)
|
|
810
|
+
$FE audio file ends
|
|
811
|
+
$FF one more byte of events follows (all the following bytes with
|
|
812
|
+
the value $FF have the same function)
|
|
813
|
+
|
|
814
|
+
The 'Not predefined sync's ($E0-EF) are for user events. You might
|
|
815
|
+
want to synchronise your music to something, like setting of an
|
|
816
|
+
explosion on-stage, turning on your screensaver etc.
|
|
817
|
+
|
|
818
|
+
There may only be one "ETC" frame in each tag.
|
|
819
|
+
|
|
820
|
+
<A NAME=MLL>
|
|
821
|
+
4.7. MPEG location lookup table</A>
|
|
822
|
+
|
|
823
|
+
To increase performance and accuracy of jumps within a MPEG [MPEG]
|
|
824
|
+
audio file, frames with timecodes in different locations in the file
|
|
825
|
+
might be useful. The ID3 frame includes references that the software
|
|
826
|
+
can use to calculate positions in the file. After the frame header is
|
|
827
|
+
a descriptor of how much the 'frame counter' should increase for every
|
|
828
|
+
reference. If this value is two then the first reference points out
|
|
829
|
+
the second frame, the 2nd reference the 4th frame, the 3rd reference
|
|
830
|
+
the 6th frame etc. In a similar way the 'bytes between reference' and
|
|
831
|
+
'milliseconds between reference' points out bytes and milliseconds
|
|
832
|
+
respectively.
|
|
833
|
+
|
|
834
|
+
Each reference consists of two parts; a certain number of bits, as
|
|
835
|
+
defined in 'bits for bytes deviation', that describes the difference
|
|
836
|
+
between what is said in 'bytes between reference' and the reality and
|
|
837
|
+
a certain number of bits, as defined in 'bits for milliseconds
|
|
838
|
+
deviation', that describes the difference between what is said in
|
|
839
|
+
'milliseconds between reference' and the reality. The number of bits
|
|
840
|
+
in every reference, i.e. 'bits for bytes deviation'+'bits for
|
|
841
|
+
milliseconds deviation', must be a multiple of four. There may only be
|
|
842
|
+
one "MLL" frame in each tag.
|
|
843
|
+
|
|
844
|
+
Location lookup table "MLL"
|
|
845
|
+
ID3 frame size $xx xx xx
|
|
846
|
+
MPEG frames between reference $xx xx
|
|
847
|
+
Bytes between reference $xx xx xx
|
|
848
|
+
Milliseconds between reference $xx xx xx
|
|
849
|
+
Bits for bytes deviation $xx
|
|
850
|
+
Bits for milliseconds dev. $xx
|
|
851
|
+
|
|
852
|
+
Then for every reference the following data is included;
|
|
853
|
+
|
|
854
|
+
Deviation in bytes %xxx....
|
|
855
|
+
Deviation in milliseconds %xxx....
|
|
856
|
+
|
|
857
|
+
<A NAME=STC>
|
|
858
|
+
4.8. Synced tempo codes</A>
|
|
859
|
+
|
|
860
|
+
For a more accurate description of the tempo of a musical piece this
|
|
861
|
+
frame might be used. After the header follows one byte describing
|
|
862
|
+
which time stamp format should be used. Then follows one or more tempo
|
|
863
|
+
codes. Each tempo code consists of one tempo part and one time part.
|
|
864
|
+
The tempo is in BPM described with one or two bytes. If the first byte
|
|
865
|
+
has the value $FF, one more byte follows, which is added to the first
|
|
866
|
+
giving a range from 2 - 510 BPM, since $00 and $01 is reserved. $00 is
|
|
867
|
+
used to describe a beat-free time period, which is not the same as a
|
|
868
|
+
music-free time period. $01 is used to indicate one single beat-stroke
|
|
869
|
+
followed by a beat-free period.
|
|
870
|
+
|
|
871
|
+
The tempo descriptor is followed by a time stamp. Every time the tempo
|
|
872
|
+
in the music changes, a tempo descriptor may indicate this for the
|
|
873
|
+
player. All tempo descriptors should be sorted in chronological order.
|
|
874
|
+
The first beat-stroke in a time-period is at the same time as the beat
|
|
875
|
+
description occurs. There may only be one "STC" frame in each tag.
|
|
876
|
+
|
|
877
|
+
Synced tempo codes "STC"
|
|
878
|
+
Frame size $xx xx xx
|
|
879
|
+
Time stamp format $xx
|
|
880
|
+
Tempo data <binary data>
|
|
881
|
+
|
|
882
|
+
Where time stamp format is:
|
|
883
|
+
|
|
884
|
+
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
|
885
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
886
|
+
|
|
887
|
+
Abolute time means that every stamp contains the time from the
|
|
888
|
+
beginning of the file.
|
|
889
|
+
|
|
890
|
+
<A NAME=ULT>
|
|
891
|
+
4.9. Unsychronised lyrics/text transcription</A>
|
|
892
|
+
|
|
893
|
+
This frame contains the lyrics of the song or a text transcription of
|
|
894
|
+
other vocal activities. The head includes an encoding descriptor and
|
|
895
|
+
a content descriptor. The body consists of the actual text. The
|
|
896
|
+
'Content descriptor' is a terminated string. If no descriptor is
|
|
897
|
+
entered, 'Content descriptor' is $00 (00) only. Newline characters
|
|
898
|
+
are allowed in the text. Maximum length for the descriptor is 64
|
|
899
|
+
bytes. There may be more than one lyrics/text frame in each tag, but
|
|
900
|
+
only one with the same language and content descriptor.
|
|
901
|
+
|
|
902
|
+
Unsynced lyrics/text "ULT"
|
|
903
|
+
Frame size $xx xx xx
|
|
904
|
+
Text encoding $xx
|
|
905
|
+
Language $xx xx xx
|
|
906
|
+
Content descriptor <textstring> $00 (00)
|
|
907
|
+
Lyrics/text <textstring>
|
|
908
|
+
|
|
909
|
+
<A NAME=SLT>
|
|
910
|
+
4.10. Synchronised lyrics/text</A>
|
|
911
|
+
|
|
912
|
+
This is another way of incorporating the words, said or sung lyrics,
|
|
913
|
+
in the audio file as text, this time, however, in sync with the audio.
|
|
914
|
+
It might also be used to describing events e.g. occurring on a stage
|
|
915
|
+
or on the screen in sync with the audio. The header includes a content
|
|
916
|
+
descriptor, represented with as terminated textstring. If no
|
|
917
|
+
descriptor is entered, 'Content descriptor' is $00 (00) only.
|
|
918
|
+
|
|
919
|
+
Synced lyrics/text "SLT"
|
|
920
|
+
Frame size $xx xx xx
|
|
921
|
+
Text encoding $xx
|
|
922
|
+
Language $xx xx xx
|
|
923
|
+
Time stamp format $xx
|
|
924
|
+
Content type $xx
|
|
925
|
+
Content descriptor <textstring> $00 (00)
|
|
926
|
+
|
|
927
|
+
|
|
928
|
+
Encoding: $00 ISO-8859-1 [ISO-8859-1] character set is used => $00
|
|
929
|
+
is sync identifier.
|
|
930
|
+
$01 Unicode [UNICODE] character set is used => $00 00 is
|
|
931
|
+
sync identifier.
|
|
932
|
+
|
|
933
|
+
Content type: $00 is other
|
|
934
|
+
$01 is lyrics
|
|
935
|
+
$02 is text transcription
|
|
936
|
+
$03 is movement/part name (e.g. "Adagio")
|
|
937
|
+
$04 is events (e.g. "Don Quijote enters the stage")
|
|
938
|
+
$05 is chord (e.g. "Bb F Fsus")
|
|
939
|
+
|
|
940
|
+
Time stamp format is:
|
|
941
|
+
|
|
942
|
+
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
|
943
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
944
|
+
|
|
945
|
+
Abolute time means that every stamp contains the time from the
|
|
946
|
+
beginning of the file.
|
|
947
|
+
|
|
948
|
+
The text that follows the frame header differs from that of the
|
|
949
|
+
unsynchronised lyrics/text transcription in one major way. Each
|
|
950
|
+
syllable (or whatever size of text is considered to be convenient by
|
|
951
|
+
the encoder) is a null terminated string followed by a time stamp
|
|
952
|
+
denoting where in the sound file it belongs. Each sync thus has the
|
|
953
|
+
following structure:
|
|
954
|
+
|
|
955
|
+
Terminated text to be synced (typically a syllable)
|
|
956
|
+
Sync identifier (terminator to above string) $00 (00)
|
|
957
|
+
Time stamp $xx (xx ...)
|
|
958
|
+
|
|
959
|
+
The 'time stamp' is set to zero or the whole sync is omitted if
|
|
960
|
+
located directly at the beginning of the sound. All time stamps should
|
|
961
|
+
be sorted in chronological order. The sync can be considered as a
|
|
962
|
+
validator of the subsequent string.
|
|
963
|
+
|
|
964
|
+
Newline characters are allowed in all "SLT" frames and should be used
|
|
965
|
+
after every entry (name, event etc.) in a frame with the content type
|
|
966
|
+
$03 - $04.
|
|
967
|
+
|
|
968
|
+
A few considerations regarding whitespace characters: Whitespace
|
|
969
|
+
separating words should mark the beginning of a new word, thus
|
|
970
|
+
occurring in front of the first syllable of a new word. This is also
|
|
971
|
+
valid for new line characters. A syllable followed by a comma should
|
|
972
|
+
not be broken apart with a sync (both the syllable and the comma
|
|
973
|
+
should be before the sync).
|
|
974
|
+
|
|
975
|
+
An example: The "ULT" passage
|
|
976
|
+
|
|
977
|
+
"Strangers in the night" $0A "Exchanging glances"
|
|
978
|
+
|
|
979
|
+
would be "SLT" encoded as:
|
|
980
|
+
|
|
981
|
+
"Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx
|
|
982
|
+
" night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx
|
|
983
|
+
xx "glan" $00 xx xx "ces" $00 xx xx
|
|
984
|
+
|
|
985
|
+
There may be more than one "SLT" frame in each tag, but only one with
|
|
986
|
+
the same language and content descriptor.
|
|
987
|
+
|
|
988
|
+
<A NAME=COM>
|
|
989
|
+
4.11. Comments</A>
|
|
990
|
+
|
|
991
|
+
This frame replaces the old 30-character comment field in ID3v1. It
|
|
992
|
+
consists of a frame head followed by encoding, language and content
|
|
993
|
+
descriptors and is ended with the actual comment as a text string.
|
|
994
|
+
Newline characters are allowed in the comment text string. There may
|
|
995
|
+
be more than one comment frame in each tag, but only one with the same
|
|
996
|
+
language and content descriptor.
|
|
997
|
+
|
|
998
|
+
Comment "COM"
|
|
999
|
+
Frame size $xx xx xx
|
|
1000
|
+
Text encoding $xx
|
|
1001
|
+
Language $xx xx xx
|
|
1002
|
+
Short content description <textstring> $00 (00)
|
|
1003
|
+
The actual text <textstring>
|
|
1004
|
+
|
|
1005
|
+
<A NAME=RVA>
|
|
1006
|
+
4.12. Relative volume adjustment</A>
|
|
1007
|
+
|
|
1008
|
+
This is a more subjective function than the previous ones. It allows
|
|
1009
|
+
the user to say how much he wants to increase/decrease the volume on
|
|
1010
|
+
each channel while the file is played. The purpose is to be able to
|
|
1011
|
+
align all files to a reference volume, so that you don't have to
|
|
1012
|
+
change the volume constantly. This frame may also be used to balance
|
|
1013
|
+
adjust the audio. If the volume peak levels are known then this could
|
|
1014
|
+
be described with the 'Peak volume right' and 'Peak volume left'
|
|
1015
|
+
field. If Peakvolume is not known these fields could be left zeroed
|
|
1016
|
+
or completely omitted. There may only be one "RVA" frame in each
|
|
1017
|
+
tag.
|
|
1018
|
+
|
|
1019
|
+
Relative volume adjustment "RVA"
|
|
1020
|
+
Frame size $xx xx xx
|
|
1021
|
+
Increment/decrement %000000xx
|
|
1022
|
+
Bits used for volume descr. $xx
|
|
1023
|
+
Relative volume change, right $xx xx (xx ...)
|
|
1024
|
+
Relative volume change, left $xx xx (xx ...)
|
|
1025
|
+
Peak volume right $xx xx (xx ...)
|
|
1026
|
+
Peak volume left $xx xx (xx ...)
|
|
1027
|
+
|
|
1028
|
+
In the increment/decrement field bit 0 is used to indicate the right
|
|
1029
|
+
channel and bit 1 is used to indicate the left channel. 1 is
|
|
1030
|
+
increment and 0 is decrement.
|
|
1031
|
+
|
|
1032
|
+
The 'bits used for volume description' field is normally $10 (16 bits)
|
|
1033
|
+
for MPEG 2 layer I, II and III [MPEG] and MPEG 2.5. This value may not
|
|
1034
|
+
be $00. The volume is always represented with whole bytes, padded in
|
|
1035
|
+
the beginning (highest bits) when 'bits used for volume description'
|
|
1036
|
+
is not a multiple of eight.
|
|
1037
|
+
|
|
1038
|
+
<A NAME=EQU>
|
|
1039
|
+
4.13. Equalisation</A>
|
|
1040
|
+
|
|
1041
|
+
This is another subjective, alignment frame. It allows the user to
|
|
1042
|
+
predefine an equalisation curve within the audio file. There may only
|
|
1043
|
+
be one "EQU" frame in each tag.
|
|
1044
|
+
|
|
1045
|
+
Equalisation "EQU"
|
|
1046
|
+
Frame size $xx xx xx
|
|
1047
|
+
Adjustment bits $xx
|
|
1048
|
+
|
|
1049
|
+
The 'adjustment bits' field defines the number of bits used for
|
|
1050
|
+
representation of the adjustment. This is normally $10 (16 bits) for
|
|
1051
|
+
MPEG 2 layer I, II and III [MPEG] and MPEG 2.5. This value may not be
|
|
1052
|
+
$00.
|
|
1053
|
+
|
|
1054
|
+
This is followed by 2 bytes + ('adjustment bits' rounded up to the
|
|
1055
|
+
nearest byte) for every equalisation band in the following format,
|
|
1056
|
+
giving a frequency range of 0 - 32767Hz:
|
|
1057
|
+
|
|
1058
|
+
Increment/decrement %x (MSB of the Frequency)
|
|
1059
|
+
Frequency (lower 15 bits)
|
|
1060
|
+
Adjustment $xx (xx ...)
|
|
1061
|
+
|
|
1062
|
+
The increment/decrement bit is 1 for increment and 0 for decrement.
|
|
1063
|
+
The equalisation bands should be ordered increasingly with reference
|
|
1064
|
+
to frequency. All frequencies don't have to be declared. Adjustments
|
|
1065
|
+
with the value $00 should be omitted. A frequency should only be
|
|
1066
|
+
described once in the frame.
|
|
1067
|
+
|
|
1068
|
+
<A NAME=REV>
|
|
1069
|
+
4.14. Reverb</A>
|
|
1070
|
+
|
|
1071
|
+
Yet another subjective one. You may here adjust echoes of different
|
|
1072
|
+
kinds. Reverb left/right is the delay between every bounce in ms.
|
|
1073
|
+
Reverb bounces left/right is the number of bounces that should be
|
|
1074
|
+
made. $FF equals an infinite number of bounces. Feedback is the amount
|
|
1075
|
+
of volume that should be returned to the next echo bounce. $00 is 0%,
|
|
1076
|
+
$FF is 100%. If this value were $7F, there would be 50% volume
|
|
1077
|
+
reduction on the first bounce, yet 50% on the second and so on. Left
|
|
1078
|
+
to left means the sound from the left bounce to be played in the left
|
|
1079
|
+
speaker, while left to right means sound from the left bounce to be
|
|
1080
|
+
played in the right speaker.
|
|
1081
|
+
|
|
1082
|
+
'Premix left to right' is the amount of left sound to be mixed in the
|
|
1083
|
+
right before any reverb is applied, where $00 id 0% and $FF is 100%.
|
|
1084
|
+
'Premix right to left' does the same thing, but right to left. Setting
|
|
1085
|
+
both premix to $FF would result in a mono output (if the reverb is
|
|
1086
|
+
applied symmetric). There may only be one "REV" frame in each tag.
|
|
1087
|
+
|
|
1088
|
+
Reverb settings "REV"
|
|
1089
|
+
Frame size $00 00 0C
|
|
1090
|
+
Reverb left (ms) $xx xx
|
|
1091
|
+
Reverb right (ms) $xx xx
|
|
1092
|
+
Reverb bounces, left $xx
|
|
1093
|
+
Reverb bounces, right $xx
|
|
1094
|
+
Reverb feedback, left to left $xx
|
|
1095
|
+
Reverb feedback, left to right $xx
|
|
1096
|
+
Reverb feedback, right to right $xx
|
|
1097
|
+
Reverb feedback, right to left $xx
|
|
1098
|
+
Premix left to right $xx
|
|
1099
|
+
Premix right to left $xx
|
|
1100
|
+
|
|
1101
|
+
<A NAME=PIC>
|
|
1102
|
+
4.15. Attached picture</A>
|
|
1103
|
+
|
|
1104
|
+
This frame contains a picture directly related to the audio file.
|
|
1105
|
+
Image format is preferably "PNG" [PNG] or "JPG" [JFIF]. Description
|
|
1106
|
+
is a short description of the picture, represented as a terminated
|
|
1107
|
+
textstring. The description has a maximum length of 64 characters,
|
|
1108
|
+
but may be empty. There may be several pictures attached to one file,
|
|
1109
|
+
each in their individual "PIC" frame, but only one with the same
|
|
1110
|
+
content descriptor. There may only be one picture with the picture
|
|
1111
|
+
type declared as picture type $01 and $02 respectively. There is a
|
|
1112
|
+
possibility to put only a link to the image file by using the 'image
|
|
1113
|
+
format' "-->" and having a complete URL [URL] instead of picture data.
|
|
1114
|
+
The use of linked files should however be used restrictively since
|
|
1115
|
+
there is the risk of separation of files.
|
|
1116
|
+
|
|
1117
|
+
Attached picture "PIC"
|
|
1118
|
+
Frame size $xx xx xx
|
|
1119
|
+
Text encoding $xx
|
|
1120
|
+
Image format $xx xx xx
|
|
1121
|
+
Picture type $xx
|
|
1122
|
+
Description <textstring> $00 (00)
|
|
1123
|
+
Picture data <binary data>
|
|
1124
|
+
|
|
1125
|
+
|
|
1126
|
+
Picture type: $00 Other
|
|
1127
|
+
$01 32x32 pixels 'file icon' (PNG only)
|
|
1128
|
+
$02 Other file icon
|
|
1129
|
+
$03 Cover (front)
|
|
1130
|
+
$04 Cover (back)
|
|
1131
|
+
$05 Leaflet page
|
|
1132
|
+
$06 Media (e.g. lable side of CD)
|
|
1133
|
+
$07 Lead artist/lead performer/soloist
|
|
1134
|
+
$08 Artist/performer
|
|
1135
|
+
$09 Conductor
|
|
1136
|
+
$0A Band/Orchestra
|
|
1137
|
+
$0B Composer
|
|
1138
|
+
$0C Lyricist/text writer
|
|
1139
|
+
$0D Recording Location
|
|
1140
|
+
$0E During recording
|
|
1141
|
+
$0F During performance
|
|
1142
|
+
$10 Movie/video screen capture
|
|
1143
|
+
$11 A bright coloured fish
|
|
1144
|
+
$12 Illustration
|
|
1145
|
+
$13 Band/artist logotype
|
|
1146
|
+
$14 Publisher/Studio logotype
|
|
1147
|
+
|
|
1148
|
+
<A NAME=GEO>
|
|
1149
|
+
4.16. General encapsulated object</A>
|
|
1150
|
+
|
|
1151
|
+
In this frame any type of file can be encapsulated. After the header,
|
|
1152
|
+
'Frame size' and 'Encoding' follows 'MIME type' [MIME] and 'Filename'
|
|
1153
|
+
for the encapsulated object, both represented as terminated strings
|
|
1154
|
+
encoded with ISO 8859-1 [ISO-8859-1]. The filename is case sensitive.
|
|
1155
|
+
Then follows a content description as terminated string, encoded as
|
|
1156
|
+
'Encoding'. The last thing in the frame is the actual object. The
|
|
1157
|
+
first two strings may be omitted, leaving only their terminations.
|
|
1158
|
+
MIME type is always an ISO-8859-1 text string. There may be more than
|
|
1159
|
+
one "GEO" frame in each tag, but only one with the same content
|
|
1160
|
+
descriptor.
|
|
1161
|
+
|
|
1162
|
+
General encapsulated object "GEO"
|
|
1163
|
+
Frame size $xx xx xx
|
|
1164
|
+
Text encoding $xx
|
|
1165
|
+
MIME type <textstring> $00
|
|
1166
|
+
Filename <textstring> $00 (00)
|
|
1167
|
+
Content description <textstring> $00 (00)
|
|
1168
|
+
Encapsulated object <binary data>
|
|
1169
|
+
|
|
1170
|
+
<A NAME=CNT>
|
|
1171
|
+
4.17. Play counter</A>
|
|
1172
|
+
|
|
1173
|
+
This is simply a counter of the number of times a file has been
|
|
1174
|
+
played. The value is increased by one every time the file begins to
|
|
1175
|
+
play. There may only be one "CNT" frame in each tag. When the counter
|
|
1176
|
+
reaches all one's, one byte is inserted in front of the counter thus
|
|
1177
|
+
making the counter eight bits bigger. The counter must be at least
|
|
1178
|
+
32-bits long to begin with.
|
|
1179
|
+
|
|
1180
|
+
Play counter "CNT"
|
|
1181
|
+
Frame size $xx xx xx
|
|
1182
|
+
Counter $xx xx xx xx (xx ...)
|
|
1183
|
+
|
|
1184
|
+
<A NAME=POP>
|
|
1185
|
+
4.18. Popularimeter</A>
|
|
1186
|
+
|
|
1187
|
+
The purpose of this frame is to specify how good an audio file is.
|
|
1188
|
+
Many interesting applications could be found to this frame such as a
|
|
1189
|
+
playlist that features better audiofiles more often than others or it
|
|
1190
|
+
could be used to profile a persons taste and find other 'good' files
|
|
1191
|
+
by comparing people's profiles. The frame is very simple. It contains
|
|
1192
|
+
the email address to the user, one rating byte and a four byte play
|
|
1193
|
+
counter, intended to be increased with one for every time the file is
|
|
1194
|
+
played. The email is a terminated string. The rating is 1-255 where
|
|
1195
|
+
1 is worst and 255 is best. 0 is unknown. If no personal counter is
|
|
1196
|
+
wanted it may be omitted. When the counter reaches all one's, one
|
|
1197
|
+
byte is inserted in front of the counter thus making the counter
|
|
1198
|
+
eight bits bigger in the same away as the play counter ("CNT").
|
|
1199
|
+
There may be more than one "POP" frame in each tag, but only one with
|
|
1200
|
+
the same email address.
|
|
1201
|
+
|
|
1202
|
+
Popularimeter "POP"
|
|
1203
|
+
Frame size $xx xx xx
|
|
1204
|
+
Email to user <textstring> $00
|
|
1205
|
+
Rating $xx
|
|
1206
|
+
Counter $xx xx xx xx (xx ...)
|
|
1207
|
+
|
|
1208
|
+
<A NAME=BUF>
|
|
1209
|
+
4.19. Recommended buffer size</A>
|
|
1210
|
+
|
|
1211
|
+
Sometimes the server from which a audio file is streamed is aware of
|
|
1212
|
+
transmission or coding problems resulting in interruptions in the
|
|
1213
|
+
audio stream. In these cases, the size of the buffer can be
|
|
1214
|
+
recommended by the server using this frame. If the 'embedded info
|
|
1215
|
+
flag' is true (1) then this indicates that an ID3 tag with the
|
|
1216
|
+
maximum size described in 'Buffer size' may occur in the audiostream.
|
|
1217
|
+
In such case the tag should reside between two MPEG [MPEG] frames, if
|
|
1218
|
+
the audio is MPEG encoded. If the position of the next tag is known,
|
|
1219
|
+
'offset to next tag' may be used. The offset is calculated from the
|
|
1220
|
+
end of tag in which this frame resides to the first byte of the header
|
|
1221
|
+
in the next. This field may be omitted. Embedded tags is currently not
|
|
1222
|
+
recommended since this could render unpredictable behaviour from
|
|
1223
|
+
present software/hardware. The 'Buffer size' should be kept to a
|
|
1224
|
+
minimum. There may only be one "BUF" frame in each tag.
|
|
1225
|
+
|
|
1226
|
+
Recommended buffer size "BUF"
|
|
1227
|
+
Frame size $xx xx xx
|
|
1228
|
+
Buffer size $xx xx xx
|
|
1229
|
+
Embedded info flag %0000000x
|
|
1230
|
+
Offset to next tag $xx xx xx xx
|
|
1231
|
+
|
|
1232
|
+
<A NAME=CRM>
|
|
1233
|
+
4.20. Encrypted meta frame</A>
|
|
1234
|
+
|
|
1235
|
+
This frame contains one or more encrypted frames. This enables
|
|
1236
|
+
protection of copyrighted information such as pictures and text, that
|
|
1237
|
+
people might want to pay extra for. Since standardisation of such an
|
|
1238
|
+
encryption scheme is beyond this document, all "CRM" frames begin with
|
|
1239
|
+
a terminated string with a URL [URL] containing an email address, or a
|
|
1240
|
+
link to a location where an email adress can be found, that belongs to
|
|
1241
|
+
the organisation responsible for this specific encrypted meta frame.
|
|
1242
|
+
|
|
1243
|
+
Questions regarding the encrypted frame should be sent to the
|
|
1244
|
+
indicated email address. If a $00 is found directly after the 'Frame
|
|
1245
|
+
size', the whole frame should be ignored, and preferably be removed.
|
|
1246
|
+
The 'Owner identifier' is then followed by a short content description
|
|
1247
|
+
and explanation as to why it's encrypted. After the
|
|
1248
|
+
'content/explanation' description, the actual encrypted block follows.
|
|
1249
|
+
|
|
1250
|
+
When an ID3v2 decoder encounters a "CRM" frame, it should send the
|
|
1251
|
+
datablock to the 'plugin' with the corresponding 'owner identifier'
|
|
1252
|
+
and expect to receive either a datablock with one or several ID3v2
|
|
1253
|
+
frames after each other or an error. There may be more than one "CRM"
|
|
1254
|
+
frames in a tag, but only one with the same 'owner identifier'.
|
|
1255
|
+
|
|
1256
|
+
Encrypted meta frame "CRM"
|
|
1257
|
+
Frame size $xx xx xx
|
|
1258
|
+
Owner identifier <textstring> $00 (00)
|
|
1259
|
+
Content/explanation <textstring> $00 (00)
|
|
1260
|
+
Encrypted datablock <binary data>
|
|
1261
|
+
|
|
1262
|
+
<A NAME=CRA>
|
|
1263
|
+
4.21. Audio encryption</A>
|
|
1264
|
+
|
|
1265
|
+
This frame indicates if the actual audio stream is encrypted, and by
|
|
1266
|
+
whom. Since standardisation of such encrypion scheme is beyond this
|
|
1267
|
+
document, all "CRA" frames begin with a terminated string with a
|
|
1268
|
+
URL containing an email address, or a link to a location where an
|
|
1269
|
+
email address can be found, that belongs to the organisation
|
|
1270
|
+
responsible for this specific encrypted audio file. Questions
|
|
1271
|
+
regarding the encrypted audio should be sent to the email address
|
|
1272
|
+
specified. If a $00 is found directly after the 'Frame size' and the
|
|
1273
|
+
audiofile indeed is encrypted, the whole file may be considered
|
|
1274
|
+
useless.
|
|
1275
|
+
|
|
1276
|
+
After the 'Owner identifier', a pointer to an unencrypted part of the
|
|
1277
|
+
audio can be specified. The 'Preview start' and 'Preview length' is
|
|
1278
|
+
described in frames. If no part is unencrypted, these fields should be
|
|
1279
|
+
left zeroed. After the 'preview length' field follows optionally a
|
|
1280
|
+
datablock required for decryption of the audio. There may be more than
|
|
1281
|
+
one "CRA" frames in a tag, but only one with the same 'Owner
|
|
1282
|
+
identifier'.
|
|
1283
|
+
|
|
1284
|
+
Audio encryption "CRA"
|
|
1285
|
+
Frame size $xx xx xx
|
|
1286
|
+
Owner identifier <textstring> $00 (00)
|
|
1287
|
+
Preview start $xx xx
|
|
1288
|
+
Preview length $xx xx
|
|
1289
|
+
Encryption info <binary data>
|
|
1290
|
+
|
|
1291
|
+
<A NAME=LNK>
|
|
1292
|
+
4.22. Linked information</A>
|
|
1293
|
+
|
|
1294
|
+
To keep space waste as low as possible this frame may be used to link
|
|
1295
|
+
information from another ID3v2 tag that might reside in another audio
|
|
1296
|
+
file or alone in a binary file. It is recommended that this method is
|
|
1297
|
+
only used when the files are stored on a CD-ROM or other circumstances
|
|
1298
|
+
when the risk of file seperation is low. The frame contains a frame
|
|
1299
|
+
identifier, which is the frame that should be linked into this tag, a
|
|
1300
|
+
URL [URL] field, where a reference to the file where the frame is
|
|
1301
|
+
given, and additional ID data, if needed. Data should be retrieved
|
|
1302
|
+
from the first tag found in the file to which this link points. There
|
|
1303
|
+
may be more than one "LNK" frame in a tag, but only one with the same
|
|
1304
|
+
contents. A linked frame is to be considered as part of the tag and
|
|
1305
|
+
has the same restrictions as if it was a physical part of the tag
|
|
1306
|
+
(i.e. only one "REV" frame allowed, whether it's linked or not).
|
|
1307
|
+
|
|
1308
|
+
Linked information "LNK"
|
|
1309
|
+
Frame size $xx xx xx
|
|
1310
|
+
Frame identifier $xx xx xx
|
|
1311
|
+
URL <textstring> $00 (00)
|
|
1312
|
+
Additional ID data <textstring(s)>
|
|
1313
|
+
|
|
1314
|
+
Frames that may be linked and need no additional data are "IPL",
|
|
1315
|
+
"MCI", "ETC", "LLT", "STC", "RVA", "EQU", "REV", "BUF", the text
|
|
1316
|
+
information frames and the URL link frames.
|
|
1317
|
+
|
|
1318
|
+
The "TXX", "PIC", "GEO", "CRM" and "CRA" frames may be linked with the
|
|
1319
|
+
content descriptor as additional ID data.
|
|
1320
|
+
|
|
1321
|
+
The "COM", "SLT" and "ULT" frames may be linked with three bytes of
|
|
1322
|
+
language descriptor directly followed by a content descriptor as
|
|
1323
|
+
additional ID data.
|
|
1324
|
+
|
|
1325
|
+
|
|
1326
|
+
5. The 'unsynchronisation scheme'
|
|
1327
|
+
|
|
1328
|
+
The only purpose of the 'unsychronisation scheme' is to make the ID3v2
|
|
1329
|
+
tag as compatible as possible with existing software. There is no use
|
|
1330
|
+
in 'unsynchronising' tags if the file is only to be processed by new
|
|
1331
|
+
software. Unsynchronisation may only be made with MPEG 2 layer I, II
|
|
1332
|
+
and III and MPEG 2.5 files.
|
|
1333
|
+
|
|
1334
|
+
Whenever a false synchronisation is found within the tag, one zeroed
|
|
1335
|
+
byte is inserted after the first false synchronisation byte. The
|
|
1336
|
+
format of a correct sync that should be altered by ID3 encoders is as
|
|
1337
|
+
follows:
|
|
1338
|
+
|
|
1339
|
+
%11111111 111xxxxx
|
|
1340
|
+
|
|
1341
|
+
And should be replaced with:
|
|
1342
|
+
|
|
1343
|
+
%11111111 00000000 111xxxxx
|
|
1344
|
+
|
|
1345
|
+
This has the side effect that all $FF 00 combinations have to be
|
|
1346
|
+
altered, so they won't be affected by the decoding process. Therefore
|
|
1347
|
+
all the $FF 00 combinations have to be replaced with the $FF 00 00
|
|
1348
|
+
combination during the unsynchonisation.
|
|
1349
|
+
|
|
1350
|
+
To indicate usage of the unsynchronisation, the first bit in 'ID3
|
|
1351
|
+
flags' should be set. This bit should only be set if the tag
|
|
1352
|
+
contained a, now corrected, false synchronisation. The bit should
|
|
1353
|
+
only be clear if the tag does not contain any false synchronisations.
|
|
1354
|
+
|
|
1355
|
+
Do bear in mind, that if a compression scheme is used by the encoder,
|
|
1356
|
+
the unsyncronisation scheme should be applied *afterwards*. When
|
|
1357
|
+
decoding a compressed, 'unsyncronised' file, the 'unsyncronisation
|
|
1358
|
+
scheme' should be parsed first, compression afterwards.
|
|
1359
|
+
|
|
1360
|
+
|
|
1361
|
+
6. Copyright
|
|
1362
|
+
|
|
1363
|
+
Copyright (C) Martin Nilsson 1998. All Rights Reserved.
|
|
1364
|
+
|
|
1365
|
+
This document and translations of it may be copied and furnished to
|
|
1366
|
+
others, and derivative works that comment on or otherwise explain it
|
|
1367
|
+
or assist in its implementation may be prepared, copied, published
|
|
1368
|
+
and distributed, in whole or in part, without restriction of any
|
|
1369
|
+
kind, provided that a reference to this document is included on all
|
|
1370
|
+
such copies and derivative works. However, this document itself may
|
|
1371
|
+
not be modified in any way and reissued as the original document.
|
|
1372
|
+
|
|
1373
|
+
The limited permissions granted above are perpetual and will not be
|
|
1374
|
+
revoked.
|
|
1375
|
+
|
|
1376
|
+
This document and the information contained herein is provided on an
|
|
1377
|
+
"AS IS" basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR
|
|
1378
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
1379
|
+
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
1380
|
+
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
1381
|
+
|
|
1382
|
+
|
|
1383
|
+
7. References
|
|
1384
|
+
|
|
1385
|
+
[CDDB] Compact Disc Data Base
|
|
1386
|
+
|
|
1387
|
+
<url:http://www.cddb.com>
|
|
1388
|
+
|
|
1389
|
+
[ISO-639-2] ISO/FDIS 639-2.
|
|
1390
|
+
Codes for the representation of names of languages, Part 2: Alpha-3
|
|
1391
|
+
code. Technical committee / subcommittee: TC 37 / SC 2
|
|
1392
|
+
|
|
1393
|
+
[ISO-8859-1] ISO/IEC DIS 8859-1.
|
|
1394
|
+
8-bit single-byte coded graphic character sets, Part 1: Latin
|
|
1395
|
+
alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2
|
|
1396
|
+
|
|
1397
|
+
[ISRC] ISO 3901:1986
|
|
1398
|
+
International Standard Recording Code (ISRC).
|
|
1399
|
+
Technical committee / subcommittee: TC 46 / SC 9
|
|
1400
|
+
|
|
1401
|
+
[JFIF] JPEG File Interchange Format, version 1.02
|
|
1402
|
+
|
|
1403
|
+
<url:http://www.w3.org/Graphics/JPEG/jfif.txt>
|
|
1404
|
+
|
|
1405
|
+
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|
1406
|
+
Extensions (MIME) Part One: Format of Internet Message Bodies",
|
|
1407
|
+
RFC 2045, November 1996.
|
|
1408
|
+
|
|
1409
|
+
<url:ftp://ftp.isi.edu/in-notes/rfc2045.txt>
|
|
1410
|
+
|
|
1411
|
+
[MPEG] ISO/IEC 11172-3:1993.
|
|
1412
|
+
Coding of moving pictures and associated audio for digital storage
|
|
1413
|
+
media at up to about 1,5 Mbit/s, Part 3: Audio.
|
|
1414
|
+
Technical committee / subcommittee: JTC 1 / SC 29
|
|
1415
|
+
and
|
|
1416
|
+
ISO/IEC 13818-3:1995
|
|
1417
|
+
Generic coding of moving pictures and associated audio information,
|
|
1418
|
+
Part 3: Audio.
|
|
1419
|
+
Technical committee / subcommittee: JTC 1 / SC 29
|
|
1420
|
+
and
|
|
1421
|
+
ISO/IEC DIS 13818-3
|
|
1422
|
+
Generic coding of moving pictures and associated audio information,
|
|
1423
|
+
Part 3: Audio (Revision of ISO/IEC 13818-3:1995)
|
|
1424
|
+
|
|
1425
|
+
|
|
1426
|
+
[PNG] Portable Network Graphics, version 1.0
|
|
1427
|
+
|
|
1428
|
+
<url:http://www.w3.org/TR/REC-png-multi.html>
|
|
1429
|
+
|
|
1430
|
+
[UNICODE] ISO/IEC 10646-1:1993.
|
|
1431
|
+
Universal Multiple-Octet Coded Character Set (UCS), Part 1:
|
|
1432
|
+
Architecture and Basic Multilingual Plane. Technical committee
|
|
1433
|
+
/ subcommittee: JTC 1 / SC 2
|
|
1434
|
+
|
|
1435
|
+
<url:http://www.unicode.org>
|
|
1436
|
+
|
|
1437
|
+
[URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource
|
|
1438
|
+
Locators (URL).", RFC 1738, December 1994.
|
|
1439
|
+
|
|
1440
|
+
<url:ftp://ftp.isi.edu/in-notes/rfc1738.txt>
|
|
1441
|
+
|
|
1442
|
+
|
|
1443
|
+
8. Appendix
|
|
1444
|
+
|
|
1445
|
+
|
|
1446
|
+
A. Appendix A - ID3-Tag Specification V1.1
|
|
1447
|
+
|
|
1448
|
+
ID3-Tag Specification V1.1 (12 dec 1997) by Michael Mutschler
|
|
1449
|
+
<amiga2@info2.rus.uni-stuttgart.de>, edited for space and clarity
|
|
1450
|
+
reasons.
|
|
1451
|
+
|
|
1452
|
+
|
|
1453
|
+
A.1. Overview
|
|
1454
|
+
|
|
1455
|
+
The ID3-Tag is an information field for MPEG Layer 3 audio files.
|
|
1456
|
+
Since a standalone MP3 doesn't provide a method of storing other
|
|
1457
|
+
information than those directly needed for replay reasons, the
|
|
1458
|
+
ID3-tag was invented by Eric Kemp in 1996.
|
|
1459
|
+
|
|
1460
|
+
A revision from ID3v1 to ID3v1.1 was made by Michael Mutschler to
|
|
1461
|
+
support track number information is described in A.4.
|
|
1462
|
+
|
|
1463
|
+
|
|
1464
|
+
A.2. ID3v1 Implementation
|
|
1465
|
+
|
|
1466
|
+
The Information is stored in the last 128 bytes of an MP3. The Tag
|
|
1467
|
+
has got the following fields, and the offsets given here, are from
|
|
1468
|
+
0-127.
|
|
1469
|
+
|
|
1470
|
+
Field Length Offsets
|
|
1471
|
+
Tag 3 0-2
|
|
1472
|
+
Songname 30 3-32
|
|
1473
|
+
Artist 30 33-62
|
|
1474
|
+
Album 30 63-92
|
|
1475
|
+
Year 4 93-96
|
|
1476
|
+
Comment 30 97-126
|
|
1477
|
+
Genre 1 127
|
|
1478
|
+
|
|
1479
|
+
|
|
1480
|
+
The string-fields contain ASCII-data, coded in ISO-Latin 1 codepage.
|
|
1481
|
+
Strings which are smaller than the field length are padded with zero-
|
|
1482
|
+
bytes.
|
|
1483
|
+
|
|
1484
|
+
Tag: The tag is valid if this field contains the string "TAG". This
|
|
1485
|
+
has to be uppercase!
|
|
1486
|
+
|
|
1487
|
+
Songname: This field contains the title of the MP3 (string as
|
|
1488
|
+
above).
|
|
1489
|
+
|
|
1490
|
+
Artist: This field contains the artist of the MP3 (string as above).
|
|
1491
|
+
|
|
1492
|
+
Album: this field contains the album where the MP3 comes from
|
|
1493
|
+
(string as above).
|
|
1494
|
+
|
|
1495
|
+
Year: this field contains the year when this song has originally
|
|
1496
|
+
been released (string as above).
|
|
1497
|
+
|
|
1498
|
+
Comment: this field contains a comment for the MP3 (string as
|
|
1499
|
+
above). Revision to this field has been made in ID3v1.1. See
|
|
1500
|
+
A.4.
|
|
1501
|
+
|
|
1502
|
+
Genre: this byte contains the offset of a genre in a predefined
|
|
1503
|
+
list the byte is treated as an unsigned byte. The offset is
|
|
1504
|
+
starting from 0. See A.3.
|
|
1505
|
+
|
|
1506
|
+
|
|
1507
|
+
A.3. Genre List
|
|
1508
|
+
|
|
1509
|
+
The following genres is defined in ID3v1
|
|
1510
|
+
|
|
1511
|
+
0.Blues
|
|
1512
|
+
1.Classic Rock
|
|
1513
|
+
2.Country
|
|
1514
|
+
3.Dance
|
|
1515
|
+
4.Disco
|
|
1516
|
+
5.Funk
|
|
1517
|
+
6.Grunge
|
|
1518
|
+
7.Hip-Hop
|
|
1519
|
+
8.Jazz
|
|
1520
|
+
9.Metal
|
|
1521
|
+
10.New Age
|
|
1522
|
+
11.Oldies
|
|
1523
|
+
12.Other
|
|
1524
|
+
13.Pop
|
|
1525
|
+
14.R&B
|
|
1526
|
+
15.Rap
|
|
1527
|
+
16.Reggae
|
|
1528
|
+
17.Rock
|
|
1529
|
+
18.Techno
|
|
1530
|
+
19.Industrial
|
|
1531
|
+
20.Alternative
|
|
1532
|
+
21.Ska
|
|
1533
|
+
22.Death Metal
|
|
1534
|
+
23.Pranks
|
|
1535
|
+
24.Soundtrack
|
|
1536
|
+
25.Euro-Techno
|
|
1537
|
+
26.Ambient
|
|
1538
|
+
27.Trip-Hop
|
|
1539
|
+
28.Vocal
|
|
1540
|
+
29.Jazz+Funk
|
|
1541
|
+
30.Fusion
|
|
1542
|
+
31.Trance
|
|
1543
|
+
32.Classical
|
|
1544
|
+
33.Instrumental
|
|
1545
|
+
34.Acid
|
|
1546
|
+
35.House
|
|
1547
|
+
36.Game
|
|
1548
|
+
37.Sound Clip
|
|
1549
|
+
38.Gospel
|
|
1550
|
+
39.Noise
|
|
1551
|
+
40.AlternRock
|
|
1552
|
+
41.Bass
|
|
1553
|
+
42.Soul
|
|
1554
|
+
43.Punk
|
|
1555
|
+
44.Space
|
|
1556
|
+
45.Meditative
|
|
1557
|
+
46.Instrumental Pop
|
|
1558
|
+
47.Instrumental Rock
|
|
1559
|
+
48.Ethnic
|
|
1560
|
+
49.Gothic
|
|
1561
|
+
50.Darkwave
|
|
1562
|
+
51.Techno-Industrial
|
|
1563
|
+
52.Electronic
|
|
1564
|
+
53.Pop-Folk
|
|
1565
|
+
54.Eurodance
|
|
1566
|
+
55.Dream
|
|
1567
|
+
56.Southern Rock
|
|
1568
|
+
57.Comedy
|
|
1569
|
+
58.Cult
|
|
1570
|
+
59.Gangsta
|
|
1571
|
+
60.Top 40
|
|
1572
|
+
61.Christian Rap
|
|
1573
|
+
62.Pop/Funk
|
|
1574
|
+
63.Jungle
|
|
1575
|
+
64.Native American
|
|
1576
|
+
65.Cabaret
|
|
1577
|
+
66.New Wave
|
|
1578
|
+
67.Psychadelic
|
|
1579
|
+
68.Rave
|
|
1580
|
+
69.Showtunes
|
|
1581
|
+
70.Trailer
|
|
1582
|
+
71.Lo-Fi
|
|
1583
|
+
72.Tribal
|
|
1584
|
+
73.Acid Punk
|
|
1585
|
+
74.Acid Jazz
|
|
1586
|
+
75.Polka
|
|
1587
|
+
76.Retro
|
|
1588
|
+
77.Musical
|
|
1589
|
+
78.Rock & Roll
|
|
1590
|
+
79.Hard Rock
|
|
1591
|
+
|
|
1592
|
+
The following genres are Winamp extensions
|
|
1593
|
+
|
|
1594
|
+
80.Folk
|
|
1595
|
+
81.Folk-Rock
|
|
1596
|
+
82.National Folk
|
|
1597
|
+
83.Swing
|
|
1598
|
+
84.Fast Fusion
|
|
1599
|
+
85.Bebob
|
|
1600
|
+
86.Latin
|
|
1601
|
+
87.Revival
|
|
1602
|
+
88.Celtic
|
|
1603
|
+
89.Bluegrass
|
|
1604
|
+
90.Avantgarde
|
|
1605
|
+
91.Gothic Rock
|
|
1606
|
+
92.Progressive Rock
|
|
1607
|
+
93.Psychedelic Rock
|
|
1608
|
+
94.Symphonic Rock
|
|
1609
|
+
95.Slow Rock
|
|
1610
|
+
96.Big Band
|
|
1611
|
+
97.Chorus
|
|
1612
|
+
98.Easy Listening
|
|
1613
|
+
99.Acoustic
|
|
1614
|
+
100.Humour
|
|
1615
|
+
101.Speech
|
|
1616
|
+
102.Chanson
|
|
1617
|
+
103.Opera
|
|
1618
|
+
104.Chamber Music
|
|
1619
|
+
105.Sonata
|
|
1620
|
+
106.Symphony
|
|
1621
|
+
107.Booty Bass
|
|
1622
|
+
108.Primus
|
|
1623
|
+
109.Porn Groove
|
|
1624
|
+
110.Satire
|
|
1625
|
+
111.Slow Jam
|
|
1626
|
+
112.Club
|
|
1627
|
+
113.Tango
|
|
1628
|
+
114.Samba
|
|
1629
|
+
115.Folklore
|
|
1630
|
+
116.Ballad
|
|
1631
|
+
117.Power Ballad
|
|
1632
|
+
118.Rhythmic Soul
|
|
1633
|
+
119.Freestyle
|
|
1634
|
+
120.Duet
|
|
1635
|
+
121.Punk Rock
|
|
1636
|
+
122.Drum Solo
|
|
1637
|
+
123.A capella
|
|
1638
|
+
124.Euro-House
|
|
1639
|
+
125.Dance Hall
|
|
1640
|
+
|
|
1641
|
+
|
|
1642
|
+
A.4. Track addition - ID3v1.1
|
|
1643
|
+
|
|
1644
|
+
In ID3v1.1, Michael Mutschler revised the specification of the
|
|
1645
|
+
comment field in order to implement the track number. The new format
|
|
1646
|
+
of the comment field is a 28 character string followed by a mandatory
|
|
1647
|
+
null ($00) character and the original album tracknumber stored as an
|
|
1648
|
+
unsigned byte-size integer. In such cases where the 29th byte is not
|
|
1649
|
+
the null character or when the 30th is a null character, the
|
|
1650
|
+
tracknumber is to be considered undefined.
|
|
1651
|
+
|
|
1652
|
+
|
|
1653
|
+
9. Author's Address
|
|
1654
|
+
|
|
1655
|
+
Martin Nilsson
|
|
1656
|
+
Rydsv�gen 246 C. 30
|
|
1657
|
+
S-584 34 Link�ping
|
|
1658
|
+
Sweden
|
|
1659
|
+
|
|
1660
|
+
Email: nilsson@id3.org
|
|
1661
|
+
|
|
1662
|
+
Co-authors:
|
|
1663
|
+
|
|
1664
|
+
Johan Sundstr�m Email: johan@id3.org
|
|
1665
|
+
|
|
1666
|
+
|
|
1667
|
+
</PRE>
|
|
1668
|
+
</BODY>
|
|
1669
|
+
</HTML>
|