heyas- I believe there is a need for a standard vorbis comment field to encode "Total Number of Tracks (on a CD)". Why we need this -------------------- - Existing Vorbis programs already implement this, inconsistently, and hence don't interoperate. These seems the key reason to me. - MP3s include this - Some software (e.g., iTunes) uses this information, e.g., to display "Track 4 of 13" or whatever. - It's easy to support, and easy to automate in ripping programs. - It's a natural addition to the existing tags. My problem -------------------------- This summer I ripped/encoded some CDs on an iMac with OS X, and had some difficulties trying to get Ogg Vorbis files. <lament>why won't Apple support Vorbis?</lament> Two programs I used were "Ogg Drop", a ripper/encoder and "Vorbis Rage", a tagger. Ogg Drop http://www.nouturn.com/oggdrop/index.html Vorbis Rage http://www.chaoticsoftware.com/ProductPages/VorbisRage.html Unfortunately, these used different fields for "Total # of Tracks", so I became rather confused -- and regardless, they didn't talk to each other. Ogg Drop X used TRACKTOTAL while Vorbis Rage used TOTALTRACKS Either is fine and natural, but we need a standard. For comparison: ID3v2 uses the TRCK field, where it stores for instance 4/13 (track 4 of total 13) iTunes.xml (the iTunes database) uses the "Track Count" field (for "total number of tracks") RFC ----------------------------------- I propose: TRACKTOTAL for "Total Number of Tracks on this Disc" ...and also, by analogy DISCTOTAL for "Total Number of Discs in the Collection" (to be pro-active ;-) The other obvious choice would be TOTALTRACKS and TOTALDISCS; this has the advantage of being more grammatical, but is not as immediately recognizeable (in connection with TRACKNUMBER) as TRACKNUMBER/TRACKTOTAL (vs. TRACKNUMBER/TOTALTRACKS) Reference ------------------------------ The listed contact info for Ogg Drop and Vorbis Rage is, respectively: info@nouturn.com, support@chaoticsoftware.com and I've emailed these with a description of the problem and an invitation to join us in discussion; I've not CCed this email to them as these seem to be general purpose contact addresses. This discussion is of course in the context of: http://xiph.org/ogg/vorbis/doc/v-comment.html the official comment recommendations and http://reactor-core.org/ogg-tag-recommendations.html the unofficial extended recommendations A quick search of the vorbis and vorbis-dev archives don't turn up any discussion of this, hence this email. So does this: ---------------------------- TRACKTOTAL the total number of tracks on the CD DISCTOTAL if part of a multi-disc album, put the total number of discs here ---------------------------- ...seem like a reasonable addition to the recommended tags? best, -nils --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
nils wrote:> I believe there is a need for a standard vorbis comment > field to encode "Total Number of Tracks (on a CD)".Why not just say TRACKNUMBER=4 of 8 or TRACKNUMBER=4th of 8 total or TRACKNUMBER=The fourth part of eight. or even TRACKNUMBER=Almost halfway. Programs should just display your comment fields, and never parse them. You'll be so much happier. <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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Sun, 5 Oct 2003, nils wrote:> heyas- > > I believe there is a need for a standard vorbis comment > field to encode "Total Number of Tracks (on a CD)". > > Why we need this -------------------- > - Existing Vorbis programs already implement this, > inconsistently, and hence don't interoperate. > These seems the key reason to me. > > - MP3s include thisMP3s don't; ID3v2 does. Not everyone uses ID3v2.> - Some software (e.g., iTunes) uses this information, > e.g., to display "Track 4 of 13" or whatever.All the current iTunes plugins for Vorbis won't be able to use a standardized track number field; it's off-limits to plugin developers.> - It's easy to support, and easy to automate in ripping > programs.Undisputed.> - It's a natural addition to the existing tags.Not really; one could just as easily use "TRACKNUMBER=4 of 13", which would arguably be more natural. Whether this or the ID3v2-style "TRACKNUMBER=4/13" is a better proposal than yours is open to a debate that I'd rather not participate in. I'm sure Segher will extol the virtues of plausibly deliberately machine-unparseable comments :)> Two programs I used were "Ogg Drop", a ripper/encoder > and "Vorbis Rage", a tagger.(snip)> Unfortunately, these used different fields for "Total # of > Tracks", so I became rather confused -- and regardless, they > didn't talk to each other.<p><p>After looking at the screenshot for Vorbis Rage, I can see why this is a problem for tools that don't allow generalized comment editing.> Ogg Drop X used TRACKTOTAL > while Vorbis Rage used TOTALTRACKS > > Either is fine and natural, but we need a standard.We? I personally don't care if we do or not except that it'll bloat the vorbis comment standard a bit for something that I've never needed to use. IMNSHO, it'd be best to have the nouturn.com and chaotic software guys work this out on their own (possibly with your prodding to reach a consensus). <p>> I propose:> TRACKTOTAL for "Total Number of Tracks on this Disc" > ...and also, by analogy > DISCTOTAL for "Total Number of Discs in the Collection" > (to be pro-active ;-)I'd hold off on DISCTOTAL (or an equivalent) until someone asks for it.> A quick search of the vorbis and vorbis-dev archives don't > turn up any discussion of this, hence this email.IMO, this is a clue that very few people (need to) care about a common format for storing the total number of tracks in a CD. Possible reasons why: (1) Few people have tools that will stuff the total number of tracks into vorbis-style comments. (2) Few people care enough to add in the total number of tracks to each individual file in their collection. In my case, my ripping toolset (rip to wav, os.system('flac -8 --replay-gain --delete-input-file *.wav'), masstag with foobar2000) doesn't automate the creation of a TRACKTOTAL field; it must be manually entered, much like the COMPOSER field.* I simply don't care enough to add that sort of stuff by myself. <p>* COMPOSER was kicked around by Jon Walther and co. and it was eventually decided (at the request of the "no new tags" crowd) that the Official Way to store the composer of a track is through "PERFORMER=Aaron Copland (composer)" or something like that. Considering I don't share my collection with anyone, I figure that pleasing myself with machine-selectable tags is more important than a slavish devotion to a set of tag recommendations.> So does this: > ---------------------------- > TRACKTOTAL > the total number of tracks on the CD > DISCTOTAL > if part of a multi-disc album, put the total number of discs here > ---------------------------- > ...seem like a reasonable addition to the recommended tags? > > best, > -nilsIn case I've obscured my points with scads of incessant rambling: TRACKTOTAL seems reasonable since there are programs out there that don't allow freeform editing of tags and do want a slot to store that information in. DISCTOTAL isn't a reasonable addition since nobody's asked for it. If you want to use DISCTOTAL for your own collection, that's perfectly fine; however, if you have no interoperability problems stemming from different uninteroperable tools, I'd recommend against specifying things simply because one can. Bear in mind, however, that reasonableness isn't a guarantee of standardization; I consider COMPOSER reasonable, but those who disagreed eventually won out. --Nathan (hoping he doesn't start Yet Another Tagging Flamewar) --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
('binary' encoding is not supported, stored as-is)
Segher Boessenkool wrote:
> > Same thing for the track number and track count tags. If you have
> > limited screen real estate (and who doesn't) then you may choose
to
> > display only the track number, not the track count. That doesn't
mean
> > that you don't want to store the track count, just that it's a
different
> > piece of data.
>
> It's metadata about an album, not quick scribblings about one track.
>
> It doesn't belong in the tags.
I agree: never thought about this, but: I don't care how many tracks an
album has when playing, all that (eventually) matters is the current tracks
number...I'm currently putting the tracktotal into the tags, but I will stop
this as soon as I found a fine (free) metadata app for linux. Someone nows one?
-- Daniel
<p>On the subject of C program indentation:
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
_______________________________________________________________________________
Email: npfdd@gmx.ch -- Homepage: http://npfdd.webhop.org/
ICQ: 75048547 -- AIM: npfdd -- MSN: npfdd@hotmail.com -- Yahoo!: npfdd
_______________________________________________________________________________
<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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
hi again-
First, note that the Vorbis Rage developers were very responsive
and decided to move to TRACKTOTAL; thus my original concern has
been addressed.
---------------------------------------------------------
Second, regarding the value of TRACKTOTAL, and the tagging
discussion (/flamewar/religious battle):
Thank you to everyone who responded, particularly Haxe's thoughtful
comments.
Also, thank you to Moz for clarifying (some perspective on) what has
been meant by "metadata".
To get some terminology straight, I understand "metadata" to mean
"data about data, in whatever form". 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).
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.
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
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?)
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.
However, as Tom Felker says, Vorbis tags fill the metadata now.
It is in -this- context that I suggested TRACKTOTAL:
we -already- store metadata in Vorbis tags,
it is very easy to add further simple metadata as tags,
it causes no harm,
and solves some problems -now- at -virtually no cost-.
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.
---------------------------------------------------------
To address Segher's concerns (which seem to be shared by others):
"the perfect is the enemy of the good"
Segher, you are over-reacting.
We agree that it is suboptimal to use Vorbis tags to store metadata,
though it is a "useful intermediary step".
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.
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-. 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?).
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!
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")
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), and adding
support for further tags does -not- make this significantly worse,
unless you think every unnecessary line is an indelible blot.
---------------------------------------------------------
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.
In the meantime, using Vorbis tags to store short, textual metadata:
- 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.
best,
-nils
--- >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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.