similar to: Dovecot Questions

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

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

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

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

On Tue, Jul 14, 2009 at 9:48 AM, Adam Rosi-Kessel<adam at rosi-kessel.org> wrote: > The only issue I'm noticing is ogginfo reports: > > Warning: sequence number gap in stream 1. Got page 14 when expecting > page 2. Indicates missing data. > Warning: discontinuity in stream (1) I'd guess this is flagging the data that was overwritten by the bad tagging code. Some

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

Please cc me on replies. My employer recently upgraded to W2K3. I have no control over the employer's set up and limited access to information. Under the old server, everything was working fine. Now I can't mount the shared drive anymore. I'm running Debian sid; samba 3.0.6-3. ################################################ # mount shared_drive cli_negprot: SMB signing is

I get the following error message in my syslog frequently when a user accesses the dovecot (IMAP) server from his OS X AppleMail client: Nov 24 09:45:42 myhost imap(someuser): file mbox-rewrite.c: line 429 (mbox_write_header): assertion failed: (hdr_parsed_size.physical_size == hdr_size) Nov 24 09:45:42 myhost dovecot: child 23277 (imap) killed with signal 6 Usually each message appears 5-6

ogg.k.ogg.k at googlemail.com wrote, on 7/14/2009 7:16 AM: >> easy to replace. The second packet is the metadata, which we can lose. >> It's just the third packet that needs to be reconstructed. After that, >> you could start at any packet division in the rest of the file and it >> would play fine? So this generic restore tool that I'm positing would >> just

Since upgrading to cygwin 1.7.x, I'm unable to complete rsync jobs to a Debian machine (running stable). cygwin rsync is 3.0.6; Debian is 3.0.3. The transfer goes for a while and then just gets stuck halfway through an arbitrary file. If I cancel and restart, same thing (but gets a little further). If I manually copy the file in question, it will usually go a bit longer and then get stuck

I have over 1,000 ogg vorbis files that are no longer playable or editable. I believe the main cause was a MediaMonkey plugin that automatically fetched album art and added it to the header. The plugin itself just uses the generic MediaMonkey metadata facility, but something happened -- perhaps when the album art bitmap image was too large -- that caused the files to no longer work.

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 --

2009/7/9 Adam Rosi-Kessel <adam at rosi-kessel.org>: > 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

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 > >

> 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

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

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,

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 terminates without actually decoding the bits?

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