Page 1 of 34
`
`Informal standard M. Nilsson
`Document: id3v2.3.0.txt 3rd February 1999
`
` ID3 tag version 2.3.0
`Status of this document
` This document is an informal standard and replaces the ID3v2.2.0
` standard [ID3v2]. 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 ID3v2.3.0, which is a more developed
` version of the ID3v2 informal standard [ID3v2] (version 2.2.0),
` evolved from the ID3 tagging system. The ID3v2 offers a flexible way
` of storing information about an audio file within itself to determine
` its origin and contents. The information may be technical
` information, such as equalisation curves, as well as related meta
` information, such as title, performer, copyright etc.
`
`1. Table of contents
` 2. Conventions in this document
` 3. ID3v2 overview
` 3.1. ID3v2 header
` 3.2. ID3v2 extended header
` 3.3. ID3v2 frames overview
` 3.3.1. Frame header flags
` 3.3.2. Default flags
` 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
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 1 of 34
`
`BMW EXHIBIT 1004
`
`

`

`Page 2 of 34
`
` 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. Commercial frame
` 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 List from ID3v1
` 9. Author's Address
`
`2. Conventions in this document
` In the examples, text within "" is a text string exactly as it
` appears in a file. Numbers preceded with $ are hexadecimal and
` numbers preceded with % are binary. $xx is used to indicate a byte
` with unknown content. %x is used to indicate a bit with unknown
` content. The most significant bit (MSB) of a byte is called 'bit 7'
` and the least significant bit (LSB) is called 'bit 0'.
` A tag is the whole tag described in this document. A frame is a block
` of information in the tag. The tag consists of a header, frames and
` optional padding. A field is a piece of information; one value, a
` string etc. A numeric string is a string that consists of the
` characters 0-9 only.
`
`3. ID3v2 overview
` The two biggest design goals were to be able to implement ID3v2
` without disturbing old software too much and that ID3v2 should be
` as flexible and expandable as possible.
` The first criterion is met by the simple fact that the MPEG [MPEG]
` decoding software uses a syncsignal, embedded in the audiostream, to
` 'lock on to' the audio. Since the ID3v2 tag doesn't contain a valid
` syncsignal, no software will attempt to play the tag. If, for any
` reason, coincidence make a syncsignal appear within the tag it will
` be taken care of by the 'unsynchronisation scheme' described in
` section 5.
` The second criterion has made a more noticeable impact on the design
` of the ID3v2 tag. It is constructed as a container for several
` information blocks, called frames, whose format need not be known to
` the software that encounters them. At the start of every frame there
` is an identifier that explains the frames' format and content, and a
` size descriptor that allows software to skip unknown frames.
` If a total revision of the ID3v2 tag should be needed, there is a
` version number and a size descriptor in the ID3v2 header.
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 2 of 34
`
`

`

`Page 3 of 34
`
` The ID3 tag described in this document is mainly targeted at files
` encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III
` and MPEG-2.5, but may work with other types of encoded audio.
` The bitorder in ID3v2 is most significant bit first (MSB). The
` byteorder in multibyte numbers is most significant byte first (e.g.
` $12345678 would be encoded $12 34 56 78).
` It is permitted to include padding after all the final frame (at the
` end of the ID3 tag), making the size of all the frames together
` smaller than the size given in the head of the tag. A possible
` purpose of this padding is to allow for adding a few additional
` frames or enlarge existing frames within the tag without having to
` rewrite the entire file. The value of the padding bytes must be $00.
`
`3.1. ID3v2 header
` The ID3v2 tag header, which should be the first information in the
` file, is 10 bytes as follows:
` ID3v2/file identifier "ID3"
` ID3v2 version $03 00
` ID3v2 flags %abc00000
` ID3v2 size 4 * %0xxxxxxx
` The first three bytes of the tag are always "ID3" to indicate that
` this is an ID3v2 tag, directly followed by the two version bytes. The
` first byte of ID3v2 version is it's major version, while the second
` byte is its revision number. In this case this is ID3v2.3.0. All
` revisions are backwards compatible while major versions are not. If
` software with ID3v2.2.0 and below support should encounter version
` three or higher it should simply ignore the whole tag. Version and
` revision will never be $FF.
` The version is followed by one the ID3v2 flags field, of which
` currently only three flags are used.
`
` a - Unsynchronisation
` Bit 7 in the 'ID3v2 flags' indicates whether or not
` unsynchronisation is used (see section 5 for details); a set bit
` indicates usage.
`
` b - Extended header
` The second bit (bit 6) indicates whether or not the header is
` followed by an extended header. The extended header is described in
` section 3.2.
`
` c - Experimental indicator
` The third bit (bit 5) should be used as an 'experimental
` indicator'. This flag should always be set when the tag is in an
` experimental stage.
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 3 of 34
`
`

`

