id3 0.4.0
Sign up to get free protection for your applications and to get access to all the features.
- 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,159 @@
|
|
|
1
|
+
<HTML>
|
|
2
|
+
<HEAD>
|
|
3
|
+
<TITLE>ID3 tag version 2.4.0 - Changes</TITLE>
|
|
4
|
+
</HEAD>
|
|
5
|
+
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" VLINK="#051271" LINK="#0000B1" ALINK="#A21600">
|
|
6
|
+
<PRE>
|
|
7
|
+
|
|
8
|
+
Informational M. Nilsson
|
|
9
|
+
Document: id3v2.4.0-changes.txt 21st December 2000
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
ID3 tag version 2.4.0 - Changes
|
|
13
|
+
|
|
14
|
+
Status of this document
|
|
15
|
+
|
|
16
|
+
This document describes the changes between ID3v2.3.0 [ID3v2.3.0] and
|
|
17
|
+
ID3v2.4.0 [ID3v2.4.0-strct][ID3v2.4.0-frames]. This document does not
|
|
18
|
+
claim to be complete nor correct.
|
|
19
|
+
|
|
20
|
+
Distribution of this document is unlimited.
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
Abstract
|
|
24
|
+
|
|
25
|
+
This document outlines the more important differences between
|
|
26
|
+
ID3v2.3.0 and ID3v2.4.0. In general ID3v.2.4.0 can be said to be more
|
|
27
|
+
consistent and easier to implement and more suitable to real world
|
|
28
|
+
conditions than the previous versions.
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
1. Table of contents
|
|
32
|
+
|
|
33
|
+
Status of this document
|
|
34
|
+
Abstract
|
|
35
|
+
1. Table of contents
|
|
36
|
+
2. Conventions in this document
|
|
37
|
+
3. Tag structure changes
|
|
38
|
+
4. Deprecated ID3v2 frames
|
|
39
|
+
5. New frames
|
|
40
|
+
6. References
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
2. Conventions in this document
|
|
44
|
+
|
|
45
|
+
References to sections in the ID3v2.4.0 Main Structure
|
|
46
|
+
[ID3v2.4.0-strct] document will be given as [S:x.y] where x is the
|
|
47
|
+
section and y is the subsection. In a similar fashion references to
|
|
48
|
+
sections in the ID3v2.4.0 Native Frames [ID3v2.4.0-frames] document
|
|
49
|
+
will be given as [F:x.y].
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
3. Tag structure changes
|
|
53
|
+
|
|
54
|
+
The location of tags in a file as well as methods to find and merge
|
|
55
|
+
tags are far better defined in ID3v2.4.0 [S:5] than previous
|
|
56
|
+
versions. A reverse search for tags are improved by the addition of a
|
|
57
|
+
tag footer [S:3.4]. A tag footer flag has been added to the header
|
|
58
|
+
flags to indicate the presence of a ID3v2 footer, hence the size
|
|
59
|
+
field is not affected by the footer [S:3.1].
|
|
60
|
+
|
|
61
|
+
The extended header has been completely rewritten [S:3.2] and can not
|
|
62
|
+
produce false synchs. It is also possible to indicate artificial tag
|
|
63
|
+
restrictions in the extended header, for use with thinner clients.
|
|
64
|
+
|
|
65
|
+
Unsynchronisation [S:6.1] is done on frame level, instead of on tag
|
|
66
|
+
level, making it easier to skip frames, increasing the streamability
|
|
67
|
+
of the tag. The unsynchronisation flag in the header [S:3.1]
|
|
68
|
+
indicates if all frames has been unsynchronized, while the new
|
|
69
|
+
unsynchronisation flag in the frame header [S:4.1.2] indicates
|
|
70
|
+
unsynchronisation. To avoid false synchronisations in the frame
|
|
71
|
+
header the size description and flag field has been rewritten [S:4].
|
|
72
|
+
Resynchronisation of the complete tag when the unsynchronisation flag
|
|
73
|
+
in the tag header is set might result in a corrupt tag.
|
|
74
|
+
|
|
75
|
+
The character encodings UTF-16BE and UTF-8 has been added to the list
|
|
76
|
+
of valid encodings [S:4].
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
4. Deprecated ID3v2 frames
|
|
80
|
+
|
|
81
|
+
EQUA - Equalization
|
|
82
|
+
This frame is replaced by the EQU2 frame, 'Equalisation (2)'
|
|
83
|
+
[F:4.12].
|
|
84
|
+
|
|
85
|
+
IPLS - Involved people list
|
|
86
|
+
This frame is replaced by the two frames TMCL, 'Musician credits
|
|
87
|
+
list' [F:4.2.2], and TIPL, 'Involved people list' [F:4.2.2].
|
|
88
|
+
|
|
89
|
+
RVAD - Relative volume adjustment
|
|
90
|
+
This frame is replaced by the RVA2 frame, 'Relative volume
|
|
91
|
+
adjustment (2)' [F:4.11].
|
|
92
|
+
|
|
93
|
+
TDAT - Date
|
|
94
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
95
|
+
[F:4.2.5].
|
|
96
|
+
|
|
97
|
+
TIME - Time
|
|
98
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
99
|
+
[F:4.2.5].
|
|
100
|
+
|
|
101
|
+
TORY - Original release year
|
|
102
|
+
This frame is replaced by the TDOR frame, 'Original release time'
|
|
103
|
+
[F:4.2.5].
|
|
104
|
+
|
|
105
|
+
TRDA - Recording dates
|
|
106
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
107
|
+
[F:4.2.5].
|
|
108
|
+
|
|
109
|
+
TSIZ - Size
|
|
110
|
+
The information contained in this frame is in the general case
|
|
111
|
+
either trivial to calculate for the player or impossible for the
|
|
112
|
+
tagger to calculate. There is however no good use for such
|
|
113
|
+
information. The frame is therefore completely deprecated.
|
|
114
|
+
|
|
115
|
+
TYER - Year
|
|
116
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
117
|
+
[F:4.2.5].
|
|
118
|
+
|
|
119
|
+
|
|
120
|
+
5. New frames
|
|
121
|
+
|
|
122
|
+
ASPI Audio seek point index [F:4.30]
|
|
123
|
+
EQU2 Equalisation (2) [F:4.12]
|
|
124
|
+
RVA2 Relative volume adjustment (2) [F:4.11]
|
|
125
|
+
SEEK Seek frame [F:4.29]
|
|
126
|
+
SIGN Signature frame [F:4.28]
|
|
127
|
+
TDEN Encoding time [F:4.2.5]
|
|
128
|
+
TDOR Original release time [F:4.2.5]
|
|
129
|
+
TDRC Recording time [F:4.2.5]
|
|
130
|
+
TDRL Release time [F:4.2.5]
|
|
131
|
+
TDTG Tagging time [F:4.2.5]
|
|
132
|
+
TIPL Involved people list [F:4.2.2]
|
|
133
|
+
TMCL Musician credits list [F:4.2.2]
|
|
134
|
+
TMOO Mood [F:4.2.3]
|
|
135
|
+
TPRO Produced notice [F:4.2.4]
|
|
136
|
+
TSOA Album sort order [F:4.2.5]
|
|
137
|
+
TSOP Performer sort order [F:4.2.5]
|
|
138
|
+
TSOT Title sort order [F:4.2.5]
|
|
139
|
+
TSST Set subtitle [F:4.2.1]
|
|
140
|
+
|
|
141
|
+
|
|
142
|
+
6. References
|
|
143
|
+
|
|
144
|
+
[ID3v2.3.0] Martin Nilsson, "ID3v2 informal standard".
|
|
145
|
+
|
|
146
|
+
http://www.id3lib.org/id3/id3v2.3.0.txt
|
|
147
|
+
|
|
148
|
+
[ID3v2-frames] Martin Nilsson,
|
|
149
|
+
"ID3 tag version 2.4.0 - Native Frames"
|
|
150
|
+
|
|
151
|
+
http://www.id3lib.org/id3/id3v2.4.0-frames.txt
|
|
152
|
+
|
|
153
|
+
[ID3v2-strct] Martin Nilsson,
|
|
154
|
+
"ID3 tag version 2.4.0 - Main Structure"
|
|
155
|
+
|
|
156
|
+
http://www.id3lib.org/id3/id3v2.4.0-structure.txt
|
|
157
|
+
</PRE>
|
|
158
|
+
</BODY>
|
|
159
|
+
</HTML>
|
|
@@ -0,0 +1,149 @@
|
|
|
1
|
+
Informational M. Nilsson
|
|
2
|
+
Document: id3v2.4.0-changes.txt 21st December 2000
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
ID3 tag version 2.4.0 - Changes
|
|
6
|
+
|
|
7
|
+
Status of this document
|
|
8
|
+
|
|
9
|
+
This document describes the changes between ID3v2.3.0 [ID3v2.3.0] and
|
|
10
|
+
ID3v2.4.0 [ID3v2.4.0-strct][ID3v2.4.0-frames]. This document does not
|
|
11
|
+
claim to be complete nor correct.
|
|
12
|
+
|
|
13
|
+
Distribution of this document is unlimited.
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
Abstract
|
|
17
|
+
|
|
18
|
+
This document outlines the more important differences between
|
|
19
|
+
ID3v2.3.0 and ID3v2.4.0. In general ID3v.2.4.0 can be said to be more
|
|
20
|
+
consistent and easier to implement and more suitable to real world
|
|
21
|
+
conditions than the previous versions.
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
1. Table of contents
|
|
25
|
+
|
|
26
|
+
Status of this document
|
|
27
|
+
Abstract
|
|
28
|
+
1. Table of contents
|
|
29
|
+
2. Conventions in this document
|
|
30
|
+
3. Tag structure changes
|
|
31
|
+
4. Deprecated ID3v2 frames
|
|
32
|
+
5. New frames
|
|
33
|
+
6. References
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
2. Conventions in this document
|
|
37
|
+
|
|
38
|
+
References to sections in the ID3v2.4.0 Main Structure
|
|
39
|
+
[ID3v2.4.0-strct] document will be given as [S:x.y] where x is the
|
|
40
|
+
section and y is the subsection. In a similar fashion references to
|
|
41
|
+
sections in the ID3v2.4.0 Native Frames [ID3v2.4.0-frames] document
|
|
42
|
+
will be given as [F:x.y].
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
3. Tag structure changes
|
|
46
|
+
|
|
47
|
+
The location of tags in a file as well as methods to find and merge
|
|
48
|
+
tags are far better defined in ID3v2.4.0 [S:5] than previous
|
|
49
|
+
versions. A reverse search for tags are improved by the addition of a
|
|
50
|
+
tag footer [S:3.4]. A tag footer flag has been added to the header
|
|
51
|
+
flags to indicate the presence of a ID3v2 footer, hence the size
|
|
52
|
+
field is not affected by the footer [S:3.1].
|
|
53
|
+
|
|
54
|
+
The extended header has been completely rewritten [S:3.2] and can not
|
|
55
|
+
produce false synchs. It is also possible to indicate artificial tag
|
|
56
|
+
restrictions in the extended header, for use with thinner clients.
|
|
57
|
+
|
|
58
|
+
Unsynchronisation [S:6.1] is done on frame level, instead of on tag
|
|
59
|
+
level, making it easier to skip frames, increasing the streamability
|
|
60
|
+
of the tag. The unsynchronisation flag in the header [S:3.1]
|
|
61
|
+
indicates if all frames has been unsynchronized, while the new
|
|
62
|
+
unsynchronisation flag in the frame header [S:4.1.2] indicates
|
|
63
|
+
unsynchronisation. To avoid false synchronisations in the frame
|
|
64
|
+
header the size description and flag field has been rewritten [S:4].
|
|
65
|
+
Resynchronisation of the complete tag when the unsynchronisation flag
|
|
66
|
+
in the tag header is set might result in a corrupt tag.
|
|
67
|
+
|
|
68
|
+
The character encodings UTF-16BE and UTF-8 has been added to the list
|
|
69
|
+
of valid encodings [S:4].
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
4. Deprecated ID3v2 frames
|
|
73
|
+
|
|
74
|
+
EQUA - Equalization
|
|
75
|
+
This frame is replaced by the EQU2 frame, 'Equalisation (2)'
|
|
76
|
+
[F:4.12].
|
|
77
|
+
|
|
78
|
+
IPLS - Involved people list
|
|
79
|
+
This frame is replaced by the two frames TMCL, 'Musician credits
|
|
80
|
+
list' [F:4.2.2], and TIPL, 'Involved people list' [F:4.2.2].
|
|
81
|
+
|
|
82
|
+
RVAD - Relative volume adjustment
|
|
83
|
+
This frame is replaced by the RVA2 frame, 'Relative volume
|
|
84
|
+
adjustment (2)' [F:4.11].
|
|
85
|
+
|
|
86
|
+
TDAT - Date
|
|
87
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
88
|
+
[F:4.2.5].
|
|
89
|
+
|
|
90
|
+
TIME - Time
|
|
91
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
92
|
+
[F:4.2.5].
|
|
93
|
+
|
|
94
|
+
TORY - Original release year
|
|
95
|
+
This frame is replaced by the TDOR frame, 'Original release time'
|
|
96
|
+
[F:4.2.5].
|
|
97
|
+
|
|
98
|
+
TRDA - Recording dates
|
|
99
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
100
|
+
[F:4.2.5].
|
|
101
|
+
|
|
102
|
+
TSIZ - Size
|
|
103
|
+
The information contained in this frame is in the general case
|
|
104
|
+
either trivial to calculate for the player or impossible for the
|
|
105
|
+
tagger to calculate. There is however no good use for such
|
|
106
|
+
information. The frame is therefore completely deprecated.
|
|
107
|
+
|
|
108
|
+
TYER - Year
|
|
109
|
+
This frame is replaced by the TDRC frame, 'Recording time'
|
|
110
|
+
[F:4.2.5].
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
5. New frames
|
|
114
|
+
|
|
115
|
+
ASPI Audio seek point index [F:4.30]
|
|
116
|
+
EQU2 Equalisation (2) [F:4.12]
|
|
117
|
+
RVA2 Relative volume adjustment (2) [F:4.11]
|
|
118
|
+
SEEK Seek frame [F:4.29]
|
|
119
|
+
SIGN Signature frame [F:4.28]
|
|
120
|
+
TDEN Encoding time [F:4.2.5]
|
|
121
|
+
TDOR Original release time [F:4.2.5]
|
|
122
|
+
TDRC Recording time [F:4.2.5]
|
|
123
|
+
TDRL Release time [F:4.2.5]
|
|
124
|
+
TDTG Tagging time [F:4.2.5]
|
|
125
|
+
TIPL Involved people list [F:4.2.2]
|
|
126
|
+
TMCL Musician credits list [F:4.2.2]
|
|
127
|
+
TMOO Mood [F:4.2.3]
|
|
128
|
+
TPRO Produced notice [F:4.2.4]
|
|
129
|
+
TSOA Album sort order [F:4.2.5]
|
|
130
|
+
TSOP Performer sort order [F:4.2.5]
|
|
131
|
+
TSOT Title sort order [F:4.2.5]
|
|
132
|
+
TSST Set subtitle [F:4.2.1]
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
6. References
|
|
136
|
+
|
|
137
|
+
[ID3v2.3.0] Martin Nilsson, "ID3v2 informal standard".
|
|
138
|
+
|
|
139
|
+
http://www.id3lib.org/id3/id3v2.3.0.txt
|
|
140
|
+
|
|
141
|
+
[ID3v2-frames] Martin Nilsson,
|
|
142
|
+
"ID3 tag version 2.4.0 - Native Frames"
|
|
143
|
+
|
|
144
|
+
http://www.id3lib.org/id3/id3v2.4.0-frames.txt
|
|
145
|
+
|
|
146
|
+
[ID3v2-strct] Martin Nilsson,
|
|
147
|
+
"ID3 tag version 2.4.0 - Main Structure"
|
|
148
|
+
|
|
149
|
+
http://www.id3lib.org/id3/id3v2.4.0-structure.txt
|
|
@@ -0,0 +1,1743 @@
|
|
|
1
|
+
<HTML>
|
|
2
|
+
<HEAD>
|
|
3
|
+
<TITLE>ID3 tag version 2.4.0 - Native Frames</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.4.0-frames.txt 1st November 2000
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
ID3 tag version 2.4.0 - Native Frames
|
|
13
|
+
|
|
14
|
+
Status of this document
|
|
15
|
+
|
|
16
|
+
This document is an informal standard and replaces the ID3v2.3.0
|
|
17
|
+
standard [ID3v2]. A formal standard will use another revision number
|
|
18
|
+
even if the content is identical to document. The contents in this
|
|
19
|
+
document may change for clarifications but never for added or altered
|
|
20
|
+
functionallity.
|
|
21
|
+
|
|
22
|
+
Distribution of this document is unlimited.
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
Abstract
|
|
26
|
+
|
|
27
|
+
This document describes the frames natively supported by ID3v2.4.0,
|
|
28
|
+
which is a revised version of the ID3v2 informal standard [ID3v2.3.0]
|
|
29
|
+
version 2.3.0. The ID3v2 offers a flexible way of storing audio meta
|
|
30
|
+
information within audio file itself. The information may be
|
|
31
|
+
technical information, such as equalisation curves, as well as title,
|
|
32
|
+
performer, copyright etc.
|
|
33
|
+
|
|
34
|
+
ID3v2.4.0 is meant to be as close as possible to ID3v2.3.0 in order
|
|
35
|
+
to allow for implementations to be revised as easily as possible.
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
1. Table of contents
|
|
39
|
+
|
|
40
|
+
2. Conventions in this document
|
|
41
|
+
3. Default flags
|
|
42
|
+
4. Declared ID3v2 frames
|
|
43
|
+
4.1. Unique file identifier
|
|
44
|
+
4.2. Text information frames
|
|
45
|
+
4.2.1. Identification frames
|
|
46
|
+
4.2.2. Involved persons frames
|
|
47
|
+
4.2.3. Derived and subjective properties frames
|
|
48
|
+
4.2.4. Rights and license frames
|
|
49
|
+
4.2.5. Other text frames
|
|
50
|
+
4.2.6. User defined text information frame
|
|
51
|
+
4.3. URL link frames
|
|
52
|
+
4.3.1. URL link frames - details
|
|
53
|
+
4.3.2. User defined URL link frame
|
|
54
|
+
4.4. Music CD Identifier
|
|
55
|
+
4.5. Event timing codes
|
|
56
|
+
4.6. MPEG location lookup table
|
|
57
|
+
4.7. Synced tempo codes
|
|
58
|
+
4.8. Unsynchronised lyrics/text transcription
|
|
59
|
+
4.9. Synchronised lyrics/text
|
|
60
|
+
4.10. Comments
|
|
61
|
+
4.11. Relative volume adjustment (2)
|
|
62
|
+
4.12. Equalisation (2)
|
|
63
|
+
4.13. Reverb
|
|
64
|
+
4.14. Attached picture
|
|
65
|
+
4.15. General encapsulated object
|
|
66
|
+
4.16. Play counter
|
|
67
|
+
4.17. Popularimeter
|
|
68
|
+
4.18. Recommended buffer size
|
|
69
|
+
4.19. Audio encryption
|
|
70
|
+
4.20. Linked information
|
|
71
|
+
4.21. Position synchronisation frame
|
|
72
|
+
4.22. Terms of use
|
|
73
|
+
4.23. Ownership frame
|
|
74
|
+
4.24. Commercial frame
|
|
75
|
+
4.25. Encryption method registration
|
|
76
|
+
4.26. Group identification registration
|
|
77
|
+
4.27. Private frame
|
|
78
|
+
4.28. Signature frame
|
|
79
|
+
4.29. Seek frame
|
|
80
|
+
4.30. Audio seek point index
|
|
81
|
+
5. Copyright
|
|
82
|
+
6. References
|
|
83
|
+
7. Appendix
|
|
84
|
+
A. Appendix A - Genre List from ID3v1
|
|
85
|
+
8. Author's Address
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
2. Conventions in this document
|
|
89
|
+
|
|
90
|
+
Text within "" is a text string exactly as it appears in a tag.
|
|
91
|
+
Numbers preceded with $ are hexadecimal and numbers preceded with %
|
|
92
|
+
are binary. $xx is used to indicate a byte with unknown content. %x
|
|
93
|
+
is used to indicate a bit with unknown content. The most significant
|
|
94
|
+
bit (MSB) of a byte is called 'bit 7' and the least significant bit
|
|
95
|
+
(LSB) is called 'bit 0'.
|
|
96
|
+
|
|
97
|
+
A tag is the whole tag described the ID3v2 main structure document
|
|
98
|
+
[ID3v2-strct]. A frame is a block of information in the tag. The tag
|
|
99
|
+
consists of a header, frames and optional padding. A field is a piece
|
|
100
|
+
of information; one value, a string etc. A numeric string is a string
|
|
101
|
+
that consists of the characters "0123456789" only.
|
|
102
|
+
|
|
103
|
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
104
|
+
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
105
|
+
document are to be interpreted as described in RFC 2119 [KEYWORDS].
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
3. Default flags
|
|
109
|
+
|
|
110
|
+
The default settings for the frames described in this document can be
|
|
111
|
+
divided into the following classes. The flags may be set differently
|
|
112
|
+
if found more suitable by the software.
|
|
113
|
+
|
|
114
|
+
1. Discarded if tag is altered, discarded if file is altered.
|
|
115
|
+
|
|
116
|
+
None.
|
|
117
|
+
|
|
118
|
+
2. Discarded if tag is altered, preserved if file is altered.
|
|
119
|
+
|
|
120
|
+
None.
|
|
121
|
+
|
|
122
|
+
3. Preserved if tag is altered, discarded if file is altered.
|
|
123
|
+
|
|
124
|
+
ASPI, AENC, ETCO, EQU2, MLLT, POSS, SEEK, SYLT, SYTC, RVA2, TENC,
|
|
125
|
+
TLEN
|
|
126
|
+
|
|
127
|
+
4. Preserved if tag is altered, preserved if file is altered.
|
|
128
|
+
|
|
129
|
+
The rest of the frames.
|
|
130
|
+
|
|
131
|
+
|
|
132
|
+
4. Declared ID3v2 frames
|
|
133
|
+
|
|
134
|
+
The following frames are declared in this draft.
|
|
135
|
+
|
|
136
|
+
4.19 AENC Audio encryption
|
|
137
|
+
4.14 APIC Attached picture
|
|
138
|
+
4.30 ASPI Audio seek point index
|
|
139
|
+
|
|
140
|
+
4.10 COMM Comments
|
|
141
|
+
4.24 COMR Commercial frame
|
|
142
|
+
|
|
143
|
+
4.25 ENCR Encryption method registration
|
|
144
|
+
4.12 EQU2 Equalisation (2)
|
|
145
|
+
4.5 ETCO Event timing codes
|
|
146
|
+
|
|
147
|
+
4.15 GEOB General encapsulated object
|
|
148
|
+
4.26 GRID Group identification registration
|
|
149
|
+
|
|
150
|
+
4.20 LINK Linked information
|
|
151
|
+
|
|
152
|
+
4.4 MCDI Music CD identifier
|
|
153
|
+
4.6 MLLT MPEG location lookup table
|
|
154
|
+
|
|
155
|
+
4.23 OWNE Ownership frame
|
|
156
|
+
|
|
157
|
+
4.27 PRIV Private frame
|
|
158
|
+
4.16 PCNT Play counter
|
|
159
|
+
4.17 POPM Popularimeter
|
|
160
|
+
4.21 POSS Position synchronisation frame
|
|
161
|
+
|
|
162
|
+
4.18 RBUF Recommended buffer size
|
|
163
|
+
4.11 RVA2 Relative volume adjustment (2)
|
|
164
|
+
4.13 RVRB Reverb
|
|
165
|
+
|
|
166
|
+
4.29 SEEK Seek frame
|
|
167
|
+
4.28 SIGN Signature frame
|
|
168
|
+
4.9 SYLT Synchronised lyric/text
|
|
169
|
+
4.7 SYTC Synchronised tempo codes
|
|
170
|
+
|
|
171
|
+
4.2.1 TALB Album/Movie/Show title
|
|
172
|
+
4.2.3 TBPM BPM (beats per minute)
|
|
173
|
+
4.2.2 TCOM Composer
|
|
174
|
+
4.2.3 TCON Content type
|
|
175
|
+
4.2.4 TCOP Copyright message
|
|
176
|
+
4.2.5 TDEN Encoding time
|
|
177
|
+
4.2.5 TDLY Playlist delay
|
|
178
|
+
4.2.5 TDOR Original release time
|
|
179
|
+
4.2.5 TDRC Recording time
|
|
180
|
+
4.2.5 TDRL Release time
|
|
181
|
+
4.2.5 TDTG Tagging time
|
|
182
|
+
4.2.2 TENC Encoded by
|
|
183
|
+
4.2.2 TEXT Lyricist/Text writer
|
|
184
|
+
4.2.3 TFLT File type
|
|
185
|
+
4.2.2 TIPL Involved people list
|
|
186
|
+
4.2.1 TIT1 Content group description
|
|
187
|
+
4.2.1 TIT2 Title/songname/content description
|
|
188
|
+
4.2.1 TIT3 Subtitle/Description refinement
|
|
189
|
+
4.2.3 TKEY Initial key
|
|
190
|
+
4.2.3 TLAN Language(s)
|
|
191
|
+
4.2.3 TLEN Length
|
|
192
|
+
4.2.2 TMCL Musician credits list
|
|
193
|
+
4.2.3 TMED Media type
|
|
194
|
+
4.2.3 TMOO Mood
|
|
195
|
+
4.2.1 TOAL Original album/movie/show title
|
|
196
|
+
4.2.5 TOFN Original filename
|
|
197
|
+
4.2.2 TOLY Original lyricist(s)/text writer(s)
|
|
198
|
+
4.2.2 TOPE Original artist(s)/performer(s)
|
|
199
|
+
4.2.4 TOWN File owner/licensee
|
|
200
|
+
4.2.2 TPE1 Lead performer(s)/Soloist(s)
|
|
201
|
+
4.2.2 TPE2 Band/orchestra/accompaniment
|
|
202
|
+
4.2.2 TPE3 Conductor/performer refinement
|
|
203
|
+
4.2.2 TPE4 Interpreted, remixed, or otherwise modified by
|
|
204
|
+
4.2.1 TPOS Part of a set
|
|
205
|
+
4.2.4 TPRO Produced notice
|
|
206
|
+
4.2.4 TPUB Publisher
|
|
207
|
+
4.2.1 TRCK Track number/Position in set
|
|
208
|
+
4.2.4 TRSN Internet radio station name
|
|
209
|
+
4.2.4 TRSO Internet radio station owner
|
|
210
|
+
4.2.5 TSOA Album sort order
|
|
211
|
+
4.2.5 TSOP Performer sort order
|
|
212
|
+
4.2.5 TSOT Title sort order
|
|
213
|
+
4.2.1 TSRC ISRC (international standard recording code)
|
|
214
|
+
4.2.5 TSSE Software/Hardware and settings used for encoding
|
|
215
|
+
4.2.1 TSST Set subtitle
|
|
216
|
+
4.2.2 TXXX User defined text information frame
|
|
217
|
+
|
|
218
|
+
4.1 UFID Unique file identifier
|
|
219
|
+
4.22 USER Terms of use
|
|
220
|
+
4.8 USLT Unsynchronised lyric/text transcription
|
|
221
|
+
|
|
222
|
+
4.3.1 WCOM Commercial information
|
|
223
|
+
4.3.1 WCOP Copyright/Legal information
|
|
224
|
+
4.3.1 WOAF Official audio file webpage
|
|
225
|
+
4.3.1 WOAR Official artist/performer webpage
|
|
226
|
+
4.3.1 WOAS Official audio source webpage
|
|
227
|
+
4.3.1 WORS Official Internet radio station homepage
|
|
228
|
+
4.3.1 WPAY Payment
|
|
229
|
+
4.3.1 WPUB Publishers official webpage
|
|
230
|
+
4.3.2 WXXX User defined URL link frame
|
|
231
|
+
|
|
232
|
+
<A NAME=UFID>
|
|
233
|
+
4.1. Unique file identifier</A>
|
|
234
|
+
|
|
235
|
+
This frame's purpose is to be able to identify the audio file in a
|
|
236
|
+
database, that may provide more information relevant to the content.
|
|
237
|
+
Since standardisation of such a database is beyond this document, all
|
|
238
|
+
UFID frames begin with an 'owner identifier' field. It is a null-
|
|
239
|
+
terminated string with a URL [URL] containing an email address, or a
|
|
240
|
+
link to a location where an email address can be found, that belongs
|
|
241
|
+
to the organisation responsible for this specific database
|
|
242
|
+
implementation. Questions regarding the database should be sent to
|
|
243
|
+
the indicated email address. The URL should not be used for the
|
|
244
|
+
actual database queries. The string
|
|
245
|
+
"<a href="http://www.id3lib.org/id3/dummy/ufid.html">http://www.id3lib.org/id3/dummy/ufid.html</a>" should be used for tests. The
|
|
246
|
+
'Owner identifier' must be non-empty (more than just a termination).
|
|
247
|
+
The 'Owner identifier' is then followed by the actual identifier,
|
|
248
|
+
which may be up to 64 bytes. There may be more than one "UFID" frame
|
|
249
|
+
in a tag, but only one with the same 'Owner identifier'.
|
|
250
|
+
|
|
251
|
+
<Header for 'Unique file identifier', ID: "UFID">
|
|
252
|
+
Owner identifier <text string> $00
|
|
253
|
+
Identifier <up to 64 bytes binary data>
|
|
254
|
+
|
|
255
|
+
|
|
256
|
+
4.2. Text information frames
|
|
257
|
+
|
|
258
|
+
The text information frames are often the most important frames,
|
|
259
|
+
containing information like artist, album and more. There may only be
|
|
260
|
+
one text information frame of its kind in an tag. All text
|
|
261
|
+
information frames supports multiple strings, stored as a null
|
|
262
|
+
separated list, where null is reperesented by the termination code
|
|
263
|
+
for the charater encoding. All text frame identifiers begin with "T".
|
|
264
|
+
Only text frame identifiers begin with "T", with the exception of the
|
|
265
|
+
"TXXX" frame. All the text information frames have the following
|
|
266
|
+
format:
|
|
267
|
+
|
|
268
|
+
<Header for 'Text information frame', ID: "T000" - "TZZZ",
|
|
269
|
+
excluding "TXXX" described in 4.2.6.>
|
|
270
|
+
Text encoding $xx
|
|
271
|
+
Information <text string(s) according to encoding>
|
|
272
|
+
|
|
273
|
+
|
|
274
|
+
4.2.1. Identification frames
|
|
275
|
+
|
|
276
|
+
<A NAME=TIT1>TIT1</A>
|
|
277
|
+
The 'Content group description' frame is used if the sound belongs to
|
|
278
|
+
a larger category of sounds/music. For example, classical music is
|
|
279
|
+
often sorted in different musical sections (e.g. "Piano Concerto",
|
|
280
|
+
"Weather - Hurricane").
|
|
281
|
+
|
|
282
|
+
<A NAME=TIT2>TIT2</A>
|
|
283
|
+
The 'Title/Songname/Content description' frame is the actual name of
|
|
284
|
+
the piece (e.g. "Adagio", "Hurricane Donna").
|
|
285
|
+
|
|
286
|
+
<A NAME=TIT3>TIT3</A>
|
|
287
|
+
The 'Subtitle/Description refinement' frame is used for information
|
|
288
|
+
directly related to the contents title (e.g. "Op. 16" or "Performed
|
|
289
|
+
live at Wembley").
|
|
290
|
+
|
|
291
|
+
<A NAME=TALB>TALB</A>
|
|
292
|
+
The 'Album/Movie/Show title' frame is intended for the title of the
|
|
293
|
+
recording (or source of sound) from which the audio in the file is
|
|
294
|
+
taken.
|
|
295
|
+
|
|
296
|
+
<A NAME=TOAL>TOAL</A>
|
|
297
|
+
The 'Original album/movie/show title' frame is intended for the title
|
|
298
|
+
of the original recording (or source of sound), if for example the
|
|
299
|
+
music in the file should be a cover of a previously released song.
|
|
300
|
+
|
|
301
|
+
<A NAME=TRCK>TRCK</A>
|
|
302
|
+
The 'Track number/Position in set' frame is a numeric string
|
|
303
|
+
containing the order number of the audio-file on its original
|
|
304
|
+
recording. This MAY be extended with a "/" character and a numeric
|
|
305
|
+
string containing the total number of tracks/elements on the original
|
|
306
|
+
recording. E.g. "4/9".
|
|
307
|
+
|
|
308
|
+
<A NAME=TPOS>TPOS</A>
|
|
309
|
+
The 'Part of a set' frame is a numeric string that describes which
|
|
310
|
+
part of a set the audio came from. This frame is used if the source
|
|
311
|
+
described in the "TALB" frame is divided into several mediums, e.g. a
|
|
312
|
+
double CD. The value MAY be extended with a "/" character and a
|
|
313
|
+
numeric string containing the total number of parts in the set. E.g.
|
|
314
|
+
"1/2".
|
|
315
|
+
|
|
316
|
+
<A NAME=TSST>TSST</A>
|
|
317
|
+
The 'Set subtitle' frame is intended for the subtitle of the part of
|
|
318
|
+
a set this track belongs to.
|
|
319
|
+
|
|
320
|
+
<A NAME=TSRC>TSRC</A>
|
|
321
|
+
The 'ISRC' frame should contain the International Standard Recording
|
|
322
|
+
Code [ISRC] (12 characters).
|
|
323
|
+
|
|
324
|
+
|
|
325
|
+
4.2.2. Involved persons frames
|
|
326
|
+
|
|
327
|
+
<A NAME=TPE1>TPE1</A>
|
|
328
|
+
The 'Lead artist/Lead performer/Soloist/Performing group' is
|
|
329
|
+
used for the main artist.
|
|
330
|
+
|
|
331
|
+
<A NAME=TPE2>TPE2</A>
|
|
332
|
+
The 'Band/Orchestra/Accompaniment' frame is used for additional
|
|
333
|
+
information about the performers in the recording.
|
|
334
|
+
|
|
335
|
+
<A NAME=TPE3>TPE3</A>
|
|
336
|
+
The 'Conductor' frame is used for the name of the conductor.
|
|
337
|
+
|
|
338
|
+
<A NAME=TPE4>TPE4</A>
|
|
339
|
+
The 'Interpreted, remixed, or otherwise modified by' frame contains
|
|
340
|
+
more information about the people behind a remix and similar
|
|
341
|
+
interpretations of another existing piece.
|
|
342
|
+
|
|
343
|
+
<A NAME=TOPE>TOPE</A>
|
|
344
|
+
The 'Original artist/performer' frame is intended for the performer
|
|
345
|
+
of the original recording, if for example the music in the file
|
|
346
|
+
should be a cover of a previously released song.
|
|
347
|
+
|
|
348
|
+
<A NAME=TEXT>TEXT</A>
|
|
349
|
+
The 'Lyricist/Text writer' frame is intended for the writer of the
|
|
350
|
+
text or lyrics in the recording.
|
|
351
|
+
|
|
352
|
+
<A NAME=TOLY>TOLY</A>
|
|
353
|
+
The 'Original lyricist/text writer' frame is intended for the
|
|
354
|
+
text writer of the original recording, if for example the music in
|
|
355
|
+
the file should be a cover of a previously released song.
|
|
356
|
+
|
|
357
|
+
<A NAME=TCOM>TCOM</A>
|
|
358
|
+
The 'Composer' frame is intended for the name of the composer.
|
|
359
|
+
|
|
360
|
+
<A NAME=TMCL>TMCL</A>
|
|
361
|
+
The 'Musician credits list' is intended as a mapping between
|
|
362
|
+
instruments and the musician that played it. Every odd field is an
|
|
363
|
+
instrument and every even is an artist or a comma delimited list of
|
|
364
|
+
artists.
|
|
365
|
+
|
|
366
|
+
<A NAME=TIPL>TIPL</A>
|
|
367
|
+
The 'Involved people list' is very similar to the musician credits
|
|
368
|
+
list, but maps between functions, like producer, and names.
|
|
369
|
+
|
|
370
|
+
<A NAME=TENC>TENC</A>
|
|
371
|
+
The 'Encoded by' frame contains the name of the person or
|
|
372
|
+
organisation that encoded the audio file. This field may contain a
|
|
373
|
+
copyright message, if the audio file also is copyrighted by the
|
|
374
|
+
encoder.
|
|
375
|
+
|
|
376
|
+
|
|
377
|
+
4.2.3. Derived and subjective properties frames
|
|
378
|
+
|
|
379
|
+
<A NAME=TBPM>TBPM</A>
|
|
380
|
+
The 'BPM' frame contains the number of beats per minute in the
|
|
381
|
+
main part of the audio. The BPM is an integer and represented as a
|
|
382
|
+
numerical string.
|
|
383
|
+
|
|
384
|
+
<A NAME=TLEN>TLEN</A>
|
|
385
|
+
The 'Length' frame contains the length of the audio file in
|
|
386
|
+
milliseconds, represented as a numeric string.
|
|
387
|
+
|
|
388
|
+
<A NAME=TKEY>TKEY</A>
|
|
389
|
+
The 'Initial key' frame contains the musical key in which the sound
|
|
390
|
+
starts. It is represented as a string with a maximum length of three
|
|
391
|
+
characters. The ground keys are represented with "A","B","C","D","E",
|
|
392
|
+
"F" and "G" and halfkeys represented with "b" and "#". Minor is
|
|
393
|
+
represented as "m", e.g. "Dbm" $00. Off key is represented with an
|
|
394
|
+
"o" only.
|
|
395
|
+
|
|
396
|
+
<A NAME=TLAN>TLAN</A>
|
|
397
|
+
The 'Language' frame should contain the languages of the text or
|
|
398
|
+
lyrics spoken or sung in the audio. The language is represented with
|
|
399
|
+
three characters according to ISO-639-2 [ISO-639-2]. If more than one
|
|
400
|
+
language is used in the text their language codes should follow
|
|
401
|
+
according to the amount of their usage, e.g. "eng" $00 "sve" $00.
|
|
402
|
+
|
|
403
|
+
<A NAME=TCON>TCON</A>
|
|
404
|
+
The 'Content type', which ID3v1 was stored as a one byte numeric
|
|
405
|
+
value only, is now a string. You may use one or several of the ID3v1
|
|
406
|
+
types as numerical strings, or, since the category list would be
|
|
407
|
+
impossible to maintain with accurate and up to date categories,
|
|
408
|
+
define your own. Example: "21" $00 "Eurodisco" $00
|
|
409
|
+
|
|
410
|
+
You may also use any of the following keywords:
|
|
411
|
+
|
|
412
|
+
RX Remix
|
|
413
|
+
CR Cover
|
|
414
|
+
|
|
415
|
+
<A NAME=TFLT>TFLT</A>
|
|
416
|
+
The 'File type' frame indicates which type of audio this tag defines.
|
|
417
|
+
The following types and refinements are defined:
|
|
418
|
+
|
|
419
|
+
MIME MIME type follows
|
|
420
|
+
MPG MPEG Audio
|
|
421
|
+
/1 MPEG 1/2 layer I
|
|
422
|
+
/2 MPEG 1/2 layer II
|
|
423
|
+
/3 MPEG 1/2 layer III
|
|
424
|
+
/2.5 MPEG 2.5
|
|
425
|
+
/AAC Advanced audio compression
|
|
426
|
+
VQF Transform-domain Weighted Interleave Vector Quantisation
|
|
427
|
+
PCM Pulse Code Modulated audio
|
|
428
|
+
|
|
429
|
+
but other types may be used, but not for these types though. This is
|
|
430
|
+
used in a similar way to the predefined types in the "TMED" frame,
|
|
431
|
+
but without parentheses. If this frame is not present audio type is
|
|
432
|
+
assumed to be "MPG".
|
|
433
|
+
|
|
434
|
+
<A NAME=TMED>TMED</A>
|
|
435
|
+
The 'Media type' frame describes from which media the sound
|
|
436
|
+
originated. This may be a text string or a reference to the
|
|
437
|
+
predefined media types found in the list below. Example:
|
|
438
|
+
"VID/PAL/VHS" $00.
|
|
439
|
+
|
|
440
|
+
DIG Other digital media
|
|
441
|
+
/A Analogue transfer from media
|
|
442
|
+
|
|
443
|
+
ANA Other analogue media
|
|
444
|
+
/WAC Wax cylinder
|
|
445
|
+
/8CA 8-track tape cassette
|
|
446
|
+
|
|
447
|
+
CD CD
|
|
448
|
+
/A Analogue transfer from media
|
|
449
|
+
/DD DDD
|
|
450
|
+
/AD ADD
|
|
451
|
+
/AA AAD
|
|
452
|
+
|
|
453
|
+
LD Laserdisc
|
|
454
|
+
|
|
455
|
+
TT Turntable records
|
|
456
|
+
/33 33.33 rpm
|
|
457
|
+
/45 45 rpm
|
|
458
|
+
/71 71.29 rpm
|
|
459
|
+
/76 76.59 rpm
|
|
460
|
+
/78 78.26 rpm
|
|
461
|
+
/80 80 rpm
|
|
462
|
+
|
|
463
|
+
MD MiniDisc
|
|
464
|
+
/A Analogue transfer from media
|
|
465
|
+
|
|
466
|
+
DAT DAT
|
|
467
|
+
/A Analogue transfer from media
|
|
468
|
+
/1 standard, 48 kHz/16 bits, linear
|
|
469
|
+
/2 mode 2, 32 kHz/16 bits, linear
|
|
470
|
+
/3 mode 3, 32 kHz/12 bits, non-linear, low speed
|
|
471
|
+
/4 mode 4, 32 kHz/12 bits, 4 channels
|
|
472
|
+
/5 mode 5, 44.1 kHz/16 bits, linear
|
|
473
|
+
/6 mode 6, 44.1 kHz/16 bits, 'wide track' play
|
|
474
|
+
|
|
475
|
+
DCC DCC
|
|
476
|
+
/A Analogue transfer from media
|
|
477
|
+
|
|
478
|
+
DVD DVD
|
|
479
|
+
/A Analogue transfer from media
|
|
480
|
+
|
|
481
|
+
TV Television
|
|
482
|
+
/PAL PAL
|
|
483
|
+
/NTSC NTSC
|
|
484
|
+
/SECAM SECAM
|
|
485
|
+
|
|
486
|
+
VID Video
|
|
487
|
+
/PAL PAL
|
|
488
|
+
/NTSC NTSC
|
|
489
|
+
/SECAM SECAM
|
|
490
|
+
/VHS VHS
|
|
491
|
+
/SVHS S-VHS
|
|
492
|
+
/BETA BETAMAX
|
|
493
|
+
|
|
494
|
+
RAD Radio
|
|
495
|
+
/FM FM
|
|
496
|
+
/AM AM
|
|
497
|
+
/LW LW
|
|
498
|
+
/MW MW
|
|
499
|
+
|
|
500
|
+
TEL Telephone
|
|
501
|
+
/I ISDN
|
|
502
|
+
|
|
503
|
+
MC MC (normal cassette)
|
|
504
|
+
/4 4.75 cm/s (normal speed for a two sided cassette)
|
|
505
|
+
/9 9.5 cm/s
|
|
506
|
+
/I Type I cassette (ferric/normal)
|
|
507
|
+
/II Type II cassette (chrome)
|
|
508
|
+
/III Type III cassette (ferric chrome)
|
|
509
|
+
/IV Type IV cassette (metal)
|
|
510
|
+
|
|
511
|
+
REE Reel
|
|
512
|
+
/9 9.5 cm/s
|
|
513
|
+
/19 19 cm/s
|
|
514
|
+
/38 38 cm/s
|
|
515
|
+
/76 76 cm/s
|
|
516
|
+
/I Type I cassette (ferric/normal)
|
|
517
|
+
/II Type II cassette (chrome)
|
|
518
|
+
/III Type III cassette (ferric chrome)
|
|
519
|
+
/IV Type IV cassette (metal)
|
|
520
|
+
|
|
521
|
+
<A NAME=TMOO>TMOO</A>
|
|
522
|
+
The 'Mood' frame is intended to reflect the mood of the audio with a
|
|
523
|
+
few keywords, e.g. "Romantic" or "Sad".
|
|
524
|
+
|
|
525
|
+
|
|
526
|
+
4.2.4. Rights and license frames
|
|
527
|
+
|
|
528
|
+
<A NAME=TCOP>TCOP</A>
|
|
529
|
+
The 'Copyright message' frame, in which the string must begin with a
|
|
530
|
+
year and a space character (making five characters), is intended for
|
|
531
|
+
the copyright holder of the original sound, not the audio file
|
|
532
|
+
itself. The absence of this frame means only that the copyright
|
|
533
|
+
information is unavailable or has been removed, and must not be
|
|
534
|
+
interpreted to mean that the audio is public domain. Every time this
|
|
535
|
+
field is displayed the field must be preceded with "Copyright " (C) "
|
|
536
|
+
", where (C) is one character showing a C in a circle.
|
|
537
|
+
|
|
538
|
+
<A NAME=TPRO>TPRO</A>
|
|
539
|
+
The 'Produced notice' frame, in which the string must begin with a
|
|
540
|
+
year and a space character (making five characters), is intended for
|
|
541
|
+
the production copyright holder of the original sound, not the audio
|
|
542
|
+
file itself. The absence of this frame means only that the production
|
|
543
|
+
copyright information is unavailable or has been removed, and must
|
|
544
|
+
not be interpreted to mean that the audio is public domain. Every
|
|
545
|
+
time this field is displayed the field must be preceded with
|
|
546
|
+
"Produced " (P) " ", where (P) is one character showing a P in a
|
|
547
|
+
circle.
|
|
548
|
+
|
|
549
|
+
<A NAME=TPUB>TPUB</A>
|
|
550
|
+
The 'Publisher' frame simply contains the name of the label or
|
|
551
|
+
publisher.
|
|
552
|
+
|
|
553
|
+
<A NAME=TOWN>TOWN</A>
|
|
554
|
+
The 'File owner/licensee' frame contains the name of the owner or
|
|
555
|
+
licensee of the file and it's contents.
|
|
556
|
+
|
|
557
|
+
<A NAME=TRSN>TRSN</A>
|
|
558
|
+
The 'Internet radio station name' frame contains the name of the
|
|
559
|
+
internet radio station from which the audio is streamed.
|
|
560
|
+
|
|
561
|
+
<A NAME=TRSO>TRSO</A>
|
|
562
|
+
The 'Internet radio station owner' frame contains the name of the
|
|
563
|
+
owner of the internet radio station from which the audio is
|
|
564
|
+
streamed.
|
|
565
|
+
|
|
566
|
+
4.2.5. Other text frames
|
|
567
|
+
|
|
568
|
+
<A NAME=TOFN>TOFN</A>
|
|
569
|
+
The 'Original filename' frame contains the preferred filename for the
|
|
570
|
+
file, since some media doesn't allow the desired length of the
|
|
571
|
+
filename. The filename is case sensitive and includes its suffix.
|
|
572
|
+
|
|
573
|
+
<A NAME=TDLY>TDLY</A>
|
|
574
|
+
The 'Playlist delay' defines the numbers of milliseconds of silence
|
|
575
|
+
that should be inserted before this audio. The value zero indicates
|
|
576
|
+
that this is a part of a multifile audio track that should be played
|
|
577
|
+
continuously.
|
|
578
|
+
|
|
579
|
+
<A NAME=TDEN>TDEN</A>
|
|
580
|
+
The 'Encoding time' frame contains a timestamp describing when the
|
|
581
|
+
audio was encoded. Timestamp format is described in the ID3v2
|
|
582
|
+
structure document [ID3v2-strct].
|
|
583
|
+
|
|
584
|
+
<A NAME=TDOR>TDOR</A>
|
|
585
|
+
The 'Original release time' frame contains a timestamp describing
|
|
586
|
+
when the original recording of the audio was released. Timestamp
|
|
587
|
+
format is described in the ID3v2 structure document [ID3v2-strct].
|
|
588
|
+
|
|
589
|
+
<A NAME=TDRC>TDRC</A>
|
|
590
|
+
The 'Recording time' frame contains a timestamp describing when the
|
|
591
|
+
audio was recorded. Timestamp format is described in the ID3v2
|
|
592
|
+
structure document [ID3v2-strct].
|
|
593
|
+
|
|
594
|
+
<A NAME=TDRL>TDRL</A>
|
|
595
|
+
The 'Release time' frame contains a timestamp describing when the
|
|
596
|
+
audio was first released. Timestamp format is described in the ID3v2
|
|
597
|
+
structure document [ID3v2-strct].
|
|
598
|
+
|
|
599
|
+
<A NAME=TDTG>TDTG</A>
|
|
600
|
+
The 'Tagging time' frame contains a timestamp describing then the
|
|
601
|
+
audio was tagged. Timestamp format is described in the ID3v2
|
|
602
|
+
structure document [ID3v2-strct].
|
|
603
|
+
|
|
604
|
+
<A NAME=TSSE>TSSE</A>
|
|
605
|
+
The 'Software/Hardware and settings used for encoding' frame
|
|
606
|
+
includes the used audio encoder and its settings when the file was
|
|
607
|
+
encoded. Hardware refers to hardware encoders, not the computer on
|
|
608
|
+
which a program was run.
|
|
609
|
+
|
|
610
|
+
<A NAME=TSOA>TSOA</A>
|
|
611
|
+
The 'Album sort order' frame defines a string which should be used
|
|
612
|
+
instead of the album name (TALB) for sorting purposes. E.g. an album
|
|
613
|
+
named "A Soundtrack" might preferably be sorted as "Soundtrack".
|
|
614
|
+
|
|
615
|
+
<A NAME=TSOP>TSOP</A>
|
|
616
|
+
The 'Performer sort order' frame defines a string which should be
|
|
617
|
+
used instead of the performer (TPE2) for sorting purposes.
|
|
618
|
+
|
|
619
|
+
<A NAME=TSOT>TSOT</A>
|
|
620
|
+
The 'Title sort order' frame defines a string which should be used
|
|
621
|
+
instead of the title (TIT2) for sorting purposes.
|
|
622
|
+
|
|
623
|
+
<A NAME=TXXX>
|
|
624
|
+
4.2.6. User defined text information frame</A>
|
|
625
|
+
|
|
626
|
+
This frame is intended for one-string text information concerning the
|
|
627
|
+
audio file in a similar way to the other "T"-frames. The frame body
|
|
628
|
+
consists of a description of the string, represented as a terminated
|
|
629
|
+
string, followed by the actual string. There may be more than one
|
|
630
|
+
"TXXX" frame in each tag, but only one with the same description.
|
|
631
|
+
|
|
632
|
+
<Header for 'User defined text information frame', ID: "TXXX">
|
|
633
|
+
Text encoding $xx
|
|
634
|
+
Description <text string according to encoding> $00 (00)
|
|
635
|
+
Value <text string according to encoding>
|
|
636
|
+
|
|
637
|
+
|
|
638
|
+
4.3. URL link frames
|
|
639
|
+
|
|
640
|
+
With these frames dynamic data such as webpages with touring
|
|
641
|
+
information, price information or plain ordinary news can be added to
|
|
642
|
+
the tag. There may only be one URL [URL] link frame of its kind in an
|
|
643
|
+
tag, except when stated otherwise in the frame description. If the
|
|
644
|
+
text string is followed by a string termination, all the following
|
|
645
|
+
information should be ignored and not be displayed. All URL link
|
|
646
|
+
frame identifiers begins with "W". Only URL link frame identifiers
|
|
647
|
+
begins with "W", except for "WXXX". All URL link frames have the
|
|
648
|
+
following format:
|
|
649
|
+
|
|
650
|
+
<Header for 'URL link frame', ID: "W000" - "WZZZ", excluding "WXXX"
|
|
651
|
+
described in 4.3.2.>
|
|
652
|
+
URL <text string>
|
|
653
|
+
|
|
654
|
+
|
|
655
|
+
4.3.1. URL link frames - details
|
|
656
|
+
|
|
657
|
+
<A NAME=WCOM>WCOM</A>
|
|
658
|
+
The 'Commercial information' frame is a URL pointing at a webpage
|
|
659
|
+
with information such as where the album can be bought. There may be
|
|
660
|
+
more than one "WCOM" frame in a tag, but not with the same content.
|
|
661
|
+
|
|
662
|
+
<A NAME=WCOP>WCOP</A>
|
|
663
|
+
The 'Copyright/Legal information' frame is a URL pointing at a
|
|
664
|
+
webpage where the terms of use and ownership of the file is
|
|
665
|
+
described.
|
|
666
|
+
|
|
667
|
+
<A NAME=WOAF>WOAF</A>
|
|
668
|
+
The 'Official audio file webpage' frame is a URL pointing at a file
|
|
669
|
+
specific webpage.
|
|
670
|
+
|
|
671
|
+
<A NAME=WOAR>WOAR</A>
|
|
672
|
+
The 'Official artist/performer webpage' frame is a URL pointing at
|
|
673
|
+
the artists official webpage. There may be more than one "WOAR" frame
|
|
674
|
+
in a tag if the audio contains more than one performer, but not with
|
|
675
|
+
the same content.
|
|
676
|
+
|
|
677
|
+
<A NAME=WOAS>WOAS</A>
|
|
678
|
+
The 'Official audio source webpage' frame is a URL pointing at the
|
|
679
|
+
official webpage for the source of the audio file, e.g. a movie.
|
|
680
|
+
|
|
681
|
+
<A NAME=WORS>WORS</A>
|
|
682
|
+
The 'Official Internet radio station homepage' contains a URL
|
|
683
|
+
pointing at the homepage of the internet radio station.
|
|
684
|
+
|
|
685
|
+
<A NAME=WPAY>WPAY</A>
|
|
686
|
+
The 'Payment' frame is a URL pointing at a webpage that will handle
|
|
687
|
+
the process of paying for this file.
|
|
688
|
+
|
|
689
|
+
<A NAME=WPUB>WPUB</A>
|
|
690
|
+
The 'Publishers official webpage' frame is a URL pointing at the
|
|
691
|
+
official webpage for the publisher.
|
|
692
|
+
|
|
693
|
+
<A NAME=WXXX>
|
|
694
|
+
4.3.2. User defined URL link frame</A>
|
|
695
|
+
|
|
696
|
+
This frame is intended for URL [URL] links concerning the audio file
|
|
697
|
+
in a similar way to the other "W"-frames. The frame body consists
|
|
698
|
+
of a description of the string, represented as a terminated string,
|
|
699
|
+
followed by the actual URL. The URL is always encoded with ISO-8859-1
|
|
700
|
+
[ISO-8859-1]. There may be more than one "WXXX" frame in each tag,
|
|
701
|
+
but only one with the same description.
|
|
702
|
+
|
|
703
|
+
<Header for 'User defined URL link frame', ID: "WXXX">
|
|
704
|
+
Text encoding $xx
|
|
705
|
+
Description <text string according to encoding> $00 (00)
|
|
706
|
+
URL <text string>
|
|
707
|
+
|
|
708
|
+
<A NAME=MCDI>
|
|
709
|
+
4.4. Music CD identifier</A>
|
|
710
|
+
|
|
711
|
+
This frame is intended for music that comes from a CD, so that the CD
|
|
712
|
+
can be identified in databases such as the CDDB [CDDB]. The frame
|
|
713
|
+
consists of a binary dump of the Table Of Contents, TOC, from the CD,
|
|
714
|
+
which is a header of 4 bytes and then 8 bytes/track on the CD plus 8
|
|
715
|
+
bytes for the 'lead out', making a maximum of 804 bytes. The offset
|
|
716
|
+
to the beginning of every track on the CD should be described with a
|
|
717
|
+
four bytes absolute CD-frame address per track, and not with absolute
|
|
718
|
+
time. When this frame is used the presence of a valid "TRCK" frame is
|
|
719
|
+
REQUIRED, even if the CD's only got one track. It is recommended that
|
|
720
|
+
this frame is always added to tags originating from CDs. There may
|
|
721
|
+
only be one "MCDI" frame in each tag.
|
|
722
|
+
|
|
723
|
+
<Header for 'Music CD identifier', ID: "MCDI">
|
|
724
|
+
CD TOC <binary data>
|
|
725
|
+
|
|
726
|
+
<A NAME=ETCO>
|
|
727
|
+
4.5. Event timing codes</A>
|
|
728
|
+
|
|
729
|
+
This frame allows synchronisation with key events in the audio. The
|
|
730
|
+
header is:
|
|
731
|
+
|
|
732
|
+
<Header for 'Event timing codes', ID: "ETCO">
|
|
733
|
+
Time stamp format $xx
|
|
734
|
+
|
|
735
|
+
Where time stamp format is:
|
|
736
|
+
|
|
737
|
+
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
|
738
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
739
|
+
|
|
740
|
+
Absolute time means that every stamp contains the time from the
|
|
741
|
+
beginning of the file.
|
|
742
|
+
|
|
743
|
+
Followed by a list of key events in the following format:
|
|
744
|
+
|
|
745
|
+
Type of event $xx
|
|
746
|
+
Time stamp $xx (xx ...)
|
|
747
|
+
|
|
748
|
+
The 'Time stamp' is set to zero if directly at the beginning of the
|
|
749
|
+
sound or after the previous event. All events MUST be sorted in
|
|
750
|
+
chronological order. The type of event is as follows:
|
|
751
|
+
|
|
752
|
+
$00 padding (has no meaning)
|
|
753
|
+
$01 end of initial silence
|
|
754
|
+
$02 intro start
|
|
755
|
+
$03 main part start
|
|
756
|
+
$04 outro start
|
|
757
|
+
$05 outro end
|
|
758
|
+
$06 verse start
|
|
759
|
+
$07 refrain start
|
|
760
|
+
$08 interlude start
|
|
761
|
+
$09 theme start
|
|
762
|
+
$0A variation start
|
|
763
|
+
$0B key change
|
|
764
|
+
$0C time change
|
|
765
|
+
$0D momentary unwanted noise (Snap, Crackle & Pop)
|
|
766
|
+
$0E sustained noise
|
|
767
|
+
$0F sustained noise end
|
|
768
|
+
$10 intro end
|
|
769
|
+
$11 main part end
|
|
770
|
+
$12 verse end
|
|
771
|
+
$13 refrain end
|
|
772
|
+
$14 theme end
|
|
773
|
+
$15 profanity
|
|
774
|
+
$16 profanity end
|
|
775
|
+
|
|
776
|
+
$17-$DF reserved for future use
|
|
777
|
+
|
|
778
|
+
$E0-$EF not predefined synch 0-F
|
|
779
|
+
|
|
780
|
+
$F0-$FC reserved for future use
|
|
781
|
+
|
|
782
|
+
$FD audio end (start of silence)
|
|
783
|
+
$FE audio file ends
|
|
784
|
+
$FF one more byte of events follows (all the following bytes with
|
|
785
|
+
the value $FF have the same function)
|
|
786
|
+
|
|
787
|
+
Terminating the start events such as "intro start" is OPTIONAL. The
|
|
788
|
+
'Not predefined synch's ($E0-EF) are for user events. You might want
|
|
789
|
+
to synchronise your music to something, like setting off an explosion
|
|
790
|
+
on-stage, activating a screensaver etc.
|
|
791
|
+
|
|
792
|
+
There may only be one "ETCO" frame in each tag.
|
|
793
|
+
|
|
794
|
+
<A NAME=MLLT>
|
|
795
|
+
4.6. MPEG location lookup table</A>
|
|
796
|
+
|
|
797
|
+
To increase performance and accuracy of jumps within a MPEG [MPEG]
|
|
798
|
+
audio file, frames with time codes in different locations in the file
|
|
799
|
+
might be useful. This ID3v2 frame includes references that the
|
|
800
|
+
software can use to calculate positions in the file. After the frame
|
|
801
|
+
header follows a descriptor of how much the 'frame counter' should be
|
|
802
|
+
increased for every reference. If this value is two then the first
|
|
803
|
+
reference points out the second frame, the 2nd reference the 4th
|
|
804
|
+
frame, the 3rd reference the 6th frame etc. In a similar way the
|
|
805
|
+
'bytes between reference' and 'milliseconds between reference' points
|
|
806
|
+
out bytes and milliseconds respectively.
|
|
807
|
+
|
|
808
|
+
Each reference consists of two parts; a certain number of bits, as
|
|
809
|
+
defined in 'bits for bytes deviation', that describes the difference
|
|
810
|
+
between what is said in 'bytes between reference' and the reality and
|
|
811
|
+
a certain number of bits, as defined in 'bits for milliseconds
|
|
812
|
+
deviation', that describes the difference between what is said in
|
|
813
|
+
'milliseconds between reference' and the reality. The number of bits
|
|
814
|
+
in every reference, i.e. 'bits for bytes deviation'+'bits for
|
|
815
|
+
milliseconds deviation', must be a multiple of four. There may only
|
|
816
|
+
be one "MLLT" frame in each tag.
|
|
817
|
+
|
|
818
|
+
<Header for 'Location lookup table', ID: "MLLT">
|
|
819
|
+
MPEG frames between reference $xx xx
|
|
820
|
+
Bytes between reference $xx xx xx
|
|
821
|
+
Milliseconds between reference $xx xx xx
|
|
822
|
+
Bits for bytes deviation $xx
|
|
823
|
+
Bits for milliseconds dev. $xx
|
|
824
|
+
|
|
825
|
+
Then for every reference the following data is included;
|
|
826
|
+
|
|
827
|
+
Deviation in bytes %xxx....
|
|
828
|
+
Deviation in milliseconds %xxx....
|
|
829
|
+
|
|
830
|
+
<A NAME=SYTC>
|
|
831
|
+
4.7. Synchronised tempo codes</A>
|
|
832
|
+
|
|
833
|
+
For a more accurate description of the tempo of a musical piece, this
|
|
834
|
+
frame might be used. After the header follows one byte describing
|
|
835
|
+
which time stamp format should be used. Then follows one or more
|
|
836
|
+
tempo codes. Each tempo code consists of one tempo part and one time
|
|
837
|
+
part. The tempo is in BPM described with one or two bytes. If the
|
|
838
|
+
first byte has the value $FF, one more byte follows, which is added
|
|
839
|
+
to the first giving a range from 2 - 510 BPM, since $00 and $01 is
|
|
840
|
+
reserved. $00 is used to describe a beat-free time period, which is
|
|
841
|
+
not the same as a music-free time period. $01 is used to indicate one
|
|
842
|
+
single beat-stroke followed by a beat-free period.
|
|
843
|
+
|
|
844
|
+
The tempo descriptor is followed by a time stamp. Every time the
|
|
845
|
+
tempo in the music changes, a tempo descriptor may indicate this for
|
|
846
|
+
the player. All tempo descriptors MUST be sorted in chronological
|
|
847
|
+
order. The first beat-stroke in a time-period is at the same time as
|
|
848
|
+
the beat description occurs. There may only be one "SYTC" frame in
|
|
849
|
+
each tag.
|
|
850
|
+
|
|
851
|
+
<Header for 'Synchronised tempo codes', ID: "SYTC">
|
|
852
|
+
Time stamp format $xx
|
|
853
|
+
Tempo data <binary data>
|
|
854
|
+
|
|
855
|
+
Where time stamp format is:
|
|
856
|
+
|
|
857
|
+
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
|
858
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
859
|
+
|
|
860
|
+
Absolute time means that every stamp contains the time from the
|
|
861
|
+
beginning of the file.
|
|
862
|
+
|
|
863
|
+
<A NAME=USLT>
|
|
864
|
+
4.8. Unsynchronised lyrics/text transcription</A>
|
|
865
|
+
|
|
866
|
+
This frame contains the lyrics of the song or a text transcription of
|
|
867
|
+
other vocal activities. The head includes an encoding descriptor and
|
|
868
|
+
a content descriptor. The body consists of the actual text. The
|
|
869
|
+
'Content descriptor' is a terminated string. If no descriptor is
|
|
870
|
+
entered, 'Content descriptor' is $00 (00) only. Newline characters
|
|
871
|
+
are allowed in the text. There may be more than one 'Unsynchronised
|
|
872
|
+
lyrics/text transcription' frame in each tag, but only one with the
|
|
873
|
+
same language and content descriptor.
|
|
874
|
+
|
|
875
|
+
<Header for 'Unsynchronised lyrics/text transcription', ID: "USLT">
|
|
876
|
+
Text encoding $xx
|
|
877
|
+
Language $xx xx xx
|
|
878
|
+
Content descriptor <text string according to encoding> $00 (00)
|
|
879
|
+
Lyrics/text <full text string according to encoding>
|
|
880
|
+
|
|
881
|
+
<A NAME=SYLT>
|
|
882
|
+
4.9. Synchronised lyrics/text</A>
|
|
883
|
+
|
|
884
|
+
This is another way of incorporating the words, said or sung lyrics,
|
|
885
|
+
in the audio file as text, this time, however, in sync with the
|
|
886
|
+
audio. It might also be used to describing events e.g. occurring on a
|
|
887
|
+
stage or on the screen in sync with the audio. The header includes a
|
|
888
|
+
content descriptor, represented with as terminated text string. If no
|
|
889
|
+
descriptor is entered, 'Content descriptor' is $00 (00) only.
|
|
890
|
+
|
|
891
|
+
<Header for 'Synchronised lyrics/text', ID: "SYLT">
|
|
892
|
+
Text encoding $xx
|
|
893
|
+
Language $xx xx xx
|
|
894
|
+
Time stamp format $xx
|
|
895
|
+
Content type $xx
|
|
896
|
+
Content descriptor <text string according to encoding> $00 (00)
|
|
897
|
+
|
|
898
|
+
Content type: $00 is other
|
|
899
|
+
$01 is lyrics
|
|
900
|
+
$02 is text transcription
|
|
901
|
+
$03 is movement/part name (e.g. "Adagio")
|
|
902
|
+
$04 is events (e.g. "Don Quijote enters the stage")
|
|
903
|
+
$05 is chord (e.g. "Bb F Fsus")
|
|
904
|
+
$06 is trivia/'pop up' information
|
|
905
|
+
$07 is URLs to webpages
|
|
906
|
+
$08 is URLs to images
|
|
907
|
+
|
|
908
|
+
Time stamp format:
|
|
909
|
+
|
|
910
|
+
$01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
|
|
911
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
912
|
+
|
|
913
|
+
Absolute time means that every stamp contains the time from the
|
|
914
|
+
beginning of the file.
|
|
915
|
+
|
|
916
|
+
The text that follows the frame header differs from that of the
|
|
917
|
+
unsynchronised lyrics/text transcription in one major way. Each
|
|
918
|
+
syllable (or whatever size of text is considered to be convenient by
|
|
919
|
+
the encoder) is a null terminated string followed by a time stamp
|
|
920
|
+
denoting where in the sound file it belongs. Each sync thus has the
|
|
921
|
+
following structure:
|
|
922
|
+
|
|
923
|
+
Terminated text to be synced (typically a syllable)
|
|
924
|
+
Sync identifier (terminator to above string) $00 (00)
|
|
925
|
+
Time stamp $xx (xx ...)
|
|
926
|
+
|
|
927
|
+
The 'time stamp' is set to zero or the whole sync is omitted if
|
|
928
|
+
located directly at the beginning of the sound. All time stamps
|
|
929
|
+
should be sorted in chronological order. The sync can be considered
|
|
930
|
+
as a validator of the subsequent string.
|
|
931
|
+
|
|
932
|
+
Newline characters are allowed in all "SYLT" frames and MUST be used
|
|
933
|
+
after every entry (name, event etc.) in a frame with the content type
|
|
934
|
+
$03 - $04.
|
|
935
|
+
|
|
936
|
+
A few considerations regarding whitespace characters: Whitespace
|
|
937
|
+
separating words should mark the beginning of a new word, thus
|
|
938
|
+
occurring in front of the first syllable of a new word. This is also
|
|
939
|
+
valid for new line characters. A syllable followed by a comma should
|
|
940
|
+
not be broken apart with a sync (both the syllable and the comma
|
|
941
|
+
should be before the sync).
|
|
942
|
+
|
|
943
|
+
An example: The "USLT" passage
|
|
944
|
+
|
|
945
|
+
"Strangers in the night" $0A "Exchanging glances"
|
|
946
|
+
|
|
947
|
+
would be "SYLT" encoded as:
|
|
948
|
+
|
|
949
|
+
"Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx
|
|
950
|
+
" night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx
|
|
951
|
+
xx "glan" $00 xx xx "ces" $00 xx xx
|
|
952
|
+
|
|
953
|
+
There may be more than one "SYLT" frame in each tag, but only one
|
|
954
|
+
with the same language and content descriptor.
|
|
955
|
+
|
|
956
|
+
<A NAME=COMM>
|
|
957
|
+
4.10. Comments</A>
|
|
958
|
+
|
|
959
|
+
This frame is intended for any kind of full text information that
|
|
960
|
+
does not fit in any other frame. It consists of a frame header
|
|
961
|
+
followed by encoding, language and content descriptors and is ended
|
|
962
|
+
with the actual comment as a text string. Newline characters are
|
|
963
|
+
allowed in the comment text string. There may be more than one
|
|
964
|
+
comment frame in each tag, but only one with the same language and
|
|
965
|
+
content descriptor.
|
|
966
|
+
|
|
967
|
+
<Header for 'Comment', ID: "COMM">
|
|
968
|
+
Text encoding $xx
|
|
969
|
+
Language $xx xx xx
|
|
970
|
+
Short content descrip. <text string according to encoding> $00 (00)
|
|
971
|
+
The actual text <full text string according to encoding>
|
|
972
|
+
|
|
973
|
+
<A NAME=RVA2>
|
|
974
|
+
4.11. Relative volume adjustment (2)</A>
|
|
975
|
+
|
|
976
|
+
This is a more subjective frame than the previous ones. It allows the
|
|
977
|
+
user to say how much he wants to increase/decrease the volume on each
|
|
978
|
+
channel when the file is played. The purpose is to be able to align
|
|
979
|
+
all files to a reference volume, so that you don't have to change the
|
|
980
|
+
volume constantly. This frame may also be used to balance adjust the
|
|
981
|
+
audio. The volume adjustment is encoded as a fixed point decibel
|
|
982
|
+
value, 16 bit signed integer representing (adjustment*512), giving
|
|
983
|
+
+/- 64 dB with a precision of 0.001953125 dB. E.g. +2 dB is stored as
|
|
984
|
+
$04 00 and -2 dB is $FC 00. There may be more than one "RVA2" frame
|
|
985
|
+
in each tag, but only one with the same identification string.
|
|
986
|
+
|
|
987
|
+
<Header for 'Relative volume adjustment (2)', ID: "RVA2">
|
|
988
|
+
Identification <text string> $00
|
|
989
|
+
|
|
990
|
+
The 'identification' string is used to identify the situation and/or
|
|
991
|
+
device where this adjustment should apply. The following is then
|
|
992
|
+
repeated for every channel
|
|
993
|
+
|
|
994
|
+
Type of channel $xx
|
|
995
|
+
Volume adjustment $xx xx
|
|
996
|
+
Bits representing peak $xx
|
|
997
|
+
Peak volume $xx (xx ...)
|
|
998
|
+
|
|
999
|
+
|
|
1000
|
+
Type of channel: $00 Other
|
|
1001
|
+
$01 Master volume
|
|
1002
|
+
$02 Front right
|
|
1003
|
+
$03 Front left
|
|
1004
|
+
$04 Back right
|
|
1005
|
+
$05 Back left
|
|
1006
|
+
$06 Front centre
|
|
1007
|
+
$07 Back centre
|
|
1008
|
+
$08 Subwoofer
|
|
1009
|
+
|
|
1010
|
+
Bits representing peak can be any number between 0 and 255. 0 means
|
|
1011
|
+
that there is no peak volume field. The peak volume field is always
|
|
1012
|
+
padded to whole bytes, setting the most significant bits to zero.
|
|
1013
|
+
|
|
1014
|
+
<A NAME=EQU2>
|
|
1015
|
+
4.12. Equalisation (2)</A>
|
|
1016
|
+
|
|
1017
|
+
This is another subjective, alignment frame. It allows the user to
|
|
1018
|
+
predefine an equalisation curve within the audio file. There may be
|
|
1019
|
+
more than one "EQU2" frame in each tag, but only one with the same
|
|
1020
|
+
identification string.
|
|
1021
|
+
|
|
1022
|
+
<Header of 'Equalisation (2)', ID: "EQU2">
|
|
1023
|
+
Interpolation method $xx
|
|
1024
|
+
Identification <text string> $00
|
|
1025
|
+
|
|
1026
|
+
The 'interpolation method' describes which method is preferred when
|
|
1027
|
+
an interpolation between the adjustment point that follows. The
|
|
1028
|
+
following methods are currently defined:
|
|
1029
|
+
|
|
1030
|
+
$00 Band
|
|
1031
|
+
No interpolation is made. A jump from one adjustment level to
|
|
1032
|
+
another occurs in the middle between two adjustment points.
|
|
1033
|
+
$01 Linear
|
|
1034
|
+
Interpolation between adjustment points is linear.
|
|
1035
|
+
|
|
1036
|
+
The 'identification' string is used to identify the situation and/or
|
|
1037
|
+
device where this adjustment should apply. The following is then
|
|
1038
|
+
repeated for every adjustment point
|
|
1039
|
+
|
|
1040
|
+
Frequency $xx xx
|
|
1041
|
+
Volume adjustment $xx xx
|
|
1042
|
+
|
|
1043
|
+
The frequency is stored in units of 1/2 Hz, giving it a range from 0
|
|
1044
|
+
to 32767 Hz.
|
|
1045
|
+
|
|
1046
|
+
The volume adjustment is encoded as a fixed point decibel value, 16
|
|
1047
|
+
bit signed integer representing (adjustment*512), giving +/- 64 dB
|
|
1048
|
+
with a precision of 0.001953125 dB. E.g. +2 dB is stored as $04 00
|
|
1049
|
+
and -2 dB is $FC 00.
|
|
1050
|
+
|
|
1051
|
+
Adjustment points should be ordered by frequency and one frequency
|
|
1052
|
+
should only be described once in the frame.
|
|
1053
|
+
|
|
1054
|
+
<A NAME=RVRB>
|
|
1055
|
+
4.13. Reverb</A>
|
|
1056
|
+
|
|
1057
|
+
Yet another subjective frame, with which you can adjust echoes of
|
|
1058
|
+
different kinds. Reverb left/right is the delay between every bounce
|
|
1059
|
+
in ms. Reverb bounces left/right is the number of bounces that should
|
|
1060
|
+
be made. $FF equals an infinite number of bounces. Feedback is the
|
|
1061
|
+
amount of volume that should be returned to the next echo bounce. $00
|
|
1062
|
+
is 0%, $FF is 100%. If this value were $7F, there would be 50% volume
|
|
1063
|
+
reduction on the first bounce, 50% of that on the second and so on.
|
|
1064
|
+
Left to left means the sound from the left bounce to be played in the
|
|
1065
|
+
left speaker, while left to right means sound from the left bounce to
|
|
1066
|
+
be played in the right speaker.
|
|
1067
|
+
|
|
1068
|
+
'Premix left to right' is the amount of left sound to be mixed in the
|
|
1069
|
+
right before any reverb is applied, where $00 id 0% and $FF is 100%.
|
|
1070
|
+
'Premix right to left' does the same thing, but right to left.
|
|
1071
|
+
Setting both premix to $FF would result in a mono output (if the
|
|
1072
|
+
reverb is applied symmetric). There may only be one "RVRB" frame in
|
|
1073
|
+
each tag.
|
|
1074
|
+
|
|
1075
|
+
<Header for 'Reverb', ID: "RVRB">
|
|
1076
|
+
Reverb left (ms) $xx xx
|
|
1077
|
+
Reverb right (ms) $xx xx
|
|
1078
|
+
Reverb bounces, left $xx
|
|
1079
|
+
Reverb bounces, right $xx
|
|
1080
|
+
Reverb feedback, left to left $xx
|
|
1081
|
+
Reverb feedback, left to right $xx
|
|
1082
|
+
Reverb feedback, right to right $xx
|
|
1083
|
+
Reverb feedback, right to left $xx
|
|
1084
|
+
Premix left to right $xx
|
|
1085
|
+
Premix right to left $xx
|
|
1086
|
+
|
|
1087
|
+
<A NAME=APIC>
|
|
1088
|
+
4.14. Attached picture</A>
|
|
1089
|
+
|
|
1090
|
+
This frame contains a picture directly related to the audio file.
|
|
1091
|
+
Image format is the MIME type and subtype [MIME] for the image. In
|
|
1092
|
+
the event that the MIME media type name is omitted, "image/" will be
|
|
1093
|
+
implied. The "image/png" [PNG] or "image/jpeg" [JFIF] picture format
|
|
1094
|
+
should be used when interoperability is wanted. Description is a
|
|
1095
|
+
short description of the picture, represented as a terminated
|
|
1096
|
+
text string. There may be several pictures attached to one file, each
|
|
1097
|
+
in their individual "APIC" frame, but only one with the same content
|
|
1098
|
+
descriptor. There may only be one picture with the picture type
|
|
1099
|
+
declared as picture type $01 and $02 respectively. There is the
|
|
1100
|
+
possibility to put only a link to the image file by using the 'MIME
|
|
1101
|
+
type' "-->" and having a complete URL [URL] instead of picture data.
|
|
1102
|
+
The use of linked files should however be used sparingly since there
|
|
1103
|
+
is the risk of separation of files.
|
|
1104
|
+
|
|
1105
|
+
<Header for 'Attached picture', ID: "APIC">
|
|
1106
|
+
Text encoding $xx
|
|
1107
|
+
MIME type <text string> $00
|
|
1108
|
+
Picture type $xx
|
|
1109
|
+
Description <text string according to encoding> $00 (00)
|
|
1110
|
+
Picture data <binary data>
|
|
1111
|
+
|
|
1112
|
+
|
|
1113
|
+
Picture type: $00 Other
|
|
1114
|
+
$01 32x32 pixels 'file icon' (PNG only)
|
|
1115
|
+
$02 Other file icon
|
|
1116
|
+
$03 Cover (front)
|
|
1117
|
+
$04 Cover (back)
|
|
1118
|
+
$05 Leaflet page
|
|
1119
|
+
$06 Media (e.g. label side of CD)
|
|
1120
|
+
$07 Lead artist/lead performer/soloist
|
|
1121
|
+
$08 Artist/performer
|
|
1122
|
+
$09 Conductor
|
|
1123
|
+
$0A Band/Orchestra
|
|
1124
|
+
$0B Composer
|
|
1125
|
+
$0C Lyricist/text writer
|
|
1126
|
+
$0D Recording Location
|
|
1127
|
+
$0E During recording
|
|
1128
|
+
$0F During performance
|
|
1129
|
+
$10 Movie/video screen capture
|
|
1130
|
+
$11 A bright coloured fish
|
|
1131
|
+
$12 Illustration
|
|
1132
|
+
$13 Band/artist logotype
|
|
1133
|
+
$14 Publisher/Studio logotype
|
|
1134
|
+
|
|
1135
|
+
<A NAME=GEOB>
|
|
1136
|
+
4.15. General encapsulated object</A>
|
|
1137
|
+
|
|
1138
|
+
In this frame any type of file can be encapsulated. After the header,
|
|
1139
|
+
'Frame size' and 'Encoding' follows 'MIME type' [MIME] represented as
|
|
1140
|
+
as a terminated string encoded with ISO 8859-1 [ISO-8859-1]. The
|
|
1141
|
+
filename is case sensitive and is encoded as 'Encoding'. Then follows
|
|
1142
|
+
a content description as terminated string, encoded as 'Encoding'.
|
|
1143
|
+
The last thing in the frame is the actual object. The first two
|
|
1144
|
+
strings may be omitted, leaving only their terminations. MIME type is
|
|
1145
|
+
always an ISO-8859-1 text string. There may be more than one "GEOB"
|
|
1146
|
+
frame in each tag, but only one with the same content descriptor.
|
|
1147
|
+
|
|
1148
|
+
<Header for 'General encapsulated object', ID: "GEOB">
|
|
1149
|
+
Text encoding $xx
|
|
1150
|
+
MIME type <text string> $00
|
|
1151
|
+
Filename <text string according to encoding> $00 (00)
|
|
1152
|
+
Content description <text string according to encoding> $00 (00)
|
|
1153
|
+
Encapsulated object <binary data>
|
|
1154
|
+
|
|
1155
|
+
<A NAME=PCNT>
|
|
1156
|
+
4.16. Play counter</A>
|
|
1157
|
+
|
|
1158
|
+
This is simply a counter of the number of times a file has been
|
|
1159
|
+
played. The value is increased by one every time the file begins to
|
|
1160
|
+
play. There may only be one "PCNT" frame in each tag. When the
|
|
1161
|
+
counter reaches all one's, one byte is inserted in front of the
|
|
1162
|
+
counter thus making the counter eight bits bigger. The counter must
|
|
1163
|
+
be at least 32-bits long to begin with.
|
|
1164
|
+
|
|
1165
|
+
<Header for 'Play counter', ID: "PCNT">
|
|
1166
|
+
Counter $xx xx xx xx (xx ...)
|
|
1167
|
+
|
|
1168
|
+
<A NAME=POPM>
|
|
1169
|
+
4.17. Popularimeter</A>
|
|
1170
|
+
|
|
1171
|
+
The purpose of this frame is to specify how good an audio file is.
|
|
1172
|
+
Many interesting applications could be found to this frame such as a
|
|
1173
|
+
playlist that features better audio files more often than others or
|
|
1174
|
+
it could be used to profile a person's taste and find other 'good'
|
|
1175
|
+
files by comparing people's profiles. The frame contains the email
|
|
1176
|
+
address to the user, one rating byte and a four byte play counter,
|
|
1177
|
+
intended to be increased with one for every time the file is played.
|
|
1178
|
+
The email is a terminated string. The rating is 1-255 where 1 is
|
|
1179
|
+
worst and 255 is best. 0 is unknown. If no personal counter is wanted
|
|
1180
|
+
it may be omitted. When the counter reaches all one's, one byte is
|
|
1181
|
+
inserted in front of the counter thus making the counter eight bits
|
|
1182
|
+
bigger in the same away as the play counter ("PCNT"). There may be
|
|
1183
|
+
more than one "POPM" frame in each tag, but only one with the same
|
|
1184
|
+
email address.
|
|
1185
|
+
|
|
1186
|
+
<Header for 'Popularimeter', ID: "POPM">
|
|
1187
|
+
Email to user <text string> $00
|
|
1188
|
+
Rating $xx
|
|
1189
|
+
Counter $xx xx xx xx (xx ...)
|
|
1190
|
+
|
|
1191
|
+
<A NAME=RBUF>
|
|
1192
|
+
4.18. Recommended buffer size</A>
|
|
1193
|
+
|
|
1194
|
+
Sometimes the server from which an audio file is streamed is aware of
|
|
1195
|
+
transmission or coding problems resulting in interruptions in the
|
|
1196
|
+
audio stream. In these cases, the size of the buffer can be
|
|
1197
|
+
recommended by the server using this frame. If the 'embedded info
|
|
1198
|
+
flag' is true (1) then this indicates that an ID3 tag with the
|
|
1199
|
+
maximum size described in 'Buffer size' may occur in the audio
|
|
1200
|
+
stream. In such case the tag should reside between two MPEG [MPEG]
|
|
1201
|
+
frames, if the audio is MPEG encoded. If the position of the next tag
|
|
1202
|
+
is known, 'offset to next tag' may be used. The offset is calculated
|
|
1203
|
+
from the end of tag in which this frame resides to the first byte of
|
|
1204
|
+
the header in the next. This field may be omitted. Embedded tags are
|
|
1205
|
+
generally not recommended since this could render unpredictable
|
|
1206
|
+
behaviour from present software/hardware.
|
|
1207
|
+
|
|
1208
|
+
For applications like streaming audio it might be an idea to embed
|
|
1209
|
+
tags into the audio stream though. If the clients connects to
|
|
1210
|
+
individual connections like HTTP and there is a possibility to begin
|
|
1211
|
+
every transmission with a tag, then this tag should include a
|
|
1212
|
+
'recommended buffer size' frame. If the client is connected to a
|
|
1213
|
+
arbitrary point in the stream, such as radio or multicast, then the
|
|
1214
|
+
'recommended buffer size' frame SHOULD be included in every tag.
|
|
1215
|
+
|
|
1216
|
+
The 'Buffer size' should be kept to a minimum. There may only be one
|
|
1217
|
+
"RBUF" frame in each tag.
|
|
1218
|
+
|
|
1219
|
+
<Header for 'Recommended buffer size', ID: "RBUF">
|
|
1220
|
+
Buffer size $xx xx xx
|
|
1221
|
+
Embedded info flag %0000000x
|
|
1222
|
+
Offset to next tag $xx xx xx xx
|
|
1223
|
+
|
|
1224
|
+
<A NAME=AENC>
|
|
1225
|
+
4.19. Audio encryption</A>
|
|
1226
|
+
|
|
1227
|
+
This frame indicates if the actual audio stream is encrypted, and by
|
|
1228
|
+
whom. Since standardisation of such encryption scheme is beyond this
|
|
1229
|
+
document, all "AENC" frames begin with a terminated string with a
|
|
1230
|
+
URL containing an email address, or a link to a location where an
|
|
1231
|
+
email address can be found, that belongs to the organisation
|
|
1232
|
+
responsible for this specific encrypted audio file. Questions
|
|
1233
|
+
regarding the encrypted audio should be sent to the email address
|
|
1234
|
+
specified. If a $00 is found directly after the 'Frame size' and the
|
|
1235
|
+
audio file indeed is encrypted, the whole file may be considered
|
|
1236
|
+
useless.
|
|
1237
|
+
|
|
1238
|
+
After the 'Owner identifier', a pointer to an unencrypted part of the
|
|
1239
|
+
audio can be specified. The 'Preview start' and 'Preview length' is
|
|
1240
|
+
described in frames. If no part is unencrypted, these fields should
|
|
1241
|
+
be left zeroed. After the 'preview length' field follows optionally a
|
|
1242
|
+
data block required for decryption of the audio. There may be more
|
|
1243
|
+
than one "AENC" frames in a tag, but only one with the same 'Owner
|
|
1244
|
+
identifier'.
|
|
1245
|
+
|
|
1246
|
+
<Header for 'Audio encryption', ID: "AENC">
|
|
1247
|
+
Owner identifier <text string> $00
|
|
1248
|
+
Preview start $xx xx
|
|
1249
|
+
Preview length $xx xx
|
|
1250
|
+
Encryption info <binary data>
|
|
1251
|
+
|
|
1252
|
+
<A NAME=LINK>
|
|
1253
|
+
4.20. Linked information</A>
|
|
1254
|
+
|
|
1255
|
+
To keep information duplication as low as possible this frame may be
|
|
1256
|
+
used to link information from another ID3v2 tag that might reside in
|
|
1257
|
+
another audio file or alone in a binary file. It is RECOMMENDED that
|
|
1258
|
+
this method is only used when the files are stored on a CD-ROM or
|
|
1259
|
+
other circumstances when the risk of file separation is low. The
|
|
1260
|
+
frame contains a frame identifier, which is the frame that should be
|
|
1261
|
+
linked into this tag, a URL [URL] field, where a reference to the
|
|
1262
|
+
file where the frame is given, and additional ID data, if needed.
|
|
1263
|
+
Data should be retrieved from the first tag found in the file to
|
|
1264
|
+
which this link points. There may be more than one "LINK" frame in a
|
|
1265
|
+
tag, but only one with the same contents. A linked frame is to be
|
|
1266
|
+
considered as part of the tag and has the same restrictions as if it
|
|
1267
|
+
was a physical part of the tag (i.e. only one "RVRB" frame allowed,
|
|
1268
|
+
whether it's linked or not).
|
|
1269
|
+
|
|
1270
|
+
<Header for 'Linked information', ID: "LINK">
|
|
1271
|
+
Frame identifier $xx xx xx xx
|
|
1272
|
+
URL <text string> $00
|
|
1273
|
+
ID and additional data <text string(s)>
|
|
1274
|
+
|
|
1275
|
+
Frames that may be linked and need no additional data are "ASPI",
|
|
1276
|
+
"ETCO", "EQU2", "MCID", "MLLT", "OWNE", "RVA2", "RVRB", "SYTC", the
|
|
1277
|
+
text information frames and the URL link frames.
|
|
1278
|
+
|
|
1279
|
+
The "AENC", "APIC", "GEOB" and "TXXX" frames may be linked with
|
|
1280
|
+
the content descriptor as additional ID data.
|
|
1281
|
+
|
|
1282
|
+
The "USER" frame may be linked with the language field as additional
|
|
1283
|
+
ID data.
|
|
1284
|
+
|
|
1285
|
+
The "PRIV" frame may be linked with the owner identifier as
|
|
1286
|
+
additional ID data.
|
|
1287
|
+
|
|
1288
|
+
The "COMM", "SYLT" and "USLT" frames may be linked with three bytes
|
|
1289
|
+
of language descriptor directly followed by a content descriptor as
|
|
1290
|
+
additional ID data.
|
|
1291
|
+
|
|
1292
|
+
<A NAME=POSS>
|
|
1293
|
+
4.21. Position synchronisation frame</A>
|
|
1294
|
+
|
|
1295
|
+
This frame delivers information to the listener of how far into the
|
|
1296
|
+
audio stream he picked up; in effect, it states the time offset from
|
|
1297
|
+
the first frame in the stream. The frame layout is:
|
|
1298
|
+
|
|
1299
|
+
<Head for 'Position synchronisation', ID: "POSS">
|
|
1300
|
+
Time stamp format $xx
|
|
1301
|
+
Position $xx (xx ...)
|
|
1302
|
+
|
|
1303
|
+
Where time stamp format is:
|
|
1304
|
+
|
|
1305
|
+
$01 Absolute time, 32 bit sized, using MPEG frames as unit
|
|
1306
|
+
$02 Absolute time, 32 bit sized, using milliseconds as unit
|
|
1307
|
+
|
|
1308
|
+
and position is where in the audio the listener starts to receive,
|
|
1309
|
+
i.e. the beginning of the next frame. If this frame is used in the
|
|
1310
|
+
beginning of a file the value is always 0. There may only be one
|
|
1311
|
+
"POSS" frame in each tag.
|
|
1312
|
+
|
|
1313
|
+
<A NAME=USER>
|
|
1314
|
+
4.22. Terms of use frame</A>
|
|
1315
|
+
|
|
1316
|
+
This frame contains a brief description of the terms of use and
|
|
1317
|
+
ownership of the file. More detailed information concerning the legal
|
|
1318
|
+
terms might be available through the "WCOP" frame. Newlines are
|
|
1319
|
+
allowed in the text. There may be more than one 'Terms of use' frame
|
|
1320
|
+
in a tag, but only one with the same 'Language'.
|
|
1321
|
+
|
|
1322
|
+
<Header for 'Terms of use frame', ID: "USER">
|
|
1323
|
+
Text encoding $xx
|
|
1324
|
+
Language $xx xx xx
|
|
1325
|
+
The actual text <text string according to encoding>
|
|
1326
|
+
|
|
1327
|
+
<A NAME=OWNE>
|
|
1328
|
+
4.23. Ownership frame</A>
|
|
1329
|
+
|
|
1330
|
+
The ownership frame might be used as a reminder of a made transaction
|
|
1331
|
+
or, if signed, as proof. Note that the "USER" and "TOWN" frames are
|
|
1332
|
+
good to use in conjunction with this one. The frame begins, after the
|
|
1333
|
+
frame ID, size and encoding fields, with a 'price paid' field. The
|
|
1334
|
+
first three characters of this field contains the currency used for
|
|
1335
|
+
the transaction, encoded according to ISO 4217 [ISO-4217] alphabetic
|
|
1336
|
+
currency code. Concatenated to this is the actual price paid, as a
|
|
1337
|
+
numerical string using "." as the decimal separator. Next is an 8
|
|
1338
|
+
character date string (YYYYMMDD) followed by a string with the name
|
|
1339
|
+
of the seller as the last field in the frame. There may only be one
|
|
1340
|
+
"OWNE" frame in a tag.
|
|
1341
|
+
|
|
1342
|
+
<Header for 'Ownership frame', ID: "OWNE">
|
|
1343
|
+
Text encoding $xx
|
|
1344
|
+
Price paid <text string> $00
|
|
1345
|
+
Date of purch. <text string>
|
|
1346
|
+
Seller <text string according to encoding>
|
|
1347
|
+
|
|
1348
|
+
<A NAME=COMR>
|
|
1349
|
+
4.24. Commercial frame</A>
|
|
1350
|
+
|
|
1351
|
+
This frame enables several competing offers in the same tag by
|
|
1352
|
+
bundling all needed information. That makes this frame rather complex
|
|
1353
|
+
but it's an easier solution than if one tries to achieve the same
|
|
1354
|
+
result with several frames. The frame begins, after the frame ID,
|
|
1355
|
+
size and encoding fields, with a price string field. A price is
|
|
1356
|
+
constructed by one three character currency code, encoded according
|
|
1357
|
+
to ISO 4217 [ISO-4217] alphabetic currency code, followed by a
|
|
1358
|
+
numerical value where "." is used as decimal separator. In the price
|
|
1359
|
+
string several prices may be concatenated, separated by a "/"
|
|
1360
|
+
character, but there may only be one currency of each type.
|
|
1361
|
+
|
|
1362
|
+
The price string is followed by an 8 character date string in the
|
|
1363
|
+
format YYYYMMDD, describing for how long the price is valid. After
|
|
1364
|
+
that is a contact URL, with which the user can contact the seller,
|
|
1365
|
+
followed by a one byte 'received as' field. It describes how the
|
|
1366
|
+
audio is delivered when bought according to the following list:
|
|
1367
|
+
|
|
1368
|
+
$00 Other
|
|
1369
|
+
$01 Standard CD album with other songs
|
|
1370
|
+
$02 Compressed audio on CD
|
|
1371
|
+
$03 File over the Internet
|
|
1372
|
+
$04 Stream over the Internet
|
|
1373
|
+
$05 As note sheets
|
|
1374
|
+
$06 As note sheets in a book with other sheets
|
|
1375
|
+
$07 Music on other media
|
|
1376
|
+
$08 Non-musical merchandise
|
|
1377
|
+
|
|
1378
|
+
Next follows a terminated string with the name of the seller followed
|
|
1379
|
+
by a terminated string with a short description of the product. The
|
|
1380
|
+
last thing is the ability to include a company logotype. The first of
|
|
1381
|
+
them is the 'Picture MIME type' field containing information about
|
|
1382
|
+
which picture format is used. In the event that the MIME media type
|
|
1383
|
+
name is omitted, "image/" will be implied. Currently only "image/png"
|
|
1384
|
+
and "image/jpeg" are allowed. This format string is followed by the
|
|
1385
|
+
binary picture data. This two last fields may be omitted if no
|
|
1386
|
+
picture is attached. There may be more than one 'commercial frame' in
|
|
1387
|
+
a tag, but no two may be identical.
|
|
1388
|
+
|
|
1389
|
+
<Header for 'Commercial frame', ID: "COMR">
|
|
1390
|
+
Text encoding $xx
|
|
1391
|
+
Price string <text string> $00
|
|
1392
|
+
Valid until <text string>
|
|
1393
|
+
Contact URL <text string> $00
|
|
1394
|
+
Received as $xx
|
|
1395
|
+
Name of seller <text string according to encoding> $00 (00)
|
|
1396
|
+
Description <text string according to encoding> $00 (00)
|
|
1397
|
+
Picture MIME type <string> $00
|
|
1398
|
+
Seller logo <binary data>
|
|
1399
|
+
|
|
1400
|
+
<A NAME=ENCR>
|
|
1401
|
+
4.25. Encryption method registration</A>
|
|
1402
|
+
|
|
1403
|
+
To identify with which method a frame has been encrypted the
|
|
1404
|
+
encryption method must be registered in the tag with this frame. The
|
|
1405
|
+
'Owner identifier' is a null-terminated string with a URL [URL]
|
|
1406
|
+
containing an email address, or a link to a location where an email
|
|
1407
|
+
address can be found, that belongs to the organisation responsible
|
|
1408
|
+
for this specific encryption method. Questions regarding the
|
|
1409
|
+
encryption method should be sent to the indicated email address. The
|
|
1410
|
+
'Method symbol' contains a value that is associated with this method
|
|
1411
|
+
throughout the whole tag, in the range $80-F0. All other values are
|
|
1412
|
+
reserved. The 'Method symbol' may optionally be followed by
|
|
1413
|
+
encryption specific data. There may be several "ENCR" frames in a tag
|
|
1414
|
+
but only one containing the same symbol and only one containing the
|
|
1415
|
+
same owner identifier. The method must be used somewhere in the tag.
|
|
1416
|
+
See the description of the frame encryption flag in the ID3v2
|
|
1417
|
+
structure document [ID3v2-strct] for more information.
|
|
1418
|
+
|
|
1419
|
+
<Header for 'Encryption method registration', ID: "ENCR">
|
|
1420
|
+
Owner identifier <text string> $00
|
|
1421
|
+
Method symbol $xx
|
|
1422
|
+
Encryption data <binary data>
|
|
1423
|
+
|
|
1424
|
+
<A NAME=GRID>
|
|
1425
|
+
4.26. Group identification registration</A>
|
|
1426
|
+
|
|
1427
|
+
This frame enables grouping of otherwise unrelated frames. This can
|
|
1428
|
+
be used when some frames are to be signed. To identify which frames
|
|
1429
|
+
belongs to a set of frames a group identifier must be registered in
|
|
1430
|
+
the tag with this frame. The 'Owner identifier' is a null-terminated
|
|
1431
|
+
string with a URL [URL] containing an email address, or a link to a
|
|
1432
|
+
location where an email address can be found, that belongs to the
|
|
1433
|
+
organisation responsible for this grouping. Questions regarding the
|
|
1434
|
+
grouping should be sent to the indicated email address. The 'Group
|
|
1435
|
+
symbol' contains a value that associates the frame with this group
|
|
1436
|
+
throughout the whole tag, in the range $80-F0. All other values are
|
|
1437
|
+
reserved. The 'Group symbol' may optionally be followed by some group
|
|
1438
|
+
specific data, e.g. a digital signature. There may be several "GRID"
|
|
1439
|
+
frames in a tag but only one containing the same symbol and only one
|
|
1440
|
+
containing the same owner identifier. The group symbol must be used
|
|
1441
|
+
somewhere in the tag. See the description of the frame grouping flag
|
|
1442
|
+
in the ID3v2 structure document [ID3v2-strct] for more information.
|
|
1443
|
+
|
|
1444
|
+
<Header for 'Group ID registration', ID: "GRID">
|
|
1445
|
+
Owner identifier <text string> $00
|
|
1446
|
+
Group symbol $xx
|
|
1447
|
+
Group dependent data <binary data>
|
|
1448
|
+
|
|
1449
|
+
<A NAME=PRIV>
|
|
1450
|
+
4.27. Private frame</A>
|
|
1451
|
+
|
|
1452
|
+
This frame is used to contain information from a software producer
|
|
1453
|
+
that its program uses and does not fit into the other frames. The
|
|
1454
|
+
frame consists of an 'Owner identifier' string and the binary data.
|
|
1455
|
+
The 'Owner identifier' is a null-terminated string with a URL [URL]
|
|
1456
|
+
containing an email address, or a link to a location where an email
|
|
1457
|
+
address can be found, that belongs to the organisation responsible
|
|
1458
|
+
for the frame. Questions regarding the frame should be sent to the
|
|
1459
|
+
indicated email address. The tag may contain more than one "PRIV"
|
|
1460
|
+
frame but only with different contents.
|
|
1461
|
+
|
|
1462
|
+
<Header for 'Private frame', ID: "PRIV">
|
|
1463
|
+
Owner identifier <text string> $00
|
|
1464
|
+
The private data <binary data>
|
|
1465
|
+
|
|
1466
|
+
<A NAME=SIGN>
|
|
1467
|
+
4.28. Signature frame</A>
|
|
1468
|
+
|
|
1469
|
+
This frame enables a group of frames, grouped with the 'Group
|
|
1470
|
+
identification registration', to be signed. Although signatures can
|
|
1471
|
+
reside inside the registration frame, it might be desired to store
|
|
1472
|
+
the signature elsewhere, e.g. in watermarks. There may be more than
|
|
1473
|
+
one 'signature frame' in a tag, but no two may be identical.
|
|
1474
|
+
|
|
1475
|
+
<Header for 'Signature frame', ID: "SIGN">
|
|
1476
|
+
Group symbol $xx
|
|
1477
|
+
Signature <binary data>
|
|
1478
|
+
|
|
1479
|
+
<A NAME=SEEK>
|
|
1480
|
+
4.29. Seek frame</A>
|
|
1481
|
+
|
|
1482
|
+
This frame indicates where other tags in a file/stream can be found.
|
|
1483
|
+
The 'minimum offset to next tag' is calculated from the end of this
|
|
1484
|
+
tag to the beginning of the next. There may only be one 'seek frame'
|
|
1485
|
+
in a tag.
|
|
1486
|
+
|
|
1487
|
+
<Header for 'Seek frame', ID: "SEEK">
|
|
1488
|
+
Minimum offset to next tag $xx xx xx xx
|
|
1489
|
+
|
|
1490
|
+
<A NAME=ASPI>
|
|
1491
|
+
4.30. Audio seek point index</A>
|
|
1492
|
+
|
|
1493
|
+
Audio files with variable bit rates are intrinsically difficult to
|
|
1494
|
+
deal with in the case of seeking within the file. The ASPI frame
|
|
1495
|
+
makes seeking easier by providing a list a seek points within the
|
|
1496
|
+
audio file. The seek points are a fractional offset within the audio
|
|
1497
|
+
data, providing a starting point from which to find an appropriate
|
|
1498
|
+
point to start decoding. The presence of an ASPI frame requires the
|
|
1499
|
+
existence of a TLEN frame, indicating the duration of the file in
|
|
1500
|
+
milliseconds. There may only be one 'audio seek point index' frame in
|
|
1501
|
+
a tag.
|
|
1502
|
+
|
|
1503
|
+
<Header for 'Seek Point Index', ID: "ASPI">
|
|
1504
|
+
Indexed data start (S) $xx xx xx xx
|
|
1505
|
+
Indexed data length (L) $xx xx xx xx
|
|
1506
|
+
Number of index points (N) $xx xx
|
|
1507
|
+
Bits per index point (b) $xx
|
|
1508
|
+
|
|
1509
|
+
Then for every index point the following data is included;
|
|
1510
|
+
|
|
1511
|
+
Fraction at index (Fi) $xx (xx)
|
|
1512
|
+
|
|
1513
|
+
'Indexed data start' is a byte offset from the beginning of the file.
|
|
1514
|
+
'Indexed data length' is the byte length of the audio data being
|
|
1515
|
+
indexed. 'Number of index points' is the number of index points, as
|
|
1516
|
+
the name implies. The recommended number is 100. 'Bits per index
|
|
1517
|
+
point' is 8 or 16, depending on the chosen precision. 8 bits works
|
|
1518
|
+
well for short files (less than 5 minutes of audio), while 16 bits is
|
|
1519
|
+
advantageous for long files. 'Fraction at index' is the numerator of
|
|
1520
|
+
the fraction representing a relative position in the data. The
|
|
1521
|
+
denominator is 2 to the power of b.
|
|
1522
|
+
|
|
1523
|
+
Here are the algorithms to be used in the calculation. The known data
|
|
1524
|
+
must be the offset of the start of the indexed data (S), the offset
|
|
1525
|
+
of the end of the indexed data (E), the number of index points (N),
|
|
1526
|
+
the offset at index i (Oi). We calculate the fraction at index i
|
|
1527
|
+
(Fi).
|
|
1528
|
+
|
|
1529
|
+
Oi is the offset of the frame whose start is soonest after the point
|
|
1530
|
+
for which the time offset is (i/N * duration).
|
|
1531
|
+
|
|
1532
|
+
The frame data should be calculated as follows:
|
|
1533
|
+
|
|
1534
|
+
Fi = Oi/L * 2^b (rounded down to the nearest integer)
|
|
1535
|
+
|
|
1536
|
+
Offset calculation should be calculated as follows from data in the
|
|
1537
|
+
frame:
|
|
1538
|
+
|
|
1539
|
+
Oi = (Fi/2^b)*L (rounded up to the nearest integer)
|
|
1540
|
+
|
|
1541
|
+
|
|
1542
|
+
5. Copyright
|
|
1543
|
+
|
|
1544
|
+
Copyright (C) Martin Nilsson 2000. All Rights Reserved.
|
|
1545
|
+
|
|
1546
|
+
This document and translations of it may be copied and furnished to
|
|
1547
|
+
others, and derivative works that comment on or otherwise explain it
|
|
1548
|
+
or assist in its implementation may be prepared, copied, published
|
|
1549
|
+
and distributed, in whole or in part, without restriction of any
|
|
1550
|
+
kind, provided that a reference to this document is included on all
|
|
1551
|
+
such copies and derivative works. However, this document itself may
|
|
1552
|
+
not be modified in any way and reissued as the original document.
|
|
1553
|
+
|
|
1554
|
+
The limited permissions granted above are perpetual and will not be
|
|
1555
|
+
revoked.
|
|
1556
|
+
|
|
1557
|
+
This document and the information contained herein is provided on an
|
|
1558
|
+
"AS IS" basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR
|
|
1559
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
|
1560
|
+
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
1561
|
+
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
1562
|
+
|
|
1563
|
+
|
|
1564
|
+
6. References
|
|
1565
|
+
|
|
1566
|
+
[CDDB] Compact Disc Data Base
|
|
1567
|
+
|
|
1568
|
+
http://www.cddb.com">http://www.cddb.com
|
|
1569
|
+
|
|
1570
|
+
[ID3v2.3.0] Martin Nilsson, "ID3v2 informal standard".
|
|
1571
|
+
|
|
1572
|
+
http://www.id3lib.org/id3/id3v2.3.0.txt
|
|
1573
|
+
|
|
1574
|
+
[ID3v2-strct] Martin Nilsson,
|
|
1575
|
+
"ID3 tag version 2.4.0 - Main Structure"
|
|
1576
|
+
|
|
1577
|
+
http://www.id3lib.org/id3/id3v2.4.0-structure.txt
|
|
1578
|
+
|
|
1579
|
+
[ISO-639-2] ISO/FDIS 639-2.
|
|
1580
|
+
Codes for the representation of names of languages, Part 2: Alpha-3
|
|
1581
|
+
code. Technical committee / subcommittee: TC 37 / SC 2
|
|
1582
|
+
|
|
1583
|
+
[ISO-4217] ISO 4217:1995.
|
|
1584
|
+
Codes for the representation of currencies and funds.
|
|
1585
|
+
Technical committee / subcommittee: TC 68
|
|
1586
|
+
|
|
1587
|
+
[ISO-8859-1] ISO/IEC DIS 8859-1.
|
|
1588
|
+
8-bit single-byte coded graphic character sets, Part 1: Latin
|
|
1589
|
+
alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2
|
|
1590
|
+
|
|
1591
|
+
[ISRC] ISO 3901:1986
|
|
1592
|
+
International Standard Recording Code (ISRC).
|
|
1593
|
+
Technical committee / subcommittee: TC 46 / SC 9
|
|
1594
|
+
|
|
1595
|
+
[JFIF] JPEG File Interchange Format, version 1.02
|
|
1596
|
+
|
|
1597
|
+
http://www.w3.org/Graphics/JPEG/jfif.txt
|
|
1598
|
+
|
|
1599
|
+
[KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate
|
|
1600
|
+
Requirement Levels', RFC 2119, March 1997.
|
|
1601
|
+
|
|
1602
|
+
ftp://ftp.isi.edu/in-notes/rfc2119.txt
|
|
1603
|
+
|
|
1604
|
+
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|
1605
|
+
Extensions (MIME) Part One: Format of Internet Message Bodies",
|
|
1606
|
+
RFC 2045, November 1996.
|
|
1607
|
+
|
|
1608
|
+
ftp://ftp.isi.edu/in-notes/rfc2045.txt
|
|
1609
|
+
|
|
1610
|
+
[MPEG] ISO/IEC 11172-3:1993.
|
|
1611
|
+
Coding of moving pictures and associated audio for digital storage
|
|
1612
|
+
media at up to about 1,5 Mbit/s, Part 3: Audio.
|
|
1613
|
+
Technical committee / subcommittee: JTC 1 / SC 29
|
|
1614
|
+
and
|
|
1615
|
+
ISO/IEC 13818-3:1995
|
|
1616
|
+
Generic coding of moving pictures and associated audio information,
|
|
1617
|
+
Part 3: Audio.
|
|
1618
|
+
Technical committee / subcommittee: JTC 1 / SC 29
|
|
1619
|
+
and
|
|
1620
|
+
ISO/IEC DIS 13818-3
|
|
1621
|
+
Generic coding of moving pictures and associated audio information,
|
|
1622
|
+
Part 3: Audio (Revision of ISO/IEC 13818-3:1995)
|
|
1623
|
+
|
|
1624
|
+
|
|
1625
|
+
[PNG] Portable Network Graphics, version 1.0
|
|
1626
|
+
|
|
1627
|
+
http://www.w3.org/TR/REC-png-multi.html
|
|
1628
|
+
|
|
1629
|
+
[URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource
|
|
1630
|
+
Locators (URL).", RFC 1738, December 1994.
|
|
1631
|
+
|
|
1632
|
+
ftp://ftp.isi.edu/in-notes/rfc1738.txt">ftp://ftp.isi.edu/in-notes/rfc1738.txt
|
|
1633
|
+
|
|
1634
|
+
[ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB
|
|
1635
|
+
Compressed
|
|
1636
|
+
Data Format Specification version 3.3", RFC 1950, May 1996.
|
|
1637
|
+
|
|
1638
|
+
ftp://ftp.isi.edu/in-notes/rfc1950.txt
|
|
1639
|
+
|
|
1640
|
+
|
|
1641
|
+
7. Appendix
|
|
1642
|
+
|
|
1643
|
+
|
|
1644
|
+
A. Appendix A - Genre List from ID3v1
|
|
1645
|
+
|
|
1646
|
+
The following genres is defined in ID3v1
|
|
1647
|
+
|
|
1648
|
+
0.Blues
|
|
1649
|
+
1.Classic Rock
|
|
1650
|
+
2.Country
|
|
1651
|
+
3.Dance
|
|
1652
|
+
4.Disco
|
|
1653
|
+
5.Funk
|
|
1654
|
+
6.Grunge
|
|
1655
|
+
7.Hip-Hop
|
|
1656
|
+
8.Jazz
|
|
1657
|
+
9.Metal
|
|
1658
|
+
10.New Age
|
|
1659
|
+
11.Oldies
|
|
1660
|
+
12.Other
|
|
1661
|
+
13.Pop
|
|
1662
|
+
14.R&B
|
|
1663
|
+
15.Rap
|
|
1664
|
+
16.Reggae
|
|
1665
|
+
17.Rock
|
|
1666
|
+
18.Techno
|
|
1667
|
+
19.Industrial
|
|
1668
|
+
20.Alternative
|
|
1669
|
+
21.Ska
|
|
1670
|
+
22.Death Metal
|
|
1671
|
+
23.Pranks
|
|
1672
|
+
24.Soundtrack
|
|
1673
|
+
25.Euro-Techno
|
|
1674
|
+
26.Ambient
|
|
1675
|
+
27.Trip-Hop
|
|
1676
|
+
28.Vocal
|
|
1677
|
+
29.Jazz+Funk
|
|
1678
|
+
30.Fusion
|
|
1679
|
+
31.Trance
|
|
1680
|
+
32.Classical
|
|
1681
|
+
33.Instrumental
|
|
1682
|
+
34.Acid
|
|
1683
|
+
35.House
|
|
1684
|
+
36.Game
|
|
1685
|
+
37.Sound Clip
|
|
1686
|
+
38.Gospel
|
|
1687
|
+
39.Noise
|
|
1688
|
+
40.AlternRock
|
|
1689
|
+
41.Bass
|
|
1690
|
+
42.Soul
|
|
1691
|
+
43.Punk
|
|
1692
|
+
44.Space
|
|
1693
|
+
45.Meditative
|
|
1694
|
+
46.Instrumental Pop
|
|
1695
|
+
47.Instrumental Rock
|
|
1696
|
+
48.Ethnic
|
|
1697
|
+
49.Gothic
|
|
1698
|
+
50.Darkwave
|
|
1699
|
+
51.Techno-Industrial
|
|
1700
|
+
52.Electronic
|
|
1701
|
+
53.Pop-Folk
|
|
1702
|
+
54.Eurodance
|
|
1703
|
+
55.Dream
|
|
1704
|
+
56.Southern Rock
|
|
1705
|
+
57.Comedy
|
|
1706
|
+
58.Cult
|
|
1707
|
+
59.Gangsta
|
|
1708
|
+
60.Top 40
|
|
1709
|
+
61.Christian Rap
|
|
1710
|
+
62.Pop/Funk
|
|
1711
|
+
63.Jungle
|
|
1712
|
+
64.Native American
|
|
1713
|
+
65.Cabaret
|
|
1714
|
+
66.New Wave
|
|
1715
|
+
67.Psychadelic
|
|
1716
|
+
68.Rave
|
|
1717
|
+
69.Showtunes
|
|
1718
|
+
70.Trailer
|
|
1719
|
+
71.Lo-Fi
|
|
1720
|
+
72.Tribal
|
|
1721
|
+
73.Acid Punk
|
|
1722
|
+
74.Acid Jazz
|
|
1723
|
+
75.Polka
|
|
1724
|
+
76.Retro
|
|
1725
|
+
77.Musical
|
|
1726
|
+
78.Rock & Roll
|
|
1727
|
+
79.Hard Rock
|
|
1728
|
+
|
|
1729
|
+
|
|
1730
|
+
8. Author's Address
|
|
1731
|
+
|
|
1732
|
+
Written by
|
|
1733
|
+
|
|
1734
|
+
Martin Nilsson
|
|
1735
|
+
Rydsv�gen 246 C. 30
|
|
1736
|
+
SE-584 34 Link�ping
|
|
1737
|
+
Sweden
|
|
1738
|
+
|
|
1739
|
+
Email: nilsson@id3.org
|
|
1740
|
+
|
|
1741
|
+
</PRE>
|
|
1742
|
+
</BODY>
|
|
1743
|
+
</HTML>
|