>- Feels like "track artists" are produced based on existence of >ALBUMARTIST tag but only as long as the album hasn't a COMPILATION tag. >This feels strange to me. Either all albums with albums.compilation=1 >should follow the same principles or all albums with an ALBUMARTIST tag >should follow the same principles. The current situation where track >artists is a special case for only Album2 just feels very strange to >me. > Yes, I've always thought that "track artists" were inconsistent. ARTIST tags on songs should always be stored with track artist role, if there is an album artist (either a defined album artist, or derived from other tags).
Seeing that the compilation tag could be set on albums that have varying track artists or on albums where all songs are performed by the same artist, I don't think the compilation property should change whether there are track artists or not. It should be whether there is an album artist or not (either via a tag or derived - eg. if SBS detects varying artists without an album artist, then compilation=1 and album artist=Various Artists and songs will have track artists). The option to show all artists in the Browse Artists list, would be the distinct union of album artists + track artists, or if the option was set to only show album artists, don't include track artists. It seems the rules to creating the list of artists is overly complicated as a result of inconsistent use of track artists. The wording of the music library setting "Group compilation albums together" suggests it only excludes artists that only appear on compilations, and doesn't exclude artists that only have guest appearances. I'm not sure if guest artists are excluded or not, but it would seem wrong if they weren't. i.e. It would be better if the radio button options were labelled "Hide guest artists" and "Show all artists" (or turn into a checkbox - "Show all artists"). >- To me it feels like Album3, Album4 and possibly even Album5 also >should have a "Various Artists" entry in the contributor_album table. >That would make it consistent with the contents of albums.contributor. > Album3 and Album4 - yes, would expect an album artist "Various Artists" if there are varying artists across songs. Album5 - don't think this should have album artist=Various Artists, going by current contributor role rules. Each song has the same artist, and no album artist tag, thus there is no album artist - just a standard artist role. I would say that there isn't a need for normal artist contributor roles (role 1) - should only need album artist roles, and track artist roles. If every album ended up with at least one album artist role (could have multiple), it would simplify queries to get a list of artists to display (queries are either looking for album context info, or song context info). i.e. scanner reads album artist(s) and stores them per album, or derives an album artist(s) of either the artists on every song (if the same) or otherwise "Various Artists" (configurable name). >However, regarding the visibility in the Artists menu, I have to look >into it a bit more because I just noticed that the 7.6 installation on >my development machine behaves differently than the 7.6 on the >production machine. So I suspect there might be some setting and not >7.5 vs 7.6 that causes the problem. > If you've been messing with album artist and compilation tags, it may mean you need to do a full rescan. This was the case with 7.5 - scan for new/changed files doesn't seem to work reliably if these tags are changed. It was mentioned when there were discussions about what needed fixing for 7.6 and auto detection. I don't think it's fixed in 7.6 though, and why I would not consider using auto-scan and why there must always be a manual scan option. I think 7.6 attempted to get rid of some DB tidy-up phases that attempted to correct things like this, as it was to be done as each new/changed file was detected. _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/ripping
