musicmatch.txt

更新mp3

    ASCII text strings.  Each of these strings are preceded by a two-byte field
    describing the size of the following string (again, in LSB order).
    Multiple entries in a text field are separated by a semicolon ($3B).  An
    empty (and non-existant) text field is indicated by a size field of 0 ($00
    00).

    The first three of these entries are fairly-self explanatory: song title,
    album title, and artist name.

    The final five entries are a little less common: Genre, Tempo, Mood,
    Situation, and Preference.  These fields can contain any information, but
    do to the interface and default set-up for the Jukebox application, they
    typically are limited to a subset of possibilities.

    The Genre entry differs from the ID3v1 tagging format in that it allows
    a full-text genre description, whereas ID3v1 maps a number to a list of
    genres.  Again, the genre description could be anything, but the interface
    in Jukebox typically limited most users to the standard ID3v1 genres.

    The Tempo entry is intended to describe the general tempo of the song.  The
    Jukebox application provided the following defaults: None, Fast, Pretty
    fast, Moderate, Pretty slow, and Slow.

    The Mood entry describes what type of mood the audio establishes: Typical
    values include the following: None, Wild, Upbeat, Morose, Mellow, Tranquil,
    and Comatose.

    The Situation entry describes in which situation this music is best played.
    Expect the following: None, Dance, Party, Romantic, Dinner, Background, 
    Seasonal, Rave, and Drunken Brawl.

    The Preference entry allows the user to rate the song.  Possible values
    include the following: None, Excellent, Very Good, Good, Fair, Poor, and
    Bad Taste.

      Song title length          $xx xx
      Song title                 <ASCII string>
      Album title length         $xx xx
      Album title                <ASCII string>
      Artist name length         $xx xx
      Artist name                <ASCII string>
      Genre length               $xx xx
      Genre                      <ASCII string>
      Tempo length               $xx xx
      Tempo                      <ASCII string>
      Mood length                $xx xx
      Mood                       <ASCII string>
      Situation length           $xx xx
      Situation                  <ASCII string>
      Preference length          $xx xx
      Preference                 <ASCII string>

4.6.2.  Non-text fields

    The next group of fields is described here as "non-text".  They are 
    probably better described as entries that are auto-created (i.e., not
    entered in by a user), although this isn't entirely accurate, either, as
    the track number field is determined by user input.  At any rate, they've
    been separated to clarify the presentation of the material.

    The "Song duration" entry consists of two fields: a size and text.  The
    text is formatted as "minutes:seconds", and thus the size field is 
    typically 4 ($04 00).

    The only field that is neither a string nor a LSB numerical value is the
    creation date.  It is 8-byte floating-point value.  It can be interpreted
    as a TDateTime in the Delphi programming language, where the integral 
    portion is the number of elapsed days since 1899-12-30, and the mantissa 
    portion represents the fractional portion of that day, where .0 would be 
    midnight, .5 would be noon, and .99999... would be just before midnight 
    of the next day.  In practice, this field is typically unused and will be
    filled with 8 null ($00) bytes.
    
    The next field is the play counter, presumably maintained by the Jukebox
    application.  Most of the time this field is unused, and is typically 0
    ($00 00 00 00).

    The next entry is a size/text combo and represents the original filename
    and path.  As these tags were created almost universally on Windows
    machines, the entries are typically in the form of "C:\path\to\file.mp3".

    The next size/text entry is the album serial number fetched from the online
    CDDB when a track is ripped with MusicMatch.

    The final field is the track number, usually entered automatically when
    ripping, encoding, and tagging the audio off from a CD using CDDB.

      Song duration length       $xx xx
      Song duration              <ASCII string>
      Creation date              <8-byte IEEE-64 float>
      Play counter               $xx xx xx xx
      Original filename length   $xx xx
      Original filename          <ASCII string>
      Serial number length       $xx xx
      Serial number              <ASCII string>
      Track number               $xx xx

