id3 0.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/LICENSE.html +146 -0
- data/README +23 -0
- data/docs/Class_AudioFile.html +110 -0
- data/docs/Class_Frame.html +125 -0
- data/docs/Class_Tag1.html +121 -0
- data/docs/Class_Tag2.html +167 -0
- data/docs/ID3-Standards/id3v2-00.html +1669 -0
- data/docs/ID3-Standards/id3v2-00.txt +1660 -0
- data/docs/ID3-Standards/id3v2.3.0.html +2033 -0
- data/docs/ID3-Standards/id3v2.3.0.txt +2025 -0
- data/docs/ID3-Standards/id3v2.4.0-changes.html +159 -0
- data/docs/ID3-Standards/id3v2.4.0-changes.txt +149 -0
- data/docs/ID3-Standards/id3v2.4.0-frames.html +1743 -0
- data/docs/ID3-Standards/id3v2.4.0-frames.txt +1732 -0
- data/docs/ID3-Standards/id3v2.4.0-structure.html +742 -0
- data/docs/ID3-Standards/id3v2.4.0-structure.txt +732 -0
- data/docs/ID3_comparison.html +2121 -0
- data/docs/ID3_comparison2.html +2043 -0
- data/docs/ID3v2_frames_comparison.html +2121 -0
- data/docs/ID3v2_frames_comparison.txt +197 -0
- data/docs/ID3v2_frames_overview.txt +60 -0
- data/docs/Module_ID3.html +146 -0
- data/docs/id3.html +245 -0
- data/docs/index.html +252 -0
- data/index.html +8 -0
- data/lib/hexdump.rb +113 -0
- data/lib/id3.rb +1177 -0
- data/lib/invert_hash.rb +105 -0
- metadata +75 -0
|
@@ -0,0 +1,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>
|