ID3v2



  • Ever read the spec for this fun little toy?  I'll quote a few of my favorites parts from http://www.id3.org/id3v2.3.0.txt.

    "This flag indicates wether or not the frame is enrypted."

    "$11  A bright coloured fish" (enumeration for picture type)

    "$0D  momentary unwanted noise (Snap, Crackle & Pop)"


    It's all fun and games until someone loses a brightly coloured fish :(



  • Sadly, the site seems to have been down for a couple hours.



  • Google has a cache


    I guess it's an easter egg?  Googling the term "A bright coloured fish" turns up a half dozen blog entries which share in your confusion.

     



  • [quote user="Jud"]

    "$11  A bright coloured fish" (enumeration for picture type)

    [/quote]

    Xiph fish? Vorbis ogg reference maybe. http://images.google.com/images?q=Xiph Fish 

    [quote user="Jud"]

    "$0D  momentary unwanted noise (Snap, Crackle & Pop)"

    [/quote]

    Why make fun of it? If many programs accepted tagging frames like this, I'd gladly mark cracks on my recording while listening on some normal / mobile player and later browse / work on them in adobe audition / whatever.

    Very good idea with timestamp tagging.



  • The bright coloured fish, is, of course, a red herring.



  • The Real WTF™ is that the spec is practically impossible to implement. Jeff Atwood complained about it a couple of months ago. It's right up there with CSV as one of the weirdest and most inconsistently implemented specs, full of cruft and special cases.



  • It's too bad the site is down.  The spec is really quite a treat.

    If ANYONE can tell me what I'm supposed to do when the event type is 0xFF, I'll do a backflip and a cartwheel for you.  Is it padding, just keep reading 0xFF until you hit a real value, or is some kind of chain implied?  I can't figure this one out.

    [quote user="id3.org"]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 [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 & 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.

    [/quote]



  • [quote user="Jud"]

    It's too bad the site is down.  The spec is really quite a treat.

    If ANYONE can tell me what I'm supposed to do when the event type is 0xFF, I'll do a backflip and a cartwheel for you.  Is it padding, just keep reading 0xFF until you hit a real value, or is some kind of chain implied?  I can't figure this one out.

    [/quote]

    OK I think I got this.  I think it's intended to take care of values over 0xFF, so if a future revision uses "0x100" it will be encoded as 0xFF 0x01.  The SYTC frame uses this convention for BPM over 255.

    Or I could be totally wrong.



  • [quote user="Jud"]

    It's too bad the site is down.  The spec is really quite a treat.

    If ANYONE can tell me what I'm supposed to do when the event type is 0xFF, I'll do a backflip and a cartwheel for you.  Is it padding, just keep reading 0xFF until you hit a real value, or is some kind of chain implied?  I can't figure this one out.

    [/quote]

    Personally I'd bet on this one: "just keep reading 0xFF until you hit a real value".

    The evolution of the spec is also a WTF in itself. Like how unsynchronisation is done on the tag level in ID3v2.3.0, and switched to the frame level in ID3v2.4.0, while still keeping the (now useless) global unsynchronisation flags of v2.3.0.

    You gotta love the layout of the v2.3.0 document too: it basically describes the whole spec without explaining what this unsynchronisation is (it's masking parts of the tag that look like an mpeg synchronisation sequence), leaving it for the very end, just before the copyright notice. The v2.4.0 spec tries to alleviate the pain by splitting the structure spec into a separate document, but still makes the same mistake. sigh


Log in to reply