[vorbis-dev] ov_comment spec

[Rudd-O]

>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 at 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 at icecast.org
> carmstrong at 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 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.