Give me your tired, your hungry, your Various Artists

Sat Mar 20 14:58:13 UTC 2010

'Twas brillig, and Jeff Mitchell at 20/03/10 04:05 did gyre and gimble:
> On 3/19/2010 10:29 PM, Colin Guthrie wrote:
>> Yo,
>>
>> 'Twas brillig, and Jeff Mitchell at 20/03/10 01:46 did gyre and gimble:
>>> Various Artists is one of those things that many people use, and few
>>> people like. 
>>
>> I like Various Artists... i just rarely like media players handling of
>> them :D
>>
>> To be fair, Amarok's is pretty good, but I'm pretty anal, so it's not
>> *perfect* (as you say).
> 
> <snip>
> 
> (I've snipped the long details out  :-)
> 
> Part of what you are describing is how it's stored in the DB and part is
> the display in the collection browser. They're separate though related
> topics. I'm interested right now in the former, because once the data is
> proper in the DB, then you can theoretically display it however you want.

Totally agree :)

> So, what you've done and gone is put your information in the various
> album artist tags. I believe this is already used by Amarok (I'll check).

The collection scanner does read them in but as I mentioned this is not
actual read into the database.

The patch I linked fixes that and with it applied the album artist tags
do get into the database :)

> What I'm talking about here is identifying specific albums. So that no
> matter what the artist says, track name is, or even if you listed a
> different album artist, you could still have it identify as the same album.

Yes this would be good. In the series of albums I linked to they all
ahve the same album name but are certainly different albums. I
differentiate them via different album artist fields, but a unique ID
would serve just as well.

> I'll have to think how this may, or may not, help out what you want. I'd
> be interested if you'd think about how it may affect your use case (or
> not) and see what you end up thinking.

Well due to the way I've tagged my tracks, I don't think I'd *need* a
specific identifier for albums. In my case, there will be two entries in
the albums table, both with the same name, but with different artist
values. i.e. in my collection "SELECT DISTINCT name FROM albums" would
return less results than "SELECT DISTINCT name,artist FROM albums". FWIW
I've not tested my patch with the above in mind, so chances are, it will
not work as I intend. I guess the hash for albums would need to be keyed
on album name + album artist for this to work. Shouldn't be too hard to
make it work that way tho' (and I'm guessing you'd need to do something
similar for an album uuid approach anyway).

> One of the problems (as you've
> seen with your experiences with XBMC and Amarok) is that different
> players display different ways because they have different heuristics.
> XBMC displays perfectly for how you've done your metadata; Amarok
> displays pretty well (but not perfectly) for a wide range of ways of
> grouping the files and tagging the tracks.

Indeed. I've been thinking about this issue on and off for five years
but never done much more than post the occasional rant e.g. the now very
outdated http://colin.guthr.ie/2005/06/metalibrarian/ which more or less
describes a nice VFS/heirarchy view on top of something like Nepomuk!

> Another possibility might be to allow you to write, at the same time as
> writing an aft album identifier, a flag indicating that an album is a
> compilation/various artists.

I very much support some kind of COMPILATION=1 vorbis comment support.
iTunes does this (but not sure what id3 tag they use - not looked).
Guessing is fine, but if you've gone to the trouble of specifically
marking it up it would be nice to support it :)

> This way you could set the property on the
> file (or maybe on the shared album ID) and not have to worry about
> losing this information when you do a rescan or if you lose your Amarok
> DB. Plus, you could do this in a batch fashion, which is nice.
> 
> Anyways, I look forward to your (and others') thoughts.

Yeah I think this is the right approach.

Incidentally, (and this is a going beyond what you're interested in just
now so apologies for the distraction :p) one of the things I think would
be really nice is to support a nice hierarchy configuration system.

e.g. I'd love to be able to wirte some kind of pseudo code to define
several "hierarchies" and present them thusly:

1. Define a Heirachy and give it a name. This heirarchy could contain a
filter for the tracks, e.g. type=mp3 or composer<>'' etc.

2. You define how many levels your hierarchy has.

3. For each level in your hierarchy, define what text to display via a
simple script language (in my exmaples below, I used SQL syntax):

e.g. I define a "Classical" hierarchy with the filter "genre=classical"
and tell it to use 4 levels.

Level 1: IF(composer<>'', composer, 'Unknown Composer')
Level 2: IF(symphony<>'', symphony, 'Unknown Symphony')
Level 3: IF(orchestra<>'', orchestra, 'Unknown Orchestra')
Level 4: title

And I could also define my "Music" hierarchy (not that Classical, isn't
Music, but for want of a better phrase) with a filter
"genre<>classical", and has 4 levels:

Level 1: IF(albumartist<>'', albumartist, IF(compilation, 'Various
Artists', IF(artist<>'', artist, 'Unknown Artist')))
Level 2: IF(album<>'', album, 'Unknown Album')
Level 3: IF(albumartist<>'', CONCAT(artist, ' - ', title), title)

This for me would be perfect! The hierarchies can be pre-cached after
scan results in some changes for very fast access. Building the cache
would not be that hard.

For me, this is the absolutely ultimate in display flexibility - things
like artwork (both artist and album) could be incorporated into this
relatively easily too.

I'm not 100% sure that this is something that should be done outside of
Amarok in e.g. Akonadi or similar, but regardless of where it lives, I
would really love this flexibility :)

Anyway, slight divergence from the "get the data in" remit, but figured
I'd mention it here for now.

Obviously providing some pre-defined hierarchies that appeal to most
users is key, but allowing users to make their own would be a good end goal.

I would be interested to hear peoples comments on this approach. Perhaps
it's too complicated or unnecessary?

Take care

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]