GNOME Bugzilla – Bug 144283
Case insensitivity and sensitivity
Last modified: 2018-05-24 10:33:18 UTC
When Rhythmbox adds music to the library and compares artist/album info for songs, it should do so not being case sensitive. For example, songs with the following artist should all be grouped under one of these names in the library (doesn't matter much which, as long as they are gathered): Guns n' Roses Guns N' Roses Guns n' roses As it is today, three different posts show up in the Artist column. As as sidenote on the matter of case: When ID3 tags are changed (when they can be so in future versions), Rhythmbox should be case sensitive, so that if the user changes the artist field from "some artISt" to "some artist", the change should be recognized and carried through.
Boy do I agree. I had "Southern Culture On the Skids" and "Southern culture on the skids" as two different artists, so I went in to EasyTag and re-tagged... and sure enough, missed one, so now I have "Southern Culture On the Skids" and "Southern Culture on the Skids" .... took me a minute of staring at it to see where I'd made the mistake.
If I could vote for this bug, I would, but it looks like voting has been disabled. Anyway I wish this bug were fixed.
I think this isn't a bug because there are unique artists with no difference except capitalization, for example HiM (http://musicbrainz.org/showartist.html?artistid=119294) and HIM (http://musicbrainz.org/showartist.html?artistid=1881).
David, I think that's irrelevant. There are also unique artists with no differences at all, like Mono, Mono, and Mono.
Ok, but maybe it could be an option that's insensitive by default? Even if people don't think it should be in the gui, I think it should at least be confiugrable with gconf.
*** Bug 318343 has been marked as a duplicate of this bug. ***
*** Bug 332519 has been marked as a duplicate of this bug. ***
A related feature -- it would be nice if diacritical marks were also collapsed to their nearest "non-extended" equivalent (at least while searching). IIRC, there is already a standard set of rules for this transform. As an example -- I have a number of songs tagged as "Björk" and some tagged "Bjork". It is rather difficult to type the correct spelling with my en-us keyboard layout, but I'd like to keep them tagged as-is for aesthetic reasons.
*** Bug 338674 has been marked as a duplicate of this bug. ***
Another "vote" for this bug. Comment 3 raises a valid point about why maybe we shouldn't treat "Artist Name" and "artist name" as the same artist (in order to cope with situations like the different artists "HiM" and "HIM"). Is there any objection to treating an artist's ALBUMS case-insensitively? e.g. I have an mp3 CD which includes the album "Volume 3: Further In Time" by artist "AfroCelt" however some of the tracks use "Volume 3: Further in Time" (lower case "in" versus captialised "In"). In rhythmbox 0.9.5 this shows up as two different albums by the one artist.
Another vote! :) Case insensitivity should be the default. We're playing music with a graphical player here, not managing system files in a terminal! For (very?) rare exceptions like "HiM"/"HIM" there could be a user's wildcard list of exclusions ("Handle these strings with case sensitivity:" or similar). I also agree with Comment #8. Ideally, I'd like... einstürzende neubauten Einstuerzende Neubauten Einsturzende%20Neubauten einstürzende_neubauten ...to be listed as the same artist. I would love to have settings for e.g. "Case Sensitivity", "Treat _, %20 as Space", "Match umlauts". To avoid mistransliterations and ambiguities, the automatic "umlaut matching" could be designed to only apply when a "close enough" umlauted string already exists. For example, "Handel" or "Haendel" would only be automatically transliterated to "Händel" if there's already a "Händel" entry in the library. Say there's already an artist|song|album called "Éxåmpłë!?!" in the library. The same artist (etc.) is also represented by another other file with the incorrect tag or file name "example". Right-clicking on "example" could bring up menu entries like "Treat this artist|song|album as Éxåmpłë!?!" (i.e. add the strings to a user list of matches) and "Change artist|song|album tag to Éxåmpłë!?!". Just some ideas.
Created attachment 131026 [details] [review] case-insensitive-grouping of artist and album names The patch converts all the titles, album/artist names to Title Case. Guns n' Roses Guns N' Roses Guns n' roses All the three above get converted to "Guns N' Roses" Also, underscores are replaced by spaces.
How about just fixing your tags? Multiple entries are just Rhythmbox' way of showing you that you're being messy. And another question: How should RB know which one of the labels to select? HiM og HIM? Also regarding HIM and HiM... no one would have those two bands in the same library :)
I don't think this is the correct way to fix the issue. First of all, if I understand the patch correctly, it would remove all punctuation from names of artists. This is certainly wrong. Some artists intentionally have punctuation in their names, and I want to keep them. Examples that I happen to have in my library include "Godspeed You! Black Emperor", "R.E.M.", "Noitalinna huraa!" and more if I happened to be at my desktop. There are many such artists and bands. If the patch also affects titles of albums and tracks, those have strange characters even more often. Removing parentheses from "Artist - Track (Foobar Mix)" probably isn't what we'd want, and some track titles have colons, question marks and other punctuation. I'm not sure if the same function for retrieving the strings is also used e.g. when submitting tracks to Last.fm, but if it is, this approach could also cause wrong data to be submitted there. Some names and titles may also be acronyms, and converting all characters that come after something else than whitespace breaks these. Further, even "title case" isn't universally the norm. It's generally not used e.g. in Finnish, and I would consider capitalizing all words in a Finnish band's name or song title a mistake. If I understand the patch correctly, the patch would break these unconditionally even when there are no "semi-duplicates". The manipulation should at the very least be limited to the semi-duplicates themselves.
To add to the above: it looks like this would convert abbreviations to title case, which would be pretty annoying. 'DJ' for instance. It also doesn't handle names that don't follow usual title case rules (A McB, C de D, E van F, ..). And more: cLOUDDEAD, Super_Collider, OVe-NaXx.. I don't think this can work. Performing the title case conversion each time the property is accessed is inefficient. This is also a gigantic memory leak. The strings returned by rhythmdb_entry_get_string for the artist, album, title, and genre properties will never be freed. When a function returns a 'const char *', the caller does not free it.
I would like to implement the solution as follows: Create a case-insensitive umbrella case, with the subcases within it. Eg: Pink Floyd |-> pInk flOYd |-> PINK FLOYD |-> pink floyd Each of the subcases will have an option to be excluded from the umbrella. Suppose pInk flOYd is a different artist, then, right-click menu will be implemented and will the structure will now be: pInk flOYd Pink Floyd |-> PINK FLOYD |-> pink floyd I hope this will be an ideal solution. Aside: I have exams this week, so I will get to making this next week :)
I think that's too complicated for the problem you're trying to solve. Have you looked at how this would be implemented? I'd be concerned about performance and memory usage impact. Where would you store the information about which artists have been excluded? As I see it, the problem here is that the tags are wrong. I think it'd be more useful to focus on helping users fix their tags.
Exactly my view. Helping the user avoiding correct tags by introducing new manual intervention doesn't sound like a good idea at all.
There are many instances when fixing the tags by file editing is impractical or not an option (even if it's at all possible to determine what's "correct"), like when the files are stored read-only to the user, when the files are shared via e.g. bittorrent and must not be changed in any way, when the number of files/artists is very large, et c. (I can't comment on the submitted patch, IANAProgrammer.)
Created attachment 131489 [details] [review] Title-case conversion of artist and album names. This patch converts each Title/Artist/Album name to title case. While this cannot be admitted as a patch because of the reasons cited above, I found it was a convenient thing to have. So I thought I'd share it anyways :) I have fixed the dropping of special characters as well as the memory leak. Cheers!
No, you haven't fixed the memory leak. rb_refstring_get_titlecase still returns an allocated string, which rhythmdb_entry_get_string still returns. The caller of rhythmdb_entry_get_string never frees the string it receives, so this still leaks. To fix the leak you'd need to add a title cased version of the string to the RBRefString structure.
*** Bug 587791 has been marked as a duplicate of this bug. ***
Holy crap.
We shouldn't be trying to update the user's tags based on their case - they may want them that way. No other music manager that I'm aware of (I've used Rhythmbox, Banshee, iTunes, Zune and Windows Media Player) do that because it's contrary to what the user expects to happen when they import their library. Rhythmbox is just a manager - its sole job is to interpret the existing tags, not what it thinks the user wants them to be.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/37.