diff options
Diffstat (limited to 'libs/taglib/taglib/mpeg/id3v2/id3v2.2.0.txt')
| -rw-r--r-- | libs/taglib/taglib/mpeg/id3v2/id3v2.2.0.txt | 1660 |
1 files changed, 0 insertions, 1660 deletions
diff --git a/libs/taglib/taglib/mpeg/id3v2/id3v2.2.0.txt b/libs/taglib/taglib/mpeg/id3v2/id3v2.2.0.txt deleted file mode 100644 index a69bddd32a..0000000000 --- a/libs/taglib/taglib/mpeg/id3v2/id3v2.2.0.txt +++ /dev/null @@ -1,1660 +0,0 @@ - -Informal standard M. Nilsson -Document: id3v2-00.txt 26th March 1998 - - - ID3 tag version 2 - -Status of this document - - This document is an Informal standard and is released so that - implementors could have a set standard before the formal standard is - set. The formal standard will use another version number if not - identical to what is described in this document. The contents in this - document may change for clarifications but never for added or altered - functionallity. - - Distribution of this document is unlimited. - - -Abstract - - The recent gain of popularity for MPEG layer III audio files on the - internet forced a standardised way of storing information about an - audio file within itself to determinate its origin and contents. - - Today the most accepted way to do this is with the so called ID3 tag, - which is simple but very limited and in some cases very unsuitable. - The ID3 tag has very limited space in every field, very limited - numbers of fields, not expandable or upgradeable and is placed at the - end of a the file, which is unsuitable for streaming audio. This draft - is an attempt to answer these issues with a new version of the ID3 - tag. - - -1. Table of contents - - 2. Conventions in this document - 3. ID3v2 overview - 3.1. ID3v2 header - 3.2. ID3v2 frames overview - 4. Declared ID3v2 frames - 4.1. Unique file identifier - 4.2. Text information frames - 4.2.1. Text information frames - details - 4.2.2. User defined text information frame - 4.3. URL link frames - 4.3.1. URL link frames - details - 4.3.2. User defined URL link frame - 4.4. Involved people list - 4.5. Music CD Identifier - 4.6. Event timing codes - 4.7. MPEG location lookup table - 4.8. Synced tempo codes - 4.9. Unsychronised lyrics/text transcription - 4.10. Synchronised lyrics/text - 4.11. Comments - 4.12. Relative volume adjustment - 4.13. Equalisation - 4.14. Reverb - 4.15. Attached picture - 4.16. General encapsulated object - 4.17. Play counter - 4.18. Popularimeter - 4.19. Recommended buffer size - 4.20. Encrypted meta frame - 4.21. Audio encryption - 4.22. Linked information - 5. The 'unsynchronisation scheme' - 6. Copyright - 7. References - 8. Appendix - A. Appendix A - ID3-Tag Specification V1.1 - A.1. Overview - A.2. ID3v1 Implementation - A.3. Genre List - A.4. Track addition - ID3v1.1 - 9. Author's Address - - -2. Conventions in this document - - In the examples, text within "" is a text string exactly as it appears - in a file. Numbers preceded with $ are hexadecimal and numbers - preceded with % are binary. $xx is used to indicate a byte with - unknown content. %x is used to indicate a bit with unknown content. - The most significant bit (MSB) of a byte is called 'bit 7' and the - least significant bit (LSB) is called 'bit 0'. - - A tag is the whole tag described in this document. A frame is a block - of information in the tag. The tag consists of a header, frames and - optional padding. A field is a piece of information; one value, a - string etc. A numeric string is a string that consists of the - characters 0-9 only. - - -3. ID3v2 overview - - The two biggest design goals were to be able to implement ID3v2 - without disturbing old software too much and that ID3v2 should be - expandable. - - The first criterion is met by the simple fact that the MPEG [MPEG] - decoding software uses a syncsignal, embedded in the audiostream, to - 'lock on to' the audio. Since the ID3v2 tag doesn't contain a valid - syncsignal, no software will attempt to play the tag. If, for any - reason, coincidence make a syncsignal appear within the tag it will be - taken care of by the 'unsynchronisation scheme' described in section - 5. - - The second criterion has made a more noticeable impact on the design - of the ID3v2 tag. It is constructed as a container for several - information blocks, called frames, whose format need not be known to - the software that encounters them. At the start of every frame there - is an identifier that explains the frames's format and content, and a - size descriptor that allows software to skip unknown frames. - - If a total revision of the ID3v2 tag should be needed, there is a - version number and a size descriptor in the ID3v2 header. - - The ID3 tag described in this document is mainly targeted to files - encoded with MPEG-2 layer I, MPEG-2 layer II, MPEG-2 layer III and - MPEG-2.5, but may work with other types of encoded audio. - - The bitorder in ID3v2 is most significant bit first (MSB). The - byteorder in multibyte numbers is most significant byte first (e.g. - $12345678 would be encoded $12 34 56 78). - - It is permitted to include padding after all the final frame (at the - end of the ID3 tag), making the size of all the frames together - smaller than the size given in the head of the tag. A possible purpose - of this padding is to allow for adding a few additional frames or - enlarge existing frames within the tag without having to rewrite the - entire file. The value of the padding bytes must be $00. - - -3.1. ID3v2 header - - The ID3v2 tag header, which should be the first information in the - file, is 10 bytes as follows: - - ID3/file identifier "ID3" - ID3 version $02 00 - ID3 flags %xx000000 - ID3 size 4 * %0xxxxxxx - - The first three bytes of the tag are always "ID3" to indicate that - this is an ID3 tag, directly followed by the two version bytes. The - first byte of ID3 version is it's major version, while the second byte - is its revision number. All revisions are backwards compatible while - major versions are not. If software with ID3v2 and below support - should encounter version three or higher it should simply ignore the - whole tag. Version and revision will never be $FF. - - The first bit (bit 7) in the 'ID3 flags' is indicating whether or not - unsynchronisation is used (see section 5 for details); a set bit - indicates usage. - - The second bit (bit 6) is indicating whether or not compression is - used; a set bit indicates usage. Since no compression scheme has been - decided yet, the ID3 decoder (for now) should just ignore the entire - tag if the compression bit is set. - - The ID3 tag size is encoded with four bytes where the first bit (bit - 7) is set to zero in every byte, making a total of 28 bits. The zeroed - bits are ignored, so a 257 bytes long tag is represented as $00 00 02 - 01. - - The ID3 tag size is the size of the complete tag after - unsychronisation, including padding, excluding the header (total tag - size - 10). The reason to use 28 bits (representing up to 256MB) for - size description is that we don't want to run out of space here. - - A ID3v2 tag can be detected with the following pattern: - $49 44 33 yy yy xx zz zz zz zz - Where yy is less than $FF, xx is the 'flags' byte and zz is less than - $80. - - -3.2. ID3v2 frames overview - - The headers of the frames are similar in their construction. They - consist of one three character identifier (capital A-Z and 0-9) and - one three byte size field, making a total of six bytes. The header is - excluded from the size. Identifiers beginning with "X", "Y" and "Z" - are for experimental use and free for everyone to use. Have in mind - that someone else might have used the same identifier as you. All - other identifiers are either used or reserved for future use. - - The three character frame identifier is followed by a three byte size - descriptor, making a total header size of six bytes in every frame. - The size is calculated as framesize excluding frame identifier and - size descriptor (frame size - 6). - - There is no fixed order of the frames' appearance in the tag, although - it is desired that the frames are arranged in order of significance - concerning the recognition of the file. An example of such order: - UFI, MCI, TT2 ... - - A tag must contain at least one frame. A frame must be at least 1 byte - big, excluding the 6-byte header. - - If nothing else is said a string is represented as ISO-8859-1 - [ISO-8859-1] characters in the range $20 - $FF. All unicode strings - [UNICODE] use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). All - numeric strings are always encoded as ISO-8859-1. Terminated strings - are terminated with $00 if encoded with ISO-8859-1 and $00 00 if - encoded as unicode. If nothing else is said newline character is - forbidden. In ISO-8859-1 a new line is represented, when allowed, with - $0A only. Frames that allow different types of text encoding have a - text encoding description byte directly after the frame size. If - ISO-8859-1 is used this byte should be $00, if unicode is used it - should be $01. - - The three byte language field is used to describe the language of the - frame's content, according to ISO-639-2 [ISO-639-2]. - - All URLs [URL] may be relative, e.g. "picture.png", "../doc.txt". - - If a frame is longer than it should be, e.g. having more fields than - specified in this document, that indicates that additions to the - frame have been made in a later version of the ID3 standard. This - is reflected by the revision number in the header of the tag. - - -4. Declared ID3v2 frames - - The following frames are declared in this draft. - - 4.19 BUF Recommended buffer size - - 4.17 CNT Play counter - 4.11 COM Comments - 4.21 CRA Audio encryption - 4.20 CRM Encrypted meta frame - - 4.6 ETC Event timing codes - 4.13 EQU Equalization - - 4.16 GEO General encapsulated object - - 4.4 IPL Involved people list - - 4.22 LNK Linked information - - 4.5 MCI Music CD Identifier - 4.7 MLL MPEG location lookup table - - 4.15 PIC Attached picture - 4.18 POP Popularimeter - - 4.14 REV Reverb - 4.12 RVA Relative volume adjustment - - 4.10 SLT Synchronized lyric/text - 4.8 STC Synced tempo codes - - 4.2.1 TAL Album/Movie/Show title - 4.2.1 TBP BPM (Beats Per Minute) - 4.2.1 TCM Composer - 4.2.1 TCO Content type - 4.2.1 TCR Copyright message - 4.2.1 TDA Date - 4.2.1 TDY Playlist delay - 4.2.1 TEN Encoded by - 4.2.1 TFT File type - 4.2.1 TIM Time - 4.2.1 TKE Initial key - 4.2.1 TLA Language(s) - 4.2.1 TLE Length - 4.2.1 TMT Media type - 4.2.1 TOA Original artist(s)/performer(s) - 4.2.1 TOF Original filename - 4.2.1 TOL Original Lyricist(s)/text writer(s) - 4.2.1 TOR Original release year - 4.2.1 TOT Original album/Movie/Show title - 4.2.1 TP1 Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group - 4.2.1 TP2 Band/Orchestra/Accompaniment - 4.2.1 TP3 Conductor/Performer refinement - 4.2.1 TP4 Interpreted, remixed, or otherwise modified by - 4.2.1 TPA Part of a set - 4.2.1 TPB Publisher - 4.2.1 TRC ISRC (International Standard Recording Code) - 4.2.1 TRD Recording dates - 4.2.1 TRK Track number/Position in set - 4.2.1 TSI Size - 4.2.1 TSS Software/hardware and settings used for encoding - 4.2.1 TT1 Content group description - 4.2.1 TT2 Title/Songname/Content description - 4.2.1 TT3 Subtitle/Description refinement - 4.2.1 TXT Lyricist/text writer - 4.2.2 TXX User defined text information frame - 4.2.1 TYE Year - - 4.1 UFI Unique file identifier - 4.9 ULT Unsychronized lyric/text transcription - - 4.3.1 WAF Official audio file webpage - 4.3.1 WAR Official artist/performer webpage - 4.3.1 WAS Official audio source webpage - 4.3.1 WCM Commercial information - 4.3.1 WCP Copyright/Legal information - 4.3.1 WPB Publishers official webpage - 4.3.2 WXX User defined URL link frame - - -4.1. Unique file identifier - - This frame's purpose is to be able to identify the audio file in a - database that may contain more information relevant to the content. - Since standardisation of such a database is beyond this document, all - frames begin with a null-terminated string with a URL [URL] containing - an email address, or a link to a location where an email address can - be found, that belongs to the organisation responsible for this - specific database implementation. Questions regarding the database - should be sent to the indicated email address. The URL should not be - used for the actual database queries. If a $00 is found directly after - the 'Frame size' the whole frame should be ignored, and preferably be - removed. The 'Owner identifier' is then followed by the actual - identifier, which may be up to 64 bytes. There may be more than one - "UFI" frame in a tag, but only one with the same 'Owner identifier'. - - Unique file identifier "UFI" - Frame size $xx xx xx - Owner identifier <textstring> $00 - Identifier <up to 64 bytes binary data> - - -4.2. Text information frames - - The text information frames are the most important frames, containing - information like artist, album and more. There may only be one text - information frame of its kind in an tag. If the textstring is followed - by a termination ($00 (00)) all the following information should be - ignored and not be displayed. All the text information frames have the - following format: - - Text information identifier "T00" - "TZZ" , excluding "TXX", - described in 4.2.2. - Frame size $xx xx xx - Text encoding $xx - Information <textstring> - - -4.2.1. Text information frames - details - - TT1 - The 'Content group description' frame is used if the sound belongs to - a larger category of sounds/music. For example, classical music is - often sorted in different musical sections (e.g. "Piano Concerto", - "Weather - Hurricane"). - - TT2 - The 'Title/Songname/Content description' frame is the actual name of - the piece (e.g. "Adagio", "Hurricane Donna"). - - TT3 - The 'Subtitle/Description refinement' frame is used for information - directly related to the contents title (e.g. "Op. 16" or "Performed - live at wembley"). - - TP1 - The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is - used for the main artist(s). They are seperated with the "/" - character. - - TP2 - The 'Band/Orchestra/Accompaniment' frame is used for additional - information about the performers in the recording. - - TP3 - The 'Conductor' frame is used for the name of the conductor. - - TP4 - The 'Interpreted, remixed, or otherwise modified by' frame contains - more information about the people behind a remix and similar - interpretations of another existing piece. - - TCM - The 'Composer(s)' frame is intended for the name of the composer(s). - They are seperated with the "/" character. - - TXT - The 'Lyricist(s)/text writer(s)' frame is intended for the writer(s) - of the text or lyrics in the recording. They are seperated with the - "/" character. - - TLA - The 'Language(s)' frame should contain the languages of the text or - lyrics in the audio file. The language is represented with three - characters according to ISO-639-2. If more than one language is used - in the text their language codes should follow according to their - usage. - - TCO - The content type, which previously (in ID3v1.1, see appendix A) was - stored as a one byte numeric value only, is now a numeric string. You - may use one or several of the types as ID3v1.1 did or, since the - category list would be impossible to maintain with accurate and up to - date categories, define your own. - References to the ID3v1 genres can be made by, as first byte, enter - "(" followed by a number from the genres list (section A.3.) and - ended with a ")" character. This is optionally followed by a - refinement, e.g. "(21)" or "(4)Eurodisco". Several references can be - made in the same frame, e.g. "(51)(39)". If the refinement should - begin with a "(" character it should be replaced with "((", e.g. "((I - can figure out any genre)" or "(55)((I think...)". The following new - content types is defined in ID3v2 and is implemented in the same way - as the numerig content types, e.g. "(RX)". - - RX Remix - CR Cover - - TAL - The 'Album/Movie/Show title' frame is intended for the title of the - recording(/source of sound) which the audio in the file is taken from. - - TPA - The 'Part of a set' frame is a numeric string that describes which - part of a set the audio came from. This frame is used if the source - described in the "TAL" frame is divided into several mediums, e.g. a - double CD. The value may be extended with a "/" character and a - numeric string containing the total number of parts in the set. E.g. - "1/2". - - TRK - The 'Track number/Position in set' frame is a numeric string - containing the order number of the audio-file on its original - recording. This may be extended with a "/" character and a numeric - string containing the total numer of tracks/elements on the original - recording. E.g. "4/9". - - TRC - The 'ISRC' frame should contian the International Standard Recording - Code [ISRC]. - - TYE - The 'Year' frame is a numeric string with a year of the recording. - This frames is always four characters long (until the year 10000). - - TDA - The 'Date' frame is a numeric string in the DDMM format containing - the date for the recording. This field is always four characters - long. - - TIM - The 'Time' frame is a numeric string in the HHMM format containing - the time for the recording. This field is always four characters - long. - - TRD - The 'Recording dates' frame is a intended to be used as complement to - the "TYE", "TDA" and "TIM" frames. E.g. "4th-7th June, 12th June" in - combination with the "TYE" frame. - - TMT - The 'Media type' frame describes from which media the sound - originated. This may be a textstring or a reference to the predefined - media types found in the list below. References are made within "(" - and ")" and are optionally followed by a text refinement, e.g. "(MC) - with four channels". If a text refinement should begin with a "(" - character it should be replaced with "((" in the same way as in the - "TCO" frame. Predefined refinements is appended after the media type, - e.g. "(CD/S)" or "(VID/PAL/VHS)". - - DIG Other digital media - /A Analog transfer from media - - ANA Other analog media - /WAC Wax cylinder - /8CA 8-track tape cassette - - CD CD - /A Analog transfer from media - /DD DDD - /AD ADD - /AA AAD - - LD Laserdisc - /A Analog transfer from media - - TT Turntable records - /33 33.33 rpm - /45 45 rpm - /71 71.29 rpm - /76 76.59 rpm - /78 78.26 rpm - /80 80 rpm - - MD MiniDisc - /A Analog transfer from media - - DAT DAT - /A Analog transfer from media - /1 standard, 48 kHz/16 bits, linear - /2 mode 2, 32 kHz/16 bits, linear - /3 mode 3, 32 kHz/12 bits, nonlinear, low speed - /4 mode 4, 32 kHz/12 bits, 4 channels - /5 mode 5, 44.1 kHz/16 bits, linear - /6 mode 6, 44.1 kHz/16 bits, 'wide track' play - - DCC DCC - /A Analog transfer from media - - DVD DVD - /A Analog transfer from media - - TV Television - /PAL PAL - /NTSC NTSC - /SECAM SECAM - - VID Video - /PAL PAL - /NTSC NTSC - /SECAM SECAM - /VHS VHS - /SVHS S-VHS - /BETA BETAMAX - - RAD Radio - /FM FM - /AM AM - /LW LW - /MW MW - - TEL Telephone - /I ISDN - - MC MC (normal cassette) - /4 4.75 cm/s (normal speed for a two sided cassette) - /9 9.5 cm/s - /I Type I cassette (ferric/normal) - /II Type II cassette (chrome) - /III Type III cassette (ferric chrome) - /IV Type IV cassette (metal) - - REE Reel - /9 9.5 cm/s - /19 19 cm/s - /38 38 cm/s - /76 76 cm/s - /I Type I cassette (ferric/normal) - /II Type II cassette (chrome) - /III Type III cassette (ferric chrome) - /IV Type IV cassette (metal) - - TFT - The 'File type' frame indicates which type of audio this tag defines. - The following type and refinements are defined: - - MPG MPEG Audio - /1 MPEG 2 layer I - /2 MPEG 2 layer II - /3 MPEG 2 layer III - /2.5 MPEG 2.5 - /AAC Advanced audio compression - - but other types may be used, not for these types though. This is used - in a similar way to the predefined types in the "TMT" frame, but - without parenthesis. If this frame is not present audio type is - assumed to be "MPG". - - TBP - BPM is short for beats per minute, and is easily computed by - dividing the number of beats in a musical piece with its length. To - get a more accurate result, do the BPM calculation on the main-part - only. To acquire best result measure the time between each beat and - calculate individual BPM for each beat and use the median value as - result. BPM is an integer and represented as a numerical string. - - TCR - The 'Copyright message' frame, which must begin with a year and a - space character (making five characters), is intended for the - copyright holder of the original sound, not the audio file itself. The - absence of this frame means only that the copyright information is - unavailable or has been removed, and must not be interpreted to mean - that the sound is public domain. Every time this field is displayed - the field must be preceded with "Copyright " (C) " ", where (C) is one - character showing a C in a circle. - - TPB - The 'Publisher' frame simply contains the name of the label or - publisher. - - TEN - The 'Encoded by' frame contains the name of the person or - organisation that encoded the audio file. This field may contain a - copyright message, if the audio file also is copyrighted by the - encoder. - - TSS - The 'Software/hardware and settings used for encoding' frame - includes the used audio encoder and its settings when the file was - encoded. Hardware refers to hardware encoders, not the computer on - which a program was run. - - TOF - The 'Original filename' frame contains the preferred filename for the - file, since some media doesn't allow the desired length of the - filename. The filename is case sensitive and includes its suffix. - - TLE - The 'Length' frame contains the length of the audiofile in - milliseconds, represented as a numeric string. - - TSI - The 'Size' frame contains the size of the audiofile in bytes - excluding the tag, represented as a numeric string. - - TDY - The 'Playlist delay' defines the numbers of milliseconds of silence - between every song in a playlist. The player should use the "ETC" - frame, if present, to skip initial silence and silence at the end of - the audio to match the 'Playlist delay' time. The time is represented - as a numeric string. - - TKE - The 'Initial key' frame contains the musical key in which the sound - starts. It is represented as a string with a maximum length of three - characters. The ground keys are represented with "A","B","C","D","E", - "F" and "G" and halfkeys represented with "b" and "#". Minor is - represented as "m". Example "Cbm". Off key is represented with an "o" - only. - - TOT - The 'Original album/Movie/Show title' frame is intended for the title - of the original recording(/source of sound), if for example the music - in the file should be a cover of a previously released song. - - TOA - The 'Original artist(s)/performer(s)' frame is intended for the - performer(s) of the original recording, if for example the music in - the file should be a cover of a previously released song. The - performers are seperated with the "/" character. - - TOL - The 'Original Lyricist(s)/text writer(s)' frame is intended for the - text writer(s) of the original recording, if for example the music in - the file should be a cover of a previously released song. The text - writers are seperated with the "/" character. - - TOR - The 'Original release year' frame is intended for the year when the - original recording, if for example the music in the file should be a - cover of a previously released song, was released. The field is - formatted as in the "TDY" frame. - - -4.2.2. User defined text information frame - - This frame is intended for one-string text information concerning the - audiofile in a similar way to the other "T"xx frames. The frame body - consists of a description of the string, represented as a terminated - string, followed by the actual string. There may be more than one - "TXX" frame in each tag, but only one with the same description. - - User defined... "TXX" - Frame size $xx xx xx - Text encoding $xx - Description <textstring> $00 (00) - Value <textstring> - - -4.3. URL link frames - - With these frames dynamic data such as webpages with touring - information, price information or plain ordinary news can be added to - the tag. There may only be one URL [URL] link frame of its kind in an - tag, except when stated otherwise in the frame description. If the - textstring is followed by a termination ($00 (00)) all the following - information should be ignored and not be displayed. All URL link - frames have the following format: - - URL link frame "W00" - "WZZ" , excluding "WXX" - (described in 4.3.2.) - Frame size $xx xx xx - URL <textstring> - - -4.3.1. URL link frames - details - - WAF - The 'Official audio file webpage' frame is a URL pointing at a file - specific webpage. - - WAR - The 'Official artist/performer webpage' frame is a URL pointing at - the artists official webpage. There may be more than one "WAR" frame - in a tag if the audio contains more than one performer. - - WAS - The 'Official audio source webpage' frame is a URL pointing at the - official webpage for the source of the audio file, e.g. a movie. - - WCM - The 'Commercial information' frame is a URL pointing at a webpage - with information such as where the album can be bought. There may be - more than one "WCM" frame in a tag. - - WCP - The 'Copyright/Legal information' frame is a URL pointing at a - webpage where the terms of use and ownership of the file is described. - - WPB - The 'Publishers official webpage' frame is a URL pointing at the - official wepage for the publisher. - - -4.3.2. User defined URL link frame - - This frame is intended for URL [URL] links concerning the audiofile in - a similar way to the other "W"xx frames. The frame body consists of a - description of the string, represented as a terminated string, - followed by the actual URL. The URL is always encoded with ISO-8859-1 - [ISO-8859-1]. There may be more than one "WXX" frame in each tag, but - only one with the same description. - - User defined... "WXX" - Frame size $xx xx xx - Text encoding $xx - Description <textstring> $00 (00) - URL <textstring> - - -4.4. Involved people list - - Since there might be a lot of people contributing to an audio file in - various ways, such as musicians and technicians, the 'Text - information frames' are often insufficient to list everyone involved - in a project. The 'Involved people list' is a frame containing the - names of those involved, and how they were involved. The body simply - contains a terminated string with the involvement directly followed by - a terminated string with the involvee followed by a new involvement - and so on. There may only be one "IPL" frame in each tag. - - Involved people list "IPL" - Frame size $xx xx xx - Text encoding $xx - People list strings <textstrings> - - -4.5. Music CD Identifier - - This frame is intended for music that comes from a CD, so that the CD - can be identified in databases such as the CDDB [CDDB]. The frame - consists of a binary dump of the Table Of Contents, TOC, from the CD, - which is a header of 4 bytes and then 8 bytes/track on the CD making a - maximum of 804 bytes. This frame requires a present and valid "TRK" - frame. There may only be one "MCI" frame in each tag. - - Music CD identifier "MCI" - Frame size $xx xx xx - CD TOC <binary data> - - -4.6. Event timing codes - - This frame allows synchronisation with key events in a song or sound. - The head is: - - Event timing codes "ETC" - Frame size $xx xx xx - Time stamp format $xx - - Where time stamp format is: - - $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit - $02 Absolute time, 32 bit sized, using milliseconds as unit - - Abolute time means that every stamp contains the time from the - beginning of the file. - - Followed by a list of key events in the following format: - - Type of event $xx - Time stamp $xx (xx ...) - - The 'Time stamp' is set to zero if directly at the beginning of the - sound or after the previous event. All events should be sorted in - chronological order. The type of event is as follows: - - $00 padding (has no meaning) - $01 end of initial silence - $02 intro start - $03 mainpart start - $04 outro start - $05 outro end - $06 verse begins - $07 refrain begins - $08 interlude - $09 theme start - $0A variation - $0B key change - $0C time change - $0D unwanted noise (Snap, Crackle & Pop) - - $0E-$DF reserved for future use - - $E0-$EF not predefined sync 0-F - - $F0-$FC reserved for future use - - $FD audio end (start of silence) - $FE audio file ends - $FF one more byte of events follows (all the following bytes with - the value $FF have the same function) - - The 'Not predefined sync's ($E0-EF) are for user events. You might - want to synchronise your music to something, like setting of an - explosion on-stage, turning on your screensaver etc. - - There may only be one "ETC" frame in each tag. - - -4.7. MPEG location lookup table - - To increase performance and accuracy of jumps within a MPEG [MPEG] - audio file, frames with timecodes in different locations in the file - might be useful. The ID3 frame includes references that the software - can use to calculate positions in the file. After the frame header is - a descriptor of how much the 'frame counter' should increase for every - reference. If this value is two then the first reference points out - the second frame, the 2nd reference the 4th frame, the 3rd reference - the 6th frame etc. In a similar way the 'bytes between reference' and - 'milliseconds between reference' points out bytes and milliseconds - respectively. - - Each reference consists of two parts; a certain number of bits, as - defined in 'bits for bytes deviation', that describes the difference - between what is said in 'bytes between reference' and the reality and - a certain number of bits, as defined in 'bits for milliseconds - deviation', that describes the difference between what is said in - 'milliseconds between reference' and the reality. The number of bits - in every reference, i.e. 'bits for bytes deviation'+'bits for - milliseconds deviation', must be a multiple of four. There may only be - one "MLL" frame in each tag. - - Location lookup table "MLL" - ID3 frame size $xx xx xx - MPEG frames between reference $xx xx - Bytes between reference $xx xx xx - Milliseconds between reference $xx xx xx - Bits for bytes deviation $xx - Bits for milliseconds dev. $xx - - Then for every reference the following data is included; - - Deviation in bytes %xxx.... - Deviation in milliseconds %xxx.... - - -4.8. Synced tempo codes - - For a more accurate description of the tempo of a musical piece this - frame might be used. After the header follows one byte describing - which time stamp format should be used. Then follows one or more tempo - codes. Each tempo code consists of one tempo part and one time part. - The tempo is in BPM described with one or two bytes. If the first byte - has the value $FF, one more byte follows, which is added to the first - giving a range from 2 - 510 BPM, since $00 and $01 is reserved. $00 is - used to describe a beat-free time period, which is not the same as a - music-free time period. $01 is used to indicate one single beat-stroke - followed by a beat-free period. - - The tempo descriptor is followed by a time stamp. Every time the tempo - in the music changes, a tempo descriptor may indicate this for the - player. All tempo descriptors should be sorted in chronological order. - The first beat-stroke in a time-period is at the same time as the beat - description occurs. There may only be one "STC" frame in each tag. - - Synced tempo codes "STC" - Frame size $xx xx xx - Time stamp format $xx - Tempo data <binary data> - - Where time stamp format is: - - $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit - $02 Absolute time, 32 bit sized, using milliseconds as unit - - Abolute time means that every stamp contains the time from the - beginning of the file. - - -4.9. Unsychronised lyrics/text transcription - - This frame contains the lyrics of the song or a text transcription of - other vocal activities. The head includes an encoding descriptor and - a content descriptor. The body consists of the actual text. The - 'Content descriptor' is a terminated string. If no descriptor is - entered, 'Content descriptor' is $00 (00) only. Newline characters - are allowed in the text. Maximum length for the descriptor is 64 - bytes. There may be more than one lyrics/text frame in each tag, but - only one with the same language and content descriptor. - - Unsynced lyrics/text "ULT" - Frame size $xx xx xx - Text encoding $xx - Language $xx xx xx - Content descriptor <textstring> $00 (00) - Lyrics/text <textstring> - - -4.10. Synchronised lyrics/text - - This is another way of incorporating the words, said or sung lyrics, - in the audio file as text, this time, however, in sync with the audio. - It might also be used to describing events e.g. occurring on a stage - or on the screen in sync with the audio. The header includes a content - descriptor, represented with as terminated textstring. If no - descriptor is entered, 'Content descriptor' is $00 (00) only. - - Synced lyrics/text "SLT" - Frame size $xx xx xx - Text encoding $xx - Language $xx xx xx - Time stamp format $xx - Content type $xx - Content descriptor <textstring> $00 (00) - - - Encoding: $00 ISO-8859-1 [ISO-8859-1] character set is used => $00 - is sync identifier. - $01 Unicode [UNICODE] character set is used => $00 00 is - sync identifier. - - Content type: $00 is other - $01 is lyrics - $02 is text transcription - $03 is movement/part name (e.g. "Adagio") - $04 is events (e.g. "Don Quijote enters the stage") - $05 is chord (e.g. "Bb F Fsus") - - Time stamp format is: - - $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit - $02 Absolute time, 32 bit sized, using milliseconds as unit - - Abolute time means that every stamp contains the time from the - beginning of the file. - - The text that follows the frame header differs from that of the - unsynchronised lyrics/text transcription in one major way. Each - syllable (or whatever size of text is considered to be convenient by - the encoder) is a null terminated string followed by a time stamp - denoting where in the sound file it belongs. Each sync thus has the - following structure: - - Terminated text to be synced (typically a syllable) - Sync identifier (terminator to above string) $00 (00) - Time stamp $xx (xx ...) - - The 'time stamp' is set to zero or the whole sync is omitted if - located directly at the beginning of the sound. All time stamps should - be sorted in chronological order. The sync can be considered as a - validator of the subsequent string. - - Newline characters are allowed in all "SLT" frames and should be used - after every entry (name, event etc.) in a frame with the content type - $03 - $04. - - A few considerations regarding whitespace characters: Whitespace - separating words should mark the beginning of a new word, thus - occurring in front of the first syllable of a new word. This is also - valid for new line characters. A syllable followed by a comma should - not be broken apart with a sync (both the syllable and the comma - should be before the sync). - - An example: The "ULT" passage - - "Strangers in the night" $0A "Exchanging glances" - - would be "SLT" encoded as: - - "Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx - " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx - xx "glan" $00 xx xx "ces" $00 xx xx - - There may be more than one "SLT" frame in each tag, but only one with - the same language and content descriptor. - - -4.11. Comments - - This frame replaces the old 30-character comment field in ID3v1. It - consists of a frame head followed by encoding, language and content - descriptors and is ended with the actual comment as a text string. - Newline characters are allowed in the comment text string. There may - be more than one comment frame in each tag, but only one with the same - language and content descriptor. - - Comment "COM" - Frame size $xx xx xx - Text encoding $xx - Language $xx xx xx - Short content description <textstring> $00 (00) - The actual text <textstring> - - -4.12. Relative volume adjustment - - This is a more subjective function than the previous ones. It allows - the user to say how much he wants to increase/decrease the volume on - each channel while the file is played. The purpose is to be able to - align all files to a reference volume, so that you don't have to - change the volume constantly. This frame may also be used to balance - adjust the audio. If the volume peak levels are known then this could - be described with the 'Peak volume right' and 'Peak volume left' - field. If Peakvolume is not known these fields could be left zeroed - or completely omitted. There may only be one "RVA" frame in each - tag. - - Relative volume adjustment "RVA" - Frame size $xx xx xx - Increment/decrement %000000xx - Bits used for volume descr. $xx - Relative volume change, right $xx xx (xx ...) - Relative volume change, left $xx xx (xx ...) - Peak volume right $xx xx (xx ...) - Peak volume left $xx xx (xx ...) - - In the increment/decrement field bit 0 is used to indicate the right - channel and bit 1 is used to indicate the left channel. 1 is - increment and 0 is decrement. - - The 'bits used for volume description' field is normally $10 (16 bits) - for MPEG 2 layer I, II and III [MPEG] and MPEG 2.5. This value may not - be $00. The volume is always represented with whole bytes, padded in - the beginning (highest bits) when 'bits used for volume description' - is not a multiple of eight. - - -4.13. Equalisation - - This is another subjective, alignment frame. It allows the user to - predefine an equalisation curve within the audio file. There may only - be one "EQU" frame in each tag. - - Equalisation "EQU" - Frame size $xx xx xx - Adjustment bits $xx - - The 'adjustment bits' field defines the number of bits used for - representation of the adjustment. This is normally $10 (16 bits) for - MPEG 2 layer I, II and III [MPEG] and MPEG 2.5. This value may not be - $00. - - This is followed by 2 bytes + ('adjustment bits' rounded up to the - nearest byte) for every equalisation band in the following format, - giving a frequency range of 0 - 32767Hz: - - Increment/decrement %x (MSB of the Frequency) - Frequency (lower 15 bits) - Adjustment $xx (xx ...) - - The increment/decrement bit is 1 for increment and 0 for decrement. - The equalisation bands should be ordered increasingly with reference - to frequency. All frequencies don't have to be declared. Adjustments - with the value $00 should be omitted. A frequency should only be - described once in the frame. - - -4.14. Reverb - - Yet another subjective one. You may here adjust echoes of different - kinds. Reverb left/right is the delay between every bounce in ms. - Reverb bounces left/right is the number of bounces that should be - made. $FF equals an infinite number of bounces. Feedback is the amount - of volume that should be returned to the next echo bounce. $00 is 0%, - $FF is 100%. If this value were $7F, there would be 50% volume - reduction on the first bounce, yet 50% on the second and so on. Left - to left means the sound from the left bounce to be played in the left - speaker, while left to right means sound from the left bounce to be - played in the right speaker. - - 'Premix left to right' is the amount of left sound to be mixed in the - right before any reverb is applied, where $00 id 0% and $FF is 100%. - 'Premix right to left' does the same thing, but right to left. Setting - both premix to $FF would result in a mono output (if the reverb is - applied symmetric). There may only be one "REV" frame in each tag. - - Reverb settings "REV" - Frame size $00 00 0C - Reverb left (ms) $xx xx - Reverb right (ms) $xx xx - Reverb bounces, left $xx - Reverb bounces, right $xx - Reverb feedback, left to left $xx - Reverb feedback, left to right $xx - Reverb feedback, right to right $xx - Reverb feedback, right to left $xx - Premix left to right $xx - Premix right to left $xx - - -4.15. Attached picture - - This frame contains a picture directly related to the audio file. - Image format is preferably "PNG" [PNG] or "JPG" [JFIF]. Description - is a short description of the picture, represented as a terminated - textstring. The description has a maximum length of 64 characters, - but may be empty. There may be several pictures attached to one file, - each in their individual "PIC" frame, but only one with the same - content descriptor. There may only be one picture with the picture - type declared as picture type $01 and $02 respectively. There is a - possibility to put only a link to the image file by using the 'image - format' "-->" and having a complete URL [URL] instead of picture data. - The use of linked files should however be used restrictively since - there is the risk of separation of files. - - Attached picture "PIC" - Frame size $xx xx xx - Text encoding $xx - Image format $xx xx xx - Picture type $xx - Description <textstring> $00 (00) - Picture data <binary data> - - - Picture type: $00 Other - $01 32x32 pixels 'file icon' (PNG only) - $02 Other file icon - $03 Cover (front) - $04 Cover (back) - $05 Leaflet page - $06 Media (e.g. lable side of CD) - $07 Lead artist/lead performer/soloist - $08 Artist/performer - $09 Conductor - $0A Band/Orchestra - $0B Composer - $0C Lyricist/text writer - $0D Recording Location - $0E During recording - $0F During performance - $10 Movie/video screen capture - $11 A bright coloured fish - $12 Illustration - $13 Band/artist logotype - $14 Publisher/Studio logotype - - -4.16. General encapsulated object - - In this frame any type of file can be encapsulated. After the header, - 'Frame size' and 'Encoding' follows 'MIME type' [MIME] and 'Filename' - for the encapsulated object, both represented as terminated strings - encoded with ISO 8859-1 [ISO-8859-1]. The filename is case sensitive. - Then follows a content description as terminated string, encoded as - 'Encoding'. The last thing in the frame is the actual object. The - first two strings may be omitted, leaving only their terminations. - MIME type is always an ISO-8859-1 text string. There may be more than - one "GEO" frame in each tag, but only one with the same content - descriptor. - - General encapsulated object "GEO" - Frame size $xx xx xx - Text encoding $xx - MIME type <textstring> $00 - Filename <textstring> $00 (00) - Content description <textstring> $00 (00) - Encapsulated object <binary data> - - -4.17. Play counter - - This is simply a counter of the number of times a file has been - played. The value is increased by one every time the file begins to - play. There may only be one "CNT" frame in each tag. When the counter - reaches all one's, one byte is inserted in front of the counter thus - making the counter eight bits bigger. The counter must be at least - 32-bits long to begin with. - - Play counter "CNT" - Frame size $xx xx xx - Counter $xx xx xx xx (xx ...) - - -4.18. Popularimeter - - The purpose of this frame is to specify how good an audio file is. - Many interesting applications could be found to this frame such as a - playlist that features better audiofiles more often than others or it - could be used to profile a persons taste and find other 'good' files - by comparing people's profiles. The frame is very simple. It contains - the email address to the user, one rating byte and a four byte play - counter, intended to be increased with one for every time the file is - played. The email is a terminated string. The rating is 1-255 where - 1 is worst and 255 is best. 0 is unknown. If no personal counter is - wanted it may be omitted. When the counter reaches all one's, one - byte is inserted in front of the counter thus making the counter - eight bits bigger in the same away as the play counter ("CNT"). - There may be more than one "POP" frame in each tag, but only one with - the same email address. - - Popularimeter "POP" - Frame size $xx xx xx - Email to user <textstring> $00 - Rating $xx - Counter $xx xx xx xx (xx ...) - - -4.19. Recommended buffer size - - Sometimes the server from which a audio file is streamed is aware of - transmission or coding problems resulting in interruptions in the - audio stream. In these cases, the size of the buffer can be - recommended by the server using this frame. If the 'embedded info - flag' is true (1) then this indicates that an ID3 tag with the - maximum size described in 'Buffer size' may occur in the audiostream. - In such case the tag should reside between two MPEG [MPEG] frames, if - the audio is MPEG encoded. If the position of the next tag is known, - 'offset to next tag' may be used. The offset is calculated from the - end of tag in which this frame resides to the first byte of the header - in the next. This field may be omitted. Embedded tags is currently not - recommended since this could render unpredictable behaviour from - present software/hardware. The 'Buffer size' should be kept to a - minimum. There may only be one "BUF" frame in each tag. - - Recommended buffer size "BUF" - Frame size $xx xx xx - Buffer size $xx xx xx - Embedded info flag %0000000x - Offset to next tag $xx xx xx xx - - -4.20. Encrypted meta frame - - This frame contains one or more encrypted frames. This enables - protection of copyrighted information such as pictures and text, that - people might want to pay extra for. Since standardisation of such an - encryption scheme is beyond this document, all "CRM" frames begin with - a terminated string with a URL [URL] containing an email address, or a - link to a location where an email adress can be found, that belongs to - the organisation responsible for this specific encrypted meta frame. - - Questions regarding the encrypted frame should be sent to the - indicated email address. If a $00 is found directly after the 'Frame - size', the whole frame should be ignored, and preferably be removed. - The 'Owner identifier' is then followed by a short content description - and explanation as to why it's encrypted. After the - 'content/explanation' description, the actual encrypted block follows. - - When an ID3v2 decoder encounters a "CRM" frame, it should send the - datablock to the 'plugin' with the corresponding 'owner identifier' - and expect to receive either a datablock with one or several ID3v2 - frames after each other or an error. There may be more than one "CRM" - frames in a tag, but only one with the same 'owner identifier'. - - Encrypted meta frame "CRM" - Frame size $xx xx xx - Owner identifier <textstring> $00 (00) - Content/explanation <textstring> $00 (00) - Encrypted datablock <binary data> - - -4.21. Audio encryption - - This frame indicates if the actual audio stream is encrypted, and by - whom. Since standardisation of such encrypion scheme is beyond this - document, all "CRA" frames begin with a terminated string with a - URL containing an email address, or a link to a location where an - email address can be found, that belongs to the organisation - responsible for this specific encrypted audio file. Questions - regarding the encrypted audio should be sent to the email address - specified. If a $00 is found directly after the 'Frame size' and the - audiofile indeed is encrypted, the whole file may be considered - useless. - - After the 'Owner identifier', a pointer to an unencrypted part of the - audio can be specified. The 'Preview start' and 'Preview length' is - described in frames. If no part is unencrypted, these fields should be - left zeroed. After the 'preview length' field follows optionally a - datablock required for decryption of the audio. There may be more than - one "CRA" frames in a tag, but only one with the same 'Owner - identifier'. - - Audio encryption "CRA" - Frame size $xx xx xx - Owner identifier <textstring> $00 (00) - Preview start $xx xx - Preview length $xx xx - Encryption info <binary data> - - -4.22. Linked information - - To keep space waste as low as possible this frame may be used to link - information from another ID3v2 tag that might reside in another audio - file or alone in a binary file. It is recommended that this method is - only used when the files are stored on a CD-ROM or other circumstances - when the risk of file seperation is low. The frame contains a frame - identifier, which is the frame that should be linked into this tag, a - URL [URL] field, where a reference to the file where the frame is - given, and additional ID data, if needed. Data should be retrieved - from the first tag found in the file to which this link points. There - may be more than one "LNK" frame in a tag, but only one with the same - contents. A linked frame is to be considered as part of the tag and - has the same restrictions as if it was a physical part of the tag - (i.e. only one "REV" frame allowed, whether it's linked or not). - - Linked information "LNK" - Frame size $xx xx xx - Frame identifier $xx xx xx - URL <textstring> $00 (00) - Additional ID data <textstring(s)> - - Frames that may be linked and need no additional data are "IPL", - "MCI", "ETC", "LLT", "STC", "RVA", "EQU", "REV", "BUF", the text - information frames and the URL link frames. - - The "TXX", "PIC", "GEO", "CRM" and "CRA" frames may be linked with the - content descriptor as additional ID data. - - The "COM", "SLT" and "ULT" frames may be linked with three bytes of - language descriptor directly followed by a content descriptor as - additional ID data. - - -5. The 'unsynchronisation scheme' - - The only purpose of the 'unsychronisation scheme' is to make the ID3v2 - tag as compatible as possible with existing software. There is no use - in 'unsynchronising' tags if the file is only to be processed by new - software. Unsynchronisation may only be made with MPEG 2 layer I, II - and III and MPEG 2.5 files. - - Whenever a false synchronisation is found within the tag, one zeroed - byte is inserted after the first false synchronisation byte. The - format of a correct sync that should be altered by ID3 encoders is as - follows: - - %11111111 111xxxxx - - And should be replaced with: - - %11111111 00000000 111xxxxx - - This has the side effect that all $FF 00 combinations have to be - altered, so they won't be affected by the decoding process. Therefore - all the $FF 00 combinations have to be replaced with the $FF 00 00 - combination during the unsynchonisation. - - To indicate usage of the unsynchronisation, the first bit in 'ID3 - flags' should be set. This bit should only be set if the tag - contained a, now corrected, false synchronisation. The bit should - only be clear if the tag does not contain any false synchronisations. - - Do bear in mind, that if a compression scheme is used by the encoder, - the unsyncronisation scheme should be applied *afterwards*. When - decoding a compressed, 'unsyncronised' file, the 'unsyncronisation - scheme' should be parsed first, compression afterwards. - - -6. Copyright - - Copyright (C) Martin Nilsson 1998. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that a reference to this document is included on all - such copies and derivative works. However, this document itself may - not be modified in any way and reissued as the original document. - - The limited permissions granted above are perpetual and will not be - revoked. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -7. References - - [CDDB] Compact Disc Data Base - - <url:http://www.cddb.com> - - [ISO-639-2] ISO/FDIS 639-2. - Codes for the representation of names of languages, Part 2: Alpha-3 - code. Technical committee / subcommittee: TC 37 / SC 2 - - [ISO-8859-1] ISO/IEC DIS 8859-1. - 8-bit single-byte coded graphic character sets, Part 1: Latin - alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2 - - [ISRC] ISO 3901:1986 - International Standard Recording Code (ISRC). - Technical committee / subcommittee: TC 46 / SC 9 - - [JFIF] JPEG File Interchange Format, version 1.02 - - <url:http://www.w3.org/Graphics/JPEG/jfif.txt> - - [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - RFC 2045, November 1996. - - <url:ftp://ftp.isi.edu/in-notes/rfc2045.txt> - - [MPEG] ISO/IEC 11172-3:1993. - Coding of moving pictures and associated audio for digital storage - media at up to about 1,5 Mbit/s, Part 3: Audio. - Technical committee / subcommittee: JTC 1 / SC 29 - and - ISO/IEC 13818-3:1995 - Generic coding of moving pictures and associated audio information, - Part 3: Audio. - Technical committee / subcommittee: JTC 1 / SC 29 - and - ISO/IEC DIS 13818-3 - Generic coding of moving pictures and associated audio information, - Part 3: Audio (Revision of ISO/IEC 13818-3:1995) - - - [PNG] Portable Network Graphics, version 1.0 - - <url:http://www.w3.org/TR/REC-png-multi.html> - - [UNICODE] ISO/IEC 10646-1:1993. - Universal Multiple-Octet Coded Character Set (UCS), Part 1: - Architecture and Basic Multilingual Plane. Technical committee - / subcommittee: JTC 1 / SC 2 - - <url:http://www.unicode.org> - - [URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource - Locators (URL).", RFC 1738, December 1994. - - <url:ftp://ftp.isi.edu/in-notes/rfc1738.txt> - - -8. Appendix - - -A. Appendix A - ID3-Tag Specification V1.1 - - ID3-Tag Specification V1.1 (12 dec 1997) by Michael Mutschler - <amiga2@info2.rus.uni-stuttgart.de>, edited for space and clarity - reasons. - - -A.1. Overview - - The ID3-Tag is an information field for MPEG Layer 3 audio files. - Since a standalone MP3 doesn't provide a method of storing other - information than those directly needed for replay reasons, the - ID3-tag was invented by Eric Kemp in 1996. - - A revision from ID3v1 to ID3v1.1 was made by Michael Mutschler to - support track number information is described in A.4. - - -A.2. ID3v1 Implementation - - The Information is stored in the last 128 bytes of an MP3. The Tag - has got the following fields, and the offsets given here, are from - 0-127. - - Field Length Offsets - Tag 3 0-2 - Songname 30 3-32 - Artist 30 33-62 - Album 30 63-92 - Year 4 93-96 - Comment 30 97-126 - Genre 1 127 - - - The string-fields contain ASCII-data, coded in ISO-Latin 1 codepage. - Strings which are smaller than the field length are padded with zero- - bytes. - - Tag: The tag is valid if this field contains the string "TAG". This - has to be uppercase! - - Songname: This field contains the title of the MP3 (string as - above). - - Artist: This field contains the artist of the MP3 (string as above). - - Album: this field contains the album where the MP3 comes from - (string as above). - - Year: this field contains the year when this song has originally - been released (string as above). - - Comment: this field contains a comment for the MP3 (string as - above). Revision to this field has been made in ID3v1.1. See - A.4. - - Genre: this byte contains the offset of a genre in a predefined - list the byte is treated as an unsigned byte. The offset is - starting from 0. See A.3. - - -A.3. Genre List - - The following genres is defined in ID3v1 - - 0.Blues - 1.Classic Rock - 2.Country - 3.Dance - 4.Disco - 5.Funk - 6.Grunge - 7.Hip-Hop - 8.Jazz - 9.Metal - 10.New Age - 11.Oldies - 12.Other - 13.Pop - 14.R&B - 15.Rap - 16.Reggae - 17.Rock - 18.Techno - 19.Industrial - 20.Alternative - 21.Ska - 22.Death Metal - 23.Pranks - 24.Soundtrack - 25.Euro-Techno - 26.Ambient - 27.Trip-Hop - 28.Vocal - 29.Jazz+Funk - 30.Fusion - 31.Trance - 32.Classical - 33.Instrumental - 34.Acid - 35.House - 36.Game - 37.Sound Clip - 38.Gospel - 39.Noise - 40.AlternRock - 41.Bass - 42.Soul - 43.Punk - 44.Space - 45.Meditative - 46.Instrumental Pop - 47.Instrumental Rock - 48.Ethnic - 49.Gothic - 50.Darkwave - 51.Techno-Industrial - 52.Electronic - 53.Pop-Folk - 54.Eurodance - 55.Dream - 56.Southern Rock - 57.Comedy - 58.Cult - 59.Gangsta - 60.Top 40 - 61.Christian Rap - 62.Pop/Funk - 63.Jungle - 64.Native American - 65.Cabaret - 66.New Wave - 67.Psychadelic - 68.Rave - 69.Showtunes - 70.Trailer - 71.Lo-Fi - 72.Tribal - 73.Acid Punk - 74.Acid Jazz - 75.Polka - 76.Retro - 77.Musical - 78.Rock & Roll - 79.Hard Rock - - The following genres are Winamp extensions - - 80.Folk - 81.Folk-Rock - 82.National Folk - 83.Swing - 84.Fast Fusion - 85.Bebob - 86.Latin - 87.Revival - 88.Celtic - 89.Bluegrass - 90.Avantgarde - 91.Gothic Rock - 92.Progressive Rock - 93.Psychedelic Rock - 94.Symphonic Rock - 95.Slow Rock - 96.Big Band - 97.Chorus - 98.Easy Listening - 99.Acoustic - 100.Humour - 101.Speech - 102.Chanson - 103.Opera - 104.Chamber Music - 105.Sonata - 106.Symphony - 107.Booty Bass - 108.Primus - 109.Porn Groove - 110.Satire - 111.Slow Jam - 112.Club - 113.Tango - 114.Samba - 115.Folklore - 116.Ballad - 117.Power Ballad - 118.Rhythmic Soul - 119.Freestyle - 120.Duet - 121.Punk Rock - 122.Drum Solo - 123.A capella - 124.Euro-House - 125.Dance Hall - - -A.4. Track addition - ID3v1.1 - - In ID3v1.1, Michael Mutschler revised the specification of the - comment field in order to implement the track number. The new format - of the comment field is a 28 character string followed by a mandatory - null ($00) character and the original album tracknumber stored as an - unsigned byte-size integer. In such cases where the 29th byte is not - the null character or when the 30th is a null character, the - tracknumber is to be considered undefined. - - -9. Author's Address - - Martin Nilsson - Rydsvägen 246 C. 30 - S-584 34 Linköping - Sweden - - Email: nilsson@id3.org - - Co-authors: - - Johan Sundström Email: johan@id3.org - - |