t3v2 made e
`
`I
`asy
`
`What is lD3v2?
`lD3v2 is a new taggingrsyetern that lets you put
`enriching and relevant information about your
`audio files within them. ln more down to earth
`terms, lD3v2 is a chunk of data prepended to
`the binary audio data. Each lD3v2 tag holds
`one or more smaller chunks of information,
`called frames. These frames can contain any
`kind of information and data you could think of
`such as title, album, performer, website. lyrics,
`equallzer presets, pictures etc. The block
`scheme to the right ls an example of how the
`layout of a typical lD3v2 tagged audio file rnay
`look like.
`
`One of the design goals were that the lD3v2
`should be very flexible and expandable. lt is
`very easy to add new functions to the lD3v2
`tag, because, just like in HTML, all parsers will
`ignore any information they don't recognize.
`Since each frame can be 16MB and the entire
`tag can be 256M8 you'll probably never again
`be in the same situation as when you tried to
`write a useful comment in the old lD3 being
`limited to 30 characters.
`
`Speaking of characters, the lD3v2 supports
`Unicode so even if you use the Bopomofo
`character set you'll be able to write in your
`native language. You can also include in whic.h
`language you're writing so that one flle might
`contain e.g. the same lyrics but in different
`languages.
`
`Even though the tag supports a lot of byte
`consuming capabilitles like inline pictures and
`evEn the possibility to include any other file,
`lD3v2 still tries to use the bytes as efficient as
`possibly. lf you convert an lD3v1 tag to an
`lD3v2 tag it is even likely that the new tag will
`be smaller. lf you convgrt an lD3v1 tag where
`allfieids are tutt (that is, all 30 charactLrs are
`used in every field) to an lD3v2 tag it will be 56
`bytes bigger. This is the worst case scenario for
`lDSvl to lD3v2 conversion.
`
`Since it's so easy to implement new
`functionality into lD3v2, one can hope that we'll
`see a.lot of creative uses for lD3v2 in the future.
`
`Example of the intemal laYout
`of an lD3v2tagged file.
`
`http://www.id3.org/easy.hbnl
`
`5t12/2003
`
`Page 1 of 45
`
`BMW EXHIBIT 1004
`
`

`

`))
`' E.g.there is a built-itystem for rating the
`music and counting how often you listen to a
`file, just to mention some brainstorm results that
`are included. This feature can be used to build
`playlists that play your favourite songs more
`often than others.
`
`t6&-v4,-_
`
`a a
`
`Some main features
`The lD3v2 tag is a containerformat, just like IFF or pNG files, allowing new
`frames (chunks) as evolution proceeds.
`Residing in the beginning of the audio file makes it suitable for streaming.
`Has an'unsynchrcnlzation scheme' to prevent lD3v2-incompatible players to
`attempt to play the tag.
`Maximum tag size is 256 megabytes and maximum frame size is 16
`megabytes.
`Byte conservative and with the capability to compress data it keeps the files
`small.
`The titfi supports Unicode.
`lsn't entirely focused on musical audio, but also other types of audio.
`Has several new telt fields such as composer, conductor, media type, BPM,
`copyright message, etc. and the possibility to design your own as you see fit.
`Can contaln lyrics as well as music-synced lyrics (karaoke) in almost any
`language.
`ls able to contain volume, balance, equalizer and reverb settings.
`Could be linked to CD-databases such as CDDB.
`ls able to contain images and just about any file you want to include.
`$upports enciphered informatlon, linked informatioh and weblinks.
`and more... (a complete list of all frames and their functions can be found here)
`
`I a o
`
`a a a a a
`
`http ://www. id3.ore/easv.htnl
`
`\t\?n.fin?
`
`Page 2 of 45
`
`

