From 685eb3b954f2806bce985b8c0dd0a0de1b830d17 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim-Philipp=20M=C3=BCller?= Date: Sun, 14 Aug 2011 20:44:19 +0100 Subject: [PATCH] tag: id3v2: add specs to git for reference --- gst-libs/gst/tag/id3v2.3.0.txt | 1942 ++++++++++++++++++++++ gst-libs/gst/tag/id3v2.4.0-frames.txt | 1734 +++++++++++++++++++ gst-libs/gst/tag/id3v2.4.0-structure.txt | 733 ++++++++ 3 files changed, 4409 insertions(+) create mode 100644 gst-libs/gst/tag/id3v2.3.0.txt create mode 100644 gst-libs/gst/tag/id3v2.4.0-frames.txt create mode 100644 gst-libs/gst/tag/id3v2.4.0-structure.txt diff --git a/gst-libs/gst/tag/id3v2.3.0.txt b/gst-libs/gst/tag/id3v2.3.0.txt new file mode 100644 index 0000000000..5b26d638e8 --- /dev/null +++ b/gst-libs/gst/tag/id3v2.3.0.txt @@ -0,0 +1,1942 @@ +* id3v2.3.0 + +Informal Standard +Document: id3v2.3 +M. Nilsson +3rd February 1999 + + +1. ID3 tag version 2.3.0 + + +1.1. Status of this document + +This document is an informal standard and replaces the id3v2.2.0 standard. The +informal standard is released so that implementors could have a set standard +before a formal standard is set. The formal standard will use another version +or revision number if not identical to what is described in this document. The +contents in this document may change for clarifications but never for added or +altered functionallity. +Distribution of this document is unlimited. + +1.2. Abstract + +This document describes the ID3v2.3.0 standard, which is a more developed +version of the ID3v2 informal standard (version [:id3v2-00: 2.2.0]), evolved +from the ID3 tagging system. The ID3v2 offers a flexible way of storing +information about an audio file within itself to determine its origin and +contents. The information may be technical information, such as equalisation +curves, as well as related meta information, such as title, performer, +copyright etc. +Contents + + 1. ID3_tag_version_2.3.0 + + 1. Status_of_this_document + 2. Abstract + + 2. Conventions_in_this_document + 3. ID3v2_overview + + 1. ID3v2_header + 2. ID3v2_extended_header + 3. ID3v2_frame_overview + + 1. Frame_header_flags + + 4. Default_flags + + 4. Declared_ID3v2_frames + + 1. Unique_file_identifier + 2. Text_information_frames + + 1. Text_information_frames_-_details + 2. User_defined_text_information_frame + + 3. URL_link_frames + + 1. URL_link_frames_-_details + 2. User_defined_URL_link_frame + + 4. Involved_people_list + 5. Music_CD_identifier + 6. Event_timing_codes + 7. MPEG_location_lookup_table + 8. Synchronised_tempo_codes + 9. Unsychronised_lyrics/text_transcription + 10. Synchronised_lyrics/text + 11. Comments + 12. Relative_volume_adjustment + 13. Equalisation + 14. Reverb + 15. Attached_picture + 16. General_encapsulated_object + 17. Play_counter + 18. Popularimeter + 19. Recommended_buffer_size + 20. Audio_encryption + 21. Linked_information + 22. Position_synchronisation_frame + 23. Terms_of_use_frame + 24. Ownership_frame + 25. Commercial_frame + 26. Encryption_method_registration + 27. Group_identification_registration + 28. Private_frame + + 5. The_unsynchronisation_scheme + 6. Copyright + 7. References + 8. Appendix + + 1. Appendix_A_-_Genre_List_from_ID3v1 + + 9. Author's_Address + + + +2. Conventions in this document + +In the examples, text within "" is a text string exactly as it appears in a +file. Numbers preceded with $ are hexadecimal and numbers preceded with % are +binary. $xx is used to indicate a byte with unknown content. %x is used to +indicate a bit with unknown content. The most significant bit (MSB) of a byte +is called 'bit 7' and the least significant bit (LSB) is called 'bit 0'. +A tag is the whole tag described in this document. A frame is a block of +information in the tag. The tag consists of a header, frames and optional +padding. A field is a piece of information; one value, a string etc. A numeric +string is a string that consists of the characters 0-9 only. + + +3. ID3v2 overview + +The two biggest design goals were to be able to implement ID3v2 without +disturbing old software too much and that ID3v2 should be as flexible and +expandable as possible. +The first criterion is met by the simple fact that the MPEG decoding software +uses a syncsignal, embedded in the audiostream, to 'lock on to' the audio. +Since the ID3v2 tag doesn't contain a valid syncsignal, no software will +attempt to play the tag. If, for any reason, coincidence make a syncsignal +appear within the tag it will be taken care of by the 'unsynchronisation +scheme' described in section_5. +The second criterion has made a more noticeable impact on the design of the +ID3v2 tag. It is constructed as a container for several information blocks, +called frames, whose format need not be known to the software that encounters +them. At the start of every frame there is an identifier that explains the +frames' format and content, and a size descriptor that allows software to skip +unknown frames. +If a total revision of the ID3v2 tag should be needed, there is a version +number and a size descriptor in the ID3v2 header. +The ID3 tag described in this document is mainly targeted at files encoded with +MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III and MPEG-2.5, but may +work with other types of encoded audio. +The bitorder in ID3v2 is most significant bit first (MSB). The byteorder in +multibyte numbers is most significant byte first (e.g. $12345678 would be +encoded $12 34 56 78). +It is permitted to include padding after all the final frame (at the end of the +ID3 tag), making the size of all the frames together smaller than the size +given in the head of the tag. A possible purpose of this padding is to allow +for adding a few additional frames or enlarge existing frames within the tag +without having to rewrite the entire file. The value of the padding bytes must +be $00. + +3.1. ID3v2 header + +The ID3v2 tag header, which should be the first information in the file, is 10 +bytes as follows: + + ID3v2/file identifier "ID3" + ID3v2 version $03 00 + ID3v2 flags %abc00000 + ID3v2 size 4 * %0xxxxxxx + +The first three bytes of the tag are always "ID3" to indicate that this is an +ID3v2 tag, directly followed by the two version bytes. The first byte of ID3v2 +version is it's major version, while the second byte is its revision number. In +this case this is ID3v2.3.0. All revisions are backwards compatible while major +versions are not. If software with ID3v2.2.0 and below support should encounter +version three or higher it should simply ignore the whole tag. Version and +revision will never be $FF. +The version is followed by one the ID3v2 flags field, of which currently only +three flags are used. + + + a - Unsynchronisation + Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is + used (see section_5 for details); a set bit indicates usage. + + b - Extended header + The second bit (bit 6) indicates whether or not the header is followed by + an extended header. The extended header is described in section_3.2. + + c - Experimental indicator + The third bit (bit 5) should be used as an 'experimental indicator'. This + flag should always be set when the tag is in an experimental stage. + +All the other flags should be cleared. If one of these undefined flags are set +that might mean that the tag is not readable for a parser that does not know +the flags function. +The ID3v2 tag size is encoded with four bytes where the most significant bit +(bit 7) is set to zero in every byte, making a total of 28 bits. The zeroed +bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01. +The ID3v2 tag size is the size of the complete tag after unsychronisation, +including padding, excluding the header but not excluding the extended header +(total tag size - 10). Only 28 bits (representing up to 256MB) are used in the +size description to avoid the introducuction of 'false syncsignals'. +An ID3v2 tag can be detected with the following pattern: + + $49 44 33 yy yy xx zz zz zz zz + +Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80. + +3.2. ID3v2 extended header + +The extended header contains information that is not vital to the correct +parsing of the tag information, hence the extended header is optional. + + Extended header size $xx xx xx xx + Extended Flags $xx xx + Size of padding $xx xx xx xx + +Where the 'Extended header size', currently 6 or 10 bytes, excludes itself. The +'Size of padding' is simply the total tag size excluding the frames and the +headers, in other words the padding. The extended header is considered separate +from the header proper, and as such is subject to unsynchronisation. +The extended flags are a secondary flag set which describes further attributes +of the tag. These attributes are currently defined as follows + + %x0000000 00000000 + + + + x - CRC data present + If this flag is set four bytes of CRC-32 data is appended to the extended + header. The CRC should be calculated before unsynchronisation on the data + between the extended header and the padding, i.e. the frames and only the + frames. + + Total frame CRC $xx xx xx xx + + + +3.3. ID3v2 frame overview + +As the tag consists of a tag header and a tag body with one or more frames, all +the frames consists of a frame header followed by one or more fields containing +the actual information. The layout of the frame header: + + Frame ID $xx xx xx xx (four characters) + Size $xx xx xx xx + Flags $xx xx + +The frame ID made out of the characters capital A-Z and 0-9. Identifiers +beginning with "X", "Y" and "Z" are for experimental use and free for everyone +to use, without the need to set the experimental bit in the tag header. Have in +mind that someone else might have used the same identifier as you. All other +identifiers are either used or reserved for future use. +The frame ID is followed by a size descriptor, making a total header size of +ten bytes in every frame. The size is calculated as frame size excluding frame +header (frame size - 10). +In the frame header the size descriptor is followed by two flags bytes. These +flags are described in section_3.3.1. +There is no fixed order of the frames' appearance in the tag, although it is +desired that the frames are arranged in order of significance concerning the +recognition of the file. An example of such order: UFID, TIT2, MCDI, TRCK ... +A tag must contain at least one frame. A frame must be at least 1 byte big, +excluding the header. +If nothing else is said a string is represented as ISO-8859-1 characters in the +range $20 - $FF. Such strings are represented as , or if newlines are allowed, in the frame descriptions. All Unicode strings +use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must +begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order. +All numeric strings and URLs are always encoded as ISO-8859-1. Terminated +strings are terminated with $00 if encoded with ISO-8859-1 and $00 00 if +encoded as unicode. If nothing else is said newline character is forbidden. In +ISO-8859-1 a new line is represented, when allowed, with $0A only. Frames that +allow different types of text encoding have a text encoding description byte +directly after the frame size. If ISO-8859-1 is used this byte should be $00, +if Unicode is used it should be $01. Strings dependent on encoding is +represented as , or if newlines are allowed. Any empty Unicode strings which +are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE +00 00 or $FE FF 00 00). +The three byte language field is used to describe the language of the frame's +content, according to ISO-639-2. +All URLs may be relative, e.g. "picture.png", "../doc.txt". +If a frame is longer than it should be, e.g. having more fields than specified +in this document, that indicates that additions to the frame have been made in +a later version of the ID3v2 standard. This is reflected by the revision number +in the header of the tag. + +3.3.1. Frame header flags + +In the frame header the size descriptor is followed by two flags bytes. All +unused flags must be cleared. The first byte is for 'status messages' and the +second byte is for encoding purposes. If an unknown flag is set in the first +byte the frame may not be changed without the bit cleared. If an unknown flag +is set in the second byte it is likely to not be readable. The flags field is +defined as follows. + + %abc00000 %ijk00000 + + + + a - Tag alter preservation + This flag tells the software what to do with this frame if it is unknown + and the tag is altered in any way. This applies to all kinds of + alterations, including adding more padding and reordering the frames. + + 0 Frame should be preserved. + 1 Frame should be discarded. + + + b - File alter preservation + This flag tells the software what to do with this frame if it is unknown + and the file, excluding the tag, is altered. This does not apply when the + audio is completely replaced with other audio data. + + 0 Frame should be preserved. + 1 Frame should be discarded. + + + c - Read only + This flag, if set, tells the software that the contents of this frame is + intended to be read only. Changing the contents might break something, + e.g. a signature. If the contents are changed, without knowledge in why + the frame was flagged read only and without taking the proper means to + compensate, e.g. recalculating the signature, the bit should be cleared. + + i - Compression + This flag indicates whether or not the frame is compressed. + + 0 Frame is not compressed. + 1 Frame is compressed using [#ZLIB zlib] with 4 bytes for + 'decompressed size' appended to the frame header. + + + j - Encryption + This flag indicates wether or not the frame is enrypted. If set one byte + indicating with which method it was encrypted will be appended to the + frame header. See section_4.26. for more information about encryption + method registration. + + 0 Frame is not encrypted. + 1 Frame is encrypted. + + + k - Grouping identity + This flag indicates whether or not this frame belongs in a group with + other frames. If set a group identifier byte is added to the frame + header. Every frame with the same group identifier belongs to the same + group. + + 0 Frame does not contain group information + 1 Frame contains group information + + +Some flags indicates that the frame header is extended with additional +information. This information will be added to the frame header in the same +order as the flags indicating the additions. I.e. the four bytes of +decompressed size will preceed the encryption method byte. These additions to +the frame header, while not included in the frame header size but are included +in the 'frame size' field, are not subject to encryption or compression. + +3.4. Default flags + +The default settings for the frames described in this document can be divided +into the following classes. The flags may be set differently if found more +suitable by the software. + + 1. Discarded if tag is altered, discarded if file is altered. + + o None. + + 2. Discarded if tag is altered, preserved if file is altered. + + o None. + + 3. Preserved if tag is altered, discarded if file is altered. + + o AENC, ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ + + 4. Preserved if tag is altered, preserved if file is altered. + + o The rest of the frames. + + + + +4. Declared ID3v2 frames + +The following frames are declared in this draft. + + 4.20 AENC [#sec4.20 Audio encryption] + 4.15 APIC [#sec4.15 Attached picture] + 4.11 COMM [#sec4.11 Comments] + 4.25 COMR [#sec4.25 Commercial frame] + 4.26 ENCR [#sec4.26 Encryption method registration] + 4.13 EQUA [#sec4.13 Equalization] + 4.6 ETCO [#sec4.6 Event timing codes] + 4.16 GEOB [#sec4.16 General encapsulated object] + 4.27 GRID [#sec4.27 Group identification registration] + 4.4 IPLS [#sec4.4 Involved people list] + 4.21 LINK [#sec4.21 Linked information] + 4.5 MCDI [#sec4.5 Music CD identifier] + 4.7 MLLT [#sec4.7 MPEG location lookup table] + 4.24 OWNE [#sec4.24 Ownership frame] + 4.28 PRIV [#sec4.28 Private frame] + 4.17 PCNT [#sec4.17 Play counter] + 4.18 POPM [#sec4.18 Popularimeter] + 4.22 POSS [#sec4.22 Position synchronisation frame] + 4.19 RBUF [#sec4.19 Recommended buffer size] + 4.12 RVAD [#sec4.12 Relative volume adjustment] + 4.14 RVRB [#sec4.14 Reverb] + 4.10 SYLT [#sec4.10 Synchronized lyric/text] + 4.8 SYTC [#sec4.8 Synchronized tempo codes] + 4.2.1 TALB [#TALB Album/Movie/Show title] + 4.2.1 TBPM [#TBPM BPM (beats per minute)] + 4.2.1 TCOM [#TCOM Composer] + 4.2.1 TCON [#TCON Content type] + 4.2.1 TCOP [#TCOP Copyright message] + 4.2.1 TDAT [#TDAT Date] + 4.2.1 TDLY [#TDLY Playlist delay] + 4.2.1 TENC [#TENC Encoded by] + 4.2.1 TEXT [#TEXT Lyricist/Text writer] + 4.2.1 TFLT [#TFLT File type] + 4.2.1 TIME [#TIME Time] + 4.2.1 TIT1 [#TIT1 Content group description] + 4.2.1 TIT2 [#TIT2 Title/songname/content description] + 4.2.1 TIT3 [#TIT3 Subtitle/Description refinement] + 4.2.1 TKEY [#TKEY Initial key] + 4.2.1 TLAN [#TLAN Language(s)] + 4.2.1 TLEN [#TLEN Length] + 4.2.1 TMED [#TMED Media type] + 4.2.1 TOAL [#TOAL Original album/movie/show title] + 4.2.1 TOFN [#TOFN Original filename] + 4.2.1 TOLY [#TOLY Original lyricist(s)/text writer(s)] + 4.2.1 TOPE [#TOPE Original artist(s)/performer(s)] + 4.2.1 TORY [#TORY Original release year] + 4.2.1 TOWN [#TOWN File owner/licensee] + 4.2.1 TPE1 [#TPE1 Lead performer(s)/Soloist(s)] + 4.2.1 TPE2 [#TPE2 Band/orchestra/accompaniment] + 4.2.1 TPE3 [#TPE3 Conductor/performer refinement] + 4.2.1 TPE4 [#TPE4 Interpreted, remixed, or otherwise modified by] + 4.2.1 TPOS [#TPOS Part of a set] + 4.2.1 TPUB [#TPUB Publisher] + 4.2.1 TRCK [#TRCK Track number/Position in set] + 4.2.1 TRDA [#TRDA Recording dates] + 4.2.1 TRSN [#TRSN Internet radio station name] + 4.2.1 TRSO [#TRSO Internet radio station owner] + 4.2.1 TSIZ [#TSIZ Size] + 4.2.1 TSRC [#TSRC ISRC (international standard recording code)] + 4.2.1 TSSE [#TSEE Software/Hardware and settings used for encoding] + 4.2.1 TYER [#TYER Year] + 4.2.2 TXXX [#TXXX User defined text information frame] + 4.1 UFID [#sec4.1 Unique file identifier] + 4.23 USER [#sec4.23 Terms of use] + 4.9 USLT [#sec4.9 Unsychronized lyric/text transcription] + 4.3.1 WCOM [#WCOM Commercial information] + 4.3.1 WCOP [#WCOP Copyright/Legal information] + 4.3.1 WOAF [#WOAF Official audio file webpage] + 4.3.1 WOAR [#WOAR Official artist/performer webpage] + 4.3.1 WOAS [#WOAS Official audio source webpage] + 4.3.1 WORS [#WORS Official internet radio station homepage] + 4.3.1 WPAY [#WPAY Payment] + 4.3.1 WPUB [#WPUB Publishers official webpage] + 4.3.2 WXXX [#WXXX User defined URL link frame] + + +4.1. Unique file identifier + +This frame's purpose is to be able to identify the audio file in a database +that may contain more information relevant to the content. Since +standardisation of such a database is beyond this document, all frames begin +with a null-terminated string with a URL containing an email address, or a link +to a location where an email address can be found, that belongs to the +organisation responsible for this specific database implementation. Questions +regarding the database should be sent to the indicated email address. The URL +should not be used for the actual database queries. The string "http:// +www.id3.org/dummy/ufid.html" should be used for tests. Software that isn't told +otherwise may safely remove such frames. The 'Owner identifier' must be non- +empty (more than just a termination). The 'Owner identifier' is then followed +by the actual identifier, which may be up to 64 bytes. There may be more than +one "UFID" frame in a tag, but only one with the same 'Owner identifier'. + +
+ Owner identifier $00 + Identifier + + +4.2. Text information frames + +The text information frames are the most important frames, containing +information like artist, album and more. There may only be one text information +frame of its kind in an tag. If the textstring is followed by a termination +($00 (00)) all the following information should be ignored and not be +displayed. All text frame identifiers begin with "T". Only text frame +identifiers begin with "T", with the exception of the "TXXX" frame. All the +text information frames have the following format: + +
+ Text encoding $xx + Information + + +4.2.1. Text information frames - details + + + + TALB + The 'Album/Movie/Show title' frame is intended for the title of the + recording(/source of sound) which the audio in the file is taken from. + + + + TBPM + The 'BPM' frame contains the number of beats per minute in the mainpart + of the audio. The BPM is an integer and represented as a numerical + string. + + + + TCOM + The 'Composer(s)' frame is intended for the name of the composer(s). They + are seperated with the "/" character. + + + + TCON + The 'Content type', which previously was stored as a one byte numeric + value only, is now a numeric string. You may use one or several of the + types as ID3v1.1 did or, since the category list would be impossible to + maintain with accurate and up to date categories, define your own. + + References to the ID3v1 genres can be made by, as first byte, enter "(" + followed by a number from the genres list (appendix A) and ended with a + ")" character. This is optionally followed by a refinement, e.g. "(21)" + or "(4)Eurodisco". Several references can be made in the same frame, e.g. + "(51)(39)". If the refinement should begin with a "(" character it should + be replaced with "((", e.g. "((I can figure out any genre)" or "(55)((I + think...)". The following new content types is defined in ID3v2 and is + implemented in the same way as the numerig content types, e.g. "(RX)". + + RX Remix + CR Cover + + + + + TCOP + The 'Copyright message' frame, which must begin with a year and a space + character (making five characters), is intended for the copyright holder + of the original sound, not the audio file itself. The absence of this + frame means only that the copyright information is unavailable or has + been removed, and must not be interpreted to mean that the sound is + public domain. Every time this field is displayed the field must be + preceded with "Copyright © ". + + + + TDAT + The 'Date' frame is a numeric string in the DDMM format containing the + date for the recording. This field is always four characters long. + + + + TDLY + The 'Playlist delay' defines the numbers of milliseconds of silence + between every song in a playlist. The player should use the "ETC" frame, + if present, to skip initial silence and silence at the end of the audio + to match the 'Playlist delay' time. The time is represented as a numeric + string. + + + + TENC + The 'Encoded by' frame contains the name of the person or organisation + that encoded the audio file. This field may contain a copyright message, + if the audio file also is copyrighted by the encoder. + + + + TEXT + The 'Lyricist(s)/Text writer(s)' frame is intended for the writer(s) of + the text or lyrics in the recording. They are seperated with the "/ + " character. + + + + TFLT + The 'File type' frame indicates which type of audio this tag defines. The + following type and refinements are defined: + + MPG MPEG Audio + /1 MPEG 1/2 layer I + /2 MPEG 1/2 layer II + /3 MPEG 1/2 layer III + /2.5 MPEG 2.5 + /AAC Advanced audio compression + VQF Transform-domain Weighted Interleave Vector Quantization + PCM Pulse Code Modulated audio + + +but other types may be used, not for these types though. This is used in a +similar way to the predefined types in the "TMED" frame, but without +parentheses. If this frame is not present audio type is assumed to be "MPG". + + + TIME + The 'Time' frame is a numeric string in the HHMM format containing the + time for the recording. This field is always four characters long. + + + + TIT1 + The 'Content group description' frame is used if the sound belongs to a + larger category of sounds/music. For example, classical music is often + sorted in different musical sections (e.g. "Piano Concerto", "Weather - + Hurricane"). + + + + TIT2 + The 'Title/Songname/Content description' frame is the actual name of the + piece (e.g. "Adagio", "Hurricane Donna"). + + + + TIT3 + The 'Subtitle/Description refinement' frame is used for information + directly related to the contents title (e.g. "Op. 16" or "Performed live + at Wembley"). + + + + TKEY + The 'Initial key' frame contains the musical key in which the sound + starts. It is represented as a string with a maximum length of three + characters. The ground keys are represented with "A","B","C","D","E", "F" + and "G" and halfkeys represented with "b" and "#". Minor is represented + as "m". Example "Cbm". Off key is represented with an "o" only. + + + + TLAN + The 'Language(s)' frame should contain the languages of the text or + lyrics spoken or sung in the audio. The language is represented with + three characters according to ISO-639-2. If more than one language is + used in the text their language codes should follow according to their + usage. + + + + TLEN + The 'Length' frame contains the length of the audiofile in milliseconds, + represented as a numeric string. + + + + TMED + The 'Media type' frame describes from which media the sound originated. + This may be a text string or a reference to the predefined media types + found in the list below. References are made within "(" and ")" and are + optionally followed by a text refinement, e.g. "(MC) with four channels". + If a text refinement should begin with a "(" character it should be + replaced with "((" in the same way as in the "TCO" frame. Predefined + refinements is appended after the media type, e.g. "(CD/A)" or "(VID/PAL/ + VHS)". + + DIG Other digital media + /A Analog transfer from media + + ANA Other analog media + /WAC Wax cylinder + /8CA 8-track tape cassette + + CD CD + /A Analog transfer from media + /DD DDD + /AD ADD + /AA AAD + + LD Laserdisc + /A Analog transfer from media + + TT Turntable records + /33 33.33 rpm + /45 45 rpm + /71 71.29 rpm + /76 76.59 rpm + /78 78.26 rpm + /80 80 rpm + + MD MiniDisc + /A Analog transfer from media + + DAT DAT + /A Analog transfer from media + /1 standard, 48 kHz/16 bits, linear + /2 mode 2, 32 kHz/16 bits, linear + /3 mode 3, 32 kHz/12 bits, nonlinear, low speed + /4 mode 4, 32 kHz/12 bits, 4 channels + /5 mode 5, 44.1 kHz/16 bits, linear + /6 mode 6, 44.1 kHz/16 bits, 'wide track' play + + DCC DCC + /A Analog transfer from media + + DVD DVD + /A Analog transfer from media + + TV Television + /PAL PAL + /NTSC NTSC + /SECAM SECAM + + VID Video + /PAL PAL + /NTSC NTSC + /SECAM SECAM + /VHS VHS + /SVHS S-VHS + /BETA BETAMAX + + RAD Radio + /FM FM + /AM AM + /LW LW + /MW MW + + TEL Telephone + /I ISDN + + MC MC (normal cassette) + /4 4.75 cm/s (normal speed for a two sided cassette) + /9 9.5 cm/s + /I Type I cassette (ferric/normal) + /II Type II cassette (chrome) + /III Type III cassette (ferric chrome) + /IV Type IV cassette (metal) + + REE Reel + /9 9.5 cm/s + /19 19 cm/s + /38 38 cm/s + /76 76 cm/s + /I Type I cassette (ferric/normal) + /II Type II cassette (chrome) + /III Type III cassette (ferric chrome) + /IV Type IV cassette (metal) + + + + + TOAL + The 'Original album/movie/show title' frame is intended for the title of + the original recording (or source of sound), if for example the music in + the file should be a cover of a previously released song. + + + + TOFN + The 'Original filename' frame contains the preferred filename for the + file, since some media doesn't allow the desired length of the filename. + The filename is case sensitive and includes its suffix. + + + + TOLY + The 'Original lyricist(s)/text writer(s)' frame is intended for the text + writer(s) of the original recording, if for example the music in the file + should be a cover of a previously released song. The text writers are + seperated with the "/" character. + + + + TOPE + The 'Original artist(s)/performer(s)' frame is intended for the performer + (s) of the original recording, if for example the music in the file + should be a cover of a previously released song. The performers are + seperated with the "/" character. + + + + TORY + The 'Original release year' frame is intended for the year when the + original recording, if for example the music in the file should be a + cover of a previously released song, was released. The field is formatted + as in the "TYER" frame. + + + + TOWN + The 'File owner/licensee' frame contains the name of the owner or + licensee of the file and it's contents. + + + + TPE1 + The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is + used for the main artist(s). They are seperated with the "/" character. + + + + TPE2 + The 'Band/Orchestra/Accompaniment' frame is used for additional + information about the performers in the recording. + + + + TPE3 + The 'Conductor' frame is used for the name of the conductor. + + + + TPE4 + The 'Interpreted, remixed, or otherwise modified by' frame contains more + information about the people behind a remix and similar interpretations + of another existing piece. + + + + TPOS + The 'Part of a set' frame is a numeric string that describes which part + of a set the audio came from. This frame is used if the source described + in the "TALB" frame is divided into several mediums, e.g. a double CD. + The value may be extended with a "/" character and a numeric string + containing the total number of parts in the set. E.g. "1/2". + + + + TPUB + The 'Publisher' frame simply contains the name of the label or publisher. + + + + TRCK + The 'Track number/Position in set' frame is a numeric string containing + the order number of the audio-file on its original recording. This may be + extended with a "/" character and a numeric string containing the total + numer of tracks/elements on the original recording. E.g. "4/9". + + + + TRDA + The 'Recording dates' frame is a intended to be used as complement to the + "TYER", "TDAT" and "TIME" frames. E.g. "4th-7th June, 12th June" in + combination with the "TYER" frame. + + + + TRSN + The 'Internet radio station name' frame contains the name of the internet + radio station from which the audio is streamed. + + + + TRSO + The 'Internet radio station owner' frame contains the name of the owner + of the internet radio station from which the audio is streamed. + + + + TSIZ + The 'Size' frame contains the size of the audiofile in bytes, excluding + the ID3v2 tag, represented as a numeric string. + + + + TSRC + The 'ISRC' frame should contain the International Standard Recording Code + (ISRC) (12 characters). + + + + TSSE + The 'Software/Hardware and settings used for encoding' frame includes the + used audio encoder and its settings when the file was encoded. Hardware + refers to hardware encoders, not the computer on which a program was run. + + + + TYER + The 'Year' frame is a numeric string with a year of the recording. This + frames is always four characters long (until the year 10000). + + +4.2.2. User defined text information frame + +This frame is intended for one-string text information concerning the audiofile +in a similar way to the other "T"-frames. The frame body consists of a +description of the string, represented as a terminated string, followed by the +actual string. There may be more than one "TXXX" frame in each tag, but only +one with the same description. + +
+ Text encoding $xx + Description $00 (00) + Value + + +4.3. URL link frames + +With these frames dynamic data such as webpages with touring information, price +information or plain ordinary news can be added to the tag. There may only be +one URL link frame of its kind in an tag, except when stated otherwise in the +frame description. If the textstring is followed by a termination ($00 (00)) +all the following information should be ignored and not be displayed. All URL +link frame identifiers begins with "W". Only URL link frame identifiers begins +with "W". All URL link frames have the following format: + +
+ URL + + +4.3.1. URL link frames - details + + + + WCOM + The 'Commercial information' frame is a URL pointing at a webpage with + information such as where the album can be bought. There may be more than + one "WCOM" frame in a tag, but not with the same content. + + + + WCOP + The 'Copyright/Legal information' frame is a URL pointing at a webpage + where the terms of use and ownership of the file is described. + + + + WOAF + The 'Official audio file webpage' frame is a URL pointing at a file + specific webpage. + + + + WOAR + The 'Official artist/performer webpage' frame is a URL pointing at the + artists official webpage. There may be more than one "WOAR" frame in a + tag if the audio contains more than one performer, but not with the same + content. + + + + WOAS + The 'Official audio source webpage' frame is a URL pointing at the + official webpage for the source of the audio file, e.g. a movie. + + + + WORS + The 'Official internet radio station homepage' contains a URL pointing at + the homepage of the internet radio station. + + + + WPAY + The 'Payment' frame is a URL pointing at a webpage that will handle the + process of paying for this file. + + + + WPUB + The 'Publishers official webpage' frame is a URL pointing at the official + wepage for the publisher. + + +4.3.2. User defined URL link frame + +This frame is intended for URL links concerning the audiofile in a similar way +to the other "W"-frames. The frame body consists of a description of the +string, represented as a terminated string, followed by the actual URL. The URL +is always encoded with ISO-8859-1. There may be more than one "WXXX" frame in +each tag, but only one with the same description. + +
+ Text encoding $xx + Description $00 (00) + URL + + +4.4. Involved people list + +Since there might be a lot of people contributing to an audio file in various +ways, such as musicians and technicians, the 'Text information frames' are +often insufficient to list everyone involved in a project. The 'Involved people +list' is a frame containing the names of those involved, and how they were +involved. The body simply contains a terminated string with the involvement +directly followed by a terminated string with the involvee followed by a new +involvement and so on. There may only be one "IPLS" frame in each tag. + +
+ Text encoding $xx + People list strings + + +4.5. Music CD identifier + +This frame is intended for music that comes from a CD, so that the CD can be +identified in databases such as the CDDB. The frame consists of a binary dump +of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and +then 8 bytes/track on the CD plus 8 bytes for the 'lead out' making a maximum +of 804 bytes. The offset to the beginning of every track on the CD should be +described with a four bytes absolute CD-frame address per track, and not with +absolute time. This frame requires a present and valid "TRCK" frame, even if +the CD's only got one track. There may only be one "MCDI" frame in each tag. + +
+ CD TOC + + +4.6. Event timing codes + +This frame allows synchronisation with key events in a song or sound. The +header is: + +
+ Time stamp format $xx + +Where time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + +Abolute time means that every stamp contains the time from the beginning of the +file. +Followed by a list of key events in the following format: + + Type of event $xx + Time stamp $xx (xx ...) + +The 'Time stamp' is set to zero if directly at the beginning of the sound or +after the previous event. All events should be sorted in chronological order. +The type of event is as follows: + + $00 padding (has no meaning) + $01 end of initial silence + $02 intro start + $03 mainpart start + $04 outro start + $05 outro end + $06 verse start + $07 refrain start + $08 interlude start + $09 theme start + $0A variation start + $0B key change + $0C time change + $0D momentary unwanted noise (Snap, Crackle & Pop) + $0E sustained noise + $0F sustained noise end + $10 intro end + $11 mainpart end + $12 verse end + $13 refrain end + $14 theme end + $15-$DF reserved for future use + $E0-$EF not predefined sync 0-F + $F0-$FC reserved for future use + $FD audio end (start of silence) + $FE audio file ends + $FF one more byte of events follows (all the following bytes with the + value $FF have the same function) + +Terminating the start events such as "intro start" is not required. The 'Not +predefined sync's ($E0-EF) are for user events. You might want to synchronise +your music to something, like setting of an explosion on-stage, turning on your +screensaver etc. +There may only be one "ETCO" frame in each tag. + +4.7. MPEG location lookup table + +To increase performance and accuracy of jumps within a MPEG audio file, frames +with timecodes in different locations in the file might be useful. The ID3v2 +frame includes references that the software can use to calculate positions in +the file. After the frame header is a descriptor of how much the 'frame +counter' should increase for every reference. If this value is two then the +first reference points out the second frame, the 2nd reference the 4th frame, +the 3rd reference the 6th frame etc. In a similar way the 'bytes between +reference' and 'milliseconds between reference' points out bytes and +milliseconds respectively. +Each reference consists of two parts; a certain number of bits, as defined in +'bits for bytes deviation', that describes the difference between what is said +in 'bytes between reference' and the reality and a certain number of bits, as +defined in 'bits for milliseconds deviation', that describes the difference +between what is said in 'milliseconds between reference' and the reality. The +number of bits in every reference, i.e. 'bits for bytes deviation'+'bits for +milliseconds deviation', must be a multiple of four. There may only be one +"MLLT" frame in each tag. + +
+ MPEG frames between reference $xx xx + Bytes between reference $xx xx xx + Milliseconds between reference $xx xx xx + Bits for bytes deviation $xx + Bits for milliseconds dev. $xx + +Then for every reference the following data is included; + + Deviation in bytes %xxx.... + Deviation in milliseconds %xxx.... + + +4.8. Synchronised tempo codes + +For a more accurate description of the tempo of a musical piece this frame +might be used. After the header follows one byte describing which time stamp +format should be used. Then follows one or more tempo codes. Each tempo code +consists of one tempo part and one time part. The tempo is in BPM described +with one or two bytes. If the first byte has the value $FF, one more byte +follows, which is added to the first giving a range from 2 - 510 BPM, since $00 +and $01 is reserved. $00 is used to describe a beat-free time period, which is +not the same as a music-free time period. $01 is used to indicate one single +beat-stroke followed by a beat-free period. +The tempo descriptor is followed by a time stamp. Every time the tempo in the +music changes, a tempo descriptor may indicate this for the player. All tempo +descriptors should be sorted in chronological order. The first beat-stroke in a +time-period is at the same time as the beat description occurs. There may only +be one "SYTC" frame in each tag. + +
+ Time stamp format $xx + Tempo data + +Where time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + +Abolute time means that every stamp contains the time from the beginning of the +file. + +4.9. Unsychronised lyrics/text transcription + +This frame contains the lyrics of the song or a text transcription of other +vocal activities. The head includes an encoding descriptor and a content +descriptor. The body consists of the actual text. The 'Content descriptor' is a +terminated string. If no descriptor is entered, 'Content descriptor' is $00 +(00) only. Newline characters are allowed in the text. There may be more than +one 'Unsynchronised lyrics/text transcription' frame in each tag, but only one +with the same language and content descriptor. + +
+ Text encoding $xx + Language $xx xx xx + Content descriptor $00 (00) + Lyrics/text + + +4.10. Synchronised lyrics/text + +This is another way of incorporating the words, said or sung lyrics, in the +audio file as text, this time, however, in sync with the audio. It might also +be used to describing events e.g. occurring on a stage or on the screen in sync +with the audio. The header includes a content descriptor, represented with as +terminated textstring. If no descriptor is entered, 'Content descriptor' is $00 +(00) only. + +
+ Text encoding $xx + Language $xx xx xx + Time stamp format $xx + Content type $xx + Content descriptor $00 (00) + +Encoding: + + $00 ISO-8859-1 character set is used => $00 is sync identifier. + $01 Unicode character set is used => $00 00 is sync identifier. + +Content type: + + $00 is other + $01 is lyrics + $02 is text transcription + $03 is movement/part name (e.g. "Adagio") + $04 is events (e.g. "Don Quijote enters the stage") + $05 is chord (e.g. "Bb F Fsus") + $06 is trivia/'pop up' information + +Time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + +Abolute time means that every stamp contains the time from the beginning of the +file. +The text that follows the frame header differs from that of the unsynchronised +lyrics/text transcription in one major way. Each syllable (or whatever size of +text is considered to be convenient by the encoder) is a null terminated string +followed by a time stamp denoting where in the sound file it belongs. Each sync +thus has the following structure: + + Terminated text to be synced (typically a syllable) + Sync identifier (terminator to above string) $00 (00) + Time stamp $xx (xx ...) + +The 'time stamp' is set to zero or the whole sync is omitted if located +directly at the beginning of the sound. All time stamps should be sorted in +chronological order. The sync can be considered as a validator of the +subsequent string. +Newline ($0A) characters are allowed in all "SYLT" frames and should be used +after every entry (name, event etc.) in a frame with the content type $03 - +$04. +A few considerations regarding whitespace characters: Whitespace separating +words should mark the beginning of a new word, thus occurring in front of the +first syllable of a new word. This is also valid for new line characters. A +syllable followed by a comma should not be broken apart with a sync (both the +syllable and the comma should be before the sync). +An example: The "USLT" passage + + "Strangers in the night" $0A "Exchanging glances" + +would be "SYLT" encoded as: + + "Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 + xx xx " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx + "ing" $00 xx xx "glan" $00 xx xx "ces" $00 xx xx + +There may be more than one "SYLT" frame in each tag, but only one with the same +language and content descriptor. + +4.11. Comments + +This frame is indended for any kind of full text information that does not fit +in any other frame. It consists of a frame header followed by encoding, +language and content descriptors and is ended with the actual comment as a text +string. Newline characters are allowed in the comment text string. There may be +more than one comment frame in each tag, but only one with the same language +and content descriptor. + +
+ Text encoding $xx + Language $xx xx xx + Short content descrip. $00 (00) + The actual text + + +4.12. Relative volume adjustment + +This is a more subjective function than the previous ones. It allows the user +to say how much he wants to increase/decrease the volume on each channel while +the file is played. The purpose is to be able to align all files to a reference +volume, so that you don't have to change the volume constantly. This frame may +also be used to balance adjust the audio. If the volume peak levels are known +then this could be described with the 'Peak volume right' and 'Peak volume +left' field. If Peakvolume is not known these fields could be left zeroed or, +if no other data follows, be completely omitted. There may only be one "RVAD" +frame in each tag. + +
+ Increment/decrement %00xxxxxx + Bits used for volume descr. $xx + Relative volume change, right $xx xx (xx ...) + Relative volume change, left $xx xx (xx ...) + Peak volume right $xx xx (xx ...) + Peak volume left $xx xx (xx ...) + +In the increment/decrement field bit 0 is used to indicate the right channel +and bit 1 is used to indicate the left channel. 1 is increment and 0 is +decrement. +The 'bits used for volume description' field is normally $10 (16 bits) for MPEG +2 layer I, II and III and MPEG 2.5. This value may not be $00. The volume is +always represented with whole bytes, padded in the beginning (highest bits) +when 'bits used for volume description' is not a multiple of eight. +This datablock is then optionally followed by a volume definition for the left +and right back channels. If this information is appended to the frame the first +two channels will be treated as front channels. In the increment/decrement +field bit 2 is used to indicate the right back channel and bit 3 for the left +back channel. + + Relative volume change, right back $xx xx (xx ...) + Relative volume change, left back $xx xx (xx ...) + Peak volume right back $xx xx (xx ...) + Peak volume left back $xx xx (xx ...) + +If the center channel adjustment is present the following is appended to the +existing frame, after the left and right back channels. The center channel is +represented by bit 4 in the increase/decrease field. + + Relative volume change, center $xx xx (xx ...) + Peak volume center $xx xx (xx ...) + +If the bass channel adjustment is present the following is appended to the +existing frame, after the center channel. The bass channel is represented by +bit 5 in the increase/decrease field. + + Relative volume change, bass $xx xx (xx ...) + Peak volume bass $xx xx (xx ...) + + +4.13. Equalisation + +This is another subjective, alignment frame. It allows the user to predefine an +equalisation curve within the audio file. There may only be one "EQUA" frame in +each tag. + +
+ Adjustment bits $xx + +The 'adjustment bits' field defines the number of bits used for representation +of the adjustment. This is normally $10 (16 bits) for MPEG 2 layer I, II and +III and MPEG 2.5. This value may not be $00. +This is followed by 2 bytes + ('adjustment bits' rounded up to the nearest +byte) for every equalisation band in the following format, giving a frequency +range of 0 - 32767Hz: + + Increment/decrement %x (MSB of the Frequency) + Frequency (lower 15 bits) + Adjustment $xx (xx ...) + +The increment/decrement bit is 1 for increment and 0 for decrement. The +equalisation bands should be ordered increasingly with reference to frequency. +All frequencies don't have to be declared. The equalisation curve in the +reading software should be interpolated between the values in this frame. Three +equal adjustments for three subsequent frequencies. A frequency should only be +described once in the frame. + +4.14. Reverb + +Yet another subjective one. You may here adjust echoes of different kinds. +Reverb left/right is the delay between every bounce in ms. Reverb bounces left/ +right is the number of bounces that should be made. $FF equals an infinite +number of bounces. Feedback is the amount of volume that should be returned to +the next echo bounce. $00 is 0%, $FF is 100%. If this value were $7F, there +would be 50% volume reduction on the first bounce, 50% of that on the second +and so on. Left to left means the sound from the left bounce to be played in +the left speaker, while left to right means sound from the left bounce to be +played in the right speaker. +'Premix left to right' is the amount of left sound to be mixed in the right +before any reverb is applied, where $00 id 0% and $FF is 100%. 'Premix right to +left' does the same thing, but right to left. Setting both premix to $FF would +result in a mono output (if the reverb is applied symmetric). There may only be +one "RVRB" frame in each tag. + +
+ Reverb left (ms) $xx xx + Reverb right (ms) $xx xx + Reverb bounces, left $xx + Reverb bounces, right $xx + Reverb feedback, left to left $xx + Reverb feedback, left to right $xx + Reverb feedback, right to right $xx + Reverb feedback, right to left $xx + Premix left to right $xx + Premix right to left $xx + + +4.15. Attached picture + +This frame contains a picture directly related to the audio file. Image format +is the MIME type and subtype for the image. In the event that the MIME media +type name is omitted, "image/" will be implied. The "image/png" or "image/jpeg" +picture format should be used when interoperability is wanted. Description is a +short description of the picture, represented as a terminated textstring. The +description has a maximum length of 64 characters, but may be empty. There may +be several pictures attached to one file, each in their individual "APIC" +frame, but only one with the same content descriptor. There may only be one +picture with the picture type declared as picture type $01 and $02 +respectively. There is the possibility to put only a link to the image file by +using the 'MIME type' "-->" and having a complete URL instead of picture data. +The use of linked files should however be used sparingly since there is the +risk of separation of files. + +
+ Text encoding $xx + MIME type $00 + Picture type $xx + Description $00 (00) + Picture data + +Picture type: + + $00 Other + $01 32x32 pixels 'file icon' (PNG only) + $02 Other file icon + $03 Cover (front) + $04 Cover (back) + $05 Leaflet page + $06 Media (e.g. lable side of CD) + $07 Lead artist/lead performer/soloist + $08 Artist/performer + $09 Conductor + $0A Band/Orchestra + $0B Composer + $0C Lyricist/text writer + $0D Recording Location + $0E During recording + $0F During performance + $10 Movie/video screen capture + $11 A bright coloured fish + $12 Illustration + $13 Band/artist logotype + $14 Publisher/Studio logotype + + +4.16. General encapsulated object + +In this frame any type of file can be encapsulated. After the header, 'Frame +size' and 'Encoding' follows 'MIME type' represented as as a terminated string +encoded with ISO-8859-1. The filename is case sensitive and is encoded as +'Encoding'. Then follows a content description as terminated string, encoded as +'Encoding'. The last thing in the frame is the actual object. The first two +strings may be omitted, leaving only their terminations. There may be more than +one "GEOB" frame in each tag, but only one with the same content descriptor. + +
+ Text encoding $xx + MIME type $00 + Filename $00 (00) + Content description $00 (00) + Encapsulated object + + +4.17. Play counter + +This is simply a counter of the number of times a file has been played. The +value is increased by one every time the file begins to play. There may only be +one "PCNT" frame in each tag. When the counter reaches all one's, one byte is +inserted in front of the counter thus making the counter eight bits bigger. The +counter must be at least 32-bits long to begin with. + +
+ Counter $xx xx xx xx (xx ...) + + +4.18. Popularimeter + +The purpose of this frame is to specify how good an audio file is. Many +interesting applications could be found to this frame such as a playlist that +features better audiofiles more often than others or it could be used to +profile a person's taste and find other 'good' files by comparing people's +profiles. The frame is very simple. It contains the email address to the user, +one rating byte and a four byte play counter, intended to be increased with one +for every time the file is played. The email is a terminated string. The rating +is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no personal counter +is wanted it may be omitted. When the counter reaches all one's, one byte is +inserted in front of the counter thus making the counter eight bits bigger in +the same away as the play counter ("PCNT"). There may be more than one "POPM" +frame in each tag, but only one with the same email address. + +
+ Email to user $00 + Rating $xx + Counter $xx xx xx xx (xx ...) + + +4.19. Recommended buffer size + +Sometimes the server from which a audio file is streamed is aware of +transmission or coding problems resulting in interruptions in the audio stream. +In these cases, the size of the buffer can be recommended by the server using +this frame. If the 'embedded info flag' is true (1) then this indicates that an +ID3 tag with the maximum size described in 'Buffer size' may occur in the +audiostream. In such case the tag should reside between two MPEG frames, if the +audio is MPEG encoded. If the position of the next tag is known, 'offset to +next tag' may be used. The offset is calculated from the end of tag in which +this frame resides to the first byte of the header in the next. This field may +be omitted. Embedded tags are generally not recommended since this could render +unpredictable behaviour from present software/hardware. +For applications like streaming audio it might be an idea to embed tags into +the audio stream though. If the clients connects to individual connections like +HTTP and there is a possibility to begin every transmission with a tag, then +this tag should include a 'recommended buffer size' frame. If the client is +connected to a arbitrary point in the stream, such as radio or multicast, then +the 'recommended buffer size' frame should be included in every tag. Every tag +that is picked up after the initial/first tag is to be considered as an update +of the previous one. E.g. if there is a "TIT2" frame in the first received tag +and one in the second tag, then the first should be 'replaced' with the second. +The 'Buffer size' should be kept to a minimum. There may only be one "RBUF" +frame in each tag. + +
+ Buffer size $xx xx xx + Embedded info flag %0000000x + Offset to next tag $xx xx xx xx + + +4.20. Audio encryption + +This frame indicates if the actual audio stream is encrypted, and by whom. +Since standardisation of such encrypion scheme is beyond this document, all +"AENC" frames begin with a terminated string with a URL containing an email +address, or a link to a location where an email address can be found, that +belongs to the organisation responsible for this specific encrypted audio file. +Questions regarding the encrypted audio should be sent to the email address +specified. If a $00 is found directly after the 'Frame size' and the audiofile +indeed is encrypted, the whole file may be considered useless. +After the 'Owner identifier', a pointer to an unencrypted part of the audio can +be specified. The 'Preview start' and 'Preview length' is described in frames. +If no part is unencrypted, these fields should be left zeroed. After the +'preview length' field follows optionally a datablock required for decryption +of the audio. There may be more than one "AENC" frames in a tag, but only one +with the same 'Owner identifier'. + +
+ Owner identifier $00 + Preview start $xx xx + Preview length $xx xx + Encryption info + + +4.21. Linked information + +To keep space waste as low as possible this frame may be used to link +information from another ID3v2 tag that might reside in another audio file or +alone in a binary file. It is recommended that this method is only used when +the files are stored on a CD-ROM or other circumstances when the risk of file +seperation is low. The frame contains a frame identifier, which is the frame +that should be linked into this tag, a URL field, where a reference to the file +where the frame is given, and additional ID data, if needed. Data should be +retrieved from the first tag found in the file to which this link points. There +may be more than one "LINK" frame in a tag, but only one with the same +contents. A linked frame is to be considered as part of the tag and has the +same restrictions as if it was a physical part of the tag (i.e. only one "RVRB" +frame allowed, whether it's linked or not). + +
+ Frame identifier $xx xx xx + URL $00 + ID and additional data + +Frames that may be linked and need no additional data are "IPLS", "MCID", +"ETCO", "MLLT", "SYTC", "RVAD", "EQUA", "RVRB", "RBUF", the text information +frames and the URL link frames. +The "TXXX", "APIC", "GEOB" and "AENC" frames may be linked with the content +descriptor as additional ID data. +The "COMM", "SYLT" and "USLT" frames may be linked with three bytes of language +descriptor directly followed by a content descriptor as additional ID data. + +4.22. Position synchronisation frame + +This frame delivers information to the listener of how far into the audio +stream he picked up; in effect, it states the time offset of the first frame in +the stream. The frame layout is: + + + Time stamp format $xx + Position $xx (xx ...) + +Where time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + +and position is where in the audio the listener starts to receive, i.e. the +beginning of the next frame. If this frame is used in the beginning of a file +the value is always 0. There may only be one "POSS" frame in each tag. + +4.23. Terms of use frame + +This frame contains a brief description of the terms of use and ownership of +the file. More detailed information concerning the legal terms might be +available through the "WCOP" frame. Newlines are allowed in the text. There may +only be one "USER" frame in a tag. + +
+ Text encoding $xx + Language $xx xx xx + The actual text + + +4.24. Ownership frame + +The ownership frame might be used as a reminder of a made transaction or, if +signed, as proof. Note that the "USER" and "TOWN" frames are good to use in +conjunction with this one. The frame begins, after the frame ID, size and +encoding fields, with a 'price payed' field. The first three characters of this +field contains the currency used for the transaction, encoded according to ISO- +4217 alphabetic currency code. Concatenated to this is the actual price payed, +as a numerical string using "." as the decimal separator. Next is an 8 +character date string (YYYYMMDD) followed by a string with the name of the +seller as the last field in the frame. There may only be one "OWNE" frame in a +tag. + +
+ Text encoding $xx + Price payed $00 + Date of purch. + Seller + + +4.25. Commercial frame + +This frame enables several competing offers in the same tag by bundling all +needed information. That makes this frame rather complex but it's an easier +solution than if one tries to achieve the same result with several frames. The +frame begins, after the frame ID, size and encoding fields, with a price string +field. A price is constructed by one three character currency code, encoded +according to ISO-4217 alphabetic currency code, followed by a numerical value +where "." is used as decimal seperator. In the price string several prices may +be concatenated, seperated by a "/" character, but there may only be one +currency of each type. +The price string is followed by an 8 character date string in the format +YYYYMMDD, describing for how long the price is valid. After that is a contact +URL, with which the user can contact the seller, followed by a one byte +'received as' field. It describes how the audio is delivered when bought +according to the following list: + + $00 Other + $01 Standard CD album with other songs + $02 Compressed audio on CD + $03 File over the Internet + $04 Stream over the Internet + $05 As note sheets + $06 As note sheets in a book with other sheets + $07 Music on other media + $08 Non-musical merchandise + +Next follows a terminated string with the name of the seller followed by a +terminated string with a short description of the product. The last thing is +the ability to include a company logotype. The first of them is the 'Picture +MIME type' field containing information about which picture format is used. In +the event that the MIME media type name is omitted, "image/" will be implied. +Currently only "image/png" and "image/jpeg" are allowed. This format string is +followed by the binary picture data. This two last fields may be omitted if no +picture is to attach. + +
+ Text encoding $xx + Price string $00 + Valid until + Contact URL $00 + Received as $xx + Name of seller $00 (00) + Description $00 (00) + Picture MIME type $00 + Seller logo + + +4.26. Encryption method registration + +To identify with which method a frame has been encrypted the encryption method +must be registered in the tag with this frame. The 'Owner identifier' is a +null-terminated string with a URL containing an email address, or a link to a +location where an email address can be found, that belongs to the organisation +responsible for this specific encryption method. Questions regarding the +encryption method should be sent to the indicated email address. The 'Method +symbol' contains a value that is associated with this method throughout the +whole tag. Values below $80 are reserved. The 'Method symbol' may optionally be +followed by encryption specific data. There may be several "ENCR" frames in a +tag but only one containing the same symbol and only one containing the same +owner identifier. The method must be used somewhere in the tag. See section +3.3.1, flag j for more information. + +
+ Owner identifier $00 + Method symbol $xx + Encryption data + + +4.27. Group identification registration + +This frame enables grouping of otherwise unrelated frames. This can be used +when some frames are to be signed. To identify which frames belongs to a set of +frames a group identifier must be registered in the tag with this frame. The +'Owner identifier' is a null-terminated string with a URL containing an email +address, or a link to a location where an email address can be found, that +belongs to the organisation responsible for this grouping. Questions regarding +the grouping should be sent to the indicated email address. The 'Group symbol' +contains a value that associates the frame with this group throughout the whole +tag. Values below $80 are reserved. The 'Group symbol' may optionally be +followed by some group specific data, e.g. a digital signature. There may be +several "GRID" frames in a tag but only one containing the same symbol and only +one containing the same owner identifier. The group symbol must be used +somewhere in the tag. See section_3.3.1, flag j for more information. + +
+ Owner identifier $00 + Group symbol $xx + Group dependent data + + +4.28. Private frame + +This frame is used to contain information from a software producer that its +program uses and does not fit into the other frames. The frame consists of an +'Owner identifier' string and the binary data. The 'Owner identifier' is a +null-terminated string with a URL containing an email address, or a link to a +location where an email address can be found, that belongs to the organisation +responsible for the frame. Questions regarding the frame should be sent to the +indicated email address. The tag may contain more than one "PRIV" frame but +only with different contents. It is recommended to keep the number of "PRIV" +frames as low as possible. + +
+ Owner identifier $00 + The private data + + + +5. The unsynchronisation scheme + +The only purpose of the 'unsynchronisation scheme' is to make the ID3v2 tag as +compatible as possible with existing software. There is no use in +'unsynchronising' tags if the file is only to be processed by new software. +Unsynchronisation may only be made with MPEG 2 layer I, II and III and MPEG 2.5 +files. +Whenever a false synchronisation is found within the tag, one zeroed byte is +inserted after the first false synchronisation byte. The format of a correct +sync that should be altered by ID3 encoders is as follows: + + %11111111 111xxxxx + +And should be replaced with: + + %11111111 00000000 111xxxxx + +This has the side effect that all $FF 00 combinations have to be altered, so +they won't be affected by the decoding process. Therefore all the $FF 00 +combinations have to be replaced with the $FF 00 00 combination during the +unsynchronisation. +To indicate usage of the unsynchronisation, the first bit in 'ID3 flags' should +be set. This bit should only be set if the tag contains a, now corrected, false +synchronisation. The bit should only be clear if the tag does not contain any +false synchronisations. +Do bear in mind, that if a compression scheme is used by the encoder, the +unsynchronisation scheme should be applied *afterwards*. When decoding a +compressed, 'unsynchronised' file, the 'unsynchronisation scheme' should be +parsed first, decompression afterwards. +If the last byte in the tag is $FF, and there is a need to eliminate false +synchronisations in the tag, at least one byte of padding should be added. + + +6. Copyright + +Copyright © Martin Nilsson 1998. All Rights Reserved. +This document and translations of it may be copied and furnished to others, and +derivative works that comment on or otherwise explain it or assist in its +implementation may be prepared, copied, published and distributed, in whole or +in part, without restriction of any kind, provided that a reference to this +document is included on all such copies and derivative works. However, this +document itself may not be modified in any way and reissued as the original +document. +The limited permissions granted above are perpetual and will not be revoked. +This document and the information contained herein is provided on an "AS IS" +basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT +INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR +A PARTICULAR PURPOSE. + + +7. References + +[CDDB] Compact Disc Data Base http://www.cddb.com + +[ID3v2] Martin Nilsson, "ID3v2_informal_standard". + + [ISO-639-2] ISO/FDIS 639-2. Codes for the representation of names of +languages, Part 2: Alpha-3 code. Technical committee / subcommittee: TC 37 / SC +2 + + [ISO-4217] ISO 4217:1995. Codes for the representation of currencies and +funds. Technical committee / subcommittee: TC 68 + + [ISO-8859-1] ISO/IEC DIS 8859-1. 8-bit single-byte coded graphic character +sets, Part 1: Latin alphabet No. 1. Technical committee / subcommittee: JTC 1 / +SC 2 + + [ISRC] ISO 3901:1986 International Standard Recording Code (ISRC). Technical +committee / subcommittee: TC 46 / SC 9 + + [JFIF] JPEG File Interchange Format, version 1.02, http://www.w3.org/Graphics/ +JPEG/jfif.txt + + [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996., +ftp://ftp.isi.edu/in-notes/rfc2045.txt + + [MPEG] ISO/IEC 11172-3:1993. Coding of moving pictures and associated audio +for digital storage media at up to about 1,5 Mbit/s, Part 3: Audio. Technical +committee / subcommittee: JTC 1 / SC 29 and ISO/IEC 13818-3:1995 Generic coding +of moving pictures and associated audio information, Part 3: Audio. Technical +committee / subcommittee: JTC 1 / SC 29 and ISO/IEC DIS 13818-3 Generic coding +of moving pictures and associated audio information, Part 3: Audio (Revision of +ISO/IEC 13818-3:1995) + + [PNG] Portable Network Graphics, version 1.0, http://www.w3.org/TR/REC-png- +multi.html + + [UNICODE] ISO/IEC 10646-1:1993. Universal Multiple-Octet Coded Character Set +(UCS), Part 1: Architecture and Basic Multilingual Plane. Technical committee / +subcommittee: JTC 1 / SC 2, http://www.unicode.org + + [URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource +Locators (URL).", RFC 1738, December 1994., ftp://ftp.isi.edu/in-notes/ +rfc1738.txt + + [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB Compressed +Data Format Specification version 3.3", RFC 1950, May 1996., url:ftp:// +ftp.isi.edu/in-notes/rfc1950.txt + + + +8. Appendix + + +8.1. Appendix A - Genre List from ID3v1 + +The following genres is defined in ID3v1 + + 0. Blues + 1. Classic Rock + 2. Country + 3. Dance + 4. Disco + 5. Funk + 6. Grunge + 7. Hip-Hop + 8. Jazz + 9. Metal + 10. New Age + 11. Oldies + 12. Other + 13. Pop + 14. R&B + 15. Rap + 16. Reggae + 17. Rock + 18. Techno + 19. Industrial + 20. Alternative + 21. Ska + 22. Death Metal + 23. Pranks + 24. Soundtrack + 25. Euro-Techno + 26. Ambient + 27. Trip-Hop + 28. Vocal + 29. Jazz+Funk + 30. Fusion + 31. Trance + 32. Classical + 33. Instrumental + 34. Acid + 35. House + 36. Game + 37. Sound Clip + 38. Gospel + 39. Noise + 40. AlternRock + 41. Bass + 42. Soul + 43. Punk + 44. Space + 45. Meditative + 46. Instrumental Pop + 47. Instrumental Rock + 48. Ethnic + 49. Gothic + 50. Darkwave + 51. Techno-Industrial + 52. Electronic + 53. Pop-Folk + 54. Eurodance + 55. Dream + 56. Southern Rock + 57. Comedy + 58. Cult + 59. Gangsta + 60. Top 40 + 61. Christian Rap + 62. Pop/Funk + 63. Jungle + 64. Native American + 65. Cabaret + 66. New Wave + 67. Psychadelic + 68. Rave + 69. Showtunes + 70. Trailer + 71. Lo-Fi + 72. Tribal + 73. Acid Punk + 74. Acid Jazz + 75. Polka + 76. Retro + 77. Musical + 78. Rock & Roll + 79. Hard Rock + +The following genres are Winamp extensions + + 80. Folk + 81. Folk-Rock + 82. National Folk + 83. Swing + 84. Fast Fusion + 85. Bebob + 86. Latin + 87. Revival + 88. Celtic + 89. Bluegrass + 90. Avantgarde + 91. Gothic Rock + 92. Progressive Rock + 93. Psychedelic Rock + 94. Symphonic Rock + 95. Slow Rock + 96. Big Band + 97. Chorus + 98. Easy Listening + 99. Acoustic + 100. Humour + 101. Speech + 102. Chanson + 103. Opera + 104. Chamber Music + 105. Sonata + 106. Symphony + 107. Booty Bass + 108. Primus + 109. Porn Groove + 110. Satire + 111. Slow Jam + 112. Club + 113. Tango + 114. Samba + 115. Folklore + 116. Ballad + 117. Power Ballad + 118. Rhythmic Soul + 119. Freestyle + 120. Duet + 121. Punk Rock + 122. Drum Solo + 123. A capella + 124. Euro-House + 125. Dance Hall + + + +9. Author's Address + +Written by +Martin Nilsson +Rydsven 246 C. 30 +S-584 34 Linkoping +Sweden + +Email: nilsson at id3.org + +Edited by +Dirk Mahoney +57 Pechey Street +Chermside Q +Australia 4032 + +Email: dirk at id3.org + +Johan Sundstrom +Alsttersgatan 5 A. 34 +S-584 35 Linkoping +Sweden + +Email: johan at id3.org +id3v2.3.0 (last edited 2006-12-18 06:25:16 by DanONeill) diff --git a/gst-libs/gst/tag/id3v2.4.0-frames.txt b/gst-libs/gst/tag/id3v2.4.0-frames.txt new file mode 100644 index 0000000000..74a21bed3d --- /dev/null +++ b/gst-libs/gst/tag/id3v2.4.0-frames.txt @@ -0,0 +1,1734 @@ +$Id$ + +Informal standard M. Nilsson +Document: id3v2.4.0-frames.txt 1st November 2000 + + + ID3 tag version 2.4.0 - Native Frames + +Status of this document + + This document is an informal standard and replaces the ID3v2.3.0 + standard [ID3v2]. A formal standard will use another revision number + even if the content is identical to document. The contents in this + document may change for clarifications but never for added or altered + functionallity. + + Distribution of this document is unlimited. + + +Abstract + + This document describes the frames natively supported by ID3v2.4.0, + which is a revised version of the ID3v2 informal standard [ID3v2.3.0] + version 2.3.0. The ID3v2 offers a flexible way of storing audio meta + information within audio file itself. The information may be + technical information, such as equalisation curves, as well as title, + performer, copyright etc. + + ID3v2.4.0 is meant to be as close as possible to ID3v2.3.0 in order + to allow for implementations to be revised as easily as possible. + + +1. Table of contents + + 2. Conventions in this document + 3. Default flags + 4. Declared ID3v2 frames + 4.1. Unique file identifier + 4.2. Text information frames + 4.2.1. Identification frames + 4.2.2. Involved persons frames + 4.2.3. Derived and subjective properties frames + 4.2.4. Rights and license frames + 4.2.5. Other text frames + 4.2.6. User defined text information frame + 4.3. URL link frames + 4.3.1. URL link frames - details + 4.3.2. User defined URL link frame + 4.4. Music CD Identifier + 4.5. Event timing codes + 4.6. MPEG location lookup table + 4.7. Synced tempo codes + 4.8. Unsynchronised lyrics/text transcription + 4.9. Synchronised lyrics/text + 4.10. Comments + 4.11. Relative volume adjustment (2) + 4.12. Equalisation (2) + 4.13. Reverb + 4.14. Attached picture + 4.15. General encapsulated object + 4.16. Play counter + 4.17. Popularimeter + 4.18. Recommended buffer size + 4.19. Audio encryption + 4.20. Linked information + 4.21. Position synchronisation frame + 4.22. Terms of use + 4.23. Ownership frame + 4.24. Commercial frame + 4.25. Encryption method registration + 4.26. Group identification registration + 4.27. Private frame + 4.28. Signature frame + 4.29. Seek frame + 4.30. Audio seek point index + 5. Copyright + 6. References + 7. Appendix + A. Appendix A - Genre List from ID3v1 + 8. Author's Address + + +2. Conventions in this document + + Text within "" is a text string exactly as it appears in a tag. + Numbers preceded with $ are hexadecimal and numbers preceded with % + are binary. $xx is used to indicate a byte with unknown content. %x + is used to indicate a bit with unknown content. The most significant + bit (MSB) of a byte is called 'bit 7' and the least significant bit + (LSB) is called 'bit 0'. + + A tag is the whole tag described the ID3v2 main structure document + [ID3v2-strct]. A frame is a block of information in the tag. The tag + consists of a header, frames and optional padding. A field is a piece + of information; one value, a string etc. A numeric string is a string + that consists of the characters "0123456789" only. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [KEYWORDS]. + + +3. Default flags + + The default settings for the frames described in this document can be + divided into the following classes. The flags may be set differently + if found more suitable by the software. + + 1. Discarded if tag is altered, discarded if file is altered. + + None. + + 2. Discarded if tag is altered, preserved if file is altered. + + None. + + 3. Preserved if tag is altered, discarded if file is altered. + + ASPI, AENC, ETCO, EQU2, MLLT, POSS, SEEK, SYLT, SYTC, RVA2, TENC, + TLEN + + 4. Preserved if tag is altered, preserved if file is altered. + + The rest of the frames. + + +4. Declared ID3v2 frames + + The following frames are declared in this draft. + + 4.19 AENC Audio encryption + 4.14 APIC Attached picture + 4.30 ASPI Audio seek point index + + 4.10 COMM Comments + 4.24 COMR Commercial frame + + 4.25 ENCR Encryption method registration + 4.12 EQU2 Equalisation (2) + 4.5 ETCO Event timing codes + + 4.15 GEOB General encapsulated object + 4.26 GRID Group identification registration + + 4.20 LINK Linked information + + 4.4 MCDI Music CD identifier + 4.6 MLLT MPEG location lookup table + + 4.23 OWNE Ownership frame + + 4.27 PRIV Private frame + 4.16 PCNT Play counter + 4.17 POPM Popularimeter + 4.21 POSS Position synchronisation frame + + 4.18 RBUF Recommended buffer size + 4.11 RVA2 Relative volume adjustment (2) + 4.13 RVRB Reverb + + 4.29 SEEK Seek frame + 4.28 SIGN Signature frame + 4.9 SYLT Synchronised lyric/text + 4.7 SYTC Synchronised tempo codes + + 4.2.1 TALB Album/Movie/Show title + 4.2.3 TBPM BPM (beats per minute) + 4.2.2 TCOM Composer + 4.2.3 TCON Content type + 4.2.4 TCOP Copyright message + 4.2.5 TDEN Encoding time + 4.2.5 TDLY Playlist delay + 4.2.5 TDOR Original release time + 4.2.5 TDRC Recording time + 4.2.5 TDRL Release time + 4.2.5 TDTG Tagging time + 4.2.2 TENC Encoded by + 4.2.2 TEXT Lyricist/Text writer + 4.2.3 TFLT File type + 4.2.2 TIPL Involved people list + 4.2.1 TIT1 Content group description + 4.2.1 TIT2 Title/songname/content description + 4.2.1 TIT3 Subtitle/Description refinement + 4.2.3 TKEY Initial key + 4.2.3 TLAN Language(s) + 4.2.3 TLEN Length + 4.2.2 TMCL Musician credits list + 4.2.3 TMED Media type + 4.2.3 TMOO Mood + 4.2.1 TOAL Original album/movie/show title + 4.2.5 TOFN Original filename + 4.2.2 TOLY Original lyricist(s)/text writer(s) + 4.2.2 TOPE Original artist(s)/performer(s) + 4.2.4 TOWN File owner/licensee + 4.2.2 TPE1 Lead performer(s)/Soloist(s) + 4.2.2 TPE2 Band/orchestra/accompaniment + 4.2.2 TPE3 Conductor/performer refinement + 4.2.2 TPE4 Interpreted, remixed, or otherwise modified by + 4.2.1 TPOS Part of a set + 4.2.4 TPRO Produced notice + 4.2.4 TPUB Publisher + 4.2.1 TRCK Track number/Position in set + 4.2.4 TRSN Internet radio station name + 4.2.4 TRSO Internet radio station owner + 4.2.5 TSOA Album sort order + 4.2.5 TSOP Performer sort order + 4.2.5 TSOT Title sort order + 4.2.1 TSRC ISRC (international standard recording code) + 4.2.5 TSSE Software/Hardware and settings used for encoding + 4.2.1 TSST Set subtitle + 4.2.2 TXXX User defined text information frame + + 4.1 UFID Unique file identifier + 4.22 USER Terms of use + 4.8 USLT Unsynchronised lyric/text transcription + + 4.3.1 WCOM Commercial information + 4.3.1 WCOP Copyright/Legal information + 4.3.1 WOAF Official audio file webpage + 4.3.1 WOAR Official artist/performer webpage + 4.3.1 WOAS Official audio source webpage + 4.3.1 WORS Official Internet radio station homepage + 4.3.1 WPAY Payment + 4.3.1 WPUB Publishers official webpage + 4.3.2 WXXX User defined URL link frame + + +4.1. Unique file identifier + + This frame's purpose is to be able to identify the audio file in a + database, that may provide more information relevant to the content. + Since standardisation of such a database is beyond this document, all + UFID frames begin with an 'owner identifier' field. It is a null- + terminated string with a URL [URL] containing an email address, or a + link to a location where an email address can be found, that belongs + to the organisation responsible for this specific database + implementation. Questions regarding the database should be sent to + the indicated email address. The URL should not be used for the + actual database queries. The string + "http://www.id3.org/dummy/ufid.html" should be used for tests. The + 'Owner identifier' must be non-empty (more than just a termination). + The 'Owner identifier' is then followed by the actual identifier, + which may be up to 64 bytes. There may be more than one "UFID" frame + in a tag, but only one with the same 'Owner identifier'. + +
+ Owner identifier $00 + Identifier + + +4.2. Text information frames + + The text information frames are often the most important frames, + containing information like artist, album and more. There may only be + one text information frame of its kind in an tag. All text + information frames supports multiple strings, stored as a null + separated list, where null is reperesented by the termination code + for the charater encoding. All text frame identifiers begin with "T". + Only text frame identifiers begin with "T", with the exception of the + "TXXX" frame. All the text information frames have the following + format: + +
+ Text encoding $xx + Information + + +4.2.1. Identification frames + + TIT1 + The 'Content group description' frame is used if the sound belongs to + a larger category of sounds/music. For example, classical music is + often sorted in different musical sections (e.g. "Piano Concerto", + "Weather - Hurricane"). + + TIT2 + The 'Title/Songname/Content description' frame is the actual name of + the piece (e.g. "Adagio", "Hurricane Donna"). + + TIT3 + The 'Subtitle/Description refinement' frame is used for information + directly related to the contents title (e.g. "Op. 16" or "Performed + live at Wembley"). + + TALB + The 'Album/Movie/Show title' frame is intended for the title of the + recording (or source of sound) from which the audio in the file is + taken. + + TOAL + The 'Original album/movie/show title' frame is intended for the title + of the original recording (or source of sound), if for example the + music in the file should be a cover of a previously released song. + + TRCK + The 'Track number/Position in set' frame is a numeric string + containing the order number of the audio-file on its original + recording. This MAY be extended with a "/" character and a numeric + string containing the total number of tracks/elements on the original + recording. E.g. "4/9". + + TPOS + The 'Part of a set' frame is a numeric string that describes which + part of a set the audio came from. This frame is used if the source + described in the "TALB" frame is divided into several mediums, e.g. a + double CD. The value MAY be extended with a "/" character and a + numeric string containing the total number of parts in the set. E.g. + "1/2". + + TSST + The 'Set subtitle' frame is intended for the subtitle of the part of + a set this track belongs to. + + TSRC + The 'ISRC' frame should contain the International Standard Recording + Code [ISRC] (12 characters). + + +4.2.2. Involved persons frames + + TPE1 + The 'Lead artist/Lead performer/Soloist/Performing group' is + used for the main artist. + + TPE2 + The 'Band/Orchestra/Accompaniment' frame is used for additional + information about the performers in the recording. + + TPE3 + The 'Conductor' frame is used for the name of the conductor. + + TPE4 + The 'Interpreted, remixed, or otherwise modified by' frame contains + more information about the people behind a remix and similar + interpretations of another existing piece. + + TOPE + The 'Original artist/performer' frame is intended for the performer + of the original recording, if for example the music in the file + should be a cover of a previously released song. + + TEXT + The 'Lyricist/Text writer' frame is intended for the writer of the + text or lyrics in the recording. + + TOLY + The 'Original lyricist/text writer' frame is intended for the + text writer of the original recording, if for example the music in + the file should be a cover of a previously released song. + + TCOM + The 'Composer' frame is intended for the name of the composer. + + TMCL + The 'Musician credits list' is intended as a mapping between + instruments and the musician that played it. Every odd field is an + instrument and every even is an artist or a comma delimited list of + artists. + + TIPL + The 'Involved people list' is very similar to the musician credits + list, but maps between functions, like producer, and names. + + TENC + The 'Encoded by' frame contains the name of the person or + organisation that encoded the audio file. This field may contain a + copyright message, if the audio file also is copyrighted by the + encoder. + + +4.2.3. Derived and subjective properties frames + + TBPM + The 'BPM' frame contains the number of beats per minute in the + main part of the audio. The BPM is an integer and represented as a + numerical string. + + TLEN + The 'Length' frame contains the length of the audio file in + milliseconds, represented as a numeric string. + + TKEY + The 'Initial key' frame contains the musical key in which the sound + starts. It is represented as a string with a maximum length of three + characters. The ground keys are represented with "A","B","C","D","E", + "F" and "G" and halfkeys represented with "b" and "#". Minor is + represented as "m", e.g. "Dbm" $00. Off key is represented with an + "o" only. + + TLAN + The 'Language' frame should contain the languages of the text or + lyrics spoken or sung in the audio. The language is represented with + three characters according to ISO-639-2 [ISO-639-2]. If more than one + language is used in the text their language codes should follow + according to the amount of their usage, e.g. "eng" $00 "sve" $00. + + TCON + The 'Content type', which ID3v1 was stored as a one byte numeric + value only, is now a string. You may use one or several of the ID3v1 + types as numerical strings, or, since the category list would be + impossible to maintain with accurate and up to date categories, + define your own. Example: "21" $00 "Eurodisco" $00 + + You may also use any of the following keywords: + + RX Remix + CR Cover + + TFLT + The 'File type' frame indicates which type of audio this tag defines. + The following types and refinements are defined: + + MIME MIME type follows + MPG MPEG Audio + /1 MPEG 1/2 layer I + /2 MPEG 1/2 layer II + /3 MPEG 1/2 layer III + /2.5 MPEG 2.5 + /AAC Advanced audio compression + VQF Transform-domain Weighted Interleave Vector Quantisation + PCM Pulse Code Modulated audio + + but other types may be used, but not for these types though. This is + used in a similar way to the predefined types in the "TMED" frame, + but without parentheses. If this frame is not present audio type is + assumed to be "MPG". + + TMED + The 'Media type' frame describes from which media the sound + originated. This may be a text string or a reference to the + predefined media types found in the list below. Example: + "VID/PAL/VHS" $00. + + DIG Other digital media + /A Analogue transfer from media + + ANA Other analogue media + /WAC Wax cylinder + /8CA 8-track tape cassette + + CD CD + /A Analogue transfer from media + /DD DDD + /AD ADD + /AA AAD + + LD Laserdisc + + TT Turntable records + /33 33.33 rpm + /45 45 rpm + /71 71.29 rpm + /76 76.59 rpm + /78 78.26 rpm + /80 80 rpm + + MD MiniDisc + /A Analogue transfer from media + + DAT DAT + /A Analogue transfer from media + /1 standard, 48 kHz/16 bits, linear + /2 mode 2, 32 kHz/16 bits, linear + /3 mode 3, 32 kHz/12 bits, non-linear, low speed + /4 mode 4, 32 kHz/12 bits, 4 channels + /5 mode 5, 44.1 kHz/16 bits, linear + /6 mode 6, 44.1 kHz/16 bits, 'wide track' play + + DCC DCC + /A Analogue transfer from media + + DVD DVD + /A Analogue transfer from media + + TV Television + /PAL PAL + /NTSC NTSC + /SECAM SECAM + + VID Video + /PAL PAL + /NTSC NTSC + /SECAM SECAM + /VHS VHS + /SVHS S-VHS + /BETA BETAMAX + + RAD Radio + /FM FM + /AM AM + /LW LW + /MW MW + + TEL Telephone + /I ISDN + + MC MC (normal cassette) + /4 4.75 cm/s (normal speed for a two sided cassette) + /9 9.5 cm/s + /I Type I cassette (ferric/normal) + /II Type II cassette (chrome) + /III Type III cassette (ferric chrome) + /IV Type IV cassette (metal) + + REE Reel + /9 9.5 cm/s + /19 19 cm/s + /38 38 cm/s + /76 76 cm/s + /I Type I cassette (ferric/normal) + /II Type II cassette (chrome) + /III Type III cassette (ferric chrome) + /IV Type IV cassette (metal) + + TMOO + The 'Mood' frame is intended to reflect the mood of the audio with a + few keywords, e.g. "Romantic" or "Sad". + + +4.2.4. Rights and license frames + + TCOP + The 'Copyright message' frame, in which the string must begin with a + year and a space character (making five characters), is intended for + the copyright holder of the original sound, not the audio file + itself. The absence of this frame means only that the copyright + information is unavailable or has been removed, and must not be + interpreted to mean that the audio is public domain. Every time this + field is displayed the field must be preceded with "Copyright " (C) " + ", where (C) is one character showing a C in a circle. + + TPRO + The 'Produced notice' frame, in which the string must begin with a + year and a space character (making five characters), is intended for + the production copyright holder of the original sound, not the audio + file itself. The absence of this frame means only that the production + copyright information is unavailable or has been removed, and must + not be interpreted to mean that the audio is public domain. Every + time this field is displayed the field must be preceded with + "Produced " (P) " ", where (P) is one character showing a P in a + circle. + + TPUB + The 'Publisher' frame simply contains the name of the label or + publisher. + + TOWN + The 'File owner/licensee' frame contains the name of the owner or + licensee of the file and it's contents. + + TRSN + The 'Internet radio station name' frame contains the name of the + internet radio station from which the audio is streamed. + + TRSO + The 'Internet radio station owner' frame contains the name of the + owner of the internet radio station from which the audio is + streamed. + +4.2.5. Other text frames + + TOFN + The 'Original filename' frame contains the preferred filename for the + file, since some media doesn't allow the desired length of the + filename. The filename is case sensitive and includes its suffix. + + TDLY + The 'Playlist delay' defines the numbers of milliseconds of silence + that should be inserted before this audio. The value zero indicates + that this is a part of a multifile audio track that should be played + continuously. + + TDEN + The 'Encoding time' frame contains a timestamp describing when the + audio was encoded. Timestamp format is described in the ID3v2 + structure document [ID3v2-strct]. + + TDOR + The 'Original release time' frame contains a timestamp describing + when the original recording of the audio was released. Timestamp + format is described in the ID3v2 structure document [ID3v2-strct]. + + TDRC + The 'Recording time' frame contains a timestamp describing when the + audio was recorded. Timestamp format is described in the ID3v2 + structure document [ID3v2-strct]. + + TDRL + The 'Release time' frame contains a timestamp describing when the + audio was first released. Timestamp format is described in the ID3v2 + structure document [ID3v2-strct]. + + TDTG + The 'Tagging time' frame contains a timestamp describing then the + audio was tagged. Timestamp format is described in the ID3v2 + structure document [ID3v2-strct]. + + TSSE + The 'Software/Hardware and settings used for encoding' frame + includes the used audio encoder and its settings when the file was + encoded. Hardware refers to hardware encoders, not the computer on + which a program was run. + + TSOA + The 'Album sort order' frame defines a string which should be used + instead of the album name (TALB) for sorting purposes. E.g. an album + named "A Soundtrack" might preferably be sorted as "Soundtrack". + + TSOP + The 'Performer sort order' frame defines a string which should be + used instead of the performer (TPE2) for sorting purposes. + + TSOT + The 'Title sort order' frame defines a string which should be used + instead of the title (TIT2) for sorting purposes. + + +4.2.6. User defined text information frame + + This frame is intended for one-string text information concerning the + audio file in a similar way to the other "T"-frames. The frame body + consists of a description of the string, represented as a terminated + string, followed by the actual string. There may be more than one + "TXXX" frame in each tag, but only one with the same description. + +
+ Text encoding $xx + Description $00 (00) + Value + + +4.3. URL link frames + + With these frames dynamic data such as webpages with touring + information, price information or plain ordinary news can be added to + the tag. There may only be one URL [URL] link frame of its kind in an + tag, except when stated otherwise in the frame description. If the + text string is followed by a string termination, all the following + information should be ignored and not be displayed. All URL link + frame identifiers begins with "W". Only URL link frame identifiers + begins with "W", except for "WXXX". All URL link frames have the + following format: + +
+ URL + + +4.3.1. URL link frames - details + + WCOM + The 'Commercial information' frame is a URL pointing at a webpage + with information such as where the album can be bought. There may be + more than one "WCOM" frame in a tag, but not with the same content. + + WCOP + The 'Copyright/Legal information' frame is a URL pointing at a + webpage where the terms of use and ownership of the file is + described. + + WOAF + The 'Official audio file webpage' frame is a URL pointing at a file + specific webpage. + + WOAR + The 'Official artist/performer webpage' frame is a URL pointing at + the artists official webpage. There may be more than one "WOAR" frame + in a tag if the audio contains more than one performer, but not with + the same content. + + WOAS + The 'Official audio source webpage' frame is a URL pointing at the + official webpage for the source of the audio file, e.g. a movie. + + WORS + The 'Official Internet radio station homepage' contains a URL + pointing at the homepage of the internet radio station. + + WPAY + The 'Payment' frame is a URL pointing at a webpage that will handle + the process of paying for this file. + + WPUB + The 'Publishers official webpage' frame is a URL pointing at the + official webpage for the publisher. + + +4.3.2. User defined URL link frame + + This frame is intended for URL [URL] links concerning the audio file + in a similar way to the other "W"-frames. The frame body consists + of a description of the string, represented as a terminated string, + followed by the actual URL. The URL is always encoded with ISO-8859-1 + [ISO-8859-1]. There may be more than one "WXXX" frame in each tag, + but only one with the same description. + +
+ Text encoding $xx + Description $00 (00) + URL + + +4.4. Music CD identifier + + This frame is intended for music that comes from a CD, so that the CD + can be identified in databases such as the CDDB [CDDB]. The frame + consists of a binary dump of the Table Of Contents, TOC, from the CD, + which is a header of 4 bytes and then 8 bytes/track on the CD plus 8 + bytes for the 'lead out', making a maximum of 804 bytes. The offset + to the beginning of every track on the CD should be described with a + four bytes absolute CD-frame address per track, and not with absolute + time. When this frame is used the presence of a valid "TRCK" frame is + REQUIRED, even if the CD's only got one track. It is recommended that + this frame is always added to tags originating from CDs. There may + only be one "MCDI" frame in each tag. + +
+ CD TOC + + +4.5. Event timing codes + + This frame allows synchronisation with key events in the audio. The + header is: + +
+ Time stamp format $xx + + Where time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + + Absolute time means that every stamp contains the time from the + beginning of the file. + + Followed by a list of key events in the following format: + + Type of event $xx + Time stamp $xx (xx ...) + + The 'Time stamp' is set to zero if directly at the beginning of the + sound or after the previous event. All events MUST be sorted in + chronological order. The type of event is as follows: + + $00 padding (has no meaning) + $01 end of initial silence + $02 intro start + $03 main part start + $04 outro start + $05 outro end + $06 verse start + $07 refrain start + $08 interlude start + $09 theme start + $0A variation start + $0B key change + $0C time change + $0D momentary unwanted noise (Snap, Crackle & Pop) + $0E sustained noise + $0F sustained noise end + $10 intro end + $11 main part end + $12 verse end + $13 refrain end + $14 theme end + $15 profanity + $16 profanity end + + $17-$DF reserved for future use + + $E0-$EF not predefined synch 0-F + + $F0-$FC reserved for future use + + $FD audio end (start of silence) + $FE audio file ends + $FF one more byte of events follows (all the following bytes with + the value $FF have the same function) + + Terminating the start events such as "intro start" is OPTIONAL. The + 'Not predefined synch's ($E0-EF) are for user events. You might want + to synchronise your music to something, like setting off an explosion + on-stage, activating a screensaver etc. + + There may only be one "ETCO" frame in each tag. + + +4.6. MPEG location lookup table + + To increase performance and accuracy of jumps within a MPEG [MPEG] + audio file, frames with time codes in different locations in the file + might be useful. This ID3v2 frame includes references that the + software can use to calculate positions in the file. After the frame + header follows a descriptor of how much the 'frame counter' should be + increased for every reference. If this value is two then the first + reference points out the second frame, the 2nd reference the 4th + frame, the 3rd reference the 6th frame etc. In a similar way the + 'bytes between reference' and 'milliseconds between reference' points + out bytes and milliseconds respectively. + + Each reference consists of two parts; a certain number of bits, as + defined in 'bits for bytes deviation', that describes the difference + between what is said in 'bytes between reference' and the reality and + a certain number of bits, as defined in 'bits for milliseconds + deviation', that describes the difference between what is said in + 'milliseconds between reference' and the reality. The number of bits + in every reference, i.e. 'bits for bytes deviation'+'bits for + milliseconds deviation', must be a multiple of four. There may only + be one "MLLT" frame in each tag. + +
+ MPEG frames between reference $xx xx + Bytes between reference $xx xx xx + Milliseconds between reference $xx xx xx + Bits for bytes deviation $xx + Bits for milliseconds dev. $xx + + Then for every reference the following data is included; + + Deviation in bytes %xxx.... + Deviation in milliseconds %xxx.... + + +4.7. Synchronised tempo codes + + For a more accurate description of the tempo of a musical piece, this + frame might be used. After the header follows one byte describing + which time stamp format should be used. Then follows one or more + tempo codes. Each tempo code consists of one tempo part and one time + part. The tempo is in BPM described with one or two bytes. If the + first byte has the value $FF, one more byte follows, which is added + to the first giving a range from 2 - 510 BPM, since $00 and $01 is + reserved. $00 is used to describe a beat-free time period, which is + not the same as a music-free time period. $01 is used to indicate one + single beat-stroke followed by a beat-free period. + + The tempo descriptor is followed by a time stamp. Every time the + tempo in the music changes, a tempo descriptor may indicate this for + the player. All tempo descriptors MUST be sorted in chronological + order. The first beat-stroke in a time-period is at the same time as + the beat description occurs. There may only be one "SYTC" frame in + each tag. + +
+ Time stamp format $xx + Tempo data + + Where time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + + Absolute time means that every stamp contains the time from the + beginning of the file. + + +4.8. Unsynchronised lyrics/text transcription + + This frame contains the lyrics of the song or a text transcription of + other vocal activities. The head includes an encoding descriptor and + a content descriptor. The body consists of the actual text. The + 'Content descriptor' is a terminated string. If no descriptor is + entered, 'Content descriptor' is $00 (00) only. Newline characters + are allowed in the text. There may be more than one 'Unsynchronised + lyrics/text transcription' frame in each tag, but only one with the + same language and content descriptor. + +
+ Text encoding $xx + Language $xx xx xx + Content descriptor $00 (00) + Lyrics/text + + +4.9. Synchronised lyrics/text + + This is another way of incorporating the words, said or sung lyrics, + in the audio file as text, this time, however, in sync with the + audio. It might also be used to describing events e.g. occurring on a + stage or on the screen in sync with the audio. The header includes a + content descriptor, represented with as terminated text string. If no + descriptor is entered, 'Content descriptor' is $00 (00) only. + +
+ Text encoding $xx + Language $xx xx xx + Time stamp format $xx + Content type $xx + Content descriptor $00 (00) + + Content type: $00 is other + $01 is lyrics + $02 is text transcription + $03 is movement/part name (e.g. "Adagio") + $04 is events (e.g. "Don Quijote enters the stage") + $05 is chord (e.g. "Bb F Fsus") + $06 is trivia/'pop up' information + $07 is URLs to webpages + $08 is URLs to images + + Time stamp format: + + $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + + Absolute time means that every stamp contains the time from the + beginning of the file. + + The text that follows the frame header differs from that of the + unsynchronised lyrics/text transcription in one major way. Each + syllable (or whatever size of text is considered to be convenient by + the encoder) is a null terminated string followed by a time stamp + denoting where in the sound file it belongs. Each sync thus has the + following structure: + + Terminated text to be synced (typically a syllable) + Sync identifier (terminator to above string) $00 (00) + Time stamp $xx (xx ...) + + The 'time stamp' is set to zero or the whole sync is omitted if + located directly at the beginning of the sound. All time stamps + should be sorted in chronological order. The sync can be considered + as a validator of the subsequent string. + + Newline characters are allowed in all "SYLT" frames and MUST be used + after every entry (name, event etc.) in a frame with the content type + $03 - $04. + + A few considerations regarding whitespace characters: Whitespace + separating words should mark the beginning of a new word, thus + occurring in front of the first syllable of a new word. This is also + valid for new line characters. A syllable followed by a comma should + not be broken apart with a sync (both the syllable and the comma + should be before the sync). + + An example: The "USLT" passage + + "Strangers in the night" $0A "Exchanging glances" + + would be "SYLT" encoded as: + + "Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx + " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx + xx "glan" $00 xx xx "ces" $00 xx xx + + There may be more than one "SYLT" frame in each tag, but only one + with the same language and content descriptor. + + +4.10. Comments + + This frame is intended for any kind of full text information that + does not fit in any other frame. It consists of a frame header + followed by encoding, language and content descriptors and is ended + with the actual comment as a text string. Newline characters are + allowed in the comment text string. There may be more than one + comment frame in each tag, but only one with the same language and + content descriptor. + +
+ Text encoding $xx + Language $xx xx xx + Short content descrip. $00 (00) + The actual text + + +4.11. Relative volume adjustment (2) + + This is a more subjective frame than the previous ones. It allows the + user to say how much he wants to increase/decrease the volume on each + channel when the file is played. The purpose is to be able to align + all files to a reference volume, so that you don't have to change the + volume constantly. This frame may also be used to balance adjust the + audio. The volume adjustment is encoded as a fixed point decibel + value, 16 bit signed integer representing (adjustment*512), giving + +/- 64 dB with a precision of 0.001953125 dB. E.g. +2 dB is stored as + $04 00 and -2 dB is $FC 00. There may be more than one "RVA2" frame + in each tag, but only one with the same identification string. + +
+ Identification $00 + + The 'identification' string is used to identify the situation and/or + device where this adjustment should apply. The following is then + repeated for every channel + + Type of channel $xx + Volume adjustment $xx xx + Bits representing peak $xx + Peak volume $xx (xx ...) + + + Type of channel: $00 Other + $01 Master volume + $02 Front right + $03 Front left + $04 Back right + $05 Back left + $06 Front centre + $07 Back centre + $08 Subwoofer + + Bits representing peak can be any number between 0 and 255. 0 means + that there is no peak volume field. The peak volume field is always + padded to whole bytes, setting the most significant bits to zero. + + +4.12. Equalisation (2) + + This is another subjective, alignment frame. It allows the user to + predefine an equalisation curve within the audio file. There may be + more than one "EQU2" frame in each tag, but only one with the same + identification string. + +
+ Interpolation method $xx + Identification $00 + + The 'interpolation method' describes which method is preferred when + an interpolation between the adjustment point that follows. The + following methods are currently defined: + + $00 Band + No interpolation is made. A jump from one adjustment level to + another occurs in the middle between two adjustment points. + $01 Linear + Interpolation between adjustment points is linear. + + The 'identification' string is used to identify the situation and/or + device where this adjustment should apply. The following is then + repeated for every adjustment point + + Frequency $xx xx + Volume adjustment $xx xx + + The frequency is stored in units of 1/2 Hz, giving it a range from 0 + to 32767 Hz. + + The volume adjustment is encoded as a fixed point decibel value, 16 + bit signed integer representing (adjustment*512), giving +/- 64 dB + with a precision of 0.001953125 dB. E.g. +2 dB is stored as $04 00 + and -2 dB is $FC 00. + + Adjustment points should be ordered by frequency and one frequency + should only be described once in the frame. + + +4.13. Reverb + + Yet another subjective frame, with which you can adjust echoes of + different kinds. Reverb left/right is the delay between every bounce + in ms. Reverb bounces left/right is the number of bounces that should + be made. $FF equals an infinite number of bounces. Feedback is the + amount of volume that should be returned to the next echo bounce. $00 + is 0%, $FF is 100%. If this value were $7F, there would be 50% volume + reduction on the first bounce, 50% of that on the second and so on. + Left to left means the sound from the left bounce to be played in the + left speaker, while left to right means sound from the left bounce to + be played in the right speaker. + + 'Premix left to right' is the amount of left sound to be mixed in the + right before any reverb is applied, where $00 id 0% and $FF is 100%. + 'Premix right to left' does the same thing, but right to left. + Setting both premix to $FF would result in a mono output (if the + reverb is applied symmetric). There may only be one "RVRB" frame in + each tag. + +
+ Reverb left (ms) $xx xx + Reverb right (ms) $xx xx + Reverb bounces, left $xx + Reverb bounces, right $xx + Reverb feedback, left to left $xx + Reverb feedback, left to right $xx + Reverb feedback, right to right $xx + Reverb feedback, right to left $xx + Premix left to right $xx + Premix right to left $xx + + +4.14. Attached picture + + This frame contains a picture directly related to the audio file. + Image format is the MIME type and subtype [MIME] for the image. In + the event that the MIME media type name is omitted, "image/" will be + implied. The "image/png" [PNG] or "image/jpeg" [JFIF] picture format + should be used when interoperability is wanted. Description is a + short description of the picture, represented as a terminated + text string. There may be several pictures attached to one file, each + in their individual "APIC" frame, but only one with the same content + descriptor. There may only be one picture with the picture type + declared as picture type $01 and $02 respectively. There is the + possibility to put only a link to the image file by using the 'MIME + type' "-->" and having a complete URL [URL] instead of picture data. + The use of linked files should however be used sparingly since there + is the risk of separation of files. + +
+ Text encoding $xx + MIME type $00 + Picture type $xx + Description $00 (00) + Picture data + + + Picture type: $00 Other + $01 32x32 pixels 'file icon' (PNG only) + $02 Other file icon + $03 Cover (front) + $04 Cover (back) + $05 Leaflet page + $06 Media (e.g. label side of CD) + $07 Lead artist/lead performer/soloist + $08 Artist/performer + $09 Conductor + $0A Band/Orchestra + $0B Composer + $0C Lyricist/text writer + $0D Recording Location + $0E During recording + $0F During performance + $10 Movie/video screen capture + $11 A bright coloured fish + $12 Illustration + $13 Band/artist logotype + $14 Publisher/Studio logotype + + +4.15. General encapsulated object + + In this frame any type of file can be encapsulated. After the header, + 'Frame size' and 'Encoding' follows 'MIME type' [MIME] represented as + as a terminated string encoded with ISO 8859-1 [ISO-8859-1]. The + filename is case sensitive and is encoded as 'Encoding'. Then follows + a content description as terminated string, encoded as 'Encoding'. + The last thing in the frame is the actual object. The first two + strings may be omitted, leaving only their terminations. MIME type is + always an ISO-8859-1 text string. There may be more than one "GEOB" + frame in each tag, but only one with the same content descriptor. + +
+ Text encoding $xx + MIME type $00 + Filename $00 (00) + Content description $00 (00) + Encapsulated object + + +4.16. Play counter + + This is simply a counter of the number of times a file has been + played. The value is increased by one every time the file begins to + play. There may only be one "PCNT" frame in each tag. When the + counter reaches all one's, one byte is inserted in front of the + counter thus making the counter eight bits bigger. The counter must + be at least 32-bits long to begin with. + +
+ Counter $xx xx xx xx (xx ...) + + +4.17. Popularimeter + + The purpose of this frame is to specify how good an audio file is. + Many interesting applications could be found to this frame such as a + playlist that features better audio files more often than others or + it could be used to profile a person's taste and find other 'good' + files by comparing people's profiles. The frame contains the email + address to the user, one rating byte and a four byte play counter, + intended to be increased with one for every time the file is played. + The email is a terminated string. The rating is 1-255 where 1 is + worst and 255 is best. 0 is unknown. If no personal counter is wanted + it may be omitted. When the counter reaches all one's, one byte is + inserted in front of the counter thus making the counter eight bits + bigger in the same away as the play counter ("PCNT"). There may be + more than one "POPM" frame in each tag, but only one with the same + email address. + +
+ Email to user $00 + Rating $xx + Counter $xx xx xx xx (xx ...) + + +4.18. Recommended buffer size + + Sometimes the server from which an audio file is streamed is aware of + transmission or coding problems resulting in interruptions in the + audio stream. In these cases, the size of the buffer can be + recommended by the server using this frame. If the 'embedded info + flag' is true (1) then this indicates that an ID3 tag with the + maximum size described in 'Buffer size' may occur in the audio + stream. In such case the tag should reside between two MPEG [MPEG] + frames, if the audio is MPEG encoded. If the position of the next tag + is known, 'offset to next tag' may be used. The offset is calculated + from the end of tag in which this frame resides to the first byte of + the header in the next. This field may be omitted. Embedded tags are + generally not recommended since this could render unpredictable + behaviour from present software/hardware. + + For applications like streaming audio it might be an idea to embed + tags into the audio stream though. If the clients connects to + individual connections like HTTP and there is a possibility to begin + every transmission with a tag, then this tag should include a + 'recommended buffer size' frame. If the client is connected to a + arbitrary point in the stream, such as radio or multicast, then the + 'recommended buffer size' frame SHOULD be included in every tag. + + The 'Buffer size' should be kept to a minimum. There may only be one + "RBUF" frame in each tag. + +
+ Buffer size $xx xx xx + Embedded info flag %0000000x + Offset to next tag $xx xx xx xx + + +4.19. Audio encryption + + This frame indicates if the actual audio stream is encrypted, and by + whom. Since standardisation of such encryption scheme is beyond this + document, all "AENC" frames begin with a terminated string with a + URL containing an email address, or a link to a location where an + email address can be found, that belongs to the organisation + responsible for this specific encrypted audio file. Questions + regarding the encrypted audio should be sent to the email address + specified. If a $00 is found directly after the 'Frame size' and the + audio file indeed is encrypted, the whole file may be considered + useless. + + After the 'Owner identifier', a pointer to an unencrypted part of the + audio can be specified. The 'Preview start' and 'Preview length' is + described in frames. If no part is unencrypted, these fields should + be left zeroed. After the 'preview length' field follows optionally a + data block required for decryption of the audio. There may be more + than one "AENC" frames in a tag, but only one with the same 'Owner + identifier'. + +
+ Owner identifier $00 + Preview start $xx xx + Preview length $xx xx + Encryption info + + +4.20. Linked information + + To keep information duplication as low as possible this frame may be + used to link information from another ID3v2 tag that might reside in + another audio file or alone in a binary file. It is RECOMMENDED that + this method is only used when the files are stored on a CD-ROM or + other circumstances when the risk of file separation is low. The + frame contains a frame identifier, which is the frame that should be + linked into this tag, a URL [URL] field, where a reference to the + file where the frame is given, and additional ID data, if needed. + Data should be retrieved from the first tag found in the file to + which this link points. There may be more than one "LINK" frame in a + tag, but only one with the same contents. A linked frame is to be + considered as part of the tag and has the same restrictions as if it + was a physical part of the tag (i.e. only one "RVRB" frame allowed, + whether it's linked or not). + +
+ Frame identifier $xx xx xx xx + URL $00 + ID and additional data + + Frames that may be linked and need no additional data are "ASPI", + "ETCO", "EQU2", "MCID", "MLLT", "OWNE", "RVA2", "RVRB", "SYTC", the + text information frames and the URL link frames. + + The "AENC", "APIC", "GEOB" and "TXXX" frames may be linked with + the content descriptor as additional ID data. + + The "USER" frame may be linked with the language field as additional + ID data. + + The "PRIV" frame may be linked with the owner identifier as + additional ID data. + + The "COMM", "SYLT" and "USLT" frames may be linked with three bytes + of language descriptor directly followed by a content descriptor as + additional ID data. + + +4.21. Position synchronisation frame + + This frame delivers information to the listener of how far into the + audio stream he picked up; in effect, it states the time offset from + the first frame in the stream. The frame layout is: + + + Time stamp format $xx + Position $xx (xx ...) + + Where time stamp format is: + + $01 Absolute time, 32 bit sized, using MPEG frames as unit + $02 Absolute time, 32 bit sized, using milliseconds as unit + + and position is where in the audio the listener starts to receive, + i.e. the beginning of the next frame. If this frame is used in the + beginning of a file the value is always 0. There may only be one + "POSS" frame in each tag. + + +4.22. Terms of use frame + + This frame contains a brief description of the terms of use and + ownership of the file. More detailed information concerning the legal + terms might be available through the "WCOP" frame. Newlines are + allowed in the text. There may be more than one 'Terms of use' frame + in a tag, but only one with the same 'Language'. + +
+ Text encoding $xx + Language $xx xx xx + The actual text + + +4.23. Ownership frame + + The ownership frame might be used as a reminder of a made transaction + or, if signed, as proof. Note that the "USER" and "TOWN" frames are + good to use in conjunction with this one. The frame begins, after the + frame ID, size and encoding fields, with a 'price paid' field. The + first three characters of this field contains the currency used for + the transaction, encoded according to ISO 4217 [ISO-4217] alphabetic + currency code. Concatenated to this is the actual price paid, as a + numerical string using "." as the decimal separator. Next is an 8 + character date string (YYYYMMDD) followed by a string with the name + of the seller as the last field in the frame. There may only be one + "OWNE" frame in a tag. + +
+ Text encoding $xx + Price paid $00 + Date of purch. + Seller + + +4.24. Commercial frame + + This frame enables several competing offers in the same tag by + bundling all needed information. That makes this frame rather complex + but it's an easier solution than if one tries to achieve the same + result with several frames. The frame begins, after the frame ID, + size and encoding fields, with a price string field. A price is + constructed by one three character currency code, encoded according + to ISO 4217 [ISO-4217] alphabetic currency code, followed by a + numerical value where "." is used as decimal separator. In the price + string several prices may be concatenated, separated by a "/" + character, but there may only be one currency of each type. + + The price string is followed by an 8 character date string in the + format YYYYMMDD, describing for how long the price is valid. After + that is a contact URL, with which the user can contact the seller, + followed by a one byte 'received as' field. It describes how the + audio is delivered when bought according to the following list: + + $00 Other + $01 Standard CD album with other songs + $02 Compressed audio on CD + $03 File over the Internet + $04 Stream over the Internet + $05 As note sheets + $06 As note sheets in a book with other sheets + $07 Music on other media + $08 Non-musical merchandise + + Next follows a terminated string with the name of the seller followed + by a terminated string with a short description of the product. The + last thing is the ability to include a company logotype. The first of + them is the 'Picture MIME type' field containing information about + which picture format is used. In the event that the MIME media type + name is omitted, "image/" will be implied. Currently only "image/png" + and "image/jpeg" are allowed. This format string is followed by the + binary picture data. This two last fields may be omitted if no + picture is attached. There may be more than one 'commercial frame' in + a tag, but no two may be identical. + +
+ Text encoding $xx + Price string $00 + Valid until + Contact URL $00 + Received as $xx + Name of seller $00 (00) + Description $00 (00) + Picture MIME type $00 + Seller logo + + +4.25. Encryption method registration + + To identify with which method a frame has been encrypted the + encryption method must be registered in the tag with this frame. The + 'Owner identifier' is a null-terminated string with a URL [URL] + containing an email address, or a link to a location where an email + address can be found, that belongs to the organisation responsible + for this specific encryption method. Questions regarding the + encryption method should be sent to the indicated email address. The + 'Method symbol' contains a value that is associated with this method + throughout the whole tag, in the range $80-F0. All other values are + reserved. The 'Method symbol' may optionally be followed by + encryption specific data. There may be several "ENCR" frames in a tag + but only one containing the same symbol and only one containing the + same owner identifier. The method must be used somewhere in the tag. + See the description of the frame encryption flag in the ID3v2 + structure document [ID3v2-strct] for more information. + +
+ Owner identifier $00 + Method symbol $xx + Encryption data + + +4.26. Group identification registration + + This frame enables grouping of otherwise unrelated frames. This can + be used when some frames are to be signed. To identify which frames + belongs to a set of frames a group identifier must be registered in + the tag with this frame. The 'Owner identifier' is a null-terminated + string with a URL [URL] containing an email address, or a link to a + location where an email address can be found, that belongs to the + organisation responsible for this grouping. Questions regarding the + grouping should be sent to the indicated email address. The 'Group + symbol' contains a value that associates the frame with this group + throughout the whole tag, in the range $80-F0. All other values are + reserved. The 'Group symbol' may optionally be followed by some group + specific data, e.g. a digital signature. There may be several "GRID" + frames in a tag but only one containing the same symbol and only one + containing the same owner identifier. The group symbol must be used + somewhere in the tag. See the description of the frame grouping flag + in the ID3v2 structure document [ID3v2-strct] for more information. + +
+ Owner identifier $00 + Group symbol $xx + Group dependent data + + +4.27. Private frame + + This frame is used to contain information from a software producer + that its program uses and does not fit into the other frames. The + frame consists of an 'Owner identifier' string and the binary data. + The 'Owner identifier' is a null-terminated string with a URL [URL] + containing an email address, or a link to a location where an email + address can be found, that belongs to the organisation responsible + for the frame. Questions regarding the frame should be sent to the + indicated email address. The tag may contain more than one "PRIV" + frame but only with different contents. + +
+ Owner identifier $00 + The private data + + +4.28. Signature frame + + This frame enables a group of frames, grouped with the 'Group + identification registration', to be signed. Although signatures can + reside inside the registration frame, it might be desired to store + the signature elsewhere, e.g. in watermarks. There may be more than + one 'signature frame' in a tag, but no two may be identical. + +
+ Group symbol $xx + Signature + + +4.29. Seek frame + + This frame indicates where other tags in a file/stream can be found. + The 'minimum offset to next tag' is calculated from the end of this + tag to the beginning of the next. There may only be one 'seek frame' + in a tag. + +
+ Minimum offset to next tag $xx xx xx xx + + +4.30. Audio seek point index + + Audio files with variable bit rates are intrinsically difficult to + deal with in the case of seeking within the file. The ASPI frame + makes seeking easier by providing a list a seek points within the + audio file. The seek points are a fractional offset within the audio + data, providing a starting point from which to find an appropriate + point to start decoding. The presence of an ASPI frame requires the + existence of a TLEN frame, indicating the duration of the file in + milliseconds. There may only be one 'audio seek point index' frame in + a tag. + +
+ Indexed data start (S) $xx xx xx xx + Indexed data length (L) $xx xx xx xx + Number of index points (N) $xx xx + Bits per index point (b) $xx + + Then for every index point the following data is included; + + Fraction at index (Fi) $xx (xx) + + 'Indexed data start' is a byte offset from the beginning of the file. + 'Indexed data length' is the byte length of the audio data being + indexed. 'Number of index points' is the number of index points, as + the name implies. The recommended number is 100. 'Bits per index + point' is 8 or 16, depending on the chosen precision. 8 bits works + well for short files (less than 5 minutes of audio), while 16 bits is + advantageous for long files. 'Fraction at index' is the numerator of + the fraction representing a relative position in the data. The + denominator is 2 to the power of b. + + Here are the algorithms to be used in the calculation. The known data + must be the offset of the start of the indexed data (S), the offset + of the end of the indexed data (E), the number of index points (N), + the offset at index i (Oi). We calculate the fraction at index i + (Fi). + + Oi is the offset of the frame whose start is soonest after the point + for which the time offset is (i/N * duration). + + The frame data should be calculated as follows: + + Fi = Oi/L * 2^b (rounded down to the nearest integer) + + Offset calculation should be calculated as follows from data in the + frame: + + Oi = (Fi/2^b)*L (rounded up to the nearest integer) + + +5. Copyright + + Copyright (C) Martin Nilsson 2000. All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that a reference to this document is included on all + such copies and derivative works. However, this document itself may + not be modified in any way and reissued as the original document. + + The limited permissions granted above are perpetual and will not be + revoked. + + This document and the information contained herein is provided on an + "AS IS" basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +6. References + + [CDDB] Compact Disc Data Base + + + + [ID3v2.3.0] Martin Nilsson, "ID3v2 informal standard". + + + + [ID3v2-strct] Martin Nilsson, + "ID3 tag version 2.4.0 - Main Structure" + + + + [ISO-639-2] ISO/FDIS 639-2. + Codes for the representation of names of languages, Part 2: Alpha-3 + code. Technical committee / subcommittee: TC 37 / SC 2 + + [ISO-4217] ISO 4217:1995. + Codes for the representation of currencies and funds. + Technical committee / subcommittee: TC 68 + + [ISO-8859-1] ISO/IEC DIS 8859-1. + 8-bit single-byte coded graphic character sets, Part 1: Latin + alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2 + + [ISRC] ISO 3901:1986 + International Standard Recording Code (ISRC). + Technical committee / subcommittee: TC 46 / SC 9 + + [JFIF] JPEG File Interchange Format, version 1.02 + + + + [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate + Requirement Levels', RFC 2119, March 1997. + + + + [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + + + [MPEG] ISO/IEC 11172-3:1993. + Coding of moving pictures and associated audio for digital storage + media at up to about 1,5 Mbit/s, Part 3: Audio. + Technical committee / subcommittee: JTC 1 / SC 29 + and + ISO/IEC 13818-3:1995 + Generic coding of moving pictures and associated audio information, + Part 3: Audio. + Technical committee / subcommittee: JTC 1 / SC 29 + and + ISO/IEC DIS 13818-3 + Generic coding of moving pictures and associated audio information, + Part 3: Audio (Revision of ISO/IEC 13818-3:1995) + + + [PNG] Portable Network Graphics, version 1.0 + + + + [URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource + Locators (URL).", RFC 1738, December 1994. + + + + [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB + Compressed + Data Format Specification version 3.3", RFC 1950, May 1996. + + + + +7. Appendix + + +A. Appendix A - Genre List from ID3v1 + + The following genres is defined in ID3v1 + + 0.Blues + 1.Classic Rock + 2.Country + 3.Dance + 4.Disco + 5.Funk + 6.Grunge + 7.Hip-Hop + 8.Jazz + 9.Metal + 10.New Age + 11.Oldies + 12.Other + 13.Pop + 14.R&B + 15.Rap + 16.Reggae + 17.Rock + 18.Techno + 19.Industrial + 20.Alternative + 21.Ska + 22.Death Metal + 23.Pranks + 24.Soundtrack + 25.Euro-Techno + 26.Ambient + 27.Trip-Hop + 28.Vocal + 29.Jazz+Funk + 30.Fusion + 31.Trance + 32.Classical + 33.Instrumental + 34.Acid + 35.House + 36.Game + 37.Sound Clip + 38.Gospel + 39.Noise + 40.AlternRock + 41.Bass + 42.Soul + 43.Punk + 44.Space + 45.Meditative + 46.Instrumental Pop + 47.Instrumental Rock + 48.Ethnic + 49.Gothic + 50.Darkwave + 51.Techno-Industrial + 52.Electronic + 53.Pop-Folk + 54.Eurodance + 55.Dream + 56.Southern Rock + 57.Comedy + 58.Cult + 59.Gangsta + 60.Top 40 + 61.Christian Rap + 62.Pop/Funk + 63.Jungle + 64.Native American + 65.Cabaret + 66.New Wave + 67.Psychadelic + 68.Rave + 69.Showtunes + 70.Trailer + 71.Lo-Fi + 72.Tribal + 73.Acid Punk + 74.Acid Jazz + 75.Polka + 76.Retro + 77.Musical + 78.Rock & Roll + 79.Hard Rock + + +8. Author's Address + + Written by + + Martin Nilsson + Rydsvägen 246 C. 30 + SE-584 34 Linköping + Sweden + + Email: nilsson@id3.org diff --git a/gst-libs/gst/tag/id3v2.4.0-structure.txt b/gst-libs/gst/tag/id3v2.4.0-structure.txt new file mode 100644 index 0000000000..5fa156a0ad --- /dev/null +++ b/gst-libs/gst/tag/id3v2.4.0-structure.txt @@ -0,0 +1,733 @@ + +Informal standard M. Nilsson +Document: id3v2.4.0-structure.txt 16 September 2001 + + + ID3 tag version 2.4.0 - Main Structure + +Status of this document + + This document is an informal standard and replaces the ID3v2.3.0 + standard [ID3v2]. A formal standard will use another revision number + even if the content is identical to document. The contents in this + document may change for clarifications but never for added or altered + functionallity. + + Distribution of this document is unlimited. + + +Abstract + + This document describes the main structure of ID3v2.4.0, which is a + revised version of the ID3v2 informal standard [ID3v2] version + 2.3.0. The ID3v2 offers a flexible way of storing audio meta + information within the audio file itself. The information may be + technical information, such as equalisation curves, as well as + title, performer, copyright etc. + + ID3v2.4.0 is meant to be as close as possible to ID3v2.3.0 in order + to allow for implementations to be revised as easily as possible. + + +1. Table of contents + + Status of this document + Abstract + 1. Table of contents + 2. Conventions in this document + 2. Standard overview + 3. ID3v2 overview + 3.1. ID3v2 header + 3.2. ID3v2 extended header + 3.3. Padding + 3.4. ID3v2 footer + 4. ID3v2 frames overview + 4.1. Frame header flags + 4.1.1. Frame status flags + 4.1.2. Frame format flags + 5. Tag location + 6. Unsynchronisation + 6.1. The unsynchronisation scheme + 6.2. Synchsafe integers + 7. Copyright + 8. References + 9. Author's Address + + +2. Conventions in this document + + Text within "" is a text string exactly as it appears in a tag. + Numbers preceded with $ are hexadecimal and numbers preceded with % + are binary. $xx is used to indicate a byte with unknown content. %x + is used to indicate a bit with unknown content. The most significant + bit (MSB) of a byte is called 'bit 7' and the least significant bit + (LSB) is called 'bit 0'. + + A tag is the whole tag described in this document. A frame is a block + of information in the tag. The tag consists of a header, frames and + optional padding. A field is a piece of information; one value, a + string etc. A numeric string is a string that consists of the + characters "0123456789" only. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [KEYWORDS]. + + +3. ID3v2 overview + + ID3v2 is a general tagging format for audio, which makes it possible + to store meta data about the audio inside the audio file itself. The + ID3 tag described in this document is mainly targeted at files + encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III + and MPEG-2.5, but may work with other types of encoded audio or as a + stand alone format for audio meta data. + + ID3v2 is designed to be as flexible and expandable as possible to + meet new meta information needs that might arise. To achieve that + ID3v2 is constructed as a container for several information blocks, + called frames, whose format need not be known to the software that + encounters them. At the start of every frame is an unique and + predefined identifier, a size descriptor that allows software to skip + unknown frames and a flags field. The flags describes encoding + details and if the frame should remain in the tag, should it be + unknown to the software, if the file is altered. + + The bitorder in ID3v2 is most significant bit first (MSB). The + byteorder in multibyte numbers is most significant byte first (e.g. + $12345678 would be encoded $12 34 56 78), also known as big endian + and network byte order. + + Overall tag structure: + + +-----------------------------+ + | Header (10 bytes) | + +-----------------------------+ + | Extended Header | + | (variable length, OPTIONAL) | + +-----------------------------+ + | Frames (variable length) | + +-----------------------------+ + | Padding | + | (variable length, OPTIONAL) | + +-----------------------------+ + | Footer (10 bytes, OPTIONAL) | + +-----------------------------+ + + In general, padding and footer are mutually exclusive. See details in + sections 3.3, 3.4 and 5. + + +3.1. ID3v2 header + + The first part of the ID3v2 tag is the 10 byte tag header, laid out + as follows: + + ID3v2/file identifier "ID3" + ID3v2 version $04 00 + ID3v2 flags %abcd0000 + ID3v2 size 4 * %0xxxxxxx + + The first three bytes of the tag are always "ID3", to indicate that + this is an ID3v2 tag, directly followed by the two version bytes. The + first byte of ID3v2 version is its major version, while the second + byte is its revision number. In this case this is ID3v2.4.0. All + revisions are backwards compatible while major versions are not. If + software with ID3v2.4.0 and below support should encounter version + five or higher it should simply ignore the whole tag. Version or + revision will never be $FF. + + The version is followed by the ID3v2 flags field, of which currently + four flags are used. + + + a - Unsynchronisation + + Bit 7 in the 'ID3v2 flags' indicates whether or not + unsynchronisation is applied on all frames (see section 6.1 for + details); a set bit indicates usage. + + + b - Extended header + + The second bit (bit 6) indicates whether or not the header is + followed by an extended header. The extended header is described in + section 3.2. A set bit indicates the presence of an extended + header. + + + c - Experimental indicator + + The third bit (bit 5) is used as an 'experimental indicator'. This + flag SHALL always be set when the tag is in an experimental stage. + + + d - Footer present + + Bit 4 indicates that a footer (section 3.4) is present at the very + end of the tag. A set bit indicates the presence of a footer. + + + All the other flags MUST be cleared. If one of these undefined flags + are set, the tag might not be readable for a parser that does not + know the flags function. + + The ID3v2 tag size is stored as a 32 bit synchsafe integer (section + 6.2), making a total of 28 effective bits (representing up to 256MB). + + The ID3v2 tag size is the sum of the byte length of the extended + header, the padding and the frames after unsynchronisation. If a + footer is present this equals to ('total size' - 20) bytes, otherwise + ('total size' - 10) bytes. + + An ID3v2 tag can be detected with the following pattern: + $49 44 33 yy yy xx zz zz zz zz + Where yy is less than $FF, xx is the 'flags' byte and zz is less than + $80. + + +3.2. Extended header + + The extended header contains information that can provide further + insight in the structure of the tag, but is not vital to the correct + parsing of the tag information; hence the extended header is + optional. + + Extended header size 4 * %0xxxxxxx + Number of flag bytes $01 + Extended Flags $xx + + Where the 'Extended header size' is the size of the whole extended + header, stored as a 32 bit synchsafe integer. An extended header can + thus never have a size of fewer than six bytes. + + The extended flags field, with its size described by 'number of flag + bytes', is defined as: + + %0bcd0000 + + Each flag that is set in the extended header has data attached, which + comes in the order in which the flags are encountered (i.e. the data + for flag 'b' comes before the data for flag 'c'). Unset flags cannot + have any attached data. All unknown flags MUST be unset and their + corresponding data removed when a tag is modified. + + Every set flag's data starts with a length byte, which contains a + value between 0 and 127 ($00 - $7f), followed by data that has the + field length indicated by the length byte. If a flag has no attached + data, the value $00 is used as length byte. + + + b - Tag is an update + + If this flag is set, the present tag is an update of a tag found + earlier in the present file or stream. If frames defined as unique + are found in the present tag, they are to override any + corresponding ones found in the earlier tag. This flag has no + corresponding data. + + Flag data length $00 + + c - CRC data present + + If this flag is set, a CRC-32 [ISO-3309] data is included in the + extended header. The CRC is calculated on all the data between the + header and footer as indicated by the header's tag length field, + minus the extended header. Note that this includes the padding (if + there is any), but excludes the footer. The CRC-32 is stored as an + 35 bit synchsafe integer, leaving the upper four bits always + zeroed. + + Flag data length $05 + Total frame CRC 5 * %0xxxxxxx + + d - Tag restrictions + + For some applications it might be desired to restrict a tag in more + ways than imposed by the ID3v2 specification. Note that the + presence of these restrictions does not affect how the tag is + decoded, merely how it was restricted before encoding. If this flag + is set the tag is restricted as follows: + + Flag data length $01 + Restrictions %ppqrrstt + + p - Tag size restrictions + + 00 No more than 128 frames and 1 MB total tag size. + 01 No more than 64 frames and 128 KB total tag size. + 10 No more than 32 frames and 40 KB total tag size. + 11 No more than 32 frames and 4 KB total tag size. + + q - Text encoding restrictions + + 0 No restrictions + 1 Strings are only encoded with ISO-8859-1 [ISO-8859-1] or + UTF-8 [UTF-8]. + + r - Text fields size restrictions + + 00 No restrictions + 01 No string is longer than 1024 characters. + 10 No string is longer than 128 characters. + 11 No string is longer than 30 characters. + + Note that nothing is said about how many bytes is used to + represent those characters, since it is encoding dependent. If a + text frame consists of more than one string, the sum of the + strungs is restricted as stated. + + s - Image encoding restrictions + + 0 No restrictions + 1 Images are encoded only with PNG [PNG] or JPEG [JFIF]. + + t - Image size restrictions + + 00 No restrictions + 01 All images are 256x256 pixels or smaller. + 10 All images are 64x64 pixels or smaller. + 11 All images are exactly 64x64 pixels, unless required + otherwise. + + +3.3. Padding + + It is OPTIONAL to include padding after the final frame (at the end + of the ID3 tag), making the size of all the frames together smaller + than the size given in the tag header. A possible purpose of this + padding is to allow for adding a few additional frames or enlarge + existing frames within the tag without having to rewrite the entire + file. The value of the padding bytes must be $00. A tag MUST NOT have + any padding between the frames or between the tag header and the + frames. Furthermore it MUST NOT have any padding when a tag footer is + added to the tag. + + +3.4. ID3v2 footer + + To speed up the process of locating an ID3v2 tag when searching from + the end of a file, a footer can be added to the tag. It is REQUIRED + to add a footer to an appended tag, i.e. a tag located after all + audio data. The footer is a copy of the header, but with a different + identifier. + + ID3v2 identifier "3DI" + ID3v2 version $04 00 + ID3v2 flags %abcd0000 + ID3v2 size 4 * %0xxxxxxx + + +4. ID3v2 frame overview + + All ID3v2 frames consists of one frame header followed by one or more + fields containing the actual information. The header is always 10 + bytes and laid out as follows: + + Frame ID $xx xx xx xx (four characters) + Size 4 * %0xxxxxxx + Flags $xx xx + + The frame ID is made out of the characters capital A-Z and 0-9. + Identifiers beginning with "X", "Y" and "Z" are for experimental + frames and free for everyone to use, without the need to set the + experimental bit in the tag header. Bear in mind that someone else + might have used the same identifier as you. All other identifiers are + either used or reserved for future use. + + The frame ID is followed by a size descriptor containing the size of + the data in the final frame, after encryption, compression and + unsynchronisation. The size is excluding the frame header ('total + frame size' - 10 bytes) and stored as a 32 bit synchsafe integer. + + In the frame header the size descriptor is followed by two flag + bytes. These flags are described in section 4.1. + + There is no fixed order of the frames' appearance in the tag, + although it is desired that the frames are arranged in order of + significance concerning the recognition of the file. An example of + such order: UFID, TIT2, MCDI, TRCK ... + + A tag MUST contain at least one frame. A frame must be at least 1 + byte big, excluding the header. + + If nothing else is said, strings, including numeric strings and URLs + [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the + range $20 - $FF. Such strings are represented in frame descriptions + as , or if newlines are allowed. If + nothing else is said newline character is forbidden. In ISO-8859-1 a + newline is represented, when allowed, with $0A only. + + Frames that allow different types of text encoding contains a text + encoding description byte. Possible encodings: + + $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. + $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All + strings in the same frame SHALL have the same byteorder. + Terminated with $00 00. + $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. + Terminated with $00 00. + $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. + + Strings dependent on encoding are represented in frame descriptions + as , or if newlines are allowed. Any empty strings of + type $01 which are NULL-terminated may have the Unicode BOM followed + by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00). + + The timestamp fields are based on a subset of ISO 8601. When being as + precise as possible the format of a time string is + yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of + 24), ":", minutes, ":", seconds), but the precision may be reduced by + removing as many time indicators as wanted. Hence valid timestamps + are + yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and + yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use + the slash character as described in 8601, and for multiple non- + contiguous dates, use multiple strings, if allowed by the frame + definition. + + The three byte language field, present in several frames, is used to + describe the language of the frame's content, according to ISO-639-2 + [ISO-639-2]. The language should be represented in lower case. If the + language is not known the string "XXX" should be used. + + All URLs [URL] MAY be relative, e.g. "picture.png", "../doc.txt". + + If a frame is longer than it should be, e.g. having more fields than + specified in this document, that indicates that additions to the + frame have been made in a later version of the ID3v2 standard. This + is reflected by the revision number in the header of the tag. + + +4.1. Frame header flags + + In the frame header the size descriptor is followed by two flag + bytes. All unused flags MUST be cleared. The first byte is for + 'status messages' and the second byte is a format description. If an + unknown flag is set in the first byte the frame MUST NOT be changed + without that bit cleared. If an unknown flag is set in the second + byte the frame is likely to not be readable. Some flags in the second + byte indicates that extra information is added to the header. These + fields of extra information is ordered as the flags that indicates + them. The flags field is defined as follows (l and o left out because + ther resemblence to one and zero): + + %0abc0000 %0h00kmnp + + Some frame format flags indicate that additional information fields + are added to the frame. This information is added after the frame + header and before the frame data in the same order as the flags that + indicates them. I.e. the four bytes of decompressed size will precede + the encryption method byte. These additions affects the 'frame size' + field, but are not subject to encryption or compression. + + The default status flags setting for a frame is, unless stated + otherwise, 'preserved if tag is altered' and 'preserved if file is + altered', i.e. %00000000. + + +4.1.1. Frame status flags + + a - Tag alter preservation + + This flag tells the tag parser what to do with this frame if it is + unknown and the tag is altered in any way. This applies to all + kinds of alterations, including adding more padding and reordering + the frames. + + 0 Frame should be preserved. + 1 Frame should be discarded. + + + b - File alter preservation + + This flag tells the tag parser what to do with this frame if it is + unknown and the file, excluding the tag, is altered. This does not + apply when the audio is completely replaced with other audio data. + + 0 Frame should be preserved. + 1 Frame should be discarded. + + + c - Read only + + This flag, if set, tells the software that the contents of this + frame are intended to be read only. Changing the contents might + break something, e.g. a signature. If the contents are changed, + without knowledge of why the frame was flagged read only and + without taking the proper means to compensate, e.g. recalculating + the signature, the bit MUST be cleared. + + +4.1.2. Frame format flags + + h - Grouping identity + + This flag indicates whether or not this frame belongs in a group + with other frames. If set, a group identifier byte is added to the + frame. Every frame with the same group identifier belongs to the + same group. + + 0 Frame does not contain group information + 1 Frame contains group information + + + k - Compression + + This flag indicates whether or not the frame is compressed. + A 'Data Length Indicator' byte MUST be included in the frame. + + 0 Frame is not compressed. + 1 Frame is compressed using zlib [zlib] deflate method. + If set, this requires the 'Data Length Indicator' bit + to be set as well. + + + m - Encryption + + This flag indicates whether or not the frame is encrypted. If set, + one byte indicating with which method it was encrypted will be + added to the frame. See description of the ENCR frame for more + information about encryption method registration. Encryption + should be done after compression. Whether or not setting this flag + requires the presence of a 'Data Length Indicator' depends on the + specific algorithm used. + + 0 Frame is not encrypted. + 1 Frame is encrypted. + + n - Unsynchronisation + + This flag indicates whether or not unsynchronisation was applied + to this frame. See section 6 for details on unsynchronisation. + If this flag is set all data from the end of this header to the + end of this frame has been unsynchronised. Although desirable, the + presence of a 'Data Length Indicator' is not made mandatory by + unsynchronisation. + + 0 Frame has not been unsynchronised. + 1 Frame has been unsyrchronised. + + p - Data length indicator + + This flag indicates that a data length indicator has been added to + the frame. The data length indicator is the value one would write + as the 'Frame length' if all of the frame format flags were + zeroed, represented as a 32 bit synchsafe integer. + + 0 There is no Data Length Indicator. + 1 A data length Indicator has been added to the frame. + + +5. Tag location + + The default location of an ID3v2 tag is prepended to the audio so + that players can benefit from the information when the data is + streamed. It is however possible to append the tag, or make a + prepend/append combination. When deciding upon where an unembedded + tag should be located, the following order of preference SHOULD be + considered. + + 1. Prepend the tag. + + 2. Prepend a tag with all vital information and add a second tag at + the end of the file, before tags from other tagging systems. The + first tag is required to have a SEEK frame. + + 3. Add a tag at the end of the file, before tags from other tagging + systems. + + In case 2 and 3 the tag can simply be appended if no other known tags + are present. The suggested method to find ID3v2 tags are: + + 1. Look for a prepended tag using the pattern found in section 3.1. + + 2. If a SEEK frame was found, use its values to guide further + searching. + + 3. Look for a tag footer, scanning from the back of the file. + + For every new tag that is found, the old tag should be discarded + unless the update flag in the extended header (section 3.2) is set. + + +6. Unsynchronisation + + The only purpose of unsynchronisation is to make the ID3v2 tag as + compatible as possible with existing software and hardware. There is + no use in 'unsynchronising' tags if the file is only to be processed + only by ID3v2 aware software and hardware. Unsynchronisation is only + useful with tags in MPEG 1/2 layer I, II and III, MPEG 2.5 and AAC + files. + + +6.1. The unsynchronisation scheme + + Whenever a false synchronisation is found within the tag, one zeroed + byte is inserted after the first false synchronisation byte. The + format of synchronisations that should be altered by ID3 encoders is + as follows: + + %11111111 111xxxxx + + and should be replaced with: + + %11111111 00000000 111xxxxx + + This has the side effect that all $FF 00 combinations have to be + altered, so they will not be affected by the decoding process. + Therefore all the $FF 00 combinations have to be replaced with the + $FF 00 00 combination during the unsynchronisation. + + To indicate usage of the unsynchronisation, the unsynchronisation + flag in the frame header should be set. This bit MUST be set if the + frame was altered by the unsynchronisation and SHOULD NOT be set if + unaltered. If all frames in the tag are unsynchronised the + unsynchronisation flag in the tag header SHOULD be set. It MUST NOT + be set if the tag has a frame which is not unsynchronised. + + Assume the first byte of the audio to be $FF. The special case when + the last byte of the last frame is $FF and no padding nor footer is + used will then introduce a false synchronisation. This can be solved + by adding a footer, adding padding or unsynchronising the frame and + add $00 to the end of the frame data, thus adding more byte to the + frame size than a normal unsynchronisation would. Although not + preferred, it is allowed to apply the last method on all frames + ending with $FF. + + It is preferred that the tag is either completely unsynchronised or + not unsynchronised at all. A completely unsynchronised tag has no + false synchonisations in it, as defined above, and does not end with + $FF. A completely non-unsynchronised tag contains no unsynchronised + frames, and thus the unsynchronisation flag in the header is cleared. + + Do bear in mind, that if compression or encryption is used, the + unsynchronisation scheme MUST be applied afterwards. When decoding an + unsynchronised frame, the unsynchronisation scheme MUST be reversed + first, encryption and decompression afterwards. + + +6.2. Synchsafe integers + + In some parts of the tag it is inconvenient to use the + unsychronisation scheme because the size of unsynchronised data is + not known in advance, which is particularly problematic with size + descriptors. The solution in ID3v2 is to use synchsafe integers, in + which there can never be any false synchs. Synchsafe integers are + integers that keep its highest bit (bit 7) zeroed, making seven bits + out of eight available. Thus a 32 bit synchsafe integer can store 28 + bits of information. + + Example: + + 255 (%11111111) encoded as a 16 bit synchsafe integer is 383 + (%00000001 01111111). + + +7. Copyright + + Copyright (C) Martin Nilsson 2000. All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that a reference to this document is included on all + such copies and derivative works. However, this document itself may + not be modified in any way and reissued as the original document. + + The limited permissions granted above are perpetual and will not be + revoked. + + This document and the information contained herein is provided on an + 'AS IS' basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +8. References + + [ID3v2] Martin Nilsson, 'ID3v2 informal standard'. + + + + [ISO-639-2] ISO/FDIS 639-2. + 'Codes for the representation of names of languages, Part 2: Alpha-3 + code.' Technical committee / subcommittee: TC 37 / SC 2 + + [ISO-3309] ISO 3309 + 'Information Processing Systems--Data Communication High-Level Data + Link Control Procedure--Frame Structure', IS 3309, October 1984, 3rd + Edition. + + [ISO-8859-1] ISO/IEC DIS 8859-1. + '8-bit single-byte coded graphic character sets, Part 1: Latin + alphabet No. 1.' Technical committee / subcommittee: JTC 1 / SC 2 + + [JFIF] 'JPEG File Interchange Format, version 1.02' + + + + [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate + Requirement Levels', RFC 2119, March 1997. + + + + [MPEG] ISO/IEC 11172-3:1993. + 'Coding of moving pictures and associated audio for digital storage + media at up to about 1,5 Mbit/s, Part 3: Audio.' + Technical committee / subcommittee: JTC 1 / SC 29 + and + ISO/IEC 13818-3:1995 + 'Generic coding of moving pictures and associated audio information, + Part 3: Audio.' + Technical committee / subcommittee: JTC 1 / SC 29 + and + ISO/IEC DIS 13818-3 + 'Generic coding of moving pictures and associated audio information, + Part 3: Audio (Revision of ISO/IEC 13818-3:1995)' + + [PNG] 'Portable Network Graphics, version 1.0' + + + + [UNICODE] The Unicode Consortium, + 'The Unicode Standard Version 3.0', ISBN 0-201-61633-5. + + + + [URL] T. Berners-Lee, L. Masinter & M. McCahill, 'Uniform Resource + Locators (URL)', RFC 1738, December 1994. + + + + [UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646', + RFC 2279, January 1998. + + + + [UTF-16] F. Yergeau, 'UTF-16, an encoding of ISO 10646', RFC 2781, + February 2000. + + + + [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, 'ZLIB + Compressed Data Format Specification version 3.3', RFC 1950, + May 1996. + + + + +9. Author's Address + + Written by + + Martin Nilsson + Rydsvägen 246 C. 30 + SE-584 34 Linköping + Sweden + + Email: nilsson@id3.org +