[vorbis] Tag changes

[Ben Pearre]

On Fri, Apr 05, 2002 at 02:37:54PM -0800, Jonathan Walther wrote:
> On Fri, Apr 05, 2002 at 10:43:24AM -0500, Ben Pearre wrote:
> >Trying to label Don Giovanni...  something like 72 parts.  May I
> >re-open the discussion of part names vs. numbers?  (a suggestion
> >follows the quote)
> 
> I have a question.  What software mechanism do you have in mind to take
> PARTNUMBERS and sort them for you?

Any software at all.  Grip names files according to the info fields
returned by FreeDB (currently woefully inadequate...).  In my case, I
like to rename the pieces so that alphabetical order of the filenames
coincides with correct play order, but also so that I can easily see
what I'm listening to.  Not all people will like the format I choose,
however, so I'm trying to ensure that enough information exists so
that you know what you're listening to.  Or do you advocate making all
people name their music the same?

Please sort these into the right order:

Moderato
Adagio
Allegro assai
Adagio

or

Lasciala, indegno
Overture
Alfin siam liberati
Ho, capito, signor, si
Mi par choggi il demonio

or

4: Tuba mirum
1: Requiem
3: Dies irae
2: Kyrie

or

vi: Denn wir haben hie keine bleibende Statt
iv: Wie lieblich sind deine Wohnungen
iii: Herr, lehre doch mich
v: Ihr habt nun Traurigkeit

(getting a computer to sort Roman numerals is harder than getting it
to sort decimal numbers.  The standard should specify decimal!)

> Could the same mechanism not be used for cases where you put the
> part number into the PARTNAME tag?

Yes, as long as it _is_ machine-parseable.  That is, the format should
be stated explicitly, like, as you suggest later, "${NUMBER}. ${NAME}"
etc.  But the extra standard tag adds little to the complexity or size
of the file, and makes our hypothetical software much simpler (no need
to add a parser).  Remember, you're allowed to not use the tags.

> I always had the impression that the mandate of these tags was to be
> human readable, and not meant for machines to use.

http://reactor-core.org/ogg-tag-standard.html claims that the tags
should be human-readable, but don't mention machine-readability.  I
propose that since these files can only be played by machines, and
since the tags are already awfully close to being machine-readable,
the information contained in them should be machine-readable.

> I believe thats what Monty has stated on the list.

I don't think I was on the list at the time, but the standard is
already so close to being machine-useful...

> In the case of a single track that contains several parts, wouldn't a
> PARTNUMBER tag add complexity to supporting software?

No, it simplifies it.  Without PARTNUMBER the software will have to
try to guess what number the part is (as in my examples above).

> The PARTNAME tag already adds some complexity by the fact it can
> occur more than once for a given track.

Yes, I hadn't thought of that, and it's a good case for coupling the
information (as in "${NUMBER}. ${NAME}").  As long as it's in the
standard!  Make explicit that when order matters, NUMBER should be in
decimal, followed by a period, colon, or some character of your
choosing.

> There are quite a few classical music works where there is only the
> name, and no part number.  And there are quite a few classical CD's that
> skip "parts" of a work, without any indication on the cover that is what
> they have done.  Then there are works by Philip Glass which may have
> different part numbers for the same part each time you play it.

The question is: does it matter in what order the tracks are played?
If so, you need a way for the computer to put them in that order.  If
not, then you don't.  If you sometimes do, then you can use the
ordering standard when it's needed.

Track numbers are inadequate for two reasons:

1) Many CDs have, say, three piano sonatas of 3 parts each.  It's
   simply wrong to call Sonata 3's second part "part 8".

2) For music that's not distributed via CD (and there will be more of
   this eventually; I'm working on it!) TRACK becomes meaningless.
   In that case it could, of course, be used as PARTNUMBER, as long as
   that's made explicit in the standard.  But why skimp on tags when
   it doesn't really save you anything?

Yeah, obviously I think reason 1 is stronger...

> I personally don't see a need to separate the partnumber tag from the
> partname tag, but if more people speak up in support of it, 

I speak for a few of my friends who aren't on this mailing list.  That
might be good for about 2 extra votes...  ;)

> saying why it is better to have it than to not have it, I'm ok with
> it.  I think the nature of "partnumber tag is better" should address
> the issue of what software will be doing the sorting in what
> context,

Any software.  Querying the database to determine what to name your
files when you rip them, allowing you to rename the files...

I had the interesting experience of trying to give some files to a Mac
user friend of mine.  I sent him 8, but he only got 1.  Turns out that
the 8 files' names only differed after the 38th character or so, and
MacOS doesn't allow filenames longer than 30 characters.  So he'd HAVE
to rename them!  This would also be a problem for VMS, VM/CMS, Xenix,
DOS, etc, but perhaps we don't care too much about such old systems?
Just a thought :)

> [...] and how this is easier for the software than sorting the
> partname tag instead.

See the examples!  As long as the standard enforces machine-
sortability, I don't think it matters too much.

> Is there a reason to switch from TITLE to TRACKTITLE?

I thought TITLE was the name of a piece, for multipart pieces.
"TITLE=Pictures at an Exhibition" or some such...?  I had more in mind
_adding_ TRACKTITLE, but David Gasaway convinced me that it should be
PARTTITLE instead...


-- 
bwpearre at alumni.princeton.edu                http://hebb.mit.edu/~ben


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