`

`This Page Is Inserted by IFW Operations
`and is not a part of the Official Record
`
`BEST AVAILABLE IMAGES
`
`Defective images within this document are accurate representations of the
`original documents submitted by the applicant.
`
`Defects in the images may include (but are not limited to):
`
`r BLACKBORDERS
`o TEXT CUT OFF AT TOP, BOTTOM OR SIDES
`o FADED TEXT
`o ILLEGIBLE TEXT
`o SKEWED/SLANTEDIMAGES
`
`COLORED PHOTOS
`
`BLACK OR VERY BLACK AND WHITE DARK PHOTOS
`
`GRAY SCALE DOCUMENTS
`
`a a
`
`IMAGES ARE BEST AVAILABLE COPY.
`
`As rescanning documents will not correct imagest
`please do not report the images to the
`fmage Problems Mailbox.
`
`Page 3 of 45
`
`

`

`5'
`
`Informal standard
`Document : id3v2.3.0.htnl
`
`M. Nilsson
`3rd February 1999
`
`ID3 tag version2.3.0
`Status of this documen
`
`This document is an informal standard and replaces the 1D3v2.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.
`
`Abstract
`
`This document describes the 1D3v2.3.0, which is a more developed version of the
`ID3v2 informal standard (version 2.2.0), evolved from the ID3 iagging systern. 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 informrition,
`such as equalisation curyes, as well as related meta information, such as title,
`performer, copyright etc.
`
`l.Table of contents
`
`2. Conventions in this document
`3. lD3v2 overview
`3.1. lD3v2 header
`3.2 i W3v2 extended header
`3.3. lD3v2 frames overyiew
`3.3.1. Frame header flags
`3.3.2. Default flags
`4. Declared lD3v2 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 ldentifier
`4.6, Event timing codes
`
`I I I
`
`http://www.id3.orglid3v2.3.0.hhrl
`
`s/r ?/?nnl
`
`Page 4 of 45
`
`

`

`4.7. MPEG ,tt,on tookup tabte
`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. Audio encryption
`4.21. Linked information
`4.22. Position synchronisation frame
`4.23. Terms of use
`4.24. Ownership frame
`4.25. Commercialframe
`4.26, Encryption method registration
`4.27. Group identification registration
`4.28. Private frame
`5. The'unsynchronisation scheme'
`6. Copyright
`7. References
`8. Appendix
`A. Appendix A - Genre Listfrom lD3v1
`9. Author's Address
`
`2.Conventions in this document
`
`In the examples, text within "" is a text sting 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 sting etc. A numeric string is a string
`that consists of the characters 0-9 onlv.
`
`3.ID3v2 overview
`
`The two biggest design goals were to be able to implement ID3v2 without
`disturbing old softrvare 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 audiosteam, to'lock on to'the audio. Since the
`
`http://www.id3,orq/id3v2.3.0.html
`
`5l1r.n.on1
`
`Page 5 of 45
`
`

`

`ID3v2 tag doesn
`
`re: ti ror any ;fkm* :ffi#"d#,,rtr4;:"1fr;nmll? ffi ,
`
`bE taken care ofby the'unsynchronisation sitreme 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, ciUed frames,
`whose format need not be known to thc softvrare that encounters them. At the stan
`of eveiy 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'I/2 layer I, MPEG-l/2 layer II, MPEG-I/2 layer IrI and MpEG-2.5, bur
`may work with other types of encoded audio.
`
`The bitorder in ID3v2 is most significant bit frst (MSB). The byteorder in
`multibyte numbers is most significant byte first (e.g. $12345678 would be e,ncoded
`$12 34 s6 78).
`
`It is permitted to include padding after all'the final frarne (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 pupose of this padding is to allow for adding a few
`additional frames or er.rlarge 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, wlrich should be the first information in the file, is l0 byes
`as follows:
`
`DSv}lfie identifier "ID3u
`ID3v2 version
`$03 00
`ID3v2 flags
`ID3v2 size
`
`%aUcOOOOO
`4 + %0xxxxxxx
`
`The first thee byes ofthe tag are always'D3r' 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. ln 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
`
`http:/iwww.id3.ore/id3v2.3.0.hunl
`
`511?J?,no7
`
`Page 6 of 45
`
`

`

