Various Artists GSoC project

Wed Apr 1 21:09:15 UTC 2009

Warning: very long email, but with a lot of project suggestions.

Stuart Neill wrote:
> On Tuesday 31 Mar 2009 13:37:05 Jeff Mitchell wrote:
>> Personally, I put the information in the title, and use the Artist tag
>> for the artist advertised on the album.  This has the added benefit of
>> making it easy to find all tracks on an album and having that album
>> sorted and collated properly in the Collection Browser, without having
>> to have an artist view show a bunch of artists with one single track:
>>
>> Album: Crazy Techno vol 2
>> Artist: Ministry of Sound
>> Track Title: Blowing Your Mind [TechnoCode f. John Blaze]
>>
>> Doing it this way ensures that no matter where I take my files, I'll
>> always get all the information from the track, without having to worry
>> about non-conforming players.  It's both standards-compliant* _and_ easy
>> to use and organize.
>>
> This strikes me as being close to minimal tagging

What exactly is "minimal tagging"?

> and therefore restricting 
> the potential use of applications such as Amarok. Is Ministry of Sound an 
> Artist (I would have thought they were more akin to a publisher). If you have 
> an album by TechnoCode, the Albums widget UI will not show your "Crazy Techno" 
> album for that Artist.

Of course not.  The album is by Ministry of Sound.

> I have just looked at the list of albums  which I have marked as "show as 
> Various Artists". Typically these would be Genre based (e.g. Acoustic 04 or 
> Cafe de Paris), Tribute based (e.g. Poet: A Tribute to Townes Van Zandt or 
> Golden Age Of Electra Records) or movie soundtracks. Where is the "artist 
> advertised on the album" for these.
> 
> The method you advocate may work for you but it is in no sense a solution and 
> I would not think it is a method to be followed for most users.

I'm not advocating it.  I'm simply presenting it as an example of using
tags according to their defined roles and properties that allows the
information I care about to be delivered to me in a cross-player fashion
-- and since it fulfills this duty, it *is* a solution for me, despite
your claim.  Other people are free to use what works for them.

What you are wanting from Amarok is a scheme that is attuned to people
that remember tracks on a VA album by the artist, not by the album
artist.  Since I tend to associate tracks with the album they originated
from, doing an artist search for "Ministry of Sound" (it's the name on
the album, after all) is as natural to me as it is unnatural to you, and
I assume the opposite is true in regards to your feelings about it.

There's nothing wrong with you wanting a solution that works better for
your needs, and the way you listen to and find your music, but please
keep things in perspective; anything that works for any particular
person is just as valid a solution as anything else.

> [BTW I also use the track title to show "featured" or "with" Artists because I 
> can't think of a better place to put them. I also put the Album Year in the 
> Album Title for those albums with varying Track Years.]

Which is a good point -- this problem is not simply limited to Album Artist.

I've never met a tag format that everyone actually likes, but some other
tag formats (such as Xiph-based formats) have a relatively (compared to
ID3) minimal set of common fields, and simply rely on players writing in
their data into comment fields/frames.  Perhaps they have a point, as
avoiding the almost-everything-but-not-quite gaggle of ID3 frames helps
minimize misappropriation of frames; at the same time, this can lead to
even more fragmentation in the market over how to represent (anything)
in a cross-player way.

In case you haven't figured this out by now, tagging sucks.

With that said, it's time to get back to basics, since the end of the
student application period is closing in.  What does a student wanting
to do Various Artist support in Amarok need to do?

On the one tag-writing extreme we have writing the album artist into the
TPE2 tag, which is widely-used but not standards-compliant.  Doing this
is also likely to annoy/irritate/piss off users that care about
standards -- which, in a FOSS community that cares a great deal about
interoperability, might be quite a few.  Plus, if people actually have
real data in TPE2, they could innocently set the album artist, not
realizing it'll wipe out the (legit) data they already have.  Another
problem: TPE2 is only in ID3.

On the other tag-writing extreme we have things like metadata profiles,
which sound cool but the average user will never, ever figure out.

Across the field there are methods that use Amarok's smartness and
database to try to kludge something together.  These tend to break easily.

My fellow developers have been conspicuously silent on this issue, so
I'll go ahead and say my preference.  Bear with me; it's long, but it
covers most/all corner cases I can think of.

1) When writing tags:

For non-ID3-based formats, try to interoperate with other players in
terms of the format used.  This will generally be a free-text comment;
if you can interoperate with other players without needing to write
player-specific tags, great.  Reading other players' player-specific
tags is nice, but please then either write our own (probably necessary
with ID3 at least since players are supposed to identify which player
wrote the comment) or write a generic one if you can drum up support
among other players.

For ID3 tags: Implement support for using TPE2, but make the user aware
that it is not standards-compliant and may overwrite existing
information.  In other words, if you are using the tag editing dialog to
write these tags, I would have the field listed as something like
Band/orchestra/accompaniment/Album Artist* with an explanation --
somewhere on the tag dialog, or perhaps  on a QWhatsThis that pops up
when you click Album Artist or the asterisk -- that this field is
commonly used for Album Artist, but doing so does not adhere to the ID3
standard.  They should be able to choose whether to write the Album
Artist in TPE2 (breaks standards, more portable), or whether to write it
in a comment (standards-compliant, less portable).

When implementing album artist/VA support throughout Amarok using values
from TPE2 you'd have to keep something else in mind as well, and this is
where things actually get difficult (if you don't want to put a burden
on the user): you can never assume that the TPE2 field being filled in
indicates an album artist, as opposed to someone that is using TPE2 for
its intended purpose (for instance someone with a Frank Sinatra track
that has TPE2 set to "The Frank Mane Band", and where the band is
different on various tracks on the album).

This problem is very hard.

The best solution I've come up with is the following:

If users either users choose to write text into the TPE2 tag and also
check a "Various Artists" checkbox, or if they simply mark an album as
being Various Artists from the Collection Browser, write a comment into
the file with a value indicating that the track is a various artists
track -- IsVariousArtists or TPE2_CONTAINS_ALBUMARTIST or something.
The point is, something that we can pick up on next time during the next
scan, so that we can be sure that once the user notes that it's a
Various Artists track, they never have to do so again.

In the case that these values don't exist you could still try to do
smartness with things like grouping together different values of the
TPE2 field, or possibly try to do some smartness where if you have
multiple tracks with the same Album Artist and the same Album Name and
none of the track #s overlap, then they are probably VA tracks.  But as
I said, these kinds of algorithms, while they can be decent, always
break down somewhere.  Hence why we should ensure that if the user tells
Amarok that these tracks are VA tracks once, we should never forget it.

Hope this provides some insight for the SoC applications.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/amarok/attachments/20090401/05d204de/attachment-0002.sig>