search for: rogg_seri

...y. You can fix them by rewriting > the serial number so there's no conflict. Basically, you change the > serialno field in each ogg page header and then update the crc. > > If you want an example, I have a quick script for doing this in > https://git.xiph.org/?p=rogg.git;a=blob;f=rogg_serial.c > > HTH, >   -r

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

...ake conflicts unlikely. You can fix them by rewriting the serial number so there's no conflict. Basically, you change the serialno field in each ogg page header and then update the crc. If you want an example, I have a quick script for doing this in https://git.xiph.org/?p=rogg.git;a=blob;f=rogg_serial.c HTH, -r

...ewriting >>  the serial number so there's no conflict. Basically, you change the >>  serialno field in each ogg page header and then update the crc. >> >>  If you want an example, I have a quick script for doing this in >>  https://git.xiph.org/?p=rogg.git;a=blob;f=rogg_serial.c >> >>  HTH, >>    -r

...e file. What's odd is it starts out, for about a > second, as audible and normal, and then the audio is scrambled -- > perhaps a bitrate issue? OK, now I've actually successfully repaired a file with this method. Rather than use rogg_crc to fix the CRC after the fact, I'm using rogg_serial to replace the serial number in the "good" ogg before swapping the first three packets into the "bad" ogg. The result appears to be an ogg that plays perfectly. This fix should be easy to script -- then I'll just need to use some other means to retag the files since th...

Thank you, ogginfo returned: ----- Note: Stream 1 has serial number 0, which is legal but may cause problems with some tools. New logical stream (#1, serial: 00000000): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: ffmpeg Channels: 1 Rate: 22050 Nominal bitrate: 35.333000 kb/s Upper bitrate not set Lower bitrate not set Vorbis stream 1: Total data

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