[vorbis] TAG Standard - ENSEMBLE/PERFORMER tags

[Jonathan Walther]

On Thu, Jan 03, 2002 at 05:37:13AM -0500, Glenn Maynard wrote:
>Once such a metadata stream is implemented, what's to happen to the
>basic tag format?  It would, I assume, give all of the functionality of
>the basic tags.

Tags are for quick and dirty simple information.  Once we get proper
metadata it will probably supplant tags.  But in the meantime it's
useful; its like the ability to set as many "file attributes" as you
want in BeOS on a file by file basis.

>I have no problem with the current tag list that's been proposed.  (That is,
>none that I care to argue about. :)

But you wanted more tags than what are currently in the standard, right?
No problem; make a list, post it here for comment, and I'll put it in
Appendix A.

>If the tags are intended to be superceded by a more comprehensive format,
>then more useful things like translated tags should, indeed, wait for that.

At the rate things are going its going to be a looooooong wait.  Noone
has felt sufficient need for the metadata stream to start using it, or
even to start the discussion on this list of how they think it should be
used...

>A previous post said the other basic requirement of tags was to allow
>players to display the title, etc. of the current file.  (This isn't listed
>in https://reactor-core.org/~djw/ogg-tags.txt.)  If that's not needed,

It is listed, but in different words.  I believe "Being able to
identify what you are listening to" would fall in that category.
``track 10 of a CD by Pink Floyd'' doesn't cut it as positive
identification, even though you might be able to use that to buy it at
the record store.

>If you *do* want to be able to do that, then the language of the tags is
>needed.  A cheap way to do it would be to have a single "lang" tag, with
>a standard two-letter language code.  (This would explicitely mark the

I disagree.  Tag data is 8 bit clean.  Right now it is mostly ascii but
there is no reason why character encoding couldn't be specified as it is
in RFC compliant email headers.  Its some kind of ugly 8 character ascii
string, and I don't know what RFC it's specified, but when I see emails
in my inbox and the subject shows up in Korean or Japanese glyphs, thats
sure enough one of those mails.

Here is an example of what I mean, taken from a recent message to the
debian-devel mailing list:

From: =?ks_c_5601-1987?B?x+7FuMDM?= <dkfjskd-dd at hotmail.com>
To: debian-devel at lists.debian.org
Subject: =?ks_c_5601-1987?B?W7GksO1dIMfuxbjAzMO1sbk=?=

Here is what that showed up as in mutt:

From: \307\356\305\270\300\314 <dkfjskd-dd at hotmail.com>
To: debian-devel at lists.debian.org
Subject: [\261\244\260\355] \307\356\305\270\300\314\303\265\261\271

But in pine it some how magically showed up as Korean glyphs.

So, since we already have an RFC approved standard (I'm assuming; I've
been seeing these types of emails for years) for mixing foreign glyphs
with real text, lets use it.

For the tags themselves, they are standard, and they're staying that
way.  I'm not going to encode CONDUCTOR into Chinese.  Because its a
standard tag, the player can translate it if it wants to.  And I see
no reason why a Chinese language encoder couldn't take their equivalent
of "conductor" and encode it as the CONDUCTOR tag in the ogg file
itself, making it invisible to the Chinese speaking user.

Jonathan

-------------- 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/20020103/39cd5581/part.pgp