musicmatch.txt

本人收集整理的一份c/c++跨平台网络库

$Id: musicmatch.txt,v 1.4 2000/09/09 23:02:37 eldamitri Exp $


                    MusicMatch (TM) tag format description

Status of this document

    This document is a description of a deprecated tagging format.  The
    information contained herein is not a specification; its intent is to
    interpret the format based on hundreds of examples.  It also relies heavily
    on information obtained by others who have done similar investigations.  It
    is not based on any official documentation of the format, as such
    documentation is not publicly available.  Therefore the contents of this
    document may change to adjust for newly-discovered information, but the
    format itself is unlikely to change due to its deprecation.

    Distribution of this document is unlimited.


Abstract

    This document describes the MusicMatch tagging format present in some
    digital audio files.  This format, like other tagging specifications,
    provides a method for storing information about an audio file within itself
    to document its contents.  This format was developed by MusicMatch and
    used exclusively by older versions of Jukebox, their popular, "all-in-one"
    MP3 application.

1.  Table of contents

        Status of this document
        Abstract
   1.   Table of contents
   2.   Introduction
   3.   Conventions in this document
   4.   Tagging format
     4.1.   Header
     4.2.   Image extension
     4.3.   Image binary
     4.4.   Unused
     4.5.   Version information
     4.6.   Audio meta-data
       4.6.1.   Single-line text fields
       4.6.2.   Non-text fields
       4.6.3.   Multi-line text fields
       4.6.4.   Internet addresses
       4.6.5.   Padding
     4.7.   Data offsets
     4.8.   Footer
   5.   Identifying and parsing a MusicMatch tag
   6.   Converting to ID3v2
   7.   Copyright
   8.   References
   9.   Author's Address


2.  Introduction

    The following document describes the structure of the tagging format used
    by MusicMatch (TM) Jukebox, prior to version 4.0 of that application.  This
    program is a so-called "All-In-One" MP3 program and provides a CD-Ripper,
    WAV-to-MP3 converter, database, and MP3 player.

    The MusicMatch tagging format has gone through several incremental
    iterations in its format, although the basic structure has remained fairly
    constant throughout its history.  The various formats of the MusicMatch tag
    have been tightly coupled with the version of Jukebox that created it.  As
    such, this document will refer to the Jukebox version and tagging format
    version interchangeably.

    As of version 4.0, MusicMatch has deprecated the use of this format in
    their own Jukebox application, transitioning instead to ID3v2, an open
    standard for tagging digital audio.  Unfortunately, despite repeated
    requests, MusicMatch has not provided to the public any documents
    describing this format, and the MusicMatch Jukebox is the only
    widely-distributed software application that can read and write these tags.

    As such, this text may not be completely accurate and is surely incomplete,
    but it covers enough to the format to enable one to write robust software
    to find and parse tags in this format.  For example, the id3lib tagging
    library's MusicMatch parsing routines were written solely based on the
    information found in this document.  However, the authors cannot be held
    responsible for any inaccuracies or any harm caused by using this
    information.  One can assume that the specifition is unlikely to change,
    given MusicMatch's own abandonment of the format.  It should also be noted
    that incoporating functionality into applications to write tags in this
    format is discouraged, as the format has been officially deprecated by
    MusicMatch themselves.

3.  Conventions in this document

    This document borrows heavily from specifications written by Martin
    Nillson, author of the ID3v2 tagging standard.  Much of the structure,
    formatting, and other such conventions used in the ID3v2 specifications are
    carried over into 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.

4.  Tag overview

    The MusicMatch Tagging Format was designed to store specific types of audio
    meta-data inside the audio file itself.  As the format was used exclusively
    by the MusicMatch Jukebox application, it is used only with MPEG-1/2 layer
    III files encoded with that program.  However, its tagging format is not
    inherently exclusive of other audio formats, and could conceivably be
    used with other types of encodings.

    MusicMatch tags were originally designed to come at the very end of MP3
    files, after all of the MP3 audio frames.  Starting with Jukebox version
    3.1, the application became more ID3-friendly and started placing ID3v1
    tags after the MusicMatch tag as well.  In practice, since very few
    applications outside of the MusicMatch Jukebox are capable of reading and
    understanding this format, it is not unusual to find MusicMatch tags
    "buried" within mp3 files, coming before other types of tagging formats in
    a file, such as Lyrics3 or ID3v2.4.0.  Such "relocations" are not uncommon,
    and therefore any software application that intends to find, read, and
    parse MusicMatch tags should be flexible in this endeavor, despite the
    apparent intentions of the original specification.

    Although various sections of a MusicMatch tag are fixed in length, other
    sections are not, and so tag lengths can vary from one file to another.  A
    valid MusicMatch tag will be at least 8 kilobytes (8192 bytes) in length.
    Those tags with image data will often be much larger.

    The byte-order in 4-byte pointers and multibyte numbers for MusicMatch tags
    is least-significant byte (LSB) first, also known as "little endian".  For
    example, $12345678 is encoded as $78 56 34 12.

    Overall tag structure:

      +-----------------------------+
      |           Header            |
      |    (256 bytes, OPTIONAL)    |
      +-----------------------------+
      |  Image extension (4 bytes)  |
      +-----------------------------+
      |        Image binary         |
      |  (var. length >= 4 bytes)   |
      +-----------------------------+
      |      Unused (4 bytes)       |
      +-----------------------------+
      |  Version info (256 bytes)   |
      +-----------------------------+
      |       Audio meta-data       |
      | (var. length >= 7868 bytes) |
      +-----------------------------+
      |   Data offsets (20 bytes)   |
      +-----------------------------+
      |      Footer (48 bytes)      |
      +-----------------------------+

    This document will describe the various sections of the tag in the order
    listed above (that is, in the sequential order that they appear when
    reading the tag from beginning to end).  However, due to the nature of the
    tag's format, in practice the tag's sections will often be parsed in the
    reverse order.  A robust parsing algorithm will be suggested and described
    later in the document.

