ogg dev - Jun 2009 - Fixing ogg vorbis corruption caused by bad metadata

Conrad Parker wrote, on 6/20/2009 10:24 PM:
>> How about another approach -- is there a tool that will verify the page
>> checksums? oggz-validate doesn't seem to do this. If the page
checksums
>> are okay, then doesn't that suggest the streams are also
recoverable?
> If the page checksums are bad then the page will get rejected by
> libogg, and oggz-validate won't even see it (or its packets).
"hogg
> dumpraw" will at least show the page CRC and segment table, before
> verifying the CRC, which could be useful.
Does it actually check the CRC, or is there some way for me to do so? I 
see the output from hogg dumpraw, but am not sure how to interpret it.

In other news, the MediaMonkey developers believe this is a bug in a 
(possibly) older version of vorbis_comment_add_tag():

http://www.ventismedia.com/mantis/view.php?id=5809

Does this seem right and/or shed any light on how to undo the damage?

Adam

Adam Rosi-Kessel wrote, on 6/21/2009 9:29 AM:
> Conrad Parker wrote, on 6/20/2009 10:24 PM:
>>> How about another approach -- is there a tool that will verify the
page
>>> checksums? oggz-validate doesn't seem to do this. If the page
checksums
>>> are okay, then doesn't that suggest the streams are also
recoverable?
>> If the page checksums are bad then the page will get rejected by
>> libogg, and oggz-validate won't even see it (or its packets).
"hogg
>> dumpraw" will at least show the page CRC and segment table, before
>> verifying the CRC, which could be useful.
>
> Does it actually check the CRC, or is there some way for me to do so? I
> see the output from hogg dumpraw, but am not sure how to interpret it.
>
> In other news, the MediaMonkey developers believe this is a bug in a
> (possibly) older version of vorbis_comment_add_tag():
>
> http://www.ventismedia.com/mantis/view.php?id=5809
>
> Does this seem right and/or shed any light on how to undo the damage?
One other potentially interesting observation -- 
Ogg::Vorbis::Header::PurePerl has no trouble reading the headers on 
these corrupted files (and outputting the contents correctly), while 
Ogg::Vorbis::Header dies. Unfortunately, the PurePerl module doesn't 
have any functions implemented to delete metadata -- if it did, I would 
try using that to clear out the tags. But I wonder if the difference 
between the two implementations provides a clue for how to fix this.

I also took a stab at hacking on hogg, but I couldn't figure out what 
was different about what you were recommending than the existing sort 
function there.

Adam

Vorbose -v reports the following for the beginning of the file:

INFO   page: Capture pattern OggS, format version 0
             Flags: first page of logical stream

             Granule position: 0x0000000000000000
             Stream serialno : 0x490f5cff
             Sequence number : 0
             Checksum        : 0xee9c02b9
             Total segments  : 1
             Total packets   : 1 completed
                              ( 30)

info header: Vorbis identification header parsed:
             Stream version     : 0
             Output channels    : 2
             Output sample rate : 44100 Hz
             Bitrate targets    : unset/224000/unset
             Block sizes        : 256/2048 samples

WARN stream: 53638 bytes of garbage before page 1

info stream: All identification header pages parsed.
             1 logical stream muxed in this link.

INFO   page: Capture pattern OggS, format version 0
             Flags: packet continued from previous page

             Granule position: 0x0000000000000000
             Stream serialno : 0x490f5cff
             Sequence number : 13
             Checksum        : 0xab096acc
             Total segments  : 6
             Total packets   : 1 completed (1 cont)
                              (255, 255, 255, 255, 255, 113)

In short, this file's Ogg encapsulation is corrupt.  There's no chance
of this being a vorbis_comment_add_tag() bug as that would be corrupt
data inside valid Ogg.  The Ogg structure itself is invalid here.

Monty