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

> Is there any way to understand exactly how it is invalid? I can replicate
> this corruption simply by adding large album art to any ogg file with the
> latest release of MediaMonkey.
The second page is corrupt.  The basic structure looks correct, first
guess would be bad checksum.  I'll look more closely in just a bit.
This might explain why some players might accept it--- if they're
ignoring checksumming and error detection.

Monty

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

Can I fix the checksum with a hex editor?

Sent from my iPhone

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
>

Monty Montgomery wrote, on 6/25/2009 3:23 PM:
> 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.
I suppose this probably won't come to a surprise to anyone, but if I 
comment out the checksum checking in framing.c, I still can't decode 
these files. ogginfo gives a different offset for the "hole in data"
and
also these additional warnings:

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

I didn't think the fix could be that simple, but I thought I'd mention 
my experiment.

Adam

Monty Montgomery wrote, on 6/25/2009 2:16 PM:
>> Is there any way to understand exactly how it is invalid? I can
replicate
>> this corruption simply by adding large album art to any ogg file with
the
>> latest release of MediaMonkey.
> The second page is corrupt.  The basic structure looks correct, first
> guess would be bad checksum.  I'll look more closely in just a bit.
> This might explain why some players might accept it--- if they're
> ignoring checksumming and error detection.
I've noticed that I may have different varieties of corruption. For 
example, this file doesn't have the oversized embedded album art:

http://adam.rosi-kessel.org/bugs/liboggz/484/other_corruption.ogg

Yet also won't play or process properly with oggz or hogg tools. Any 
ideas whether this is the same or different root cause? (In all of these 
cases, I'm reasonably certain that disk corruption is not an issue).

Adam

2009/6/30 Adam Rosi-Kessel <adam at
rosi-kessel.org>:
> Monty Montgomery wrote, on 6/25/2009 2:16 PM:
>>> Is there any way to understand exactly how it is invalid? I can
replicate
>>> this corruption simply by adding large album art to any ogg file
with the
>>> latest release of MediaMonkey.
>> The second page is corrupt. ?The basic structure looks correct, first
>> guess would be bad checksum. ?I'll look more closely in just a bit.
>> This might explain why some players might accept it--- if they're
>> ignoring checksumming and error detection.
>
> I've noticed that I may have different varieties of corruption. For
> example, this file doesn't have the oversized embedded album art:
>
> http://adam.rosi-kessel.org/bugs/liboggz/484/other_corruption.ogg
>
> Yet also won't play or process properly with oggz or hogg tools. Any
> ideas whether this is the same or different root cause? (In all of these
> cases, I'm reasonably certain that disk corruption is not an issue).
that one is entirely missing the comments data, and the second page is
incorrectly marked as continued. Not sure that helps with
understanding the problem, but I can confirm that it's broken in a
different way :-)

Conrad.