`,
`
`''1
`
`Bit 7 in rrrr'tQ flags'indicates whether or not *r*t"isation is
`u'sed (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 - Exporimental indicator
`
`The third bit Oit 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
`- l0). Only 28 bits (representing up to 256M8) 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 W yy xx zz z,z ?,2 zz
`Where yy is less than $FF, xx is the'flags'byte and zz is less than $80,
`
`3 .2.1D3v2 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.
`
`Extendedheader size $xx xx xx xx
`Extended Flags
`$xx xx
`Size of padding $xx xx xx xx
`
`Where the'Extended header size', curently 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 atfibutes are currently defined as follows
`
`%x0000000 00000000
`
`hnp ://www.iilI.ore/id3v2.3.0.htnl
`
`5t12/2003
`
`Page 7 of 45
`
`

`

`x - CRC Out. prrrJ
`If this flag is set four bytes of CRC-32 datais 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 &ame 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 $xxxxxx xx
`Flags $xx xx
`
`The frame ID made out of the characters capital A-Z and0-9. Identifiers beginning
`with uX','Yu aAd"Z" are for experimental use and tee for everyone to use,
`witbout the need to set the experimental bit in the tag header. Have in mind that
`someone else migbt 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 ev€ry frame. The size is calculated as frame size excluding frame header
`(frame size - l0).
`
`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' appqmnce in the tag, although it is desired
`that the frames are arranged in order of significance concerning the recognition of
`the file. fur example of such order: UFID, TlT2, 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 sting is represented as ISO-8859-1 characters in the range
`$20 - $FF. Such shings are represented as <text string>, or <full text string> if
`newlines are allowed, in the frame descriptions. All Unicode strings use 16-bit
`unicode 2.0 (ISO/IEC 10646-l:1993, UCS-2). Unicode sbings must begin with the
`Unicode BOM ($FF FE or $FB FF) to identify the byte order,
`
`All numeric strings and URLs are always encoded as l$O-8859-1. Terminated
`sfings are terminated with $00 if encoded with ISO-8859-1 and $00 00 if encoded
`as unicode. Ifnothing 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
`
`http://www.id3.ore/id3v2.3.0.hunl
`
`5112t2003
`
`Page 8 of 45
`
`

`

`tlpes ofitext *rodrt*e a text encoding description Uyt, atrrv 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 <text string according to
`encoding>, or <full text string according to encoding> if newlines are allowed. fuiy
`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 I30-639-2.
`
`All URLs may be relative, e.g. "picfure.ptrg", ',../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. l.Frame header flags
`
`In the &ame 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 frarne 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.
`I
`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,
`
`http ://www.id3.ore/id3v2.3.0.hunl
`
`5112/2003
`
`Page 9 of 45
`
`

`

`e.g. a signaturtth, contents are changed, without knoMedge inwhy
`the frame was flagged read only and without taking the proper means io
`compensate, e.g. recalculating the signature, the bii should be cleared.
`
`i - Compression
`
`This flag indicates whether or not the frame is compressed.
`
`0 Frame is not compressed.
`,, Frame is compressed using zlib with 4 bytes for'decompressed size'
`^ appended to the frame header.
`
`j - Encryption
`
`This flag indicates wether or not the franre is en4ryted. 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 registation.
`0
`I
`
`Frame is not encrypted.
`Frame is encqryted.
`
`k - Cnouping identify
`
`This flag indicates whether.or not this frame belongs in a group with
`other frames. If set a group identifierbyte 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
`I Frame contains goup information
`
`Some flags indicates that the frame header is extended with additional infomration.
`This information will be added to the frane 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 headqr, while not included in
`the frame header size but are included in the'frame siae'field, are not subject to
`encryption or compression.
`
`3.3.2.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
`softrvare.
`
`l. Discarded if tag is altered, discarded if file is altered.
`
`None.
`
`http ://www. id3.ore/id3v2.3.0.htnl
`
`ynDa03
`
`Page 10 of 45
`
`