4.1.  Header

    An optional tag header often precedes the tag data in a MusicMatch tag.
    Although the rules that determine this header's required presence are
    unknown, the header is usually found in tag versions up to and including
    2.50, and is usually lacking otherwise.  Luckily, its format is rigid and
    therefore its presence is easy to determine.  The data in the header are
    not vital to the correct parsing of the rest of the tag and can thus be
    discarded.  The header is the only optional section in a MusicMatch tag.
    All other sections are required to consider the tag valid.

    The header section is always 256 bytes in length.  It begins with three
    10-byte subsections, and ends with 226 bytes of space ($20) padding.  Each
    of the first three subsections contains an 8-byte ASCII text string
    followed by two bytes of null ($00) padding.

    The first subsection serves as a sync string: its 8-byte string is always
    "18273645".

    The second subsection's 8-byte string is the version of the Xing encoder
    used to encode the mp3 file.  The last four bytes of this string are
    usually '0' ($30).  An example of this string is "1.010000".

    The third and final 10-byte subsection is the version of the MusicMatch
    Jukebox used to encode the mp3 file.  The last four bytes of this string
    are usually '0' ($30).  An example of this string is "2.120000".

      Sync string                "18273645"
      Null padding               $00 00
      Xing encoder version       <8-byte numerical ASCII string>
      Null padding               $00 00
      MusicMatch version         <8-byte numerical ASCII string>
      Null padding               $00 00
      Space padding        226 * $20

4.2.  Image extension

    MusicMatch tags can contain at most one image.  This first required section
    is the extension of the image when saved as a file (for example, "jpg" or
    "bmp").  This section is 4 bytes in length, and the data is padded with
    spaces ($20) if the extension doesn't use all 4 bytes (in practice, 3-byte
    extensions are the most prevalent).  Likewise, tags without images have all
    spaces for this section (4 * $20).

      Picture extension           $xx xx xx xx

4.3.  Image binary

    When an image is present in the tag, the image binary section consists of
    two fields.  The first field is the size of the image data, in bytes.  The
    second is the actual image data.

      Image size                  $xx xx xx xx
      Image data                  <binary data>

    If no image is present, the image binary section consists of exactly four
    null bytes ($00 00 00 00).

4.4.  Unused

    This section is never used, to the best of the author's knowledge.  It is
    always 4 null ($00) bytes.

      Null padding               $00 00 00 00

4.5.  Version information

    This section of the tag has the exact same format as the header.  Unlike
    the header, this section is required for the tag to be considered valid.

      Sync string                "18273645"
      Null padding               $00 00
      Xing encoder version       <8-byte numerical ASCII string>
      Null padding               $00 00
      MusicMatch version         <8-byte numerical ASCII string>
      Null padding               $00 00
      Space padding        226 * $20

4.6.  Audio meta-data

    The audio meta-data is the heart of the MusicMatch tag.  It contains most
    of the pertinent information found in other tagging formats (song title,
    album title, artist, etc.) and some that are unique to this format (mood,
    prefernce, situation).

    In all versions of the MusicMatch format up to and including 3.00, this
    section is always 7868 bytes in length.  All subsequent versions allowed
    three possible lengths for this section: 7936, 8004, and 8132 bytes.  The
    conditions under which a particular length from these three possibilities
    was used is unknown.  In all cases, this section is padded with dashes 
    ($2D) to achieve this constant size.

    Due to the great number of fields in this portion of the tag, they are
    divided amongst the next four sections of the document: single-line text
    fields, non-text fields, multi-line text fields, and internet addresses.
    This clarification is somewhat arbitrary and somewhat inaccurate (some of
    the fields described as "non-text" are indeed ASCII strings).  However, the
    clarification does allow for easier description of the meta-data as a
    whole.  At any rate, the actual fields in this section of the tag appear
    sequentially in the order presented.
    

4.6.1.  Single-line text fields

    The first group entries in this section of the tag are variable-length