Pardon my ignorance, as I just started playing with Ogg stuff a few days ago, but I'd appreciate some help if someone has time... I was trying to write a very basic comment editor for Ogg Vorbis files. I think I mostly have it working, but it seems to output slightly broken streams. Here's a basic overview of what I'm doing; could someone tell me if I've got the right basic idea? Basically because the all the packets are variable-width, I (AFAIK) need to read out all the packets one at a time, replacing the second (comment header) packet with the new comments. All the other packets can stay exactly the same. I read the packets out of one ogg stream, and feed them into a second ogg stream, grabbing pages from the second stream as I get them and writing them to disk. Then I move the new file into place where the old file was. It's a little ugly, but I can't think of any other way to do it. If I knew the second or third header was going to fall on a page boundary, I could figure out how long the header pages were in the first file, then figure out how long the header pages were in the new stream, then expand or contract the original file to match and overwrite the header pages. That would probably be a classier way of doing it, but since I am probably screwing with the page boundaries by changing the comment header, that won't work, and my two file approach is apparently the only way to do it. Can anyone tell me if the above assumptions are correct? If they are I can show you a few lines of pseudocode and hopefully you could tell me what I'm doing wrong... Thanks for any help you can offer... --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
To follow up my own post.... I just read: http://www.xiph.org/ogg/vorbis/doc/framing.html which I missed somehow... Would it perhaps be wiser to do my own framing of pages and packets? I guess if I did raw reads and re-framed the first few pages myself (i.e. re-framed all the pages containing header info), I could do in-place comment editing of sorts. Is that a wise decision, or is it discouraged? Certainly I'm more prone to screw up than the lib, but the framing format seems pretty set-in-stone at this point, so it hopefully wouldn't be too big of a deal? (Just got your post, Monty... I somehow missed the bitstream framing doc, but I'd pretty much figured out how it worked from playing around... These exact details sure clear things up, though :) I'll reply with the problems I'm having in a bit... thanks...) --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> Here's a basic overview of what I'm doing; could someone tell me if I've > got the right basic idea?Sure. BTW, have you read the Ogg bitstream/framing spec on the website? This details all the implications of modifying packets/pages. (I assume that if you've gotten this far without asking for help the answer is yes, but it's worth checking).> Basically because the all the packets are variable-width, I (AFAIK) need > to read out all the packets one at a time, replacing the second (comment > header) packet with the new comments.Correct. You will also need to rebuild the comment page at a minimum.> All the other packets can stay > exactly the same.Also correct.> I read the packets out of one ogg stream, and feed them > into a second ogg stream, grabbing pages from the second stream as I get > them and writing them to disk. Then I move the new file into place where > the old file was.I assume you're doing this using the ogg_stream_xxxx and ogg_sync_xxxx functions, correct?> It's a little ugly, but I can't think of any other way to do it.No, this seems like the proper way to do it to me.> If I knew the second or third header was going to fall on a page boundary, > I could figure out how long the header pages were in the first file, then > figure out how long the header pages were in the new stream, then expand > or contract the original file to match and overwrite the header pages.The second packet is guaranteed to be the first packet content on the second page, but it is not necessarily constrained to the second page, or the only packet on the second page. One thing I need to add to the libvorbis API is an ogg_stream_flush() so that one can flush a complete page comprised of however many packets one has submitted up to that point, rather than when libvorbis feels like flushing. That way you still don't know exactly how much you need to read, but when you *do* have all the pages needed to extract the second (comment) packet, you only need to split open those pages, not the pages for the entire stream.> That would probably be a classier way of doing it, but since I am probably > screwing with the page boundaries by changing the comment header, that > won't work, and my two file approach is apparently the only way to do it.Once you have the flush command, you'd be able to do this because you could just build new pages with the modified header packet (with one restriction actually; the pages have sequence numbers, so you'd need to end up with the same number of pages after editing if you don't want to peel/rewrap each page after editing. The max page size is just under 64k, and libvorbis normally outputs pages at 4k, so you've got lots of room to work before needing to start re-wrapping pages)> Can anyone tell me if the above assumptions are correct? If they are I > can show you a few lines of pseudocode and hopefully you could tell me > what I'm doing wrong...Your assumptions as stated are all correct. Can you provide more detail of the trouble you're having? Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
At 03:25 AM 5/16/00 -0700, you wrote:>Pardon my ignorance, as I just started playing with Ogg stuff a few days >ago, but I'd appreciate some help if someone has time... > >I was trying to write a very basic comment editor for Ogg Vorbis files. I >think I mostly have it working, but it seems to output slightly broken >streams.Well - there's a coincidence. Guess what I've been doing? Mine now works, produces correct streams, and has a suckier-than-sucky user interface. If you're still having troubles, and you'd like to look at my code, just ask - it's not too horrible for the most part.> >Here's a basic overview of what I'm doing; could someone tell me if I've >got the right basic idea? > >Basically because the all the packets are variable-width, I (AFAIK) need >to read out all the packets one at a time, replacing the second (comment >header) packet with the new comments. All the other packets can stay >exactly the same. I read the packets out of one ogg stream, and feed them >into a second ogg stream, grabbing pages from the second stream as I get >them and writing them to disk. Then I move the new file into place where >the old file was. >That's exactly correct - in almost all cases, everything other than the second page (which includes the second packet) will remain identical, so you'd be able to just copy the data raw from the input file to the output after writing out the headers normally. Unfortunately, under some circumstances the comments packet could be sufficiently large that it gets split over two pages - then the rest of the stream has to be decoded (not fully - you need only extract the packets from the stream), then restreamed, because the page sequence numbers change. It'd be possible to detect this case, and only use this (slower) method if you needed to (my code currently doesn't).>It's a little ugly, but I can't think of any other way to do it. > >If I knew the second or third header was going to fall on a page boundary, >I could figure out how long the header pages were in the first file, then >figure out how long the header pages were in the new stream, then expand >or contract the original file to match and overwrite the header pages. >That would probably be a classier way of doing it, but since I am probably >screwing with the page boundaries by changing the comment header, that >won't work, and my two file approach is apparently the only way to do it. > >Can anyone tell me if the above assumptions are correct? If they are I >can show you a few lines of pseudocode and hopefully you could tell me >what I'm doing wrong...Well, the theory here is all correct, so it's probably just a minor bug. The only part of the process that the libvorbis API makes somewhat hard is actually regenerating the header packets (well, just the comment packet is needed - but the api only allows for generating all of them). The rest is just a matter of using the ogg layer of libvorbis to pull the packets out, then recreate pages from them and push these out onto the disk. If you want me to take a look at the code, you can mail it to me, and I'll try and figure out where the problem is. Michael --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/