[vorbis] Re: Total Tracks Tag?

[Segher Boessenkool]

nils wrote:
> To get some terminology straight, I understand "metadata" to mean
> "data about data, in whatever form".

Yes.  It's also used loosely to mean "the proper metadata thing
(that we don't have yet)".

> Indeed, even a filename (and
> extension) is a form of metadata. Similarly, Macs (before OS X) stored
> Application and Creator metadata, I believe in a "resource fork" (a
> separate stream inside a file).

Actually, creator and type data is stored in the folder info, not
in the resource fork.  The resource fork can contain a lot of stuff,
but not that.

> As I understand it, some people (particularly Segher) are advocating
> storing metadata in a separate stream within an Ogg file, rather than
> as tacked on tags to a Vorbis stream.

It's not just me, and it's not my original idea either.

> Currently such a system/standard doesn't exist, and metadata is stored
> in one of two forms:
> - Vorbis tags
> - an application-specific database, like iTunes

3) in application-agnostic (global) databases, like CDDB and
MusicBrainz and whatnot.

> for interchange/distribution, the only current solution is vorbis tags
>   (one -could- distribute an XML document containing the metadata;
>    I don't know if iTunes does this -- it has an "export database"
>    option, doesn't it?)

No idea.  Never had the need for that.

Note that the 3) above also fullfills this need.  The not-yet-existing
Ogg metadata stream thing would work perfectly for this, of course.

> I agree that Vorbis tagging has limitations; in particular, it doesn't
> deal with Album-wide metadata (except by duplicating the information
> in each file/stream), nor does it deal with large data, like lyrics or
> album covers.

Most importantly: it only deals with human-readable content, and only
per stream.

> However, as Tom Felker says, Vorbis tags fill the metadata now.

Bzzzt.  Some applications use it to prime their metadata.  I know
that some applications try to use it _as_ the metadata, but that
is broken and it will only get worse over time.

> It is in -this- context that I suggested TRACKTOTAL:
> we -already- store metadata in Vorbis tags,

Yes.

> it is very easy to add further simple metadata as tags,

Yes.

> it causes no harm,

No.  If applications start trying to use Vorbis tags as machine-
readable data, they will have a *big* problem.  And so do we.

> and solves some problems -now- at -virtually no cost-.

At virtually no cost _now_.  Backward compatibility is
_very_ expensive _ever_.  And we _do_ want to be backward
compatible, don't we?  It's what users require from us.

> In particular, I understand that TRACKTOTAL, like ALBUM name and
> album covers (and CDDB DISCID etc.) should properly go in an
> albumwide metadata stream, which does not exist.
> 
> Vorbis tags are pretty good; maybe not "good enough", but certainly
> good enough for some purposes.

Certainly.  They are good for human-readable (human-read!) data.

> ---------------------------------------------------------

> To address Segher's concerns (which seem to be shared by others):
> 
>   "the perfect is the enemy of the good"

That's only one part of the story.  You can't condense it to just
this.

> Segher, you are over-reacting.

With respect to just this tag; sure, I can understand your feelings.
But please take the bigger picture into account.

> We agree that it is suboptimal to use Vorbis tags to store metadata,
> though it is a "useful intermediary step".

_Human-readable_ data.  Never ever try to parse it.

> However, you state that it would do "more harm than good" to add
> further metadata to tags, rather than developing a correct
> metadata stream standard.
> 
> I do not agree with this.

See previous comment.

> The bulk of code to deal with additional tags
> (economics terms: the marginal cost of supporting an additional tag)
> is almost entirely in code to deal with -that piece of metadata-,
> -regardless of source-.

And _every_ application will have to have that code _forever_.

> So most of the code to deal with the piece of
> metadata "Total Number of Tracks on CD" or "Album Title" or "Composer
> of this Track" is -independent- of whether we get it from a Vorbis tag
> or a metadata stream or a local database or a remote source
> (MusicBrainz? CDDB?).

No.  A well-defined metadata format will be straightforward, instead
of the fuzzy-logic guesswork that a tag reader has to do.

> The Vorbis tag specific code consists of the following line:
> 
> get_file_info_tag("foo.ogg",TRACK_TOTAL,"TRACKTOTAL");
> 
> ...assuming there's a half-way sane function for reading tags.
> 
> That's it! One line!

And then you have the text contents of the tag.  That's the
easy part.  If you only want to display it, that's fine.

But what if a player program tries to use it as numerical data,
or even just tries to use it as a sorting key?

> Even if we eventually move to a metadata stream to store metadata,
> all the Vorbis tag code can be stuck into a separate file/library
> (which, yes, would need to be maintained -- but if written even
>  slightly well, you'd only need to update the function
>  which I've dubbed "get_file_info_tag" that puts Vorbis tag info
>  into the program's internal data structures),
> and the only lines one needs to deal with legacy tags is:
> 
> if !(get_file_info_from_metadata_stream("foo.ogg"))
>   then get_file_info_from_vorbis_tags("foo.ogg")

You have a very simplified world view.  Sorry.

> Indeed, you could even write:
> 
> if !(get_file_info_from_metadata_stream("foo.ogg"))
>   then
>     get_file_info_from_vorbis_tags("foo.ogg")
>     write_file_info_as_metadata_stream("foo.ogg")
> 
> to update old Vorbis files.
> 
> Summary:
> Yes, supporting Vorbis tags will be a wart once we have a proper
> metadata stream standard -- but it's a wart we -already- will have to
> deal with (thanks to the standard TITLE, ALBUM, etc. tags),

No.  Those tags, as defined in the standard, are just tags, just
simple jots on a stream.  You'll never have to do anything else
with them than just display them to the user if he/she sho chooses.

You never use them for identifying artist of a stream or whatever.

> and adding
> support for further tags does -not- make this significantly worse,
> unless you think every unnecessary line is an indelible blot.

The big differences between the existing tags and what I'm fearing this
particular TRACKTOTAL tag will be used for, are 1) you want to parse
it as a number.  But it's not; and 2) it is not about the stream
_at all_, but about some other entity (the number of tracks on the
CD you ripped this track from, supposedly).

> ---------------------------------------------------------

> In summary:
> 
> A proper metadata standard will be nice when it comes.
> It's not here today, nor is it coming tomorrow, as far as I know:
> the Xiph developers are busy with Theora, Tarkin, hardware support
> for Vorbis, etc.

What about other developers?  Xiph is just a company, Ogg is a community.

> In the meantime, using Vorbis tags to store short, textual metadata:

_textual_.  Well said.

> - solves problems -now-
> - does not hurt
> - does not impose an undue backwards compatibility burden
>   (as I have demonstrated above)
> - and in fact allows development of program internals
>   to deal with this metadata -in whatever form it may come-
>   in future.

Programs should never deal with this data other than present
it to the user as the thing it is, i.e., international text.

<p>I hope I get my points through.

I'm not opposed to storing any kind of textual data in tags,
that's what they are for after all, but I'm sure this particular
one will be misused by programs, and open up the gates to
even worse things, and the compatibility hell that comes
with that.  No thanks.

<p>Thanks for taking the time to write such a long mail, I hope
this one isn't too long for most readers,

<p>Segher

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