-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya folks, I've been hacking on an audio metadata library (creatively called TagLib) which we'll be using in KDE in the next release ( == I need to get around to finishing it). I've got the Vorbis comment implementation working, but just wanted to clarify a couple of things: *) The vendor ID -- "vendor" is ambiguous here. Is this the "vendor" of the standard? The encoder? (Seems to be implied by the value mentioned in the spec.) The tool writing the comment? In my current implementation, I've assumed the second and as such don't modify the vendor ID, but I didn't know if I should stuff something in there mentioning TagLib. *) There seems to be no provision for "padding" (to use the ID3v2 word). Since the comment is very near to the beginning of a Vorbis stream, assuming a file based implementation, the overwhelming majority of the file's contents will have to be moved when the comment size changes. Is this correct? *) To what extent is/will a Vorbis comment be an Ogg comment? Will/do the other Ogg formats (FLAC and Speex come to mind) use the same format? In my (C++) implementation I have separate classes for files and tags. i.e. With mp3 there are two tag types -- id3v1 and id3v2. TagLib::VorbisFile and TagLib::Vorbis::Comment are independant; as such it would be possible for the comment to become something that could be mapped to multiple Ogg based file formats (which would extract the comment from the format's stream) -- i.e. TagLib::Ogg::Comment -- if appropriate. And now for the obligatory comments section -- *) First, I feel compelled to thank you guys for coming up with a scheme that's relatively (i.e. relative to ID3v2) easy to parse and render -- thanks. *) Presuming there's no scheme for "padding" it would be nice if some convention could be adopted. This makes "tagging" much faster since in most cases it won't require rewriting the entire file. This could be as simple as a standard comment field with an obvious name -- but I think I've come up with a better solution; more on that later. *) There's no location to read the complete length of the header from. This makes parsing in a streaming situation, where data is being pushed rather than pulled, more complicated. *) Rerendering the full Ogg page(s) seems to be a requirement of the current scheme. This isn't particularly difficult, but could be simplified. *) A comment is allowed to span multiple Ogg pages. This is a pain in the butt. ;-) Despite the Ogg spec saying "large packets are forseens as being useful for initialization data at the beginning of a logical bitstream", it wasn't stipulated in the Vorbis comment spec that this is one such application. Especially when you're just tagging -- and not encoding at the same time -- you're never going to want to split the tag into multiple pages because then you have to go through and rewrite the page number for every following page. I was thinking about these issues, and while they weren't connected in the issues that they raise, I think I've come up with a way that they could all be solved in a backwards compatible way: If it was required, as is true with the Vorbis identification header, that future implementations put the comment in an Ogg stream page by itself this could solve the above issues. It would then be possible to deduce the total size of the comment from the Ogg page header. Though I haven't tried it yet, I also presume that empty space at the end of an Ogg page would simply be ignored, thus providing a mechanism for padding. The size of the padding would then be the size of the comment page minus the comment size. Also this would simplify reading and rendering the comment since it wouldn't be required to account for additional Vorbis data that comes later in the Ogg page or deal with comments that span multiple pages. This seems to have the benefit that it would not confuse current Vorbis implementations, but would solve the issues mentioned above. Anyway -- let me know your thoughts, and please CC me since I'm not on the list. Cheers, - -Scott - -- I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, "Dijkstra would not have liked this", well that would be enough immortality for me. - -E. W. Dijkstra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/kL2Qu0ByfY5QTkRAhOJAJ0fXVmY2esbUtIOxhZbO7+V09fnzwCgwZT4 okYJlbU4z45soxI40/Zak+M=9zX/ -----END PGP SIGNATURE----- <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Scott Wheeler wrote on 2003-06-29:> I've been hacking on an audio metadata library (creatively called TagLib) > which we'll be using in KDE in the next release ( == I need to get around to > finishing it). I've got the Vorbis comment implementation working, but just > wanted to clarify a couple of things: > > *) The vendor ID -- "vendor" is ambiguous here. Is this the "vendor" of the > standard? The encoder? (Seems to be implied by the value mentioned in the > spec.) The tool writing the comment? In my current implementation, I've > assumed the second and as such don't modify the vendor ID, but I didn't know > if I should stuff something in there mentioning TagLib. >Currently AFAIK all ogg files in the world are have a vendor string string identifying some the version of libvorbis that encoded them. So de-facto, it's the encoder. I can't say whether officially it's intended for anything else but frankly, identifying the encoder is more useful than identifying the last application that edited the tags... And if you do want to say something important about the source of the tags, it's probably better put it in a comment tag. The vendor string seems to be not intended as uneditable by end-users (though not protected in any DRM sense), so anything a human might want to say belongs in comment tags.> *) There seems to be no provision for "padding" (to use the ID3v2 word). > Since the comment is very near to the beginning of a Vorbis stream, assuming > a file based implementation, the overwhelming majority of the file's contents > will have to be moved when the comment size changes. Is this correct? >Ogg tells you the size of the comment packet. However, the packet itself contains the number of the comment strings and each has a length count so you can know where the useful packet content ends from the data itself. Therefore, you can pad the comments by putting garbage (preferably zeros, to allow compression on network lines and make sure pieces of old coments don't remain there (the MS word sindrom of embarassing partial erasure)) at the end of the packet, after the useful data. AFAIK that's the "blessed" way to do padding. I'm not aware of anybody implementing this to-date and I'm not 100% sure quick-and dirty programs will ignore this padding but if not the are broken.> *) There's no location to read the complete length of the header > from. This makes parsing in a streaming situation, where data is > being pushed rather than pulled, more complicated. >Indeed. The same is true of all ogg/vorbis packets. As far as Ogg is concerned, packets might be arbitrarily long and it might make sense to do stream processing of a single packet (if you are ready to deal with partial packet corruption.> *) Rerendering the full Ogg page(s) seems to be a requirement of the current > scheme. This isn't particularly difficult, but could be simplified. >You mean that you want to avoid a full implemnattion of the Ogg framing? You are free to use libogg to save yourself the trouble ;-). Handling of Vorbis comments is designed to be easy on top of aa full Ogg implementation; making the comments any kind of a special case outside Ogg framing would make it easier on comment-only programs ubt complicate things for full Vorbis implmentations. Note also that Vorbis does not have to be wrapped in Ogg (e.g. there is a draft Vorbis-over-RTP standard). Conceptually, all Vorbis depends upon is marking of packet boundaries.> *) A comment is allowed to span multiple Ogg pages. This is a pain in the > butt. ;-) Despite the Ogg spec saying "large packets are forseens as being > useful for initialization data at the beginning of a logical bitstream", it > wasn't stipulated in the Vorbis comment spec that this is one such > application. Especially when you're just tagging -- and not encoding at the > same time -- you're never going to want to split the tag into multiple pages > because then you have to go through and rewrite the page number for every > following page. >Yes, this is a problem. It can't be helped because pages are limited to 64KB and comments can in theory exceed that. Rewriting the pages is not a lot of work if you are copying the file anyway; padding will solve both issues in the common case.> I was thinking about these issues, and while they weren't connected in the > issues that they raise, I think I've come up with a way that they could all > be solved in a backwards compatible way: > > If it was required, as is true with the Vorbis identification header, that > future implementations put the comment in an Ogg stream page by itself this > could solve the above issues. It would then be possible to deduce the total > size of the comment from the Ogg page header. Though I haven't tried it yet, > I also presume that empty space at the end of an Ogg page would simply be > ignored, thus providing a mechanism for padding. The size of the padding > would then be the size of the comment page minus the comment size. Also this > would simplify reading and rendering the comment since it wouldn't be required > to account for additional Vorbis data that comes later in the Ogg page or > deal with comments that span multiple pages. >Again, this won't help much because the comments won't always fit in a single page.> This seems to have the benefit that it would not confuse current Vorbis > implementations, but would solve the issues mentioned above. >Not really, because there are a lot of existing files out there that don't close the page between the comments and codebooks packets.> Anyway -- let me know your thoughts, and please CC me since I'm not on the > list. >-- Beni Cherniavsky <cben@tx.technion.ac.il> --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Sunday, June 29, 2003, at 02:37 am, Scott Wheeler wrote:> I've been hacking on an audio metadata library (creatively called > TagLib) > which we'll be using in KDE in the next release ( == I need to get > around to > finishing it). I've got the Vorbis comment implementation working, > but just > wanted to clarify a couple of things:cool!> *) The vendor ID -- "vendor" is ambiguous here. Is this the "vendor" > of the > standard? The encoder? (Seems to be implied by the value mentioned > in the > spec.) The tool writing the comment? In my current implementation, > I've > assumed the second and as such don't modify the vendor ID, but I > didn't know > if I should stuff something in there mentioning TagLib.This is meant to identify the 'encoder' so it's a little ambiguous when you're rewriting the file. In as much as this is metadata describing the compressed content itself, I'd leave it alone if you're just editing the tags.> *) There seems to be no provision for "padding" (to use the ID3v2 > word). > Since the comment is very near to the beginning of a Vorbis stream, > assuming > a file based implementation, the overwhelming majority of the file's > contents > will have to be moved when the comment size changes. Is this correct?That's correct.> *) To what extent is/will a Vorbis comment be an Ogg comment? Will/do > the > other Ogg formats (FLAC and Speex come to mind) use the same format? > In my > (C++) implementation I have separate classes for files and tags. i.e. > With > mp3 there are two tag types -- id3v1 and id3v2. TagLib::VorbisFile and > TagLib::Vorbis::Comment are independant; as such it would be possible > for the > comment to become something that could be mapped to multiple Ogg based > file > formats (which would extract the comment from the format's stream) -- > i.e. > TagLib::Ogg::Comment -- if appropriate.Well, specification of the packet structure is *entirely* up to the codec, so I wouldn't use Ogg::Comment. However, we do by convention use this structure in our designs for speex, vorbis and theora. (I'm not sure about Ogg FLAC) so maybe Xiph::Comment? There is one hitch in that the various codecs have different preambles before the common decode. Vorbis starts with 0x03,'vorbis'; Theora begins 0x81,'theora'; Speex has no preamble at all and begins the packet directly with the vendor length. You'll have to handle this variation somehow.> And now for the obligatory comments section -- > > *) First, I feel compelled to thank you guys for coming up with a > scheme > that's relatively (i.e. relative to ID3v2) easy to parse and render -- > thanks.You're certainly welcome!> *) Presuming there's no scheme for "padding" it would be nice if some > convention could be adopted. This makes "tagging" much faster since > in most > cases it won't require rewriting the entire file. This could be as > simple as > a standard comment field with an obvious name -- but I think I've come > up > with a better solution; more on that later.It may help to think of ogg at a bitstream rather than a file format. That's really the point of view from which is was designed. This is actually true of mp3 as well, but the folks who designed the tagging system didn't appreciate that.> *) There's no location to read the complete length of the header from. > This > makes parsing in a streaming situation, where data is being pushed > rather > than pulled, more complicated.Aye, you have to buffer a bit. Look at icecast2 if you're curious. That's why we specify a page flush after the last header packet; you can just watch the granulepos and know when you've got the headers without parsing pages.> *) Rerendering the full Ogg page(s) seems to be a requirement of the > current > scheme. This isn't particularly difficult, but could be simplified.Yes, but yours is really the only application where that makes any sense. The page mechanism or something like it is required to limit the overhead, so you have to be able to handle all of Ogg to deal with the actual data. As you say, it's not particularly difficult, and libogg if available if you want some help. :-)> [...] > > If it was required, as is true with the Vorbis identification header, > that > future implementations put the comment in an Ogg stream page by itself > this > could solve the above issues. It would then be possible to deduce the > total > size of the comment from the Ogg page header. Though I haven't tried > it yet, > I also presume that empty space at the end of an Ogg page would simply > be > ignored, thus providing a mechanism for padding./page/packet/ here. It usually takes a while to grok the two levels. The spec doesn't say either way about extra data in the header packet, but presumedly a good decoder would handle that. The reason we won't put it on a page by itself is that limits the length to 64k. Is that enough for everyone? That will also be a significant fraction of a low-bitrate file if you always use the full length for padding. We have considered ideas of this sort in the past, particularly when we wrote our own example tag editor. So you're not the first to have to deal with this stuff. Generally our conclusion has been that it's not worth adjusting the spec for the convenience of only that application. My thoughts, FWIW, -r --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> *) The vendor ID -- "vendor" is ambiguous here. Is this the "vendor" of > the standard? The encoder? (Seems to be implied by the value mentioned in > the spec.) The tool writing the comment? In my current implementation, > I've assumed the second and as such don't modify the vendor ID, but I > didn't know if I should stuff something in there mentioning TagLib.Encoder vendor. Not changing it is the right thing to do.> > *) There seems to be no provision for "padding" (to use the ID3v2 word). > Since the comment is very near to the beginning of a Vorbis stream, > assuming a file based implementation, the overwhelming majority of the > file's contents will have to be moved when the comment size changes. Is > this correct?Yes, this lastt bit is correct, but padding is certainly possible. Just use a packet which is larger than the contents of the packet - with the rest probably zero-filled, though it doesn't really matter.> > *) To what extent is/will a Vorbis comment be an Ogg comment? Will/do the > other Ogg formats (FLAC and Speex come to mind) use the same format? In my > (C++) implementation I have separate classes for files and tags. i.e. With > mp3 there are two tag types -- id3v1 and id3v2. TagLib::VorbisFile and > TagLib::Vorbis::Comment are independant; as such it would be possible for > the comment to become something that could be mapped to multiple Ogg based > file formats (which would extract the comment from the format's stream) -- > i.e. TagLib::Ogg::Comment -- if appropriate.So far, other ogg specs have pulled in the vorbis comment specs themselves, with minor differences (i.e. the others generally don't start with "vorbis"). In the future, we'll probably have a generalised ogg metadata stream type.> > *) Presuming there's no scheme for "padding" it would be nice if some > convention could be adopted. This makes "tagging" much faster since in > most cases it won't require rewriting the entire file. This could be as > simple as a standard comment field with an obvious name -- but I think I've > come up with a better solution; more on that later.Well, as described above, you can use padding already, so...> > *) There's no location to read the complete length of the header from. > This makes parsing in a streaming situation, where data is being pushed > rather than pulled, more complicated.That's true, I suppose, if the header spans multiple pages. Fundamental part of the ogg design, so that won't change...> > *) Rerendering the full Ogg page(s) seems to be a requirement of the > current scheme. This isn't particularly difficult, but could be > simplified.Depends. This is a matter of how much complexity you want. The only case where (assuming a correct input file) you need to re-'render' every ogg page is if the total length of the comment header increases to more than (current_number_of_ogg_pages_for_comment_header * max_page_length), where max_page_length is just under 64 kB. That's pretty rare.> > *) A comment is allowed to span multiple Ogg pages. This is a pain in the > butt. ;-) Despite the Ogg spec saying "large packets are forseens as > being useful for initialization data at the beginning of a logical > bitstream", it wasn't stipulated in the Vorbis comment spec that this is > one such application. Especially when you're just tagging -- and not > encoding at the same time -- you're never going to want to split the tag > into multiple pages because then you have to go through and rewrite the > page number for every following page.Right. See above. This is only the case where the number of pages HAS to change, which will essentially never happen. You could just choose not to support that case - 64 kB of text comments is quite a lot. Doing so would solve your issues, I think. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Michael Smith wrote on 2003-07-01:> > *) There seems to be no provision for "padding" (to use the ID3v2 word). > > Since the comment is very near to the beginning of a Vorbis stream, > > assuming a file based implementation, the overwhelming majority of the > > file's contents will have to be moved when the comment size changes. Is > > this correct? > > Yes, this lastt bit is correct, but padding is certainly possible. Just use a > packet which is larger than the contents of the packet - with the rest > probably zero-filled, though it doesn't really matter. >http://www.xiph.org/ogg/vorbis/doc/v-comment.html is not entirely explicit on this. It only says you must have one "framing bit" equal to 1 after the comments - what for? The natural way to read it would be that if you do have the framing bit, everything after it should be ignored -- but it doesn't take too much squinting at it to decide to do anything else (like complaining) when the packet doesn't end there. If the intent is that such padding is legal, could this be written there explicitly?> > *) Rerendering the full Ogg page(s) seems to be a requirement of the > > current scheme. This isn't particularly difficult, but could be > > simplified. > > Depends. This is a matter of how much complexity you want. The only case where > (assuming a correct input file) you need to re-'render' every ogg page is if > the total length of the comment header increases to more than > (current_number_of_ogg_pages_for_comment_header * max_page_length), where > max_page_length is just under 64 kB. That's pretty rare. >If you want to strain it, you could always keep lengthening following pages until you catch up with the page number of the original file, so that the rest can be trivially bit-copied. This is not necessarily a good idea since long pages require bigger buffers (=> higher latency) at the decoder and reduce the fault-tolerance and seek effeciency(?). Besides, all such tricks require deeper tying of the comment-handling to the Ogg framing implementation than if you just take the Ogg packets abstraction as opaque to your needs. And the later will be easier to adapt to parsing comments from Ogg-less RTP streams, if these are relevant to your TagLib. In any case, I don't think re-paginating the file makes much difference if you are rwriting it completely anyway. If you normally avoid this by padding, you also avoid re-pagination.> You could just choose not to support that case - 64 kB of text > comments is quite a lot. Doing so would solve your issues, I think. >You can do so on writing but you must be prepared to read files that do split the comment header to multiple pages. -- Beni Cherniavsky <cben@tx.technion.ac.il> --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Tuesday 01 July 2003 4:19, Michael Smith wrote:> Encoder vendor. Not changing it is the right thing to do.Cool; won't change that then.> Yes, this lastt bit is correct, but padding is certainly possible. Just use > a packet which is larger than the contents of the packet - with the rest > probably zero-filled, though it doesn't really matter.Ok, in my other mail I mentioned that I'm playing with this and will do some more soon...> So far, other ogg specs have pulled in the vorbis comment specs themselves, > with minor differences (i.e. the others generally don't start with > "vorbis").Ok, like I said, my comment handling class assumes that the file handling class has already parsed the Vorbis (or any other codec) packet. From there it just assumes that the rest of the byte arrangement follows the specification. I think what I'm hearing is that this type of separation (i.e. just doing step 4 from section 5.2.1 of the spec in my comment class) should work for the other Xiph codecs too.> In the future, we'll probably have a generalised ogg metadata stream type.Cool. I'll probably subscribe here and let the lurking begin. :-)> That's true, I suppose, if the header spans multiple pages. Fundamental part > of the ogg design, so that won't change...Yes, but I hadn't understood earlier that I can get the size of the Vorbis packet from the lacing values -- in fact I realize now that I had misinterpreted what exactly a "codec packet" is.> Depends. This is a matter of how much complexity you want. The only case > where (assuming a correct input file) you need to re-'render' every ogg page > is if the total length of the comment header increases to more than > (current_number_of_ogg_pages_for_comment_header * max_page_length), where > max_page_length is just under 64 kB. That's pretty rare. > > > *) A comment is allowed to span multiple Ogg pages. This is a pain in the > > butt. ;-) Despite the Ogg spec saying "large packets are forseens as > > being useful for initialization data at the beginning of a logical > > bitstream", it wasn't stipulated in the Vorbis comment spec that this is > > one such application. Especially when you're just tagging -- and not > > encoding at the same time -- you're never going to want to split the tag > > into multiple pages because then you have to go through and rewrite the > > page number for every following page. > > Right. See above. This is only the case where the number of pages HAS to > change, which will essentially never happen. You could just choose not to > support that case - 64 kB of text comments is quite a lot. Doing so would > solve your issues, I think.Well, yes, I could (and do in my attempt from last weekend), but despite my whining I'll probably go ahead and get a compliant implementation working. Aside from padding my comments were mostly intended as a "at some point in the future this might be nice for future implementors" type-of-thing. My attempts from last weekend, while working for the cases I've tested, well, I can say that part of the "working" bit was luck. :-) But it gave me a little bit of background for to bring up these questions, for which the answers have been really helpful. Again, thanks folks - -Scott -- We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. -Donald Knuth <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First, sorry that I'm slow on the responses -- my DSL provider doesn't love me. ;-) On Monday 30 June 2003 13:17, Ralph Giles wrote:> This is meant to identify the 'encoder' so it's a little ambiguous when > you're rewriting the file. In as much as this is metadata describing > the compressed content itself, I'd leave it alone if you're just > editing the tags.No problems here -- I just wanted to make sure that I wasn't supposed to set this.> Well, specification of the packet structure is *entirely* up to the > codec, so I wouldn't use Ogg::Comment. However, we do by convention use > this structure in our designs for speex, vorbis and theora. (I'm not > sure about Ogg FLAC) so maybe Xiph::Comment?Ok, I was forgetting that Ogg can contain non-Xiph formats.> There is one hitch in that the various codecs have different preambles > before the common decode. Vorbis starts with 0x03,'vorbis'; Theora > begins 0x81,'theora'; Speex has no preamble at all and begins the > packet directly with the vendor length. You'll have to handle this > variation somehow.This is actually no problem for my implementation since the "comment" in my case doesn't refer to a Vorbis header, but actually with the data that happens to be contained in the second Vorbis header. I leave it up to my file representation to handle extracting that and the stuffing it back into the Vorbis and Ogg wrappers. I haven't written implementations for these other formats yet, but anticipate doing so and am trying to get the design close to right on the first go-round (famous last words).> > *) Presuming there's no scheme for "padding" it would be nice if some > > convention could be adopted. This makes "tagging" much faster since > > in most > > cases it won't require rewriting the entire file. This could be as > > simple as > > a standard comment field with an obvious name -- but I think I've come > > up > > with a better solution; more on that later. > > It may help to think of ogg at a bitstream rather than a file format. > That's really the point of view from which is was designed. This is > actually true of mp3 as well, but the folks who designed the tagging > system didn't appreciate that.Well, ID3v1 was an accident; "design" is a laughable word in that context. On the other hand ID3v2 is stream oriented, but very much overly complicated -- it takes a few thousand lines of code do a minimal implementation of its 40 page spec. However, with their concept of a "stream" it was also recognized that very much of the time said stream would be a file and that such a file would require being rewritten without some provision for "padding" (It's also a prepended format.).> Aye, you have to buffer a bit. Look at icecast2 if you're curious. > That's why we specify a page flush after the last header packet; you > can just watch the granulepos and know when you've got the headers > without parsing pages.Ok, I think I understand things a bit better so here's a test to see if I get it -- I actually can find out the size of the Vorbis comment header using the current scheme since it will be the first packet that starts on the second Ogg page and as such if it's fully contained in the second Ogg page I can get the length of the Vorbis comment header packet by summing the lacing values from the first until the first lacing value less than 255. (And since a comment is often less than 255 bytes, often the size of the Vorbis comment header will simply be equal to the first lacing value.) (Whew...) How'd I do? :-)> > *) Rerendering the full Ogg page(s) seems to be a requirement of the > > current scheme. This isn't particularly difficult, but could be > > simplified. > > Yes, but yours is really the only application where that makes any > sense. The page mechanism or something like it is required to limit the > overhead, so you have to be able to handle all of Ogg to deal with the > actual data. As you say, it's not particularly difficult, and libogg if > available if you want some help. :-)And using libogg would feel like giving in at this point. ;-) I think things are starting to fit together for me though. I'm going to go back this weekend and try to make my implementation more enlightened...> s/page/packet/ here. It usually takes a while to grok the two levels. > > The spec doesn't say either way about extra data in the header packet, > but presumedly a good decoder would handle that. The reason we won't > put it on a page by itself is that limits the length to 64k. Is that > enough for everyone? That will also be a significant fraction of a > low-bitrate file if you always use the full length for padding.Given that Vorbis comments are text-only, I would assume that a limit of 64k really isn't a strange or unusual constraint -- I mean, printed, that's several full pages of text. Certainly the "spirit" of the comment spec is that it's not meant for huge amounts of data (thinking of the comment that it's supposed to be equivalent to what you might jot on a CD-R). As for padding, no I wasn't assuming that the maximum page length would always be used. The way that most ID3v2 implementations work is that the first time you write a tag, you add ~2 kb of "padding". You continue to work in that tag size + 2 kb until you actually write something more than that size, and then when re-writing the file you add another 2 kb.> We have considered ideas of this sort in the past, particularly when we > wrote our own example tag editor. So you're not the first to have to > deal with this stuff. Generally our conclusion has been that it's not > worth adjusting the spec for the convenience of only that application.Yes, I realize that changing a spec is an annoyance -- that's why I was trying to think of a way that wouldn't break existing implementations, and really could be backwards compatible. But of course once Ogg takes over the world you must realize that you'll inherit all 436 taggers on SourceForge. (Yes, I made that number up; I'm probably underestimating.) :-) When you get into things like batch tagging, moving around the contents of 20-2000 files at once takes a *long* time as compared to just inserting a few hundred bytes at the beginning... I've been trying to hack out an example of what I talked about and can't find a variation that ogg123 seems to like. (And again, because my DSL is out I can't just grab the sources -- will do so at work tomorrow when I send this mail.) The variations that I tried were: - - adding 1024 bytes to the end of the first packet in the second Ogg page, after the comment and - - adding a new packet to the Ogg header (via the lacing values) and just appending 1024 bytes to the end of the page Neither seemed to work, but it's entirely possible that I botched something with the hex editor. Again, thanks for the patience folks -- I realize that these are mostly "dummy" questions in this context. Cheers, - -Scott - -- New Orleans food is as delicious as the less criminal forms of sin. --Mark Twain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/AiC3Qu0ByfY5QTkRApDmAJ9CuEhMM2u9pplaYwtfkGR9hyg3XQCfUFoF YolxlgsJE/3Np3SNAQ6uVqg=6Ofj -----END PGP SIGNATURE----- <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ralph Giles wrote:> This is meant to identify the 'encoder' so it's a little ambiguous when > you're rewriting the file. In as much as this is metadata describing the > compressed content itself, I'd leave it alone if you're just editing the > tags.In my peelers etc., which _are_ changing the content, I leave it alone as well; I add "normal" comments instead. Much more readable, if you run multiple tools on a stream :-)>> *) There seems to be no provision for "padding" (to use the ID3v2 word). >> Since the comment is very near to the beginning of a Vorbis stream, >> assuming >> a file based implementation, the overwhelming majority of the file's >> contents >> will have to be moved when the comment size changes. Is this correct? > > That's correct.You can pad the comment packet, with no ill effects. But you are not required to pad it. Or does the spec prohibit padding altogether? I would hope not, if only for upward compatibility issues.> There is one hitch in that the various codecs have different preambles > before the common decode. Vorbis starts with 0x03,'vorbis'; Theora > begins 0x81,'theora'; Speex has no preamble at all and begins the packet > directly with the vendor length. You'll have to handle this variation > somehow.Aren't all Speex header packets identifiable as such? That's bad. <p>Segher <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ralph Giles wrote:> Aye, you have to buffer a bit. Look at icecast2 if you're curious. > That's why we specify a page flush after the last header packet; you can > just watch the granulepos and know when you've got the headers without > parsing pages.No, you can't. Think "error detection/recovery". <p>Segher <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.