Various Artists GSoC project

[Jeff Mitchell]

Ben K wrote:
> Regardless of that, you do make some good points about TPE2, but here's
> the thing:
> 
> *Users care about functionality. They don't care how that functionality
> is achieved.*

We are well aware of this.

> So while we sit here and quibble about standards and compliance and
> implementation details, iTunes and WMP "do whatever they want" ie they
> are free to *innovate*.

I don't call this innovation.  Innovation would have been contributing
to the standards process and helping to usher in a more capable ID3v2.5.
 Instead they dug in their heels at ID3v2.3 and hacked up crappy
player-specific solutions.  Innovation suggests furthering technology or
using it in novel ways.  There's nothing novel or furthering about
embrace-and-extend; in fact, it's about as old-hat as you can get.

Please don't lecture about innovation just because I don't agree that
your solution to your pet peeve problem is necessarily the correct one.

> This means you can comply with standards until
> you're blue in the face; you're still going to bleed market share to
> apple and microsoft when users see things like Coverflow, or the fact
> that suddenly they see 500 artist entries when sorting their albums
> instead of 3,000 (this is the difference between Artist and Album Artist).

This doesn't happen to me.  But then, I properly tag my tracks.

> You try to dismiss my description of using TPE2 as Album Artist as a de
> facto standard by claiming that iTunes and WMP somehow don't count
> bacause they do what they like. But they are the two biggest players in
> terms of market share. Let's take a look at who uses TPE2 to represent
> Release Artist, and decide whether the term 'de facto standard' is
> appropriate or not.
> 
> Players which call TPE2 "album artist":
>   *Winamp*
>   *Windows media player*
>   *iTunes*
>   *Realplayer*
>   *Songbird* (with AlbumArtist plugin)
> *  Squeezebox*/*SqueezeCenter*
> 
> Sure sounds like the de facto standard to me..

It's not a standard.  I've not argued against using it in Amarok.  But
the fact remains that it's not a standard, and if Amarok does this, it
will not be standards-compliant.  (Tradeoffs between interoperability
and standards-compliant are everywhere in computer software, standards,
and protocols, unfortunately.)

Interesting note about the above list: Songbird uses (a modified version
of) TagLib for its tagging, just like Amarok.  TagLib takes great pains
to be standards-compliant (except in some cases where it works around
bugs in tags that iTunes writes).  You'll note that it requires a plugin
for Songbird to tag album artists using TPE2.

> That being said, if we do implement it we should try to do something
> sensible. For example, I have tagged all my music in Musicbrainz Picard,
> and this adds Album Artist information. Where does it put it?

TPE2.

> That would
> seem to me to be a good place to start in terms of supporting a sensible
> (pseudo) standard.

It's not a standard.

> Picard is open source tool like Amarok, and the
> Musicbrainz community have put a lot of thought into exactly the kinds
> of problems we're coming up against with music metadata like this.

Or they just followed the pack as you propose.

> XMMS suggested an interesting way of dealing with the problem of
> deifferent people using tags in different ways - ie some people might
> actually use TPE2 to store the accompanying orchestra/ensemble. It does
> this by letting you customize a profile that essentially defines what
> each tag means to you. There's a summary of the idea here:
> http://wiki.xmms2.xmms.se/wiki/Metadata_profiles

More interesting, although probably too complicated for the average user.

> Another way forward would be to allow sorting/grouping of collections by
> arbitrary fields, though this is not possible under the current
> implementation, and most of the ways to do this would likely require
> schema changes (ie are not likely to happen).

Why are schema changes unlikely to happen?  Amarok makes no
backwards-compatibility guarantees for its database.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/amarok/attachments/20090331/787bd3f2/attachment.sig>