*yawn*

I couldn't find anything over at xiph, but maybe that's just me.

So, given more than one track in a flac, am I supposed to just write:
TITLE='one'
TITLE='two'

and expect some add-on to xmms sometime in the future to handle this by displaying a list of tracks?

It appears to me that something is missing for those who like to have _one_ file per album... hopefully it isn't my brain.

I'm in the same boat. Near as I can tell, there's no standard for it. The FLAC format cuesheet doesn't have per-track artist and title info, so that's out. Their explanation of why they don't makes sense, I guess, but that's no help.

A couple of things that might work, but aren't great:

vorbiscomments of the form:
TRACK_TITLE_1=trackname
TRACK_ARTIST_1=artist
this is a quick and dirty thing, but would probably suffice for most of the people who want to do this. It seems kind of inelegant, because the only thing linking the per-track metadata to the correct track is the number concatenated onto the end of the comment name. Not very robust.

An APPLICATION block containing an XML album description:
<album artist='Frank Zappa' title='Laether'>
<disc number='1'>
<track number='1' title='Re-gyptian Strut' />
<track number='2' title='Naval Aviation In Art' />
(more tracks)
</disc>
<disc number='2'>
(tracks)
</disc>
<disc number='3'>
(tracks)
</disc>
</album>
Advantages include that it can be very hierarchical, well-defined, and flexible. XML parsing libraries are available on nearly every platform now. It is not optimally space-efficient (although we're talking about a couple kb of redundant data, tops, in a 250Mb flac album file, so that's not much of an issue). It is human-readable and -editable, but not really human-createable (you could do it by hand, but a tool to do it helps much). Tools for cd ripping, FLAC creation, and FLAC playback would all have to support this APPLICATION data block for this to catch on. The XML format itself would have to be very well-defined; much better than I've done here. I'm sure there's already some work being done on XML album descriptions, and it would be best not to reinvent the wheel.

Short answer: it's not you, lots of us would like to do one-file-per-album, and the FLAC format, while closer than any other format, isn't there yet with respect to heirarchical metadata.