`

`2. Discarded if tag itrO, preserved if file is altered.
`
`None
`
`3. Preserved iftag is altered, discarded if file is altered.
`
`ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ
`
`4. Preserved iftag is altered, preserved iffile is altered.
`
`The rest of the frames.
`
`4.Declared ID3v2 frames
`
`The following frames are declared in this draft.
`
`4.20 AENC Audio encryption
`4.15 APIC Attached picture
`4.11 COMM Comments
`4.25 COMR Commercialframe
`4.26 ENCR Encryption method registration
`4.13 EQUA Equalization
`4.6 ETCO Event timing codes
`4.16 GEOB General encapsulated object
`4.27 GRID Group identification registration
`4.4 IPLS Involved people list
`4.21 LINK Linked information
`4.5 MCDI Music CD identifier
`4.7 MLLT MPEG location lookup table
`4.24 OWNE Ownership frame
`4.28 PRIV Private frame
`4.17 PCNT Play counter
`4.18 POPM Popularimeter
`4.22 POSS Position synchronisation frame
`4.19 RBUF Recommended buffer size
`4.12 RVAD Relative volume adjustment
`4.1.4 RVRB Reverb
`4,10 SYLT Synchronized lyric/text
`4.8 SYTC Synchronized tempo codes
`4.2.1 TALB Album/Movie/Show title
`4.2.1 TBPM BPM (beats per minute)
`4.2.1TCOM Composer
`4.2.1 TCON Content type
`4.2.1 TCOP Copyright message
`
`.
`
`http //www.id3.org/id3 v2. 3.0.htrnl
`
`5tru2a03
`
`Page 11 of 45
`
`

`

`,
`
`'
`
`,
`
`4.2.1 rDAr t
`4.2.1 TDLY Playlist delay
`4.2.1 TENC Encoded by
`4.2.1 TEXT LyricisUText writer
`4.2,1 TFLT File type
`4.2.1 TIME Time
`4.2.1 TITI Content group description
`4,2.1 TIT2 Title/songnamelcontent description
`4.2.1 TIT3 Subtitle/Descriptionrefinement
`4.2.1TKEY lnitial key
`4.2.1 TLAN Language(s)
`4.2.1TLEN Length
`4.2.1 TMED Media type
`4.2.1 TOAL Original album/movie/show title
`4.2.1 TOFN Original filename
`4.2.1 TOLY Original lyricist(s)/text writer(s)
`4.2.1 TOPE Original artist(s)/performer(s)
`4.2.1 TORY Original release year
`4.2.1 TOWN File ownerllicensee
`4.2.t TPEI Lead performer(s/soloist(s)
`4.2.1 TPE2 Band/orchestra/accompaniment
`4.2.1 TPE3 Conductor/performerrefinement
`4.2.lTPEA Interpreted, remixed, or otherwise modified by
`4.2.1 TPOS Part of a set
`4.2.1 TPUB Publisher
`4.2.1 TRCK Track number/Position in set
`4.2.1 TRDA Recording dates
`4.2.1 TRSN Internet radio station name
`4.2.1 TRSO Internet radio station owner
`4.2.lTSIZ Size
`4.2.1TSRC ISRC (international standard recording code)
`4.2.1 TSSE Software/Hardware and settings used for encoding
`4.2.1 TYER Year
`4.2.2 TXXX User defined text information frame
`4.1 UFID Unique file identifier
`4.23 USER Terms of use
`4.9 USLT Unsychronizedlyricltexttranscription
`4.3.1 WCOM Commercial information
`4.3.1 WCOP CopyrighVlegal information
`4.3.1 WOAF Official audio file webpage
`4.3.1 WOAR Official artisUperformer webpage
`
`1
`
`http://wwrv.id3.org/id3v2,3.0.htnl
`
`str2t2003
`
`Page 12 of 45
`
`

`

`rO
`
`fficial audio source webpage
`Official internet radio station homepage
`Payment
`Publishers official webpage
`User defined URL link frame
`
`4.3.1 WOAS
`,1.3.1 WORS
`4.3.1 WPAY
`4.3.1 WPUB
`4.3.2 WXXX
`
`4.l.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 begrn 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.htnl" should be used for tests.
`Software that isn't told otherwise may safely remove such frames. The'Owner
`identifie/ 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 "IJFID" frame in a tag, but only one with the same'Owner
`identifier'.
`
`<Header for unique file identifier',ID: "LIFID">
`Owner
`identifier <text string> $00
`Identifier <up to 64 bytes binary data>
`
`4 .2.T extinformation fr ames
`
`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 frarne
`identifiers begin with "T", Only text frame identifiers begin with "T", with the
`exception of the UTXXX" frame. All the text information frames have the following
`format:
`
`<Header for'Text information frame', ID: !'T000" - "TZZZ,, excluding
`'TX)O('' described in 4.2.2.>
`Text
`encoding uxx
`lnformation <text string according to encoding>
` .z.l^Text information frames - details
`TALB
`The'Album/lvlovie/Show title'frame is intended for the title of the recording
`
`http ://www.id3.org/id3vZ.3.0.hfinl
`
`str2t2003
`
`Page 13 of 45
`
`

`

`(/source of sound) w
`
`the audio in the file is taken from. O
`
`TBPM
`The tsPM' 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 bye 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 refinernent, e.g. u(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 'Copynght message' frame, which must befin with a year and a space character
`(making five characters), is intended for the copynght 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 'lgopyright @ ".
`
`TDAT
`. The'Date'frame is a numeric string in the DDMM forqrat containing the date for
`the recording. This field is always four characters long.
`
`TDLY
`The'Playlist delay'defines the numbers of milliseconds of silence befween every
`song in a playlist. The player should use the UETC" 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.
`
`http://www.id3.org/id3v2,3.0.html
`
`5t12t2003
`
`Page 14 of 45
`
`

`

`' TEXT
`The'Lyricist(s)/Text writeds)' frame is intended for the writeds) of the text or
`lyrics in the recording. They are seperated with the "/" character.
`
`TFLT
`The'File [r'pe'frame indicates which type of audio this tag defines. The following
`type and refinements are defined:
`
`MPG MPEG Audio
`It MPEG ll?layerl
`12 MPEG ll2layertr
`13 MPEG ll2layerll
`t2.5 MPEG 2,5
`/AAC Advanced audio compression
`VQf Transformdomain Weighted Interleave Vector Quantization
`PCM Pulse Code Modulated audio
`
`but other tlpes may be rised, not for these types though. This is used in a similar
`way to the predefined tlpes 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 anumeric string in the HHMM format containing the time for
`the recording. This field is always four characters long.
`
`TITl
`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"r"Bur"g","D"r"E", t'Ft' and ttGtt and halfl<eys represented
`with "b" and "#u. Minor is represented as "m". Example "Cbm". Off key is
`represented with an "o" only.
`
`TLA}[
`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
`
`http://www.id3.orglidlv2.3.0.html
`
`sn2n0a3
`
`Page 15 of 45
`
`

