[vorbis] Re: TAG-mess

[Cameron Simpson]

On Fri, Dec 07, 2001 at 11:52:33PM -0800, Craig Dickson <crdic at yahoo.com> wrote:
| > >>ARTIST
| > >>        role fulfilled by COMPOSER, LYRICIST, PERFORMER, ENSEMBLE,
| > >>        CONDUCTOR, AUTHOR, PRODUCER, and ARRANGER tags.
| Which he calls "simple".

Well, it is simple, once it's done. THe trouble is it's complex at the
creation end.

| > Hears an idea. How about the 99% of the population that understands the
| > simple concept of "Artist" use the "optional" tag "ARTIST". Meanwhile,
| > the 1% of the population that want's a multi-dimension normalized database
| > of all rythmic sounds can specify the "optional" tags COMPOSER, ENSEMBLE, 
| > etc.
| 
| Your suggestion has come up before and Jonathan has already rejected it
| quite firmly.

This does puzzle me a bit; what I suspect he hates about it is twofold:

        - ARTIST is rather vague - for a given track it may
          mean any of several roles and it's not giving any clues as to which

        - if ARTIST is available (or, worse, the default), then nobody will
          use the better descriptors; this is a subtly different situation
          from the one where all the other descriptors are there and Joe
          User _chooses_ to be deliberately lazy (which may happen a lot
          anyway)

| This fact, all by itself, allows me, with a fair degree of
| certainty, to predict that Jonathan will shortly complain that [...]

This isn't contributing to keeping things civil.

| > Which part of "optional" DO YOU understand? Tags are always an
| > optional thing. The music is the primary part of the file. Why can't I
| > "optionly" use an Artist tag? Is that OK if I take the option of using
| > none of your tags?
| 
| This is the part that's still puzzling me. Tags are optional, and in the
| real world, they aren't used all that much, or all that well. I end up
| creating or fixing the tags in most of the MP3s I download. So why does
| Jonathan see value in "standardizing" something that nobody is ever
| going to enforce in software, and that most users will never know about
| or bother to comply with? As far as I can tell, he just has an emotional
| attachment to his little structures, and a rather childish desire to
| make everybody play by his rules.

Now this I think really is a gross misstatement of his position.

1: If we don't have these extra tags at all (or tags resembling them)
   then the current extremely vague tagging _will_ continue.

2: If we're going to encourage richer tag names then either

        - there's no spec and everyone goes their own way,
          in which case the tag names do _not_ have semantic
          meaning in any broad sense and cannot be meaningfully
          parsed even by people, let alone programs (like slang)

        - there's a spec and people thus have a common vocabulary
          for describing this stuff - that is the core purpose of
          exercises like this: that the tags convey consistent meaning
          and people have much less need to invent random tag names for
          their special purposes (which is why he has so many - to attempt
          to accomodate a fairly large set of needs initially)

   I certainly prefer the latter situation.

2: Users _should_ know about the available tags in the spec.
   True, many users are lazy and fill in nothing (something ripping
   tools should discourage but hopefully not actually prevent).
   However, the tools should also make it fairly easy to use the
   available standard tags.

   Currently people can (to take the FreeDB example) specify an "artist"
   and an album title, and track titles.  Poor. Other schemes have
   similar shortcomings to a greater or lesser degree.

   So consider the hypothetical current input interface:

        Album:
        Artist: ___________
        ...
   
   This could so easily be like this:

        Album:
        Artist:	___________ [Type: choice of PERF, ENSEMB, etc]

   i.e. an input field and a type tag. THus you externally have
   the hated "artist" keyword which has good intuitive meaning for
   many users and internally the type chosen in the adjacent selector
   is used to store the input string against the appropriate tag.

   The complexity for the user remains as before, the interface is a bit
   more expressive for the user who cares, and the internal data is
   definitely more expressive to the benefit of others. The common
   case (yes, "pop" is it - almost by definition actually) is still
   easy and the less common case is readily available.

   In short, the tag vocabulary is the tool author's problem, not the
   user's, and it should be handy to the user.

3: He doesn't want to force everyone into his scheme, or at least,
   not into jumping through every hoop need to utilise everything
   the scheme can do. But he does want a scheme that readily and
   human-clearly will identify the source disc for comparison,
   and to have that scheme used.

So surely we shouldn't be arguing about breaking up ARTIST into
various flavours, but arguing about how to make it easy for the
users to use a suitable one of these as they use ARTIST now.
Perhaps without clueing the user in that they're not entering
_just_ an artist.
   
| > Get a grip. If you want a normalized, comprehensive database of all
| > classical music don't expect everyone else to build it for you.

Of course, FreeDB has exactly this attitude and seems to be doing very well.

| > Embedded
| > metadata in audio streams is 99% just to display a simple artist and song
| > name to the user. Stop trying to make it into the card catalog of the
| > National Music Appreciation Society.
| 
| I've been trying to find a way to say this since the last thread on this
| topic, two months or so ago. You've put it very well. Jonathan seems to
| want this sort of distributed database where every piece of music comes
| with its own complete record [...]

He's explicitly said not. (But I do! No matter.) What he wants is:

        - sufficient info in the spec to identify things
        - a spec for things to be said this way

He doesn't want to force people to fill it all out - he wants it to be
available, and the tags in current use that are so vague as to _actively_
work against this be supplanted by one of a set of more adequate tags.

I still think this is a user interface problem, not a tag scheme problem.

Let the players be a tad smarter: several tags are artists of one kind or
another: for many things there will be only one and it can be displayed
in a conventional artist display field.

| and then you have a program that can index
| and search your entire collection (or, via a P2P file-sharing system,
| everybody's collections) without the need to put it all in a
| conventional database table. It's an interesting idea, but it's crazy to
| think that very many people are going to give a damn about it or
| participate in it, and therefore it's ridiculous to try to establish it
| as a "standard" that all Ogg Vorbis users should adhere to.

You're confusing having the expressiveness available and coercing
everyone to be megafinicky at input time.

| Well, so much for the "consensus". I think the discussion over the last
| day or two has shown that any such thing exists only in Jonathan's mind.

Come back at it as a user interface thing: take his scheme for its
expressiveness and make the user side of things easy for the common
case. A win win situation. The current situation is stagnation.

--
Cameron Simpson, DoD#743        cs at zip.com.au    http://www.zip.com.au/~cs/

Any profit should go to Arnie's `get the daemon carved on Mount Rushmore' fund.
	- Marty Albini, DOD0550, martya at sdd.hp.com

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