search for: incplt

...king at the start of the stream with "hogg pagedump": conrad at chichai:~/share/484$ hogg pagedump unfixed_corrupted.ogg |head -n 12 0x00000000: Vorbis serialno 1225743615, granulepos 0|0 *** bos: 58 bytes [30] 00:00:00.000 0x0000003a: Vorbis serialno 1225743615, granulepos 0|0 (incplt): 53525 bytes [49719,3570] 00:00:00.000 0x0000d1c0: Vorbis serialno 1225743615, granulepos 0|0 (cont): 1421 bytes [1388] 00:00:00.000 0x0000d74d: Vorbis serialno 1225743615, granulepos 21056|0 (incplt): 4261 bytes [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,448,517,534,536,543,546,548,...

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 113 bytes shorter than unfixed_corrupted.ogg. Comparing the page offsets of the two files $ hogg pagedump unfixed_corrupted.ogg |head -n 30 0x00000000: Vorbis serialno 1225743615, granulepos 0|0 *** bos: 58 bytes [30] 00:00:00.000 0x0000003a: Vorbis serialno 1225743615, granulepos 0|0 (incplt): 53525 bytes [49719,3570] 00:00:00.000 0x0000d1c0: Vorbis serialno 1225743615, granulepos 0|0 (cont): 1421 bytes [1388] 00:00:00.000 $ hogg pagedump 484-hogg-reconstructed.ogg |head -n 30 0x00000000: Vorbis serialno 1225743615, granulepos 0|0 *** bos: 58 bytes [30] 00:00:...

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

...et. The last page is always one that has a granulepos set (that of the last packet finishing on that page). But let's say it subsequently contains an incomplete packet, like this (from 'hogg pagedump' of the output file): 0x0013ec0c: Theora serialno 2127823547, granulepos 494|7 (cont) (incplt) *** eos: 4223 bytes [665,1605,1653,255] That list specifies the segment lengths. I would have expected the eos to refer to the same packet that the granulepos refers to, ie. the segment of length 1653. However, when later reading this file via libogg, no packets in that track are marked a...