`

`IS0-639-2. If more ,Ilon, language is used in the text *rri, Q,r"ge 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 tlryes found in the list below.
`References are made within "(" and ")" and are optionally followed,by a text
`relinement, e.g. '(MC) with four channels". If a text refinement should begrn with a
`"(" character it should be replaced with "((" in the same way as in the "TCO" frame.
`Predefi.ned refinements is appended after the media t1pe, e.g. "(CD/A)" or
`,(VID/?AIIVHS)'!.
`
`DIG
`Other digital media
`lA Analog transfer from media
`ANA Other analog media
`AMAC Wax cylinder
`/8CA 8-track tape cassette
`CD
`
`CD
`lA Analog transfer from media
`/DD DDD
`/AD ADD
`/AA AAD
`
`LD
`
`TT
`
`MD
`
`DAT
`
`t33
`t45
`17r
`t76
`t78
`/80
`
`IA
`
`IA
`
`Laserdisc
`Analog transfer from inedia
`
`Turntable records
`33.33 rpm
`45 rpm
`71.29 rym
`76.59 rpm
`78.26 rpm
`80 rpm
`
`MiniDisc
`Analog fransfer from media
`
`DAT
`Analog transfer from media
`
`http ://www.id3,org/id3v2. 3.O.hfrnl
`
`511212003
`
`Page 16 of 45
`
`

`

