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

[Jonathan Walther]

Beni, thanks for your comments.  I believe they are addressed in the
most recent revision of the proposal, here:

http://209.53.17.13/~djw/ogg-tags.txt

The proposal hasn't been updated for 4 days now; a good sign that it has
settled into something pretty close to its final form, unless Monty
speaks up and suprises us all.

Jonathan

On Wed, Dec 12, 2001 at 12:08:29PM +0200, Beni Cherniavksy 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 797 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20011212/aa95953c/part.pgp