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

[Conrad Parker]

2009/6/26 Adam Rosi-Kessel <adam at rosi-kessel.org>:
> Can I fix the checksum with a hex editor?

I just realized that the hogg tools will fix the CRC issues (by design
accident: hogg ignores the CRC on reading but sets it correctly on
writing). "hogg rip" rewrites the pages (fixing the CRC), and "hogg
reconstruct" also rewrites the

I've uploaded the outputs of these, run on unfixed_corrupted.ogg, to:

  http://seq.kfish.org/~conrad/tmp/484

These pass oggz-validate without warnings about the headers, and have
the Vorbis headers intact (including large COVERART). However in the
ripped version the codebooks are not visible to libogg, so something
else is corrupt there.

For the reconstructed versions: the -nocomments.ogg version was then
run through "oggz-comment -d" to remove all comments, in case the
large COVERART was causing a problem.

However ogginfo still reports the following errors:

$ ogginfo 484-hogg-reconstructed-nocomments.ogg |head
Processing file "484-hogg-reconstructed-nocomments.ogg"...

New logical stream (#1, serial: 490f5cff): type vorbis
Warning: Could not decode vorbis header packet 2 - invalid vorbis stream (1)
Warning: sequence number gap in stream 1. Got page 30 when expecting
page 4. Indicates missing data.
Warning: discontinuity in stream (1)
Warning: Could not decode vorbis header packet 2 - invalid vorbis stream (1)
Warning: Could not decode vorbis header packet 2 - invalid vorbis stream (1)
Warning: Could not decode vorbis header packet 2 - invalid vorbis stream (1)
Warning: Could not decode vorbis header packet 2 - invalid vorbis stream (1)

So it seems the codebooks are corrupt; perhaps vorbose can shed some
light on what's wrong here. Monty, could you try running
hogg-reconstructed.ogg through vorbose?

Another clue is that the file hogg-reconstructed.ogg is 113 bytes
shorter than unfixed_corrupted.ogg. Comparing the page offsets of the
two files

$ hogg pagedump unfixed_corrupted.ogg |head -n 30
0x00000000: Vorbis serialno 1225743615, granulepos 0|0 *** bos: 58 bytes
        [30] 00:00:00.000

0x0000003a: Vorbis serialno 1225743615, granulepos 0|0 (incplt): 53525 bytes
        [49719,3570] 00:00:00.000

0x0000d1c0: Vorbis serialno 1225743615, granulepos 0|0 (cont): 1421 bytes
        [1388] 00:00:00.000

$ hogg pagedump 484-hogg-reconstructed.ogg |head -n 30
0x00000000: Vorbis serialno 1225743615, granulepos 0|0 *** bos: 58 bytes
        [30] 00:00:00.000

0x0000003a: Vorbis serialno 1225743615, granulepos 0|0 (incplt): 53525 bytes
        [49719,3570] 00:00:00.000

0x0000d14f: Vorbis serialno 1225743615, granulepos 0|0 (cont): 1421 bytes
        [1388] 00:00:00.000

This difference seems to occur before the start of the third page,
which is partway through header 2, even though the segment lengths [in
square brackets] are the same. 113 bytes is also the last lacing value
on the last header page.

cheers,

Conrad.

> On Jun 25, 2009, at 3:23 PM, Monty Montgomery <monty at xiph.org> wrote:
>
>> Confirmed--- the checksum on the second page (the comment page where
>> the album art was added) is incorrect.  Vorbis players are not allowed
>> to decode any stream in which one of the setup headers is corrupt, and
>> a bad checksum counts as corrupt.
>>
>> Unfortunately, this means none of the remuxing ogg tools in our
>> toolchains will touch those pages either; they will remux and fix most
>> problems with valid pages, but a bad checksum usually means the page
>> is toast, so they won't try.
>>
>> Monty
>>
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
>