`lt ,tuol}d, Swtzlt6bits,linear I
`
`12 mode 2, 32k*lzJl6 bits,linear
`13 mode 3,32WfzJl2 bits, nonlinear,low speed
`/4 ,mode 4,32Wldl2 bits,4 channels
`15 mode 5, 44.lWlzll6 bits,linear
`16 mode 6, 44.lkLlz/l1 bits,'wide kack'play
`
`DCC
`
`DCC
`lA Analog transfer from media
`
`DVD
`
`DVD
`Analog transfer from media
`
`IA
`
`TV
`
`IPAL
`NTSC
`/SECAM
`
`Television
`PAL
`NTSC
`SECAM
`
`VID
`.IPAL
`
`NTSC
`/SECAM
`A/HS
`/SVHS
`/BETA
`
`Video
`PAL
`NTSC
`SECAM
`VHS
`S.VHS
`BETAMAX
`
`RAD
`
`/FM
`/AM
`/LW
`a{w
`
`Radio
`FM
`AN4
`LW
`MW
`
`TEL
`
`MC
`
`Telephone
`ISDN
`
`fl
`
`MC (normal cassette)
`4.75 cm/s (normal speed for a two sided cassette)
`9.5 cm/s
`Type I cassette (fenic/normal)
`Tlpe II cassette (chrome)
`Type trI cassette (ferric chrome)
`Type IV cassette (metal)
`
`t4
`t9
`n
`t\
`/Itr
`nv
`
`http://www.id!.org/id3v2.3.O.hfinl
`
`5tr2n0a3
`
`Page 17 of 45
`
`

`

`REE
`
`Orrrl
`
`t9
`
`^9138
`t76
`fI
`iII
`fllr
`/IV
`
`9.6 cm/s
`19 cmls
`38 crn/s
`76 cnr/s
`Type I cassette (ferric/normal)
`Type tr cassette.. (chrome)
`Type III oass$ (fenic chrome) :
`Type IV cassett$ (metal)
`
`,
`
`,
`
`TOAL
`The'Original album/movie/show.title'frame is intended for the title of the-original
`recording (or source of sound), if.'-for exarnple the music in the file should be a
`cover of a previously released song.
`
`i.,'
`.ll.
`
`.,]
`
`TOF'I\T
`The 'Original filename' franre contains the prefened filename for the file, since
`some mfria doesn't allow the desired length of the file,name. The filename is case
`sensitive and includ.es its suffix. ,
`TOLY
`The'Original lyricist(s)/text writer(s)' frame is intended for the text writer(s) of the
`original iecording, if for example the music in the file should be a cover of a
`previously released song. Theiext writers are seperated with the "1" character.
`TOPE
`.,
`ftre'Original artist(s)/performe(s)' frame is intended for the performer{s) of the
`original iecording, if ticr exarnplithemusic in the file should be a cover of a
`prwiously released song. The performers are seperated with the "/" character.
`
`,
`
`TORY
`The'Original release yeat' frame is intended for the year when the original
`recordin!, if for example the music in the file should be a cover of a previously
`releasediong, was reliased. The field is formatted as in the ilTYER." frarne.
`
`TOWN
`The'File owner/licensee' frame contains the name of the owner or licensee of the
`file and ifs oontents.
`
`TPEl
`The'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing Soup' is used for the
`main artist(s). They are se,perated with the "/" character.
`
`TPE2
`The'Band/OrcheshalAccompaniment' frame is used for additional information
`about the performers in the recording.
`
`http ://www.id3.org/id3 v2. 3.0.htnl
`
`slt2t2003
`
`Page 18 of 45
`
`

`

`TPE3
`The'Conductor' frame is used for the name of the cofrductor.
`
`TPE4
`The'Interpreted, remixed, or othenvise modified by' frame contains more
`information about the people behind a remix and similar interpretations of another
`existing piece.
`
`TPOS
`The ?art of a set' frame is a numliic shing that describes which part of a set the
`audio came from. This frame is used if the source described in thg UTALB" 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.
`8,9."112".
`
`TPUB
`The ?ublisher' frame simply contains the name of the label or publisher.
`
`TRCK
`The'Track numberlPosition in sef 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 nack#elements on the
`original recording. 8.9. "419".
`
`TRDA
`The'Recording dates'frame is a intended to be used as complement to the "TYFR*,
`UTDAT" and "iiME" frames. E.g. "4th-7th June, l2th June" in combination with the
`'TYER.' frame.
`
`TRSN
`