similar to: Fixing ogg vorbis corruption caused by bad metadata

Conrad Parker wrote, on 6/20/2009 10:24 PM: >> How about another approach -- is there a tool that will verify the page >> checksums? oggz-validate doesn't seem to do this. If the page checksums >> are okay, then doesn't that suggest the streams are also recoverable? > If the page checksums are bad then the page will get rejected by > libogg, and oggz-validate

Hi, (I was discussing this with Adam earlier today, and he has also mailed vorbis at xiph.org about this issue in March). This sounds like it needs a new tool specifically for fixing broken Ogg files. Suggestions so far (tried by Adam, or suggested to him in email/IRC): * oggz-sort, hogg sort These rewrite the file, sorting the pages by presentation time. This usually fixes muxing problems,

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

Adam Rosi-Kessel wrote, on 6/19/2009 3:56 PM: > Conrad Parker wrote, on 6/18/2009 3:15 PM: >> 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

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

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

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

> 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

Adam Rosi-Kessel wrote, on 6/30/2009 11:14 AM: > Conrad Parker wrote, on 6/30/2009 11:05 AM: >>> 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

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

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 2) an Hex editor, even if just to check what's wrong in the metadata section -Ivo

On Fri, Jul 17, 2009 at 12:48:27PM -0700, Ralph Giles wrote: > > In my ongoing quest to restore corrupted ogg files, I'm trying to find > > an easy way to identify the setup header without having to actually > > decode it. I understand that it starts with [packet_type] = 5 and then > > the string 'vorbis', but is there some way to figure out where it > >

Adam Rosi-Kessel <adam at rosi-kessel.org> wrote: > So I've written a script to do the following: ... I have got lost. Did you manage to identify the rogue software that corrupted the files in the first place? In the greater scheme of things, fixing this (prevention) is more important than repairing the files (cure). Regards, Martin -- Martin J Leese E-mail: martin.leese

Adam Rosi-Kessel wrote, on 6/21/2009 9:29 AM: > Conrad Parker wrote, on 6/20/2009 10:24 PM: >>> How about another approach -- is there a tool that will verify the page >>> checksums? oggz-validate doesn't seem to do this. If the page checksums >>> are okay, then doesn't that suggest the streams are also recoverable? >> If the page checksums are bad then

Adam Rosi-Kessel wrote: > Yes, it was Mediamonkey. They claim that it was due to a bug in vorbis > libraries. All software has bugs, but this explanation doesn't really add up. libvorbis is the codec. If they had blamed libogg, which does the container, then yes, that would have been a believable explanation :-). Erik --

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

2009/7/18 Adam Rosi-Kessel <adam at rosi-kessel.org>: > On Fri, Jul 17, 2009 at 12:48:27PM -0700, Ralph Giles wrote: >> > In my ongoing quest to restore corrupted ogg files, I'm trying to find >> > an easy way to identify the setup header without having to actually >> > decode it. I understand that it starts with [packet_type] = 5 and then >> > the

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

I have several corrupted ogg files; I believe they were created several years ago with grip, and that the corruption is not disk corruption but just something wrong with the encoder at the time. I would rather not have to re-rip these discs. The error I see with ogginfo is Warning: Hole in data (18000 bytes) found at approximate offset 702086827724505088 bytes. Corrupted ogg. Warning: Hole

HOgg 0.4.1 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the fourth public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on