[vorbis] TAG Standard - ENSEMBLE/PERFORMER tags

[Glenn Maynard]

On Fri, Jan 04, 2002 at 09:11:12PM +1000, Geoff Shang wrote:
> > The group is usually of more interest than individual performers
> > playing with them.  The concensus is that tags are for SIMPLE data which
> > should require no parsing at all.  If you want to tell winamp "display
> > the ensemble, but not performers", without an ENSEMBLE tag, you can't do
> > that.

If you want to tell winamp "display the title in Hebrew", you can't do
it at all with the tags.  :)  Is "display the ensemble, but not
performers" a request you want to support?  That goes well beyond just
"identifying the song" (and the corollary "display the data so it can be
identified.")

> You're going to hit this problem with any tags that are specified more than
> once.  If someone specifies title twice (don't ask me why they would), what
> will winamp do?  This is probably undefined as far as the standard is
> concerned.
>
> Perhaps it could be stated that, in such cases where only one of a given
> tag is desired by the player (as in your winamp example), the first (or
> last, or whatever) tag will be considered of most importance and will be
> used in preference to any other.

https://reactor-core.org/~djw/ogg-tags.txt says TITLE can only appear
once.  It probably shouldn't say " ... but if it DOES appear twice,
prioritize it this and that way".  That's contradictory.  (It's like the
FTP RFC, which says you can't send more than one command over an FTP
control connection at a time ... but servers must allow it.  End result:
clients do it anyway, expecting servers to support it.)

I really don't think the order of tags should be significant, either.
What if I load the tags into a C++ set?  Now I have to keep track of the
order, too, and everything gets harder.

> IMHO, adding a tag just so that a player knows what to display is
> overkill.

Do you mean "adding a tag just so the player can choose more
specifically what to display is overkill?"  (The entire point of tags is
so players, etc. can know what to display: the title of the song, for
example.)

The three independent goals listed:
"1) Identify a track so the listener can know exactly what he is listening
to.  2) Identify a track so the listener can purchase the piece of music.
4) Identify a track within a database that contains complete information
about the track."

I'm going to skip #1 and #2.  (We can satisfy them without tag names at
all; they don't even seem to imply any programmatic, parsable interface.
A paragraph of information in English sentences could fulfill that.)  
#4 seems to be where tags become useful and their classifications
become important.

So, the question would become: does the PERFORMER/ENSEMBLE split help
#4?  (I don't know.)

I'm not reading "let a player pick and choose what information to display
in a fairly finely-grained manner" into the goals.  If that is, in fact,
desired, I'd suggest adding it to the list.  I think it's better to
leave it off, though.  My interpretation of the current state: The ability
to selectively display titles, composers, etc. in interesting ways by a
player is a nice side effect, but nothing more.  Having things for this
purpose alone would seem to fall in the same category as me wanting
multiple translations: wait for the metadata stream.  (And maybe consider
it another incentive to start talks about it! :)  

(So there's no confusion: I have no real opinion on this split; I'm not
arguing for or against it, just suggesting a way to look at the debate.
Of course, other issues have been brought up, like whether they're distinct
or obvious enough; I think those are different debates, however.)


-- 
Glenn Maynard

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