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

2009/6/18 Adam Rosi-Kessel <adam at
rosi-kessel.org>:
> Ivo Emanuel Gon?alves wrote, on 6/18/2009 6:14 AM:
>>
>> On 6/18/09, Conrad Parker<conrad at metadecks.org> ?wrote:
>>>
>>> This sounds like it needs a new tool specifically for fixing broken
>>> Ogg files.
>>
>> I see two solutions:
>>
>> 1) the new vcut which I reckon will fix the problem since it has to
>> split and rebuild the audio in a new Ogg
>
> vcut built today from svn doesn't work here:
>
> Processing: Cutting at 0.000000 seconds
> Page error, continuing
> Header packet corrupt
> Processing failed
>
>> 2) an Hex editor, even if just to check what's wrong in the
metadata
>> section
>
> What should I look at with a Hex editor? The oggz dump for an example
header
> shows the following -- packetno 1, where the metadata would be, is just
> skipped:
>
> 00:00:00.000: serialno 1225743615, granulepos 0, packetno 0 *** bos: 30
> bytes
> ? ? ?0000: 0176 6f72 6269 7300 0000 0002 44ac 0000 ?.vorbis.....D...
> ? ? ?0010: 0000 0000 006b 0300 0000 0000 b801 ? ? ? .....k........
>
> 00:00:00.416: serialno 1225743615, calc. gpos 18368, packetno 2: 1 byte
> ? ? ?0000: 00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .
>
> 00:00:00.419: serialno 1225743615, calc. gpos 18496, packetno 3: 1 byte
> ? ? ?0000: 0a
>
> [etc, same through packetno 16]
>
> 00:00:00.460: serialno 1225743615, calc. gpos 20288, packetno 17: 448 bytes
>
> [real data here]
yow, that's pretty badly corrupted, the vorbis codebooks (usually the
third packet) is completely gone. It looks like you'd need to throw
away the first 16 packets, start with fresh headers, and copy in the
rest of the data (packet by packet, or page by page?)

K.

On Thu, Jun 18, 2009 at 11:12:30PM +0900, Conrad Parker
wrote:
> > [etc, same through packetno 16]
> >
> > 00:00:00.460: serialno 1225743615, calc. gpos 20288, packetno 17: 448
bytes
> >
> > [real data here]
> yow, that's pretty badly corrupted, the vorbis codebooks (usually the
> third packet) is completely gone. It looks like you'd need to throw
> away the first 16 packets, start with fresh headers, and copy in the
> rest of the data (packet by packet, or page by page?)
Maybe the metadata writer somehow spilled over the second packet into the
third? In any case, is this something I can do myself -- insert fresh
headers, and then start with packetno 17? I tried doing this with the
oggz-dump trick, and the resulting file validated but wouldn't play. I
tried running the resulting file through the various other tools
(oggz-sort, hogg reconstruct) with no luck.

Adam

> yow, that's pretty badly corrupted, the vorbis codebooks (usually the
> third packet) is completely gone. It looks like you'd need to throw
FWIW, yesterday I tried to dump the file, and replace the comments
and codebooks packets with some the ones from a known good file,
and dump -r it, but since you say dump -r doesn't preserve segmentation
(not sure what you meant there), that might be why it did not work. I
also don't know how much the codebooks header would change between
files, I didn't try to work out which rate/channels/etc to match with a
codebooks packet from a matching stream.

2009/6/18 Adam Rosi-Kessel <adam at
rosi-kessel.org>:
> On Thu, Jun 18, 2009 at 11:12:30PM +0900, Conrad Parker wrote:
>> yow, that's pretty badly corrupted, the vorbis codebooks (usually
the
>> third packet) is completely gone. It looks like you'd need to throw
>> away the first 16 packets, start with fresh headers, and copy in the
>> rest of the data (packet by packet, or page by page?)
>
> Maybe the metadata writer somehow spilled over the second packet into the
> third? In any case, is this something I can do myself -- insert fresh
> headers, and then start with packetno 17? I tried doing this with the
> oggz-dump trick, and the resulting file validated but wouldn't play. I
> tried running the resulting file through the various other tools
> (oggz-sort, hogg reconstruct) with no luck.
2009/6/19 ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at
googlemail.com>:
> FWIW, yesterday I tried to dump the file, and replace the comments
> and codebooks packets with some the ones from a known good file,
> and dump -r it, but since you say dump -r doesn't preserve segmentation
> (not sure what you meant there), that might be why it did not work. I
> also don't know how much the codebooks header would change between
> files, I didn't try to work out which rate/channels/etc to match with a
> codebooks packet from a matching stream.
oggz-dump -r will at least create an Ogg file with the desired
packets, and it's good that that at least validated. By "not
preserving segmentation" I meant that it won't respect the page
boundaries of the original file -- but now I see that that doesn't
matter here, as the issue is really that the packet data is corrupted.

Hopefully at some point the vorbis data in the file becomes valid.
Perhaps we just need to know the original encoding settings to create
a new file with valid codebooks and splice them together: oggz-dump -r
should be ok for that, just take the first 3 packets of the new file,
and packets 17 onwards (or 100 onwards) of the original file ...

vi is a great audio editor ;-)

Conrad.