[vorbis-dev] ov_comment spec

[Michael Smith]

At 02:16 PM 10/18/00 -0700, you wrote:
>I've been working towards a mp3info like tool, OggInfo, which will surplant
>vorbiscomment in functionality, and also incorportate mp3info like
>featuers. Looking at existing vorbis api calls, i find:

Surplanting vorbiscomment in either functionality or readability of code shouldn't be hard...

>
>vorbis_comment_add() /* unsupervised string insertion */
>vorbis_comment_add_tag() /* formated TAG=text insertion */
>vorbis_comment_query() /* scans for matching tag (up to count duplicates) and
>returns the last one */
>vorbis_comment_query_count() /* returns the number of matching TAG instances
>*/
>vorbis_comment_clear() /* obvious */
>
>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.

The decision to allow multiple instances of the one tag was made a long time ago. It's deliberately like this, it isn't just a result of the code being easier. However, it's possibly worthwhile to add further calls to libvorbis (personally, I think what's there is sufficient, but I'm having difficulty with actually caring that much about metadata issues these days) to do something like returning a formatted string containing all the instances of some tag (so ARTIST=John and ARTIST=Bob would become "John and Bob" or something)

Removing the capability of having multiple instances of a tag isn't reasonable, though. This is explicitly documented in doc/v-comment.html (I think).

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

The code as it is is sufficient for the comments header, though some convenience additions might be nice. Changing ogg123 to actually use it would be a good idea. For more stuff (like song lyrics) see the long flamewar (err.. discussion) in the archives. People apparently want to use XML for it. I'm keeping out of that discussion now.

Michael

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