search for: chichai

...reported. eg. There's nothing in http://trac.annodex.net/query?status=new&component=liboggz Here's some oggz output that seems a bit fishy. Using http://diracvideo.org/download/test-streams/ogg/sage-640x360.ogg and current liboggz svn, http://svn.annodex.net/liboggz/trunk/ : conrad at chichai:~/share/dirac$ oggz validate --max-errors 0 sage-640x360.ogg 2>&1 | wc -l 135 conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg sage-640x360.ogg: Error: 00:00:00.000: serialno 1763535876: Granulepos decreasing within track 00:00:00.166: serialno 1763535876: Granulepos decreasi...

...shortly. > > Ok, i've tested muxing some audio and video together and that works fine. > woo. great, thanks :-) So the last remaining tool to check is oggz-chop. I at first assumed it would not work with Dirac's granulepos, but it seems to do something vaguely useful: conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o sage-7-11.ogv ../dirac/sage-640x360.ogg conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep serialno | head -n 20 00:00:00.000: serialno 1762443388, granulepos 0, packetno 0 *** bos: 64 bytes 00:00:00.000: serialno 1763535876, granulepos (pt...

...meaningful time for it, so the granulepos should be -1 on the eos > page on the dirac logical stream. ok, as it seems the EOS granulepos is under discussion I've not made any checks specific to that. As of changeset:3782, oggz-validate reports only this one error for that file: conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg sage-640x360.ogg: Error: 00:02:36.077: serialno 1763535876: Granulepos decreasing within track >> conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg >> sage-640x360.ogg: Error: >> 00:00:00.000: serialno 1763535876: Granu...

On Fri, Dec 05, 2008 at 06:34:41AM +0900, Conrad Parker wrote: > So the last remaining tool to check is oggz-chop. I at first assumed it > would not work with Dirac's granulepos, but it seems to do something > vaguely useful: > > conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o > sage-7-11.ogv ../dirac/sage-640x360.ogg > conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep > serialno | head -n 20 > 00:00:00.000: serialno 1762443388, granulepos 0, packetno 0 *** bos: 64 bytes > 00:00:00.000: serialno 1...

...t; ??? while (ogg_page_granulepos(&og) < time * freq); // time in seconds, > freq: 16000 > > But this way I can't get enough precision neither. Seeking on Ogg pages will only give you page accuracy, and each page can contain multiple packets. eg. a narrowband encode: conrad at chichai:~/share/speech$ speexenc male.wav male.spx Encoding 8000 Hz audio using narrowband mode (mono) conrad at chichai:~/share/speech$ oggz info male.spx Content-Duration: 00:00:06.000 Speex: serialno 1523256763 303 packets in 5 pages, 60.6 packets/page, 3.653% Ogg overhead Audio-Sampler...

Hello everybody, I'm new to this mailing list so I'm sorry if it's the wrong place to post this. I'm developing a Speex player and I need to seek with a precision of milliseconds. I used liboggz that supposedly does just that, but it never seeks exactly where it should. For example if I use oggz_seek_units(oggz, 18450, SEEK_SET) result it's 16386 and there is a delay between

...://svn.annodex.net/liboggz/trunk/ : The only niggle i have with this file is that the EOS page has a bizare timestamp. imho, because there is no picture in the eos page, there is no meaningful time for it, so the granulepos should be -1 on the eos page on the dirac logical stream. > conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg > sage-640x360.ogg: Error: > 00:00:00.000: serialno 1763535876: Granulepos decreasing within track > 00:00:00.166: serialno 1763535876: Granulepos decreasing within track These two are understood -- infact, the fact it has errored twice possib...

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 2008/11/15 David Flynn <davidf+nntp at woaf.net>: >>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >>>> It seems oggz chop, merge and sort will need some attention to deal >>>> with the Dirac

...ranulepos and dependency ordering, so let's leave them > for the next release. ok. -- may be worth having them 'warn' if they are operating on something containing oggdirac. > > As of changeset:3782, oggz-validate reports only this one error for that file: > > conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg > sage-640x360.ogg: Error: > 00:02:36.077: serialno 1763535876: Granulepos decreasing within track Ok, that is due to the invalid granulepos in the EOS page (the actual value doesn't make sense -- and is infact invalid (see in a moment)) The...

...uption you could try that. > > In other words, everything in between ^Evorbis and OggS is the setup > header? no, you can't just rip the bytes out because the setup header may be split across two pages. eg. looking 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 serialn...

...true (ie. since David Flynn's recent updates > to support Dirac), and if so could you please explain what the > problems are, or point me to a bugtracker where they are reported. eg. I mostly meant what you apparently fixed below, namely, showing pt, dt, dist, and delay. > conrad at chichai:~/share/dirac$ oggz dump -c dirac sage-640x360.ogg > |grep granulepos|head > 00:00:00.000: serialno 1763535876, granulepos > (pt:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes > 00:00:00.000: serialno 1763535876, granulepos > (pt:0,dt:4294967292,dist:0,delay:4), packetno 2: 19....

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