[ogg-dev] Fixing ogg vorbis corruption caused by bad metadata

[Adam Rosi-Kessel]

Adam Rosi-Kessel wrote, on 7/14/2009 7:55 AM:
> ogg.k.ogg.k at googlemail.com wrote, on 7/14/2009 7:16 AM:
>>> easy to replace. The second packet is the metadata, which we can lose.
>>> It's just the third packet that needs to be reconstructed. After that,
>>> you could start at any packet division in the rest of the file and it
>>> would play fine? So this generic restore tool that I'm positing would
>>> just need to try every known codebook set until a valid file was
>>> produced? How hard would that be?
>> You'd need to renumber and regenerate CRCs. rogg might do all that
>> (a set of tools somewhere on svn.xiph.org).
>>> What I'm puzzled by, based on the information above, is why my attempted
>>> fixes haven't worked: pick a valid ogg vorbis file that I believe was
>>> ripped with the same tool around the same time, swap in the first three
>>> packets from that file, modify the serial number to match the new file.
>>> Thus far this technique hasn't actually fixed any files.
>> CRCs ? If they're wrong (and they'd become wrong if you fiddle with the
>> serial number without regenerating them), libogg will ignore the page.
>
> Thank you! I'd never heard of rogg. That definitely gets me one step
> closer to a solution. Taking a file where I had substituted the header
> from a good ogg into the "bad" ogg, and then using rogg to fix the crc,
> I now have a playable file. What's odd is it starts out, for about a
> second, as audible and normal, and then the audio is scrambled --
> perhaps a bitrate issue?

OK, now I've actually successfully repaired a file with this method. 
Rather than use rogg_crc to fix the CRC after the fact, I'm using 
rogg_serial to replace the serial number in the "good" ogg before 
swapping the first three packets into the "bad" ogg. The result appears 
to be an ogg that plays perfectly.

This fix should be easy to script -- then I'll just need to use some 
other means to retag the files since they will have lost their metadata. 
I suppose if I wanted to be clever, I could extract from the binary all 
the key tags which are still fine (album, artist, genre, trackno, etc) 
and the retag the file with a standard tool after the first three 
packets are replaced.

The only issue I'm noticing is ogginfo reports:

Warning: sequence number gap in stream 1. Got page 14 when expecting 
page 2. Indicates missing data.
Warning: discontinuity in stream (1)

This doesn't seem to interfere with proper playing, but does anyone have 
a suggestion for a simple fix here? I suppose I just need to renumber 
the pages?

Adam