[vorbis-dev] clarifications on comments spec

Scott Wheeler wheeler at kde.org
Sat Jun 28 18:37:57 PDT 2003



-----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 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.



More information about the Vorbis-dev mailing list