Bugzilla – Bug 11159
Setting to show artist SORTNAMES instead of artist names
Last modified: 2009-09-08 09:20:49 UTC
Filed this under "Misc" since it might touch Database, PlayerUI, CLI, Scanner, Tagging and others. As suggested in http://forums.slimdevices.com/showthread.php?p=399792#post399792 I'd like to suggeest a (WebUI + per player) setting like Artist (Contributor) Sorting: (_) Sort by name, display name ("E" -> "Elton John") (x) Sort by sorting name, display name ("J" -> "Elton John") (_) Sort by sorting name, display sorting name ("J" -> "John, Elton") If using, say, the MusicBrainz Schema whereby BANDS are listed under the band name ("Steve Miller Band") and PERSONS under their sorted name ("Miller, Steve"), it is sometimes confusing having to make the "translation" into a sort name "in the brain", i.e. guessing that "Steve Miller" is under "M" but the band under "S". I think it would be a nicer "SqueezeBox Experience" for the end user to be able to decide on any ONE of these schemes: a) Use artist names, list by it: "S" --> "Steve Miller" b) Use artist names, list by sortname: "M" --> "Steve Miller" (as is now) c) Use artist sortnames, list by it: "M" --> "Miller, Steve" Eventually, this should be possible to be used on a WebUI *and* per-player basis for *all CONTRIBUTORS* (i.e., Artist, Album Artist, Conductor, Composer, ...) but starting with ARTIST and ARTISTSORT might be a good first step.
Thinking of contributors: For those who wish to have the "perfect" database, tagging of things like multiple composers (spec'd in ID3v2) would have to be made transparent (i.e., multi-value tags: Use same sequence and the like): COMPOSER=John Lennon/Paul McCartney COMPOSERSORT=Lennon, John/McCartney, Paul Since only ARTISTSORT and ALBUMARTISTSORT are in wide use today, it might still be early enough to "introduce" this as a "pseudo standard" into the tagging world: a) Use same tag frame name but "SORT" appended b) On multi value-tags, use same sequence of names The only problem I see is if using multiple tag frames like COMPOSER=John Lennon COMPOSER=Paul McCartney COMPOSERSORT=Lennon, John COMPOSERSORT=McCartney, Paul since there is no known way to "force" some taggers into writing a specified sequence of tag frames, so the internal sequence of tag frames cannot be relied upon when reading. (And would make things too complicated anyway.)
Thanks for including me, James. I'm happy enough to add a setting if that's what Dean, et al wish for. Implementing the fuction could have some big consequences as far as supporting it in all UIs. It may be something that has to be held off for the db rework. However, my personal feelings on this issue is that it confuses the purpose of the tags to use the *SORT as a display. IF we do it for one, we really have to do it (or be prepared for handling the requests to do it) for all of them. A Sort tag should be used for sorting, while a tag editor can be used to the the displayed ARTIST tag to be whatever the users wants. There are apps that can do bulk mapping from ARTISTSORT to ARTIST where required.
Since it involves some changes (DB, UIs), I agree it *might* have to be postponed, maybe with the "new schema". And I agree one has to be prepared to probably handle all "sort" cases, i.e. contributors, titles, and so on. I still think it would make things more logical to the end user. People like me even rely on it, and I’ve let others play with the UIs. Almost everyone expected they would "see what is set" and not some "hidden sorting". We must also take care NOT to assume that everyone is willing to bulk change tags in big libraries, just because ONE software "requires" it. I’ve seen this "let them change their tags" quite often recently but there ARE people that need and want their files (and tags) for other uses. MusicBrainz is a good example. Really more and more people use it nowadays, and it gives us at least a good artistsort and album artist sort for free. (And shows the right way: NOT introduce "funny tags" just to make software work, but feed sensible data into the tags, in a human-agreed and human-readable form.) Agreed, SC *IS* already the best designed and most flexible playing solution, but it should STAY this way. Sometimes its worth stepping back from our programmer's insights, and just try to walk in our customer's shows for a moment. I always found that it pays. That said, I think priorities must be set, and the right balance found. The sky’s the limit, so we should do what’s feasible, needed, wanted, and require cooperation (i.e. changing bad tags) from users where needed. Oh well, long post. My suggestion: If artistsort and albumartistsort are already in the db (or can be easily included) in a human-readable form, make the change early (i.e., in 7.4 or 7.5) as a signal to show "we are willing and there's more to come", PLUS make it clear that "a complete solution" can only come with the new schema. That what I'd do, since "Artist" is a very visible option, and many already ARE confused about the sorting. Sorry for the long comment. Somehow I felt you should be able to follow my thoughts.
I think this suggestion would make sense - it's been requested more than once in the forums in the past. The big change in the database would be that the strings stored for sorting contributors would need to be left in mixed-case rather than capitalized and punctuation characters would need to be left intact. Neither should affect the sorting, since MySQL does case-insensitive collating, but there could be issues in the less common character sets. It would also need to be verified that SQLite works in the same manner.
(In reply to comment #1) > Thinking of contributors: For those who wish to have the "perfect" database, > tagging of things like multiple composers (spec'd in ID3v2) would have to be > made transparent (i.e., multi-value tags: Use same sequence and the like): > > COMPOSER=John Lennon/Paul McCartney > COMPOSERSORT=Lennon, John/McCartney, Paul Although COMPOSERSORT may not currently be supported, this is exactly how SqueezeCenter handles delimiter separated SORT tags. > Since only ARTISTSORT and ALBUMARTISTSORT are in wide use today, it might still > be early enough to "introduce" this as a "pseudo standard" into the tagging > world: > > a) Use same tag frame name but "SORT" appended This is a separate topic - bug 4584 already exists, and suggests supporting ALBUMARTISTSORT as well as other permutations of ____SORT tags.
Do we have some patches for this?