[vorbis-dev] ov_comment spec

Ralph Giles giles at snow.ashlu.bc.ca
Wed Oct 18 14:59:18 PDT 2000

On Wed, 18 Oct 2000, chad wrote:

> It seems to be allowing duplicate TAG identifies is less than optimal.  I
> know there are instances where you have more than one artist, for example,
> and you need to allow for more than one artist value.  I'm interested in
> making  as seemless an api usage as possible, so that it extremely easy to
> use (not alot of application coding to get something to work) and something
> that lends itself to being implemented the same way, and extensible at that.

See, see Vakor? :-)

Duplicate tags are an excellent choice from the metadata point of view.
It's much easier to write an indexer if you can assume one tag = one
record. Cleaner design. Look at any library database.

BUT, it's only useful if most people use it, and that requires careful
application support.

> TAG=string is very straightforward, and easy, but it allows things like
> duplicates, something which is not clearly documented (except code) and which
> might be handled differently depending on the application developer.

The duplicate tag issue is clearly described in the comment header
documentation. see vorbis/doc/v-comment.html in cvs.

> I see
> ogg123 for instance is doing all the TAG string matching by hand, and also
> with hardcoded TAG values.. this seems like something that should all be
> taken away and packaged nicely behind an api, so that there aren't any
> mistakes. Yet we also need something extensible that has streaming in mind,
> and all the cool features we'd want to use this space for... (song lyrics,
> html links ect...)

I'm not sure what you're proposing here. Ogg123 is pretty rough code, and
the analysis could certainly be more elegant. The intent (well, mine
anyway) was just to distinguish canonical from custom comments as a policy
example. I remember the vc query api needed work (did that ever happen?)
but I'm not sure what else needs wrapping.

Be aware that the vorbis comment header really is just intended for brief,
identificatory metadata. More complete metadata, as well as separate
tracks like lyrics will go in a separate stream type, probably xml based.
This we need serious help with, including a good api!

Check the list archives this summer (mostly on vorbis@) for details, or
see my two current proposals:

http://musicbrainz.org/MM/ (for general metadata, parsing library exists)
http://www.xiph.org/archives/vorbis/0434.html (for lyrics)

> Anyone have any thoughts on this?

My own biased perspective :-)


giles at ashlu.bc.ca

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