Bugzilla – Bug 18096
Support COMPOSERSORT and other contibutor sort tags
Last modified: 2015-06-23 09:03:24 UTC
LMS supports corresponding sort tags for ARTIST and ALBUMARTIST tagging fields, but does not support COMPOSERSORT and similar fields to be associated with tags that create other contributor roles. Free-form field names for each of these should be self apparent. COMPOSER -> COMPOSERSORT CONDUCTOR -> CONDUCTORSORT BAND -> BANDSORT ORCHESTRA -> ORCHESTRASORT With ID3v2, iTunes and other software used TS0C for COMPOSERSORT, while BANDSORT/ALBUMARTISTSORT is TSO2. I think TSO2 should simply be associated with the TPE2 field, no matter which pref is set for the use of TPE2. There is no CONDUCTORSORT (for TPE3) in ID3v2 that I'm aware of. If/when similar fields within other tagging systems become known, we can add them in the future.
Jim - looking at the code it seems COMPOSERSORT (& TS0C) and ALBUMARTISTSORT should already be supported in some way. But what I was wondering is: why should we have different sort values for the same contributor, depending on the role he played? Is the idea that we can have Elvis sorted as "Elvis Presley" when he's the singer, but "Presley, Elvis" when he's the composer? And what if on one track there's a COMPOSERSORT (or even ARTISTSORT fwiw) it's "Elvis Presley" and on another one it's "Presley, Elvis"?
Heh... bug 3069, which you filed years ago, should take care of not overwriting the sort value if it's already defined and different from the contributor name :-)
Yes, ALBUMARTISTSORT and ARTISTSORT are fully supported. If I recall correctly, COMPOSERSORT may be recognized by the scanner, but I don't believe the sort value is ever applied to the data. BTW, a small typo above: Should be TSOC (containing the letter 'oh', not a zero), and TSC in the three letter tags of ID3v2.2. See: http://id3.org/iTunes Yes, the current scanning behavior of applying the first seen sort value for a contributor name should still apply, regardless of the role. It's a somewhat arbitrary rule, but it's as good as any.
But do you have a case where the COMPOSERSORT value would be different from the ARTISTSORT or other *SORT value, and where you indeed want them to be different? It just doesn't make sense to me. The rule currently is (as you can see from that other, old bug): if the SORT value is different from the raw name, then use it. Otherwise let it as is. But as this rule is applied to the same contributor value for every *SORT value found, the last one will win. Eg. if you have ARTIST="Elvis", ARTISTSORT="Elvis Presley" and COMPOSERSORT="Presley, Elvis", you might end up with "Elvis Presley", if that value was found _after_ the COMPOSERSORT. Does this make any sense?
> But do you have a case where the COMPOSERSORT value would be different from > the ARTISTSORT or other *SORT value, and where you indeed want them to be > different? It just doesn't make sense to me. No, you probably would not have that case. But it's not a matter of the sort value being different. It's a matter of not being able to apply a sort value at all to contributor names found in those tags. It would be common for a COMPOSER, CONDUCTOR, or ORCHESTRA to not appear anywhere in the library as an ARTIST. For instance, the composer 'Franz Schubert' would not appear as an ARTIST on any recording. (Unless you're in the habit of using ARTIST or ALBUMARTIST to hold the composer name.) > The rule currently is (as you can see from that other, old bug): if the SORT > value is different from the raw name, then use it. Otherwise let it as is. > But as this rule is applied to the same contributor value for every *SORT > value found, the last one will win. Eg. if you have ARTIST="Elvis", > ARTISTSORT="Elvis Presley" and COMPOSERSORT="Presley, Elvis", you might end > up with "Elvis Presley", if that value was found _after_ the COMPOSERSORT. > Does this make any sense? I believe it's actually: If the sort value in the tag differs from the raw name *and* the contributor sort field in the database is blank, save the new sort value. This should have the effect of applying only the first <>raw sort value encountered and then ignoring anything after. I believe this works as expected for the two tagging fields ARTIST and ALBUMARTIST, so adding additional fields shouldn't change anything.
Created attachment 7735 [details] Include Composersort & Conductorsort (does this even exist?) in contributor table. Could this fix be as simple as this one line change? Jim - I don't have any test material. Could you please give this a try?
Jim - could you please test the suggested patch?
*** Bug 10387 has been marked as a duplicate of this bug. ***
I have just found and tested the proposed patch with COMPOSERSORT, CONDUCTORSORT and BANDSORT. I don't use ORCHESTRA. Fantastic! So far as I can tell it's working very well. I need to count the number of entries before and after in the 3 contributor tables, to make sure no extra records have crept in, but it seems fine thus far. I will report further. Apart from the tests above, and using the Additional Browse Modes menus to check that I have consistent ordering both where Conductors (etc) are, and are not, also Artists, what other tests should I perform? The need for this on my system is that I have Composers who are not Artists or AlbumArtists, and other Composers who are two or all three of these. Ditto for Conductors and Bands. With pop/rock the benefits are less obvious, but for musicals etc the benefit is also clear for those of us who treat the roles as being distinct. I treat Artists as performers, so only Composers from around 1905 on may sometimes appear as Artists. For Conductors, if there is no other 'main' performer, I set Artist, and if needed, AlbumArtist, to the same name, since I want at least one Artist and AlbumArtist set on each track (and I use Various for AlbumArtist where no main Artist appears on all tracks of an Album). In principle any of these tags can have multiple values on my system (that is separate tags created using puddletag \\).
*** Bug 18132 has been marked as a duplicate of this bug. ***
Re-reading earlier comments I should clarify that it's important to set up all tags and sort tags consistently. So for a Composer who is both a Composer and Artist, ArtistSort and ComposerSort should be the same (or one omitted). Since the logic for creating sort forms is easier to apply to every occurrence rather than only some, I apply it to every artist-related tag, with subtly different rules for Bands (I don't want Music Roxy as a sort version) As it happens I share my database with another music tool, that although less powerful than LMS and hence only used as a backup, mainly when LMS is scanning, has other benefits. A notable one is that it tests to make sure that for any contributor, the sort form is the same in all cases. If not, it complains and throws out the scan of that contributor. The music server is MinimServer (only for UPnP devices).
Created attachment 7741 [details] A patch diff file to add some SORT forms I have tested this. All my Composers, Conductors and Bands are now using the SORT forms I set up previously in my flac tags. I have checked that contributors, contributor_track and contributor_album contain the same number of records as they did before the patch and full re-scan. I have no mp3s or other types to test. on linux/ubuntu: patch /usr/share/perl5/Slim/Schema.pm Schema.diff
commit f590592f7d385de3ac5064d89ed26ca45eb82e6d - thanks!
Thanks very much.
Re-tested in Logitech Media Server Version: 7.9.0 - 1431440256 @ Wed May 13 04:05:18 UTC 2015. Fixed. Thanks.
Is there any reason why Contributor #6 - TRACKARTIST - has been omitted from this patch - that would make the full set? I use TRACKARTIST to hold supporting artists and since they might not be a main artist on any track, they will not necessarily get a proper sort key. I have added TRACKARTISTSORT to the patch on my local system and it seems to work fine - any chance of adding this to the main build?
(In reply to comment #16) > Is there any reason why Contributor #6 - TRACKARTIST - has been omitted from > this patch - that would make the full set? I use TRACKARTIST to hold > supporting artists and since they might not be a main artist on any track, > they will not necessarily get a proper sort key. I have added > TRACKARTISTSORT to the patch on my local system and it seems to work fine - > any chance of adding this to the main build? TRACKARTISTSORT does not exist. Sure, you can add it if you like, but it's not part of any format or standard.
Curious that Contributors #1 - 5 all have sort keys but #6 does not. I guess I'll just have to patch the schema on each release - just one word to add to it, so not a big deal for me! However, I am in the process of producing a classical music tagging scheme which optimizes the combination of Muso and LMS. This will be made freely available to others who may wish to use the TRACKARTIST tag for supporting artists in the same way. Is there any reason why TRACKARTISTSORT should not be included in the main build? I note that it is already in the schema to deal with bug 6507. Reading bug 6507, it seems that this fix was done for "internal" reasons, and I note the quote: "Hmmm I think the key insight might be that a TRACKARTIST is an artist that should not appear in the "Browse Artists" list (unless it also appears in some "first class" role elsewhere)." However LMS7.9 now includes TRACKARTIST (whether or not also an ARTIST) as a browseable role in the "Additional browse modes" so it seems to me that it has already been endorsed. That's a lot of words to request the addition of one word in the schema (pretty please), but I hope I have made a case! In my mind the counter-argument is possibly that TRACKARTIST is actually the wrong word since ID3v2, FLAC etc use PERFORMER(S) and SOLOIST(S). If LMS is going to stick with TRACKARTIST instead then I hope my argument holds water. If Contributor #6 becomes PERFORMER then I am equally happy with that (provided we get PERFORMERSORT too :)). Muso natively looks for PERFORMER anyway. But I am not suggesting a change to PERFORMER as I suspect it involves more than just one word!
TrackArtist is an internal contributor role used only in the LMS database. I'm not aware of its use as a field in any tagging system. It's been argued and shown that this role in the database is largely unnecessary. It was apparently some programmer's idea to work around some issue being dealt with years ago. It could be dropped tomorrow and it would likely clean up a lot of code and simplify many DB queries. If you want to create TrackArtist roles in LMS, use the ARTIST tag and provide an ALBUMARTIST tag in the same file. Then contributors listed in the ARTIST tags will be given TrackArtist roles in the LMS database. To provide sort fields for these contributors, use ARTISTSORT tags.
Hmm. Well, if it's "official" that TRACKARTIST (or similar) is not really supported and that its inclusion in the additional browse modes is an aberration then that leaves me with two options - either the one word local patch or using ALBUMARTIST as a work-round as suggested. The latter would mean mapping ALBUMARTIST in LMS to ARTIST in Muso and mapping ARTIST in LMS to PERFORMER in Muso, to retain the distinction between lead and supporting artists. Then using a custom tag to map onto ALBUMARTIST in Muso on the rare occasion that is necessary.
As regards TRACKARTIST, it's just another 'role' in LMS. Provided your source ARTIST and ALBUMARTIST tags also have ARTISTSORT and ALBUMARTISTSORT tags then all your TRACKARTISTs in LMS will also be sorted properly. There is no need (or purpose) for a TRACKARTISTSORT.
(In reply to comment #21) > As regards TRACKARTIST, it's just another 'role' in LMS. > > Provided your source ARTIST and ALBUMARTIST tags also have ARTISTSORT and > ALBUMARTISTSORT tags then all your TRACKARTISTs in LMS will also be sorted > properly. There is no need (or purpose) for a TRACKARTISTSORT. That assumes that TRACKARTIST only exists as a consequence of LMS's internal actions. If TRACKARTIST is explicitly provided in, say, a FLAC tag then it will not be sorted properly unless the artist also exists as ARTIST or ALBUMARTIST. The question is whether or not TRACKARTIST (as an analogue of PERFORMER or SOLOIST) should have a separate existence. I had (maybe wrongly) assumed that was the case, given its explicit inclusion in the additional browse modes and, as I have described, the patch is very simple. If that is not the case then clearly it makes no sense to use it as an explicit tag. As I said earlier, I am trying to provide a tagging scheme that caters for classical music, using Muso and LMS. Muso uses PERFORMER or SOLOIST (the FLAC "standards") for supporting artists. However, Muso gets all its sort keys from LMS's Contributor table. Hence my desire to know if Contributor #6 would get a sort key "in its own right" as the other roles do. It struck me as a simple completion of the existing fix (which works and is very useful, for which I am very grateful).
I also had the classical music conundrum to solve. I use ALBUMARTIST + SORT for the primary Album performers, ARTIST + SORT for all performers on a track, COMPOSER + SORT, CONDUCTOR + SORT and BAND + SORT (instead of ORCHESTRA). ARTIST and ALBUMARTIST are always populated, with ALBUMARTIST being 'various' if there's no such beast on the ALBUM. My ARTIST also often contains the CONDUCTOR and ALBUMARTIST. For me, TRACKARTIST is just a confusing addition in LMS, but it's far too late to change LMS now. So I added TRACKARTIST to my ARTIST menu in Additional Browse Modes, and all works as it should in LMS. Everything is sorted correctly, since it is the Contributor name that has the sort tag, not the role (which is per track). So for TRACKARTIST, LMS uses the ARTISTSORT tag (if present) matching the ARTIST from with TRACKARTIST is derived. To make classical music tags function as I need them I added WORK and WORKARTIST and WORKARTISTSORT. So I also use Custom Browse and Custom Scan. There's a setting that allows ARTIST and TRACKARTIST to be synonymous, so I can just ignore TRACKARTIST. The other software I use against the same flacs (foobar2000 and minimserver) don't know about TRACKARTIST, nor need to, they work perfectly well without it. Both also work with custom tags. As to PERFORMER and SOLOIST, I thought about using them but decided not to, since ARTIST and WORKARTIST do what I want.
Very helpful, Tim - thanks. Looks like I will have to do custom imports to Muso, which is doable, but inelegant. On reading various other earlier bug reports I can see that there is a lot of rather convoluted history surrounding the existence of TRACKARTIST, of which I was not aware when I posted my original comment on this bug. In particular, if I understand correctly, TRACKARTIST was introduced to deal with the issue of handling ALBUMARTIST on a compilation album. Being a simpleton, I would have thought that ALBUMARTIST for a compilation album is semantically inconsistent so maybe the compilation flag should just be ignored. If this bug is considered to be fully closed, maybe I should raise the more general issue in the Squeezebox Forum, but I fear opening a can of worms.
I think this bug, as defined, is fixed. I'm not sure there's much to be gained by raising another issue on the forum. It's an old and complex topic, and there are too many users to make it safe to make many changes to such things. This particular bug proved to be fixable in an easy and safe way. I've been somewhat irked the the 'Artist' count in LMS statistics which seems to exclude TRACKARTISTS, but I'm not to to chase it further. I hope 'WORK' and 'WORKARTIST' make sense to you. I also have 'MOVEMENT' as a tag. I got those ideas from Erland, the custom browse plugin developer. They do well for me, and I can even do things that 'Play Random Works' in LMS, which is something I can do with no other music software.
(In reply to comment #25) > I think this bug, as defined, is fixed. > > I'm not sure there's much to be gained by raising another issue on the > forum. It's an old and complex topic, and there are too many users to make > it safe to make many changes to such things. This particular bug proved to > be fixable in an easy and safe way. > > I've been somewhat irked the the 'Artist' count in LMS statistics which > seems to exclude TRACKARTISTS, but I'm not to to chase it further. > > I hope 'WORK' and 'WORKARTIST' make sense to you. I also have 'MOVEMENT' as > a tag. I got those ideas from Erland, the custom browse plugin developer. > They do well for me, and I can even do things that 'Play Random Works' in > LMS, which is something I can do with no other music software. Thanks. I'm largely following Erland's scheme too. Will post info about my scheme on the main forum, when done. Now I have seen the history, I can see that there is a risk in using TRACKARTIST as PERFORMER. Not satisfactory, but I agree that any more fundamental change could cause problems too. So I will close my original comment.