4.6.3.  Multi-line text fields

    The next three entries are typically multi-line entries.  All line
    separators use the Windows-standard carriage return ($0D 0A).  As with the
    single-line text entries, the text fields are preceded by LSB size fields
    which indicate their length.

      Notes length               $xx xx
      Notes                      <ASCII string>
      Artist bio length          $xx xx
      Artist bio                 <ASCII string>
      Lyrics length              $xx xx
      Lyrics                     <ASCII string>

4.6.4.  Internet addresses

    The final group of meta-data are internet addresses.  As with other text
    entries, the text fields are preceded by LSB size fields.

      Artist URL length          $xx xx
      Artist URL                 <ASCII string>
      "Buy CD" URL length        $xx xx
      "Buy CD" URL               <ASCII string>
      Artist email length        $xx xx
      Artist email               <ASCII string>

4.6.5.  Padding
 
    The data fields are then followed by 16 null ($00) bytes.  Presumably these
    were intended for (up to 8) future text fields.

    The remainder of this section is padded with '-' ($2D) characters.

4.7.  Data offsets

    This section of the tag was intended to give offsets into the file for each
    of the five major required sections of the tag.  The offsets, however, are
    off by 1; for searching a file where the first position is offset 0, the
    offset given here must be reduced by 1.  In practice, however, these
    offsets can often be invalid, since the data that comes before may be
    increased or reduces (such as when an ID3v2 tag is appended to the file).
    Therefore these offsets are best used to calculate the size of the sections
    by finding the difference of two consecutive offsets.  Obviously, the size
    of the audio meta-data section must be calculated in a different manner.

      Image extension offset     $xx xx xx xx
      Image binary offset        $xx xx xx xx  
      Unused offset              $xx xx xx xx
      Version info offset        $xx xx xx xx
      Audio meta-data offset     $xx xx xx xx

4.8.  Footer

    Unlike the header, the footer is a required section of any MusicMatch tag,
    and checking for its existance is an easy way to determine if a file has a
    MusicMatch tag.  It is always 48 bytes in length.  The first 19 bytes is
    the company name "Brava Software Inc." (Note: it seems that the company
    name has officially changed to MusicMatch, as "Brava Software" is not
    mentioned anywhere on their website), followed by 13 bytes of space ($20)
    padding.  The next 4 bytes is the tag version as a numerical ASCII string
    (e.g., "3.05"), and should match the version string found in the Version
    section and the (optional) header.  This is followed by 12 bytes of space
    ($20) padding.

      Signature                  "Brava Software Inc."
      Space padding         13 * $20
      Tag version                <4-byte numerical ASCII string>
      Space padding         12 * $20

5.   Identifying and parsing a MusicMatch tag

    Finding and parsing a MusicMatch tag is not difficult to do, but due to 
    lack of foresight and questionable design decisions by MusicMatch, care 
    must be taken to ensure it is done correctly.

    <unfinished />

6.   Converting to ID3v2

    As of Jukebox 4.0, MusicMatch has abandoned the MusicMatch tagging format
    in favor of the open standard ID3v2.  The Jukebox application will convert
    old tags to ID3v2 upon request, but as this is a closed application that
    serves a limited number of platforms (currently on Windows and Macintosh),
    having a public specification for performing this mapping is necessary.  As
    ID3v2 can encapsulate all of the information found in the original
    MusicMatch format while being infinitely more flexible, the decision to
    convert shouldn't be a difficult one.

    <unfinished />

7.   Copyright

    Copyright (C) Scott Thomas Haug 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

    [MMTrailer] Peter "The Videoripper" Luijer, 
    'Description of the MusicMatch trailer in MP3 files'

      <url:http://members.xoom.com/videoripper/warez/mmtrailer.txt>

    [ID3v2] Martin Nilsson, 'ID3v2 informal standard'.

      <url:http://www.id3.org/id3v2.3.0.txt>

    [id3lib] Scott Thomas Haug, 'The ID3v1/ID3v2 Tagging Library'
 
      <url:http://www.id3lib.org>

    [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>

    [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)'

    [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>


9.   Author's Address

    Written by

      Scott Thomas Haug
      Seattle, WA
      USA