Even nicer than just some sort of XML would be to use RDF, as this is an accepted standard for specifying all kinds of metadata, so there is some support for it (although I've never seen it in combination with multimedia) and it would open up very interesting possibilities (if the right tools were available of course).
Personally I had hoped that Matroska would use something like this (they already use XML-like structures, so adding some RDF shouldn't be too hard), instead they went for an almost completely pre-defined set of attributes, which is great for most things, but will never take care of every possible need (a completely flexible system in combination with an accepted standard set of tags is much more useful in my opinion).

Right, well, okay.

So what is needed is a de-facto standard that handles both the 'by-hand' tagging (say like ALBUMARTIST=foo, TRACK01ARTIST=bar), as well as a more robust XML / whatever format.

And the first developers to implement this as a de-facto standard (by creating foobar2k and xmms functional add-ons to display and skip to the individual tracks in a flac plus of course tools to add the tags) will 0Wn j00.

Fair enough.

I just find it... puzzling that xiph doesn't bother with that kind of standardisation.

You can find a lot of discussion about this by searching through the Vorbis list archives. The reason it's not there is because no significantly large group of people can agree on how it should work. Such is the fate of metadata.

Josh

Whilst I feel I should bow down and chant "I am not worthy!" to Mr. Coalson responding to this, I feel slightly annoyed by his response.

Mr. Coalson may not feel that his time is best spent on hammering out a standard, or even that it is his responsibility, but still, the sentence(s):


has a particularly foul taste to it.

Leaving my pet peeves / f***ing psychotic hatreds aside, I don't really see why the flac metadata format can't just adopt the "simple" + optional extended approach which mp3 (idv2, idv3) and freedb (trackXX,extendedXX) uses.

My suggestion would then be, for the _simple_ tagging, to smack in the data from a simple CUE-file generated by EAC.

Namely:
ALBUMARTIST=George 'Retarded' Bush
ALBUMTITLE=Boldly We Go F***ing Up The World Again
TRACK_01_ARTIST=Rumsfeld Dude
TRACK_01_TITLE=Let's Talk Through Our A**
TRACK_01_INDEX_00=0 (samples)
TRACK_01_INDEX_01=32

and so on...

I don't see the problem here.

It is perhaps inconvenient to you, as it is to me.

On the other hand, flac is in a sense very well organized now. No metadata from wav or cue files is allowed into the stream, and any metadata is appropriately stored in its own space. It is a 'free space' that allows you to put in any kind of comment you like. Standardizing the metadata would remove that freedom.

Also, note that tags are totally redundant having a system like Freedb. One could theoretically mount a flac file as a virtual CD and recognize the disc by it's cuesheet.

For now, I keep the cuesheets as separate files, until something like a Freedb connection for FB2k or flac support in Daemon tools comes along.

Really? How would making proper tags work remove my freedom to add whatever else I wanted?

If there was a plugin that parsed the vc block, why couldn't that just ignore my




Have you ever actually, like, _looked_ at the contents in freedb?
Well I have. When I scan the entire db, I get (I think) >35% of _crap_.
That is, shit. Turds. Faeces. Excrement.

Am I getting through? No? Well I am happy to post the perl-script I am using, and you can try it for yourself. I am not even considering mis-spellings yet.



Statistically, each male between the ages of 18 and 35, will by a 95% confidence intervall have 2.3 sexpartners in a year.
How do you sleep with a girl... statistically?

Leaving that behind, the metadata belongs with the file. End of story.

OK, I see your point. Somehow I have an aesthetical objection to it, that I can't really express in English. but I feel it would be an ugly solution. Forget I ever said it


No need to use dirty words . I suppose you have been correcting these mistakes when you were ripping the cd (I have). So, (at least) your local version of it is right. Personally, I find this a very elegant solution. And mounting an image would be somewhat of a nostalgic action, like putting a disc in the drawer. I like it...


Lol.

DrDoogie, my point still stands. Just because it makes sense to you doesn't mean it does to enough others to warrant standardizing.

I wasn't being facetious when I said to check the Vorbis archives. Over the course of years I have seen monster thread after monster thread go by where people argue about this. Some people have your opinion, some don't. Some people exactly agree with you but will fight to the death on naming it ALBUMPERFORMER instead of ALBUMARTIST. Seriously do some research and you will see why I don't want to try and come up with a simplistic standard. And not even FLAC's problem in particular; this will come up if you have a whole album encoded in Vorbis or APE too.

In the meantime, nothing prevents you from tagging your files however you want. But you want to see them in your player you say? Well, now you have to convince players to support an album tagging system and they can't agree either, because user interfaces are so different.

Josh

Josh, I see your point, even though I haven't checked the archives (couldn't find 'em). It's clear, though, that there is significant demand for some kind of one-file-per-album-oriented metadata.

What would you think of someone (possibly me) working up an application data block solution for this? Is this a reasonable use for the FLAC application data system?

If you think this is acceptable, I'll see about putting together a format, a wrapper to create the data block given a FLAC file and an EAC cuesheet, and a foobar2000 plugin to parse it.

Thanks,
Jeff Paulsen

Well said, and politely put too.

@ottar:
Want a hand, drop me a note.

@coalson:
If there cannot be a standard, then people will just start making one. Which has been snidely put before, by stating: "The good thing about standards is that there are so many of them."
But you, Josh, are in the unique position of actually being able to _decide_ what a "barebones bedrock simple" tagging format should look like.
May we most humbly petition your lordship for a decision.

We received a lot of criticism for our decision to define a standard set of tags for matroska, but the discussion here is confirming us it was the right decision.

Sorry for jumping in here, unasked. But matroska could be a nice alternative to store complete CDs using FLAC, once we have solved our problems as described in another thread here.

Christian, thanks for the pointer; I'll look into Matroska.

DrDoogie: I tried to email you through HydrogenAudio, but it bounced. Please email me with your email address.

That's fine. But I would still want to see major consensus from users before adopting it into FLAC officially.


I did. I agreed with and copied the design of Vorbis comments. We just fundamentally disagree about where machine-parseable album tags should go.


Is this sarcasm? I don't see where this is coming from.


This is ideal. This stuff really belongs in a separate stream, muxed in a good container. It's a problem more general than FLAC that has needed to be solved for a long time.

Josh

Seems Matroska is more flexible than I first thought (never imagined chapters would be that versatile). But in the case of FLAC it might be an idea to look to RDF for that application block, the Adobe XMP metadata toolkit makes it very easy for example to create, manipulate and embed RDF in a more or less standard way, this would have the advantage of using an existing standard (both in - most of - the actual fields and the way of tagging). Information about XMP can be found here:
http://www.adobe.com/products/xmp/
Information about RDF in general:
http://www.w3.org/RDF/
Information about Dublin Core (involved in metadata standards):
http://www.dublincore.org/