`Page 4 of 34
`
` All the other flags should be cleared. If one of these undefined
` flags are set that might mean that the tag is not readable for a
` parser that does not know the flags function.
` The ID3v2 tag size is encoded with four bytes where the most
` significant bit (bit 7) is set to zero in every byte, making a total
` of 28 bits. The zeroed bits are ignored, so a 257 bytes long tag is
` represented as $00 00 02 01.
` The ID3v2 tag size is the size of the complete tag after
` unsychronisation, including padding, excluding the header but not
` excluding the extended header (total tag size - 10). Only 28 bits
` (representing up to 256MB) are used in the size description to avoid
` the introducuction of 'false syncsignals'.
` An ID3v2 tag can be detected with the following pattern:
` $49 44 33 yy yy xx zz zz zz zz
` Where yy is less than $FF, xx is the 'flags' byte and zz is less than
` $80.
`
`3.2. ID3v2 extended header
` The extended header contains information that is not vital to the
` correct parsing of the tag information, hence the extended header is
` optional.
` Extended header size $xx xx xx xx
` Extended Flags $xx xx
` Size of padding $xx xx xx xx
` Where the 'Extended header size', currently 6 or 10 bytes, excludes
` itself. The 'Size of padding' is simply the total tag size excluding
` the frames and the headers, in other words the padding. The extended
` header is considered separate from the header proper, and as such is
` subject to unsynchronisation.
` The extended flags are a secondary flag set which describes further
` attributes of the tag. These attributes are currently defined as
` follows
` %x0000000 00000000
`
` x - CRC data present
` If this flag is set four bytes of CRC-32 data is appended to the
` extended header. The CRC should be calculated before
` unsynchronisation on the data between the extended header and the
` padding, i.e. the frames and only the frames.
` Total frame CRC $xx xx xx xx
`
`3.3. ID3v2 frame overview
` As the tag consists of a tag header and a tag body with one or more
` frames, all the frames consists of a frame header followed by one or
` more fields containing the actual information. The layout of the
` frame header:
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 4 of 34
`
`

`

`Page 5 of 34
`
` Frame ID $xx xx xx xx (four characters)
` Size $xx xx xx xx
` Flags $xx xx
` The frame ID made out of the characters capital A-Z and 0-9.
` Identifiers beginning with "X", "Y" and "Z" are for experimental use
` and free for everyone to use, without the need to set the
` experimental bit in the tag header. Have in mind that someone else
` might have used the same identifier as you. All other identifiers are
` either used or reserved for future use.
` The frame ID is followed by a size descriptor, making a total header
` size of ten bytes in every frame. The size is calculated as frame
` size excluding frame header (frame size - 10).
` In the frame header the size descriptor is followed by two flags
` bytes. These flags are described in section 3.3.1.
` There is no fixed order of the frames' appearance in the tag,
` although it is desired that the frames are arranged in order of
` significance concerning the recognition of the file. An example of
` such order: UFID, TIT2, MCDI, TRCK ...
` A tag must contain at least one frame. A frame must be at least 1
` byte big, excluding the header.
` If nothing else is said a string is represented as ISO-8859-1
` [ISO-8859-1] characters in the range $20 - $FF. Such strings are
` represented as <text string>, or <full text string> if newlines are
` allowed, in the frame descriptions. All Unicode strings [UNICODE] use
` 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings
` must begin with the Unicode BOM ($FF FE or $FE FF) to identify the
` byte order.
` All numeric strings and URLs [URL] are always encoded as ISO-8859-1.
` Terminated strings are terminated with $00 if encoded with ISO-8859-1
` and $00 00 if encoded as unicode. If nothing else is said newline
` character is forbidden. In ISO-8859-1 a new line is represented, when
` allowed, with $0A only. Frames that allow different types of text
` encoding have a text encoding description byte directly after the
` frame size. If ISO-8859-1 is used this byte should be $00, if Unicode
` is used it should be $01. Strings dependent on encoding is
` represented as <text string according to encoding>, or <full text
` string according to encoding> if newlines are allowed. Any empty
` Unicode strings which are NULL-terminated may have the Unicode BOM
` followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).
` The three byte language field is used to describe the language of the
` frame's content, according to ISO-639-2 [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 ID3v2 standard. This
` is reflected by the revision number in the header of the tag.
`
`3.3.1. Frame header flags
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 5 of 34
`
`

`

