Hi Erland,
>I'm sorry I don't have the time to read through all this discussion
>
You wouldn't enjoy it if you did ;)
Thanks for stepping in to get this discussion back on track.
>Would it be possible to summarize what needs to be changed in
>SqueezeCenter to end all these compilation debates ?
>
Not much at all, in my opinion.
The issue is how to deal with cases when there are both Album Artist tags AND
Compilation tags, specifically in mp3 id3v2.3 files (although I would think
this is a generic scanner processing problem with any tagging format). There
are no problems being discussed for when either Album Artist OR Compilation
tags are used (or none).
The problem that has been identified is when songs on an album have album
artist tags AND a compilation = 0 tag. From what I gather, in this case the
album artist and track artist roles do not get populated and normal artist
contributor roles are stored in the SC library instead. As a result,
contributing artists get blown out into the Browse Artists list, even if those
artists only appear as guest performers.
I believe this is because SC reads and processes compilation tags first, so
COMPILATION=1 takes precidence over any defined album artist, and the album
artist would be displayed as Various Artists (or whatever the VA string is
defined as in SC settings).
I believe in previous posts of this nature, most people were in agreement that
Album Artist tags should take precidence, in that if there is an album artist,
the album can't be a compilation, as the point of an album artist tag is to
group differing contributors to list them under that artist name instead of
Various Artists.
SC scanner could be changed to process tags something like the following:
if Compilation tag = 1
store album as a compilation, artist tags become track artist roles.
ELSE
if Album Artist tags exist
store album with album artist role = Album Artist tag, and
artist tags become track artist roles.
else
if artist tags on song on the album are different
store album as a compilation, artist tags become track
artist roles.
COMPILATION=0 needs to be addressed in this logic though (see below).
Personally:
I don't think there's any urgent need to make any changes. Most users do not
have compilation tags, and there have not been many complaints about things not
working. A workaround is that there should either be an album artist OR a
compilation tag, not both.
As the DB schema is being totally reworked, it's not worth trying to sort this
out now.
>And preferable list a number of registered bug reports/enhancement
>request that describes what needs to be done.
>
I think Mr. Sinatra wrote a bug report, but I haven't read it yet.
>As I've understand the intended behavior is:
>- If an album has several artists it is considered a compilation unless
>it has been tagged with an album artist.
>
>- If an album only has a single artist it is not considered to be a
>compilation.
>- If an album has a single album artist it is not considered to be a
>compilation independent on how many track artists it have.
>
>You can override this behavior with a custom COMPILATION tag set to 0
>or 1.
>
>This behavior makes perfect sense to me and I'm pretty sure it makes
>sense to most SC users. You can always argue that SC shouldn't do
>compilation logic at all, but this really is an enhancement compared to
>other applications so I can't see a problem with it as most users are
>going to like it.
And to me. Your summary is what I believe too, although COMPILATION=0 has
another use. I think it is due to the default iTunes behaviour of always
storing ripped songs in artist/album/track folder hierarchy. As a result, SC
would see that as several albums of the same name; one for each artist, due to
the way it solves the "Greatest Hits" issue. And thus I think COMPILATION=0 is
used to rejoin all songs back into one album.
Mr. Sinatra is stating that for any user that has ever used any other
application or receives tags from metadata sources, all albums will always have
an album artist tag. So, there will never be compilation albums.
Phil
_______________________________________________
ripping mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/ripping
