[vorbis] Comment field spec needs to be expanded and tightened

[Michael Smith]

At 10:36 PM 3/3/01 -0500, you wrote:
>
>Hello!  I think the "Ogg Vorbis comment field specification"
>(http://www.xiph.org/ogg/vorbis/doc/v-comment.html)
>should specify many more fields and define them more exactly. That way,
>everyone will agree on their meanings and computers can process them.
>Three of the current field names are very misleading; I think they should be
>changed, ASAP.  In particular, a few more tags would help support commercial
>use and staying within the law (e.g., "copy all tracks that can be freely
>redistributed"); I think that would speed acceptance of Ogg Vorbis.

Some of these suggestions are quite sensible, and I agree with them (more
detail below). However, a lot of it isn't appropriate for the comment header.
As v-comment.html says, that header is designed for "short, text comments,
not arbitrary metadata". We've discussed a full metadata stream on the lists
several times, but people haven't had enough time to flesh out the
suggestions into a full (if only draft) spec. 

Most of your suggestions below, whilst good in concept, are appropriate
for this, rather than the headers. Perhaps you'd like to read over the 
list archives on this topic and work with other people on the list towards 
a final metadata spec. 

More detailed comments below:

>First, the misleading names.
>Change "ORGANIZATION" to "PUBLISHER"; many other organizations
>may be involved, and not all publishers are organizations.
>Note that MP3's related spec already calls this value "publisher".  I suggest
>changing "DATE" to "RECORDING_DATE" and "LOCATION" to "RECORDING_LOCATION";
>there are many other potential dates and locations someone might store.

Changing organisation to publisher is probably a good idea. 
Changing date and location doesn't seem neccesary - whilst other
dates/locations are indeed possible, the meaning of those two seems
clear to me - others should be qualified.

>COMPOSER
>AUTHOR
>ARRANGER
>PRODUCER
>CONDUCTOR
>ACCOMPANIMENT
>ACCOMPANIMENT_ARTIST
>STATION
>INTERVIEWEE
>INTERVIEWER

The first few (up to conductor) seem reasonable to me. The later ones are
too unlikely to be of interest. We'd want something like these in a full
metadata stream, but not in the header. 'station' seems irrelevent, though.

>LENGTH

Definately not. This is already present in the file (the decoder knows how
long a track is), and is unneccesary. It's also likely to be wrong, as the
file gets edited, chopped into parts, etc.

>SUBTITLE
> Subtitle.

Perhaps - but I think it'd be better to have this in the title comment 
(or in a second title comment).

>LANGUAGE
> The language(s) used in the recording (comma-separated if more than one).

Seems reasonable.

>CD_ID

No. "Short, text, comments". This is completely inappropriate.

>DEMO

See 'VERSION'.

>REDISTRIBUTION
>USAGE
>LICENSE
>LICENSEE
>LYRICS_COPYRIGHT
>MUSIC_COPYRIGHT
>PURCHASE-URL

I'd suggest that these all go in the COPYRIGHT comment(s). Splitting them
up doesn't add anything, and people are unlikely to use them.

>* General conventions:
>
>For a field with a URL (URI), just append "-URL" to the fieldname.

Why? There's nothing preventing the user from reading a url from a
comment as-is, and no reason to change that. The comment header is
meant (unlike a true metadata stream) to consist of human-readable
and usable data - so splitting this out isn't useful here.

>If field data has different values for different languages,
>append "[", language name, and "]" to the field name.

Seems appropriate for a metadata stream, but overly complex for
the comment header.

>(Modify COPYRIGHT to say): This field should have a date, a space,
>and then the name of the copyright owner.

Disagree. Copyright should contain any and all copyright data in 
whatever format the creator deems appropriate.

>
>(Modify GENRE to say this - you might just copy in the list):
>For GENRE, where possible, use the full text name of the genre as
>specified in the MP3 ID3v2 specification, appendix A
>(http://www.id3.org/develop.html).

I've never liked the id3 genre listings, and I don't think this is a 
good way to go. We shouldn't constrain ourselves like this.

>All dates/times must be specified using a subset of ISO 8601
>(this is also true for ID3v2, see below). The format of a time string is
>yyy-MM-ddTHH:mm:ss

>All languages must be specified using IETF RFC 1766.
>Examples include "en" (English), "en-US" (U.S. English), "fr" (French),
>"de" (German), "ru" (Russian), "ja" (Japanese), and "zh" (Chinese).

For both of the above: change "must" to "should". Though I agree these
should be encouraged, I don't think it's advantageous to require this.
In fact, I'm confident that, should be 'require' it, any such requirement
would be completely ignored. Most uses of this will include a year, and
little more.

>
>The "Structure" entry should be modified, changing
>"single vector for vendor name" to
>"single vector for encoding library", since that's what it is.

No, it isn't. It happens to be the same things right now, since there 
is but a single implementation of vorbis encoding - but this is meant to 
be the vendor name.

>If you're "not sure" if you want to accept a particular field name
>definition, perhaps create a list titled "under consideration" --
>that way, more people can see the proposal, and those who wish to
>capture that information will at least have a suggestion on how
>to capture it.

I'd say we should just continue discussion on the list, for things like
this. 

>Perhaps append "_IMAGE" for the image.

Images don't belong in the comment header - but it's perfectly reasonable
to refer to a url in one of the copyrights, I don't think we need to tag
such comments differently.
>I haven't tried to define how to capture lyrics/text.
>I know that one proposal (by Ralph Giles on 28 August 2000) is at:
>http://xiph.org/archives/vorbis/200008/0082.html

This is a definate metadata-stream issue - discussion on it is interesting
still, but not in the context of the comment header.

Michael

p.s. I think further discussion should be moved to vorbis-dev

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