search for: packetno

...;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:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes 00:00:00.000: serialno 0719746932, granulepos 0, packetno 0 *** bos: 30 bytes 00:00:00.000: serialno 0719746932, calc. gpos 0, packetno 1: 75 bytes 00:00:00.000: serialno 07197...

...acket then i write all pages but the last one to the output file (because, as i understand it, only the last packet has the correct granulepos; all other packets have a granulepos of -1). foreach packet in list[:-1]: # does NOT include the last packet! packet.granulepos=-1 packet.packetno=global_packetno++ write_packet(packet) now i write the last packet (this is also the place where i would set e_o_f...): packet=list[len(list)-1] packet.granulepos=g packet.packetno=global_packetno++ write_packet(packet) the write_packet function looks like this: def write_pac...

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

...t two being header data, the third containing two packets of data and the last containing one packet of data. I am confused at the results I get if I corrupt the third page (The first one of the two that contain data). If I corrupt the first page, then I will successfully read out packets with the packetno set to 1, 2, 3, and 4 respectively which is what I expect. Packet 0 is the first page which is corrupt and can therefore not be read out. I get the similar results if I corrupt the second page. Specifically, I get packets with packetno set to 0, 2, 3, and 4. But, if I corrupt the third page, th...

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

...ask I'm trying to use the liboggz 0.9.9 Write API. Here is the code of my application to write silence in an ogg file : ------------------------------------------------------------------------------------------------ /static long serialno; static ogg_int64_t granulepos = 0; static ogg_int64_t packetno = 0;/ ------------------------------------------------------------------------------------------------ /static int oggzHungry(OGGZ * oggz, int empty, void * user_data) { ogg_packet op; //unsigned char buf[1]; //buf[0] = 'A' + (int)packetno; unsigned char buf[2]; buf[0] = 0; buf[...

...vorbis_analysis_buffer() vorbis_analysis_wrote() c) while true vorbis_analysis_blockout() vorbis_analysis() vorbis_bitrate_addblock() vorbis_bitrate_flushpacket() This generates ogg_packets with packetno and granulepos values as described below Case #1 : Generated ogg_packets Packet # packetno granulepos --------------------------------------------- 1 Large 0 2 Large 0 3 Large 0 4 3 0 5 4 576 In the second scenario, ogg_packets has additional been processed through a) ogg_stre...

...omething > 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:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes > 00:00:00.000: serialno 0719746932, granulepos 0, packetno 0 *** bos: 30 bytes > 00:00:00.000: serialno 0719746932, calc. gpos 0, packetno 1: 75 bytes > 00:...

...o 1763535876: Packet out of order (previous 00:00:01.335) oggz-validate --max-errors 10: maximum error count reached, bailing out ... 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.658 kB 00:00:00.166: serialno 1763535876, granulepos (pt:8,dt:4294967294,dist:1,delay:10), packetno 3: 6.700 kB 00:00:00.041: serialno 1763535876, granulepos (pt:2,dt:0,dist:2,delay...

...ds > Page error, continuing > Header packet corrupt > Processing failed > >> 2) an Hex editor, even if just to check what's wrong in the metadata >> section > > What should I look at with a Hex editor? The oggz dump for an example header > shows the following -- packetno 1, where the metadata would be, is just > skipped: > > 00:00:00.000: serialno 1225743615, granulepos 0, packetno 0 *** bos: 30 > bytes > ? ? ?0000: 0176 6f72 6269 7300 0000 0002 44ac 0000 ?.vorbis.....D... > ? ? ?0010: 0000 0000 006b 0300 0000 0000 b801 ? ? ? .....k........ > &...

...in the ``Speex `` (with 3 training spaces), which identifies the bit-stream. The next field, speex_version contains the version of Speex that encoded the file. For now, refer to speex_header.[ch] for more info. The beginning of stream (b_o_s) flag is set to 1 for the header. The header packet has packetno=0 and granulepos=0. The second packet contains a user-comment string, without terminating null. The content/format of the comment string is not defined. This packet has packetno=1 and granulepos=0. The third and subsequant packets each contain one or more (number found in header) Speex frames. Th...

...here: Processing: Cutting at 0.000000 seconds Page error, continuing Header packet corrupt Processing failed > 2) an Hex editor, even if just to check what's wrong in the metadata section What should I look at with a Hex editor? The oggz dump for an example header shows the following -- packetno 1, where the metadata would be, is just skipped: 00:00:00.000: serialno 1225743615, granulepos 0, packetno 0 *** bos: 30 bytes 0000: 0176 6f72 6269 7300 0000 0002 44ac 0000 .vorbis.....D... 0010: 0000 0000 006b 0300 0000 0000 b801 .....k........ 00:00:00.416: serialno 12257...

...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.658 kB > 00:00:00.166: serialno 1763535876, granulepos > (pt:8,dt:4294967294,dist:1,delay:10), packetno 3: 6.700 kB > 00:00:00.041: serialno 1763535876, granulepo...

(Sending again after subscribing, I guess the moderator is on vacation.) I'm working on support for tagging Speex files for Mutagen[0] and part of the specification at [1] is confusing me. It says the first page should have granulepos 0 and packetno 0. Does this really mean page sequence number 0, since the Ogg format doesn't number packets? If it doesn't mean page sequence number, what does it mean? If it does really mean packet, does that mean there are no guarantees about page/packet boundries? e.g. Vorbis guarantees the first pag...

...r, I believe such function > may be usefull in the case when 2, 3 or 4 buffers could be needed to fill a > new ogg packet.. > > Patch is attached. I didn't test it yet, but it is mainly packetout's code. I > believe it is correct, though I don't know if the granulepos and packetno > should be incremented in this case. As for these questions regarding your patch, packetno would need to be incremented. I think granulepos would probably be the same as that of the previous packet (ie. the last actual frame), but the spec doesn't define that such an empty packet is valid...

...e is a picture of what the bitstream looks like, as output by a python program that uses pyogg/pyvorbis to read the stream and print a representation: <OggPage, BOS pageno = 0, granulepos = 0, serialno = 2079510926, head length = 28, body length = 30 at 0x4019b3e0> <OggPacket, BOS packetno = 0, granulepos = 0, length = 30 at 0x401e7bb0> <OggPage, pageno = 1, granulepos = 0, serialno = 2079510926, head length = 44, body length = 3877 at 0x4019b368> <OggPacket, packetno = 1, granulepos = -1, length = 45 at 0x401e7bb0> <OggPacket, packetno = 2, granulep...

...700, Ralph Giles wrote: > On Sat, Jul 15, 2006 at 02:17:22PM -0500, Joe Wreschnig wrote: > > > I'm working on support for tagging Speex files for Mutagen[0] and part > > of the specification at [1] is confusing me. It says the first page > > should have granulepos 0 and packetno 0. Does this really mean page > > sequence number 0, since the Ogg format doesn't number packets? > > Sounds like a spec bug. The libogg reference implementation always > flushes a page after the zeroth packet, so packetno=0 is effectively > page sequence no zero. But as you...

...speex_bits_insert_terminator(&enc_bits); //The time stamp if(i==0) ((int*)packet)[0]=total_samples; } int nbBytes = speex_bits_write(&enc_bits, packet+4, 2000); tam=nbBytes+4; //Now the ogg package op.packet = (unsigned char *)packet; op.bytes = nbBytes+4; op.b_o_s = 0; op.packetno = packet_id; packet_id++; ogg_stream_packetin(&os, &op); ogg_stream_flush(&os, &audio_page); return audio_page; } As for the decoder I have this. //Incoming data from udp is on buffer char *buffer=ogg_sync_buffer(&oy,4096); memcpy(buffer,buff,len); ogg_sync_wrote(&oy,len...

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

On Sat, Jul 15, 2006 at 02:17:22PM -0500, Joe Wreschnig wrote: > I'm working on support for tagging Speex files for Mutagen[0] and part > of the specification at [1] is confusing me. It says the first page > should have granulepos 0 and packetno 0. Does this really mean page > sequence number 0, since the Ogg format doesn't number packets? Sounds like a spec bug. The libogg reference implementation always flushes a page after the zeroth packet, so packetno=0 is effectively page sequence no zero. But as you say, packetno doesn'...