My question here is not about how to convert or strip accents from tags going to ID3.
Instead it is about working with the "Search Discogs" feature when your song or artist etc. name includes accents.
Example: Mp3tag's Discogs-search for "Ace of Spades" by Motörhead fails to find "Motörhead" (requiring instead the plain-ASCII form "Motorhead") but then when it does match, it returns "Motörhead" as artist-name. Facepalm... I don't blame Lemmy (RIP) and anyway I have similar issues with French songs etc. (and I prefer to keep the accents).
Question/Suggestion: Is it possible to strip accents only in the search-string going from Mp3tag to Discogs, given Discogs doesn't seem to like them? Would this be a reasonable and practical feature request?
Oddly, this morning (unlike last night) it works: "Motörhead" is now being accepted as artist name in Mp3tag's Discogs-search - in the sense that it is now returning the expected results (not just a blank).
I wonder if something has been changed at Discogs (perhaps they read this forum?) or in Mp3tag.
Still doesn't work for the French accent in this artist-name though
- Mylène Farmer
Only works when I change the "è" to an "e".
It would be handy if Mp3tags did that automatically before sending the request to Discogs (etc.)
Honestly, if this were a common problem that non-ascii character should cause problems with discogs, corresponding threads would have been opened.
Could it be that you save ID3V2.3 tags in ISO encoding and not UTF-16?
Or that you have old files where this was so and now that you have updated them, they are encoded with UTF?
I have Mp3tag configured to save UTF-16.
All I am doing is putting in the artist and title, from the filename, via Mp3tag's "Import tags from filenames" then manually entering the album name (no accents) then doing a Discogs search (via Mp3tag's "Import Tags from online Tags sources".
Why not confirm for yourself what happens? Only takes a minute.
Example: Just give any file the tags Artist: Mylène Farmer and Title: Sans Logique
Then search (finds nothing) then change it to a normal "e" and search again.
BTW I am using the Mac version of Mp3tag, if that matters. I'll try it on Windows in a moment, and report back here.
I see the Windows variant of Mp3tag behaves somewhat differently from the Mac version (which is all I have ever used up till now). Discogs accessed via Windows-Mp3tag asks me for an authorization code, which I don't recall having had to do on the mac. Also there are more menu options, including tag sources, on the Windows one.
I will try to settle into this new environment (e.g. getting the required code) then attempt the example search.
For the Windows variant of Mp3tag, Discogs-search handles accented characters ok.
But for the Mac version, it fails in the way I described earlier.
Please can anyone else with a Mac test (confirm/refute) this?
Just give any file the tags Artist: Mylène Farmer and Title: Sans Logique
then do a Discogs-search from Mp3tag
It works here using v1.4. Can you re-check, maybe it's a different album that fails?
Thank you for testing it Florian.
I had exactly the same details (Album, Artist) as in your screenshot, but the only way I got the same listing as your screenshot was if I searched without the accented "e", otherwise no results (as before).
I have the same version 1.4 (I just now checked).
And I can see from your screenshot that it is from the Mac variant (same as mine).
This is strange.
So then I tried a few variations...
- First I tried using the MusicBrainz search-option. But it behaved the same way (apart from giving fewer results - only when the "e" was without accent, else blank)
- Next, on (what proved to be) a fruitless hunch, I tried "going German", in case that was more accents-friendly, by changing my Mac's language and region to German/Germany and rebooting, connecting by VPN into Germany, also setting my Discogs web-browser account language to German. But none of this made any difference.
Next thought I would try installing Mp3tag as portable (for the Mac), in case independence helped. But I bought it from the App store so there is no installer file I am aware of (maybe hidden away somewhere by Apple?). So then I went to your website and downloaded a fresh copy: [Mp3tag-1.4.0.zip]. This I put on an external drive and expanded to [Mp3tag.app] dated Jan 25. But when I ran it, it complained "Please move mp3tag to your Applications folder". I had hoped it would ask me if I wanted this one to be a portable installation (just for testing).
- Is there a way I can create a portable installation? Useful to know in any case.
- Is there some way to dig deeper - e.g. to generate a log of what is being sent to Discogs.
- Or is there some setting I'm unaware of that needs changing. All I do know is, unlike the Windows one, I never had to provide any Authorize Code" to grant access to Discogs from my Mac Mp3tag (in case that's relevant).
FWIW, below are screenshots from my failure ("è") and success("e").
All I did between the two was edit the artist's name in the search window (I did not exit the search window or change any tags in the main window).
Thank you for looking into this Florian. I do not like to disturb your weekend.
Just now I renamed and moved the fresh trial download to my Mac's Applications folder and ran it from there. But still the same behaviour - it likes Mylene but not Mylène.
My macOS version is 10.15.7 (Catalina) - in case that explains the difference in our test-results
There is no difference between the Mac App Store version and the standalone version. Both share the same code and are using the same settings.
I've just tried with macOS 10.15.7 (Catalina) with the same successful result.
Thank you for trying that Florian. Another hypothetical branch trimmed off.
Sans Logique indeed. There must be an explanation.
(BTW: I did not chose that so-named file with irony in mind)
Update: I may have found something - I'll report back shortly, when more certain (following more testing).
Aha! Got it - something to do with Convert from filename to tag-fields.
I first removed all ID3 tags (v1 if any, and v2), then entered dummy text for the artist and album (e.g. "a", "b") - and saved. The dummy text was merely to enable the search window to come up. I then typed in these fields' proper values (text, including the accented character) - and it worked!
However, when, instead I used Convert to populate the ID3v2 field for artist from the file name, then the search failed (no Discogs matches).
I then retried, but this time overtyping (only) the apparent "è" character in the search-box with a fresh one (complete with accent) - and then it worked!
Repeated the above two cases - with same results.
Not the same type of "è" then, despite appearances.
Good to hear this has been resolved for you. Dealing with similar appearance characters that don’t follow standard unicode can be tough to figure out.
Now what is still tough to understand - why did it work for @Florian when you sent a copy of the file to him, prior to finding this?
I'm guessing he just typed in the artist name (as I would have done), as opposed to converting from filename to tag fields. Because the latter was not known to be a factor at the time.
Oh - and I didn't send him a copy of the file - because (I had discovered by testing that) the actual file didn't matter - e.g. in one of my tests I gave fake artist ("Mylène Farmer") and album metadata to a Styx track).
The puzzle is resolved (unless proven otherwise) and a possible software issue is implied (again, I stand to be corrected).
Good catch! The difference is between
U+0065 LATIN SMALL LETTER E, U+0300 COMBINING GRAVE ACCENT
U+00E8 LATIN SMALL LETTER E WITH GRAVE
The former is a combination of two letters, while the latter is the actual letter with accent grave. The problem results from macOS file system enumeration returning URLs that use the former variant while Discogs requires the latter.
I'm using Unicode Normalization Form C in most of the areas of Mp3tag to prevent such problems, but some of the macOS APIs switch back to the representation with the combining character.
I'll try to find a solution for the next release. Thanks for taking the time to research this problem so thoroughly!