Monty Montgomery
2009-Jun-25 18:16 UTC
[ogg-dev] 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
Monty Montgomery
2009-Jun-25 19:23 UTC
[ogg-dev] Fixing ogg vorbis corruption caused by bad metadata
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
Adam Rosi-Kessel
2009-Jun-25 19:52 UTC
[ogg-dev] Fixing ogg vorbis corruption caused by bad metadata
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 >
Adam Rosi-Kessel
2009-Jun-26 03:50 UTC
[ogg-dev] Fixing ogg vorbis corruption caused by bad metadata
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
Adam Rosi-Kessel
2009-Jun-30 14:55 UTC
[ogg-dev] Fixing ogg vorbis corruption caused by bad metadata
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
Conrad Parker
2009-Jun-30 15:05 UTC
[ogg-dev] Fixing ogg vorbis corruption caused by bad metadata
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.
Reasonably Related Threads
- Fixing ogg vorbis corruption caused by bad metadata
- Fixing ogg vorbis corruption caused by bad metadata
- Fixing ogg vorbis corruption caused by bad metadata
- Fixing ogg vorbis corruption caused by bad metadata
- Fixing ogg vorbis corruption caused by bad metadata