[vorbis] (Classical) Request for Standardization of expanded TAGS

[Beni Cherniavksy]

On 2001-12-06, Jonathan Walther wrote:

> On Thu, Dec 06, 2001 at 11:30:15PM -0500, Wilson wrote:
> >I won't cry myself to sleep because I filled in the name of the barbershop
> >quartet in the ARTIST field rather than the ENSEMBLE field.
>
> Well thats good.  You are a big boy.  So you won't cry either if your
> favorite ogg player releases a version that doesn't recognize an ARTIST
> tag, or pops up an annoying reminder window saying "switch to some of
> these other tags instead".
>
The first behaviour is a Bug.  All ogg vorbis software that doesn't
provide means for a user to redefine the tag-treating policy arbitrarily
has only one possible correct behaviour - to show all tags!  The second
is a bug too if one can't disable it.

The vorbis tag mechanism is a mechanism, it's not a policy.  You can build
multiple possible policies around it, by agreement and possibly by
_configurable_ software support but a software that is just incapable of
providing at least raw access to the _any_ use of the mechanism can't be
considered a correct implementation.  I won't consider it such and I plead
everybody else to stop suggesting tag policeware.

That's the whole beauty of the vorbis tagging scheme - it does not need
any understanding of it's meaning from the software in order to have
unlimited expression power.  Compare with ID3v2 which needs huge support
from the software only in order to provide a limited structure (yes, one
can stuck everything in a Comment field - what is the big win then?  One
can't express the fact that "Sivan 5, 5734" is a date (hebrew calendar)
because the date field has frozen format).

> >Also, nowhere in my message did I suggest that we no standardize a bunch of
> >tag names.
>
> Except you want to keep the meaningless ARTIST tag, for backwards
> compatibility with software that hasn't been released yet, and might not
> even support an ARTIST tag if the standard says not to!
>
> >If you read the message, you'll see that I'm agreeing with the concept of
> >subtags.
>
> Tags are meant for simple data.  Subtags sound like "structure".  It
> adds too much complexity to clients that want to parse and display them.
> If you want structure, then use the metadata stream, not tags.
>
> >I'd rather have one generic "ID" tag with substructures than 50 different
> >tags that basically all mean "15 digit number that represents this exact
> >disc."
>
> Which 50 different tags? I only wanted one; someone else added 2 more
> proposals in.  3 tags for different disc hashes and identifications is
> still manageable.
>
I disagree.  More are bound to be added as time passes.  Dics IDs that are
not very readable by humans are not very appropriate among vorbis tags
anyway.  However they are useful and we need.  Why not reserve a single
corner to them:

ID=FREEDB:...
ID=SOMEFUTUREID:...

and be sure that unreadable tags can be filtered from disaply simply by
configuring the player not to show any `ID' tags?

> >A profusion of tags that aren't clearly marked as "optional" is just going
> >to confuse media player programmers, in my mind.
>
As I stated above, programmers need deal with tag meanings at all, unless
thye are capable of producing a generic system tunable by the user.  Any
hardwired scheme would be worse than a dumb show-all-tags player.

> Perhaps you should have read the proposed standard more carefully.  All
> the tags were stated to be optional.  You could even release an Ogg with
> no tags!
>
> Jonathan
>


-- 
Beni Cherniavsky <cben at tx.technion.ac.il>
                 (also scben at t2 in Technion)

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