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

[John Morton]

On Thursday 13 December 2001 13:15, Jonathan Walther wrote:
> On Thu, Dec 13, 2001 at 12:23:04PM +1300, John Morton wrote:

> Do you see anywhere there it forbids a compliant Ogg player to display
> non-standard tags?

Let's just say Marks' change in wording makes it look less like you're saying 
'compliant players can display everything, but we're not using artist now, so 
you can like it or lump it.'

> >I'm also not keen on _requiring_ certain fields to be singletons, either.
> >Most of the fields mentioned in that list are likely to only have one
> > value because it doesn't make much sense to enter more than one.

> Quack quack quack! Quack! 

I'm going to assume that little outburst is a symptom of your passion for the 
topic at hand, and the 'standard' as you see it, rather than a personal 
attack. 

The problem I'm having with your proposal is that you're pretty much trying 
to lay down the law as to how other people should be tagging their files. 
That's not necessarily a bad thing, but some ways to achieve that goal are 
better than others. 

Take the singletons, for example. Right now, your document is dictating that 
certain fields can only appear once. In some cases, it's pretty obvious that 
it wouldn't be sensible to have more than one, in which case spelling it out 
amounts to the same as errecting promanent 'No Spitting' signs in a 
department store. In other cases, it's not so clear why the tag has to be a 
singleton. I'm inclined to split the titles of remixed songs across two title 
fields, and add the remix artist as another artist fieldat the moment. Maybe 
I could benifit from placing the remix info into version, but in the 
meantime, it's clearly better to concatenate all the title fields together.

> It would be nice to suggest how rippers, encoders, and players could be
> standard compliant while still making users of legacy oggs happy; if you
> have such ideas I'll be happy to include them in the proposal as
> examples of how things might work.  I've avoided making such suggestions
> myself because every peice of software does things slightly differently.
> No matter how generic a suggestion I make, there will be some software
> that it doesn't make sense for.  Hence the "Compliance" section of the
> proposal.

'Singleton tags, which can only appear once.  If one of these
tags appears more than once, its last appearance is used.'

What is this if it's not implementation advice? I'm advocating you include 
more of this, but couch it in less commanding terms. Consider that much of 
the standards that the internet is built on are called  'recommendations' and 
'requests for comment'.

I'd advise tag editor implementors about artist/title fields as follows:

 The artist field is used to hold the names of the performers (including 
 remix artists) of the track. 'Artist' works well for a lot of music, and is 
 the simplest target for migrating between other common tag formats,
 but there are many cases where it is inadequate. 

 For example, in order to express that a song is being covered by the 
 performers, use 'composer' to indicate the people who wrote the music, 
 and 'lyricist' to indicate the lyrics writers. 
 
 In the case of classical music, fields like 'composer', 'conductor',
 'performer'  and 'ensemble' have there usual meaning in that domain. See
  the individual field descriptions for more information.
  
 As most users will only be familiar with fields from simplistic tag formats
 such as id3v1, and the commonly used fields of CDDB, it's a good idea to
 advertise the richer fields offered by vorbiscomment via help text, balloon
 help, mouse overs and so forth. Some editors may choose to further 
 discourage the use of 'artist' by automatically converting the field to 
 'performer'.

That's an example. I'd expect there would a similar section for 'title' (ie, 
use opus, part, type and so on for classical stuff), fuller descriptions for 
each field (ie opus/part/type for dummies, including a broader range of 
typical values) and a general discussion of why more specific tags are a good
thing, and how to avoid ambiguities between similar fields becoming 
problematic at the implementation level.

John

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