[vorbis] TAG Standard - ENSEMBLE/PERFORMER tags

[Glenn Maynard]

On Mon, Jan 07, 2002 at 01:04:46PM -0800, Jonathan Walther wrote:
> You guys are quick to yell "throw stuff out!" because you will never
> need or use it, and disregard people who have said they need it.
> 
> As expressed in the proposed standard, allowing RFC2047 in Ogg tags
> doesn't conflict with UTF8 nor does it place any extra burder on taggers
> and players.

I've already said that there's a very high cost.  Every encoder and
player that decodes tags at this level *must* deal with it; it's not
optional.

What if I have text in a tag that looks like an RFC2047 string?  (Don't
say "that probably won't happen"; that would be extremely poor design.)

If that happens, I have to encode the string with RFC2047, so it'll be
decoded back; otherwise, things will try to decode it and odd things
happen.

This means regular, all-UTF-8 tags can have RFC2047, so every player
must be able to decode it.

I've said all this already, of course.

I wouldn't argue much against most additions that really could be skipped
completely by players and editors, if it was too much of a burden.  This
isn't one of them.

> The soles reason I've seen so far for chucking it out are: if you dump

I have listed a large number of reasons not to use it.

> RFC2047 directly to the screen, it will look ugly, and the other one is
> "it adds more work for everyone".  Both of which reasons are bogus, and
> the second isn't even true.

Both of these reasons are true, and you're the only one claiming they're
"bogus".  Lots of people agree the tags should be human-readable; you
(and maybe Dan) appear to be the the only ones who think this is
unimportant.

> >RFC2047 has a terrible price/advantage ratio since it means all
> >implementations must now include support for many encoding, instead of a
> >single one (UTF-8).  It's also ugly and not intended for this use.
> >Good
>
> That is false.  RFC2047 encoding can just be interpreted as plain text.
> And if that is ugly, so are UTF-8 glyphs that just don't happen to be in
> the local font.

UTF-8 glyphs that aren't in the local font can be displayed
intelligently, either as a placeholder font entry, a "best-fit", or by
simply using another font.

The alternative:

=?iso-2022-jp?B?KBskQjJWMWMbKEIp?=

(No, I don't know what that says; I pulled it out of a grep of my mail
directory.)


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