[vorbis-dev] clarifications on comments spec

[Michael Smith]

> *) 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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.