Vorbis dev - Oct 2000 - ov_comment spec

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:

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.

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

I'd like to implement something cleanly that wont bite us in the ass later
(:
So i'm bitching now!  Lets get something writen down and worked out while
there is still a bit of time. 

Anyone have any thoughts on this?

gratz

-=C=-
Chad Armstrong
icecast/vorbis developer
chad@icecast.org
carmstrong@icast.com


<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001018/33ea8cf2/part-0001.obj

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

 -ralph


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

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

>From an end user point of view:
I'd like to play my ogg file in my player X, then 
select File information: and pop a box that shows the 
information for the last TAG that the player went 
through.  So if I have an ogg file with several audio 
or video streams, information relative to the current 
stream should be shown, be it music metadata or lyrics, 
or narratives.

I'd like to be able to author them too, maybe by 
selecting New information... in a menu, then responding 
to a simple question:
o General info
o Insert info in current play point
Select one of these, and create, modify or delete that 
information.

Something that would be easy to use for newbies, 
displayed at all the time, and easy to modify too.

Quoting chad <chad@analogself.com>:
> 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:
>
> 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)
> a> nd
> 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.
>
> TAG=string is very straightforward, and easy, but it 
allows things like
> duplicates, something which is not clearly documented 
(except code) and
> whi> ch
> 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...)
>
> I'd like to implement something cleanly that wont 
bite us in the ass later
> > (:
> So i'm bitching now!  Lets get something writen down 
and worked out while
> there is still a bit of time. 
>
> Anyone have any thoughts on this?
>
> gratz
>
> -=C=-
> Chad Armstrong
> icecast/vorbis developer
> chad@icecast.org
> carmstrong@icast.com
> 
----------------------------------------------------------
   Universidad Federico Santa Maria - Campus Guayaquil

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