Bugzilla – Bug 10583
VA albums handled as many one-track albums with 2 artists each
Last modified: 2009-06-17 09:36:10 UTC
I think I have found some more faults regarding the aggregation of »VA«/»Compilation« albums, verified against both SC 7.3.2-24401 and 7.3.2-24523 (both Windows). I was wondering why very few of my VA albums were shown as »albums«, some even with a list of artists beneath, while most of them display as lots of »albums« containing »1 track by 2 artists« [sic]. After many nights of debugging and doing full re-scans, I think I found out the following: * If a VA album is stored in one folder, the track artists will be shown beneath. (Something like »16 All-Time Country Greats« with a list below like »Anne Murray, Barbra Mandrell, Conway Twitty, Dolly Parton, Don Williams, Flatt & Scruggs, Frankie Laine, Freddie Fender, George Jones, Johnny Cash, Kenny Rogers, Lynn Anderson, Ned Miller, Sandy Posey, Waylon Jennings, Willie Nelson«) * If the single tracks are stored elsewhere, no »artist list« will appear. (Mine are usually stored under the artist folder, even for compilations, since I want to know all titles I have from any single artist. Compilations are »held together« by playlists, or SC logic.) * VA Albums seem to be »detected« somehow by SC by comparing Album Artist, Album Name, and other frames (Year and Date?). This often leads to VA albums being shown as many »albums« of one track each. * Number of artists shown and grouping logic are faulty and need to be re-verified. I think it is bad practice to deduce content assumptions from physical storage locations! This is what metadata is for. People tend to come up with inventive variants to store their data, so no assumptions should be made by things like »ah, they are together in one folder, they must be an album!« I have two VA compilations I want to use as an example here: 1. »Various Artists - 20 Years of Nuclear Blast« (4 discs) 2. »Various Artists - 30 Jaar Disco« (2 discs) (1) is shown in my SC as 4 »albums« like 20 Years of Nuclear Blast (disc 1) (2007) Various Artists 20 Years of Nuclear Blast (disc 2) (2007) Various Artists and so on. When I click on the album title, SC will state »Compilation: Yes« and show all tracks on the disc, and their artists, summarizing below like: »1 album with 17 songs by 18 artists« (!) (Apparently it counts the Album Artist »Various Artists« as an extra artist?!) (2) is shown as 40 (!) single albums like 30 Jaar Disco (disc 1) (2006) Various Artists 30 Jaar Disco (disc 1) (2006) Various Artists and so on. When I click on an album title here, SC will state »Compilation: Yes« and show only one track from the disc, summarizing below: »1 album with 1 song by 2 artists« (!) (Apparently, it also counts artist plus album artist here!) It took my a while (and many re-scans) to find that apparently SC only aggregates VA albums into one if not only the Album Artist and Album Name are the same but also Disc Number (?), Year and Date are given! Unfortunately, many of my old MP3 VA albums have TYER set but not TDAT! This *seems* to be the only difference. I guess SC wants to compare Album Artist, Album Name, and the complete release date, constructed from both TYER+TDAT. If these dont’ agree or TDAT is empty/non-existent, the match will fail and as many »albums« created as there are tracks on the (real) album! This approach might function with ID3v2.4's TDRL/TDOR or Vorbis Comments, where (usually, not always!) a full date/time can be stored, but it seemingly breaks when using ID3v2.2/2.3 and having only TYER. I’d wish for development/users to verify what I—more or less—can only assume, so here are more details: EDIT: Using TYER might not be the ideal solution to aggregate compilations: Gracenote-based taggers (iTunes, Winamp) tend to use TYER for something like »first release year we know about«, so especially the YEAR in compilations might be used more like what was originally spec'ed (»recording year«), albeit most people use this (TYER+TDAT) for »date of release of this album« and TORY for the »original year« (date of first release). EDIT 2: Just seen that »MUSICBRAINZ ALBUM ID« is at least read/mapped, and all my files have that but are still not seen as one album. This should actually be a »higher priority« tag to group albums together, and be sufficient (if it exists). Please see long description in forum: http://forums.slimdevices.com/showthread.php?t=57807
Bug 10528 seems related. For me, looks like Schema.pm rework.
SC requires a disc number to correctly group compilations together, both for FLAC and MP3. See also: http://forums.slimdevices.com/showthread.php?t=58159 Tags shouldn't be redundant, and MANY users won't have a "disc #1 of 1" tagging for single-disc releases (might be singles even!). Schema rework needed. AND, eventually, a really understandable "guide to tagging for SC". Which might prove to be the harder bit ;-)
Still the same in SC7.4-24817 :-(
Reproducably needs TYER+TDAT tags equal to work with ID3v2.3 tags. Stupid.
... and only works on a complete wipe & rescan, which takes short of 5 hours here (added TDAT=0000 for one album to verify). SHOULD at least work with "new & changed".
Created attachment 4736 [details] Screenshots for "compilation album scattering" Now I'm at a complete loss -- can't make out any differences between the following albums, but "Best of Driving Rock (disc 2)" is shown as ONE album while "German Rock Scene, Volume 2" is shown as 9 separate 1-track albums. (All MP3, tagged with only ID3v2.3/ISO-8859-1 encoding, no duplicate frames.) When doing a full rescan, clicking on any one of the multiple albums produces "1 album with 1 songs by 2 artists" (sc-va-album-bad-tracks-1.jpg), when only doing a "scan for new & changed" it produces "0 albums with 0 songs by 0 artists" (sc-va-album-bad-tracks-2.jpg). The "good" album shows "1 album with 10 songs by 11 artists" (probably due to the "11. artist" being the Album Artist "Various Artists") (sc-va-album-good-tracks.jpg). I attach Mp3tag screenshots (showing file names, path names, and the "extended tags" view) as well as the SC settings screen and output. (ZIPped since otherwise we'd get too many attachments.) Hope for help. It is really, seriously broken. (And no, I'm NOT willing to put VA albums in ONE directory, and no, I'm NOT willing to change the Album Artist (TPE2). This scheme has been evolving over 9 years and proved feasible, also for other uses.) Btw, setting "Group compilation albums together" instead of "List compilation albums under each artist" didn't help. FYI: MusicBrainz' Picard is the step-before-last in my tagging workflow (the last step is adding the MMM analysis data), which means that files will have XSOP set to the same value TXXX:ARTISTSORT has. (Mp3tag doesn't show XSOP, unfortunately.) Currently testing version: SC7.4-24817/Windows.
I zipped up the music files with the original path structure, only the file is 122 MB. Available upon request, if needed for serious testing.
After having a quick look at _postCheckAttributes in Schema.pm today, I’d suggest two possible ways to handle this bug. 1. It appears that all discs that are part of a set greater than 1/1 (i.e. 1/2) are handled correctly, even if their tracks are in different directories. This mechanism is broken by the special handling of the "iTunes useless disc 1/1 tag". For an easy solution, I’d suggest reinstating the "disc 1 of 1" logic and not ignoring these. This would allow for tagging MP3 compilations with TCMP=1 and TPOS=1/1, FLACs with COMPILATION=1, DISC=1 and DISCC=1 and have them handled correctly. I guess it could be "sold" to users that they have to set COMPILATION PLUS DISCNUMBER in case they want compilation tracks in different folders. 2. A more elaborate solution would be checking if we had an album with the same ALBUM, the same ALBUMARTIST contributor, and COMPILATION set. To avoid the "Best of" problem, I’d suggest ALSO checking for the same MUSICBRAINZ_ALBUM_ID since we read it anyway and many people use Picard. This should "overrule" the "same basename" check IF a MUSICBRAINZ_ALBUM_ID is present. Thus, we would allow people using MusicBrainz to have their album tracks stored whereever they want, PLUS have a fallback to the old "same folder" scheme in case they only use minimal tags. The only caveat to think about might be if they enable grouping of disc sets in which case MusicBrainz will have a different MUSICBRAINZ_ALBUM_ID for EACH DISC in the set. --- Solution 1 appears quite easy, solution 2 just a little more work, so I’d say it might be worth to retrofit the change into 7.4 instead of waiting for 8 and a complete schema rework. I would have written and suggested a patch but unfortunately my Windows dev machine is already at Perl 5.10.0 for other reasons, and Schema.pm isn’t exposed in the Windows version ... What does anyone think? Any hope?
Created attachment 4742 [details] Patch to Schema.pm to realize solution #2 I invested a few hours to come up with my proposed solution #2: Reinstate "disc 1/1" logic plus use MusicBrainz Album Id if available. After several tests and rescans here on my system (Test suite + full library: ~25k files, MP3, FLAC, OGG, WMA), I can say it seems to work beautifully and not break anything. Of course someone should look it over and do more testing. Please?!
Patch file also contains the patch for bug 10935 (1st diff). Just made one diff since not working against the "live" svn.
Created attachment 4753 [details] Schema.pm diff against SC 7.4-24858 Updated patch for SC 7.4-24858
Created attachment 4820 [details] Schema.pm diff against SC 7.4-25035 Oh well. Since nobody seems to care about SOLUTIONS, I update the Schema.pm diff for the latest 7.4 version 25035.
Created attachment 4866 [details] Schema.pm diff against SC 7.4-25192
Patch applied in 7.3.3 change 25605.
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.