did a little inspect via sqliteviewer.app. found a strange behaviour on those two tracks. this only refers to the filename (title column is normal).
if im searching for “mö” via the filename column, the one added via lexicon (the one that ist not working) can be found, while the track that is working on the sc6000 can’t be found. the both appear with “ö” on the viewer, but the working one can’t be found typing “ö”.
The thing with the umlaut is that there are 2 versions of that character. Try pasting them into this website: https://unicodelookup.com/
It should show one combined character and one with 2 characters.
It’s always a pain properly supporting them and I thought Lexicon did support them the same way Engine does but for some reason it is different on your computer.
To confirm the problem you can try replacing the ö from the red track with the one from the working track. Then we are a step closer at least.
Finally managed to look it up.
“ö” is created by lexicon by combining “o” and “combining diaeresis 01410 776 0x308 ̈”
(via unicodelookup)
to me that looks overcomplicated as there exists “ö”: “latin small letter o with diaeresis 0366 246 0xF6 ö”
i can actually reproduce it on two different macs. one intel one m-series. replacing the combined one with ö, solves the problem.
is there a way that lexicon doesn’t write combined values to the database? As there are existing true ones? i think this is the underlying problem with all french special characters as well.
Lexicon has 2 locations for tracks, one is the original location and one where it has proper unicode characters (that one is used to prevent duplicates).
Lexicon uses this to convert those characters to their single character unicode version.
So Lexicon uses the single characters in the database and that’s also what it uses when copying files to the Denon hardware, so those filenames should have the single character.
As far as I know, that should match and I’m not sure I should just change it not to use those single characters…
ok. as someone who has virtually no knowledge of coding (apart from a bit of r studio statistics) i tried to follow your article and look into unicode composition and decomposition.
in the end, i think i see decomposed values for all special characters in my database. according to this article, there are several ways to perform composition in the context of normalization (NFC, NFKC). are there any possibilities here?
I’ll try something again, I have an idea that might be good to check
1 Like
Well upon further research I discovered that the problem mostly lies with Engine. It doesn’t properly support combining characters at all. In Engine desktop it shows these characters:
Where it should display both Ë
And the other thing it does to “handle” tracks with a combining character, it just doesn’t use them on the filesystem 
It does support combined (one char):
But if it has to use a combining char (so 2 chars) then it just doesn’t use the artist/album name anymore but goes to this:
So I guess I have to change Lexicon to work in the same broken/stupid way for Engine and hopefully we can get this behind us.
More soon.
1 Like
Next beta update will have a change in the Engine exporter that should hopefully fix this finally. Be sure to test it thoroughly 
1 Like
Will do! Sitting here eagerly awaiting it!
Sorry to hear that engine is the problem.
Is there a reason why the direct sync to the player happened without problems?
Actually I’d like to skip engine completely - the direct sync from lexicon is just perfect - except obligatory loading of waveforms on the player… - when there’s a possible workaround I’m the first one to use it!
Thanks a again for your outstanding user support regarding this topic!
Beta update online now
Did a quick test with erased harddrive on the sc6000. Unfortunately red tracks. Will do a reset of the engine library on the computer and further inspecting after work.
I have now tested it extensively - deleted the engine database on the computer and sc6000, everything new - unfortunately lexicon still writes o + ̈.
What does the folder structure on the SC look like? If those are double characters, then it they should be in an Unknown Artist folder
here it is (from the sc6000)!
m.db (688 KB)
Check the ö in the folder name on unicodelookup, is it a single character or two characters? Should be single…
Do the same for both the ö in the filenames. If either of those is the double character, maybe that’s it then.
I don’t get it…
when I check the file with Mac OS finder or mp3tag (filename, artist, track name):
always single ö latin small letter o with diaeresis 0366 246 0xF6 ö
when I check the filename in the engine library database with db browser for SQlite:
clearly double character ( o + ̈ ) as in the picture (but only the filename!).
I think the the problem lies in how the entries are written to the database…
for example, I have to type in “mo…” to find the files, because it is written as “mo ̈dern” into the database. typing “mö…” will show no results
Odd because the way it is in the db comes from the filename… I’ll check again, but will be later next week
1 Like
Okay, I’ve found yet another small issue there, this time it was Mac only (applying the fix to Windows would actually break it on Windows). Will be in the next beta update, this week.
1 Like
Hey Christiaan, unfortunately the latest beta does not change anything at all. Still red tracks, and still ö ist written as o + ̈ to the database.
As usual I wiped the ssd of the sc6000 and the engine database on my Mac…