`Page 6 of 34
`
` In the frame header the size descriptor is followed by two flags
` bytes. All unused flags must be cleared. The first byte is for
` 'status messages' and the second byte is for encoding purposes. If an
` unknown flag is set in the first byte the frame may not be changed
` without the bit cleared. If an unknown flag is set in the second byte
` it is likely to not be readable. The flags field is defined as
` follows.
` %abc00000 %ijk00000
`
` a - Tag alter preservation
` This flag tells the software what to do with this frame if it is
` unknown and the tag is altered in any way. This applies to all
` kinds of alterations, including adding more padding and reordering
` the frames.
` 0 Frame should be preserved.
` 1 Frame should be discarded.
`
` b - File alter preservation
` This flag tells the software what to do with this frame if it is
` unknown and the file, excluding the tag, is altered. This does not
` apply when the audio is completely replaced with other audio data.
` 0 Frame should be preserved.
` 1 Frame should be discarded.
`
` c - Read only
` This flag, if set, tells the software that the contents of this
` frame is intended to be read only. Changing the contents might
` break something, e.g. a signature. If the contents are changed,
` without knowledge in why the frame was flagged read only and
` without taking the proper means to compensate, e.g. recalculating
` the signature, the bit should be cleared.
`
` i - Compression
` This flag indicates whether or not the frame is compressed.
` 0 Frame is not compressed.
` 1 Frame is compressed using zlib [zlib] with 4 bytes for
` 'decompressed size' appended to the frame header.
`
` j - Encryption
` This flag indicates wether or not the frame is enrypted. If set
` one byte indicating with which method it was encrypted will be
` appended to the frame header. See section 4.26. for more
` information about encryption method registration.
` 0 Frame is not encrypted.
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 6 of 34
`
`

`

`Page 7 of 34
`
` 1 Frame is encrypted.
`
` k - Grouping identity
` This flag indicates whether or not this frame belongs in a group
` with other frames. If set a group identifier byte is added to the
` frame header. Every frame with the same group identifier belongs
` to the same group.
` 0 Frame does not contain group information
` 1 Frame contains group information
`
` Some flags indicates that the frame header is extended with
` additional information. This information will be added to the frame
` header in the same order as the flags indicating the additions. I.e.
` the four bytes of decompressed size will preceed the encryption
` method byte. These additions to the frame header, while not included
` in the frame header size but are included in the 'frame size' field,
` are not subject to encryption or compression.
`
`3.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 software.
` 1. Discarded if tag is altered, discarded if file is altered.
` None.
` 2. Discarded if tag is altered, preserved if file is altered.
` None.
` 3. Preserved if tag is altered, discarded if file is altered.
` AENC, ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ
` 4. Preserved if tag is altered, preserved if file is altered.
` The rest of the frames.
`
`4. Declared ID3v2 frames
` The following frames are declared in this draft.
` 4.21 AENC Audio encryption
` 4.15 APIC Attached picture
` 4.11 COMM Comments
` 4.25 COMR Commercial frame
` 4.26 ENCR Encryption method registration
` 4.13 EQUA Equalization
` 4.6 ETCO Event timing codes
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 7 of 34
`
`

`

`Page 8 of 34
`
` 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.14 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.1 TCOM Composer
` 4.2.1 TCON Content type
` 4.2.1 TCOP Copyright message
` 4.2.1 TDAT Date
` 4.2.1 TDLY Playlist delay
` 4.2.1 TENC Encoded by
` 4.2.1 TEXT Lyricist/Text writer
` 4.2.1 TFLT File type
` 4.2.1 TIME Time
` 4.2.1 TIT1 Content group description
` 4.2.1 TIT2 Title/songname/content description
` 4.2.1 TIT3 Subtitle/Description refinement
` 4.2.1 TKEY Initial key
` 4.2.1 TLAN Language(s)
` 4.2.1 TLEN 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 owner/licensee
` 4.2.1 TPE1 Lead performer(s)/Soloist(s)
` 4.2.1 TPE2 Band/orchestra/accompaniment
` 4.2.1 TPE3 Conductor/performer refinement
` 4.2.1 TPE4 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.1 TSIZ Size
` 4.2.1 TSRC ISRC (international standard recording code)
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 8 of 34
`
`

`

`Page 9 of 34
`
` 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 Unsychronized lyric/text transcription
` 4.3.1 WCOM Commercial information
` 4.3.1 WCOP Copyright/Legal information
` 4.3.1 WOAF Official audio file webpage
` 4.3.1 WOAR Official artist/performer webpage
` 4.3.1 WOAS Official audio source webpage
` 4.3.1 WORS Official internet radio station homepage
` 4.3.1 WPAY Payment
` 4.3.1 WPUB Publishers official webpage
` 4.3.2 WXXX User defined URL link frame
`
`4.1. Unique file identifier
` This frame's purpose is to be able to identify the audio file in a
` database that may 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. The string
` "http://www.id3.org/dummy/ufid.html" should be used for tests.
` Software that isn't told otherwise may safely remove such frames. The
` 'Owner identifier' must be non-empty (more than just a termination).
` The 'Owner identifier' is then followed by the actual identifier,
` which may be up to 64 bytes. There may be more than one "UFID" frame
` in a tag, but only one with the same 'Owner identifier'.
` <Header for 'Unique file identifier', ID: "UFID">
` Owner identifier <text string> $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 text frame identifiers
` begin with "T". Only text frame identifiers begin with "T", with the
` exception of the "TXXX" frame. All the text information frames have
` the following format:
` <Header for 'Text information frame', ID: "T000" - "TZZZ",
` excluding "TXXX" described in 4.2.2.>
` Text encoding $xx
` Information <text string according to encoding>
`
`4.2.1. Text information frames - details
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 9 of 34
`
`

`

`Page 10 of 34
`
` TALB
` The 'Album/Movie/Show title' frame is intended for the title of the
` recording(/source of sound) which the audio in the file is taken
` from.
` TBPM
` The 'BPM' frame contains the number of beats per minute in the
` mainpart of the audio. The BPM is an integer and represented as a
` numerical string.
` TCOM
` The 'Composer(s)' frame is intended for the name of the composer(s).
` They are seperated with the "/" character.
` TCON
` The 'Content type', which previously was stored as a one byte numeric
` value only, is now a numeric string. You may use one or several of
` the types as ID3v1.1 did or, since the category list would be
` impossible to maintain with accurate and up to date categories,
` define your own.
` References to the ID3v1 genres can be made by, as first byte, enter
` "(" followed by a number from the genres list (appendix A.) and
` ended with a ")" character. This is optionally followed by a
` refinement, e.g. "(21)" or "(4)Eurodisco". Several references can be
` made in the same frame, e.g. "(51)(39)". If the refinement should
` begin with a "(" character it should be replaced with "((", e.g. "((I
` can figure out any genre)" or "(55)((I think...)". The following new
` content types is defined in ID3v2 and is implemented in the same way
` as the numerig content types, e.g. "(RX)".
` RX Remix
` CR Cover
` TCOP
` The 'Copyright message' frame, which must begin with a year and a
` space character (making five characters), is intended for the
` copyright holder of the original sound, not the audio file itself.
` The absence of this frame means only that the copyright information
` is unavailable or has been removed, and must not be interpreted to
` mean that the sound is public domain. Every time this field is
` displayed the field must be preceded with "Copyright " (C) " ", where
` (C) is one character showing a C in a circle.
` TDAT
` The 'Date' frame is a numeric string in the DDMM format containing
` the date for the recording. This field is always four characters
` long.
` TDLY
` The 'Playlist delay' defines the numbers of milliseconds of silence
` between every song in a playlist. The player should use the "ETC"
` frame, if present, to skip initial silence and silence at the end of
` the audio to match the 'Playlist delay' time. The time is represented
` as a numeric string.
` TENC
` The 'Encoded by' frame contains the name of the person or
` organisation that encoded the audio file. This field may contain a
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 10 of 34
`
`

`

`Page 11 of 34
`
` copyright message, if the audio file also is copyrighted by the
` encoder.
` TEXT
` The 'Lyricist(s)/Text writer(s)' frame is intended for the writer(s)
` of the text or lyrics in the recording. They are seperated with the
` "/" character.
` TFLT
` The 'File type' frame indicates which type of audio this tag defines.
` The following type and refinements are defined:
` MPG MPEG Audio
` /1 MPEG 1/2 layer I
` /2 MPEG 1/2 layer II
` /3 MPEG 1/2 layer III
` /2.5 MPEG 2.5
` /AAC Advanced audio compression
` VQF Transform-domain Weighted Interleave Vector Quantization
` PCM Pulse Code Modulated audio
` but other types may be used, not for these types though. This is used
` in a similar way to the predefined types in the "TMED" frame, but
` without parentheses. If this frame is not present audio type is
` assumed to be "MPG".
` TIME
` The 'Time' frame is a numeric string in the HHMM format containing
` the time for the recording. This field is always four characters
` long.
` TIT1
` The 'Content group description' frame is used if the sound belongs to
` a larger category of sounds/music. For example, classical music is
` often sorted in different musical sections (e.g. "Piano Concerto",
` "Weather - Hurricane").
` TIT2
` The 'Title/Songname/Content description' frame is the actual name of
` the piece (e.g. "Adagio", "Hurricane Donna").
` TIT3
` The 'Subtitle/Description refinement' frame is used for information
` directly related to the contents title (e.g. "Op. 16" or "Performed
` live at Wembley").
` TKEY
` The 'Initial key' frame contains the musical key in which the sound
` starts. It is represented as a string with a maximum length of three
` characters. The ground keys are represented with "A","B","C","D","E",
` "F" and "G" and halfkeys represented with "b" and "#". Minor is
` represented as "m". Example "Cbm". Off key is represented with an "o"
` only.
` TLAN
` The 'Language(s)' frame should contain the languages of the text or
` lyrics spoken or sung in the audio. The language is represented with
` three characters according to ISO-639-2. If more than one language is
` used in the text their language codes should follow according to
` their usage.
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 11 of 34
`
`

`

`Page 12 of 34
`
` TLEN
` The 'Length' frame contains the length of the audiofile in
` milliseconds, represented as a numeric string.
` TMED
` The 'Media type' frame describes from which media the sound
` originated. This may be a text string or a reference to the
` predefined media types found in the list below. References are made
` within "(" and ")" and are optionally followed by a text refinement,
` e.g. "(MC) with four channels". If a text refinement should begin
` with a "(" character it should be replaced with "((" in the same way
` as in the "TCO" frame. Predefined refinements is appended after the
` media type, e.g. "(CD/A)" or "(VID/PAL/VHS)".
` DIG Other digital media
` /A Analog transfer from media
` ANA Other analog media
` /WAC Wax cylinder
` /8CA 8-track tape cassette
` CD CD
` /A Analog transfer from media
` /DD DDD
` /AD ADD
` /AA AAD
` LD Laserdisc
` /A Analog transfer from media
` TT Turntable records
` /33 33.33 rpm
` /45 45 rpm
` /71 71.29 rpm
` /76 76.59 rpm
` /78 78.26 rpm
` /80 80 rpm
` MD MiniDisc
` /A Analog transfer from media
` DAT DAT
` /A Analog transfer from media
` /1 standard, 48 kHz/16 bits, linear
` /2 mode 2, 32 kHz/16 bits, linear
` /3 mode 3, 32 kHz/12 bits, nonlinear, low speed
` /4 mode 4, 32 kHz/12 bits, 4 channels
` /5 mode 5, 44.1 kHz/16 bits, linear
` /6 mode 6, 44.1 kHz/16 bits, 'wide track' play
` DCC DCC
` /A Analog transfer from media
` DVD DVD
` /A Analog transfer from media
` TV Television
` /PAL PAL
` /NTSC NTSC
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 12 of 34
`
`

`

`Page 13 of 34
`
` /SECAM SECAM
` VID Video
` /PAL PAL
` /NTSC NTSC
` /SECAM SECAM
` /VHS VHS
` /SVHS S-VHS
` /BETA BETAMAX
` RAD Radio
` /FM FM
` /AM AM
` /LW LW
` /MW MW
` TEL Telephone
` /I ISDN
` MC MC (normal cassette)
` /4 4.75 cm/s (normal speed for a two sided cassette)
` /9 9.5 cm/s
` /I Type I cassette (ferric/normal)
` /II Type II cassette (chrome)
` /III Type III cassette (ferric chrome)
` /IV Type IV cassette (metal)
` REE Reel
` /9 9.5 cm/s
` /19 19 cm/s
` /38 38 cm/s
` /76 76 cm/s
` /I Type I cassette (ferric/normal)
` /II Type II cassette (chrome)
` /III Type III cassette (ferric chrome)
` /IV Type IV cassette (metal)
` TOAL
` The 'Original album/movie/show title' frame is intended for the title
` of the original recording (or source of sound), if for example the
` music in the file should be a cover of a previously released song.
` TOFN
` The 'Original filename' frame contains the preferred filename for the
` file, since some media doesn't allow the desired length of the
` filename. The filename is case sensitive and includes its suffix.
` TOLY
` The 'Original lyricist(s)/text writer(s)' frame is intended for the
` text writer(s) of the original recording, if for example the music in
` the file should be a cover of a previously released song. The text
` writers are seperated with the "/" character.
` TOPE
` The 'Original artist(s)/performer(s)' frame is intended for the
` performer(s) of the original recording, if for example the music in
` the file should be a cover of a previously released song. The
` performers are seperated with the "/" character.
` TORY
`
`https://web.archive.org/web/20001206090000if_/http://www.id3.org:80/id3v2.3.0.txt
`
`5/30/2018
`
`Page 13 of 34
`
`

`

`Page 14 of 34
`
` The 'Original release year' frame is intended for the year when the
` original recording, if for example the music in the file should be a
` cover of a previously released song, was released. The field is
` formatted as in the "TYER" frame.
` TOWN
` The 'File owner/licensee' frame contains the name of the owner or
` licensee of the file and it's contents.
` TPE1
` The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is
` used for the main artist(s). They are seperated with the "/"
` character.
` TPE2
` The 'Band/Orchestra/Accompaniment' frame is used for additional
` information about the performers in the recording.
` TPE3
` The 'Conductor' frame is used for the name of the conductor.
` TPE4
` The 'Interpreted, remixed, or otherwise modified by' frame contains
` more information about the people behind a remix and similar
` interpretations of another existing piece.
` TPOS
` The 'Part of a set' frame is a numeric string that describes which
` part of a set the audio came from. This frame is used if the source
` described in the "TALB" frame is divided into several mediums, e.g. a
` double CD. The value may be extended with a "/" character and a
` numeric string containing the total number of parts in the set. E.g.
` "1/2".
` TPUB
` The 'Publisher' frame simply contains the name of the label or
` publisher.
` TRCK
` The 'Track number/Position in set' frame is a numeric string
` containing the order number of the audio-file on its original
` recording. This may be extended with a "/" character and a numeric
` string containing the total numer of tracks/elements on the original
` recording. E.g. "4/9".
` TRDA
` The 'Recording dates' frame is a intended to be used as complement to
` the "TYE