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

Monty Montgomery wrote:
> Yes.  Without the first three packets (which hold all the codec
> settings and all the instruction how to handle the subsequent packets)
> the rest of the stream is gibberish.  Vorbis can't even unpack the
> bits without the codebooks packed into the third header.
Curiosity man here.

Is there a finite set of predetermined codebooks or is the codebook
source dependent?

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

On Tue, Jul 14, 2009 at 1:41 AM, Erik de Castro
Lopo<mle+la at mega-nerd.com> wrote:
> Monty Montgomery wrote:
>
>> Yes. ?Without the first three packets (which hold all the codec
>> settings and all the instruction how to handle the subsequent packets)
>> the rest of the stream is gibberish. ?Vorbis can't even unpack the
>> bits without the codebooks packed into the third header.
>
> Curiosity man here.
>
> Is there a finite set of predetermined codebooks or is the codebook
> source dependent?
Both-- The current encoders use predetermined books, but its a large
set.  And the set has often changed between releases.

The set is small enough that its possible to make good reasonable guesses.

Monty

Monty Montgomery wrote, on 7/14/2009 1:44 AM:
> On Tue, Jul 14, 2009 at 1:41 AM, Erik de Castro
> Lopo<mle+la at mega-nerd.com>  wrote:
>> Monty Montgomery wrote:
>>
>>> Yes.  Without the first three packets (which hold all the codec
>>> settings and all the instruction how to handle the subsequent
packets)
>>> the rest of the stream is gibberish.  Vorbis can't even unpack
the
>>> bits without the codebooks packed into the third header.
>> Curiosity man here.
>>
>> Is there a finite set of predetermined codebooks or is the codebook
>> source dependent?
>
> Both-- The current encoders use predetermined books, but its a large
> set.  And the set has often changed between releases.
>
> The set is small enough that its possible to make good reasonable guesses.
So if I understand correctly -- the first packet is just OggS, so that's 
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?

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.

Adam