tag: id3v2: add specs to git for reference
authorTim-Philipp Müller <tim.muller@collabora.co.uk>
Sun, 14 Aug 2011 19:44:19 +0000 (20:44 +0100)
committerTim-Philipp Müller <tim.muller@collabora.co.uk>
Sun, 14 Aug 2011 23:10:35 +0000 (00:10 +0100)
gst-libs/gst/tag/id3v2.3.0.txt [new file with mode: 0644]
gst-libs/gst/tag/id3v2.4.0-frames.txt [new file with mode: 0644]
gst-libs/gst/tag/id3v2.4.0-structure.txt [new file with mode: 0644]

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