I'm doing some work where narrowband speex audio capture is happening and being written to file in the ogg container format. Later retrieval for reading will occur too. I've been using liboggz to do the file reading and writing and have obviously come across some things I don't seem to follow or have just got wrong. I can happily generate an ogg file using liboggz with some test data. I write the headers then pump a couple of 600 byte test data packets into it and liboggz does the magic of breaking the 600 byte packet into 3 page segments. Then I write an eos page to finish up. I can then read this file back and rewrite it to another file and get exactly the same result ? which is great (result is test_with_data.ogg file attached). I then attempted to read back a sample spx file I obtained from the web (attached female_scrub.spx) file. I can read it back happily but I end up with a resultant file twice the size as the read_packet callback gets called on each page segment being read, and I am writing each of these back to the resultant file with a write feed and they all end up on their own page (no matter how I set the flush flags). The part I don't understand is why the read_packet callback only gets invoked on my test file when the full 600 bytes have been read, noting that it is written to file as 3 segments on the page (lengths, FF, FF and 5A I think it was). But when the sample spx file gets read, the read_packet callback gets called for each segment, which by the way are all of size 20 bytes, and returns only 20 bytes at a time. Ideas? Please forgive any obvious stupidity as I am a rank amateur with all this stuff ;-) Thanks, Warwick Baker. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080731/651fc100/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: test_with_data.ogg Type: application/octet-stream Size: 1450 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080731/651fc100/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: female_scrub.spx Type: application/octet-stream Size: 16531 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080731/651fc100/attachment-0003.obj
On 31-Jul-08, at 12:26 AM, Warwick Baker wrote:> The part I don't understand is why the read_packet callback only > gets invoked on my test file when the full 600 bytes have been > read, noting that it is written to file as 3 segments on the page > (lengths, FF, FF and 5A I think it was). But when the sample spx > file gets read, the read_packet callback gets called for each > segment, which by the way are all of size 20 bytes, and returns > only 20 bytes at a time. >Segments aren't exposed by the API, they're just used internally to partition the data. What liboggz feeds you are *packets* which should be the exactly the same units that were feed when the file was written. So if you gave it 600 byte packets writing the file, you get a callback every 600 bytes reading the file. Speex packets are much smaller, so you get a callback every 20 bytes (or so) reading a speex file. It's just maintaining the original packet boundaries, regardless of how many segments the packets occupy. Make sense? -r