Dear all,
I experienced several times, and in a recurrent way, issues with folder or file names that contain accented characters that were not accepted by the Mac, and created many problems with the import procedure of Audirvana.
There are cases where some tracks are not recognised, some where the directory cannot be entered, or even situations where no new albums are recognised because some of them have the issue with the accented characters.
This is due to the way those characters are encoded in UTF-8: in short, Linux file systems use NFC where MAC FS choose NFD.
If you don’t want to manually correct all file names, the following solution will work: use of rsync to copy and convert the files from the NAS to the MAC, and then copy the converted files to the NAS.
The command to be used is (On the MAC):
rsync -a --delete --iconv=UTF-8-MAC,UTF-8 ‘user@NAS_address:<Nas_directory>’ /Local_directory
I tested it and that works perfectly (Using a Mac Mini and a Syno).
I’ve encountered a problem with accented filenames just then with local files on the Mac. The accented character is in a directory name. Everything about this directory and its contents functions normally, and I can play the tracks in Finder using QuickView. Audirvana finds the directory and all its tracks, and displays them properly incl. artwork. Only when trying to play any of the tracks I get:
Hi,
What’s strange in your case is that you are talking about local files (So you mean files on the local hard drive or SSD) and not files on a NAS. What is very strange is that you are able to open the files and play them from the finder but from AS.
But anyway, the whole thing is certainly due to a “wrong” or at least incompatible encoding of the accented characters.
Maybe you got thos files from an external sources and copied them to the MAC without changing the file names and correcting the wrong encoding.
If possible you should try to copy them again from the source using the rsync command I mentionned above, just to see if that changes the result and if you are able to play those files using AS.
I encountered the very same problem with a Zapitti Media Player where sometimes video files are visible at the Zappitti level but are not playable until you rename the files as you did. So, this is not an AS specific error.
I ripped this CD myself using iTunes. After renaming the directory to the non-accented name I renamed it back, typing á using the keyboard (by holding down a), like I did just now. The issue promptly returned.
OK, looks like to me that the accented chars are not properly handled at the database level by Audirvana.
My conclusion is that the path names stored in the database are badly encoded when they contains accented chars. As a result, when AS tries to load the audio file, it uses the wrongly encoded path name that does not match the real path as seen by MacOS through the finder.
Maybe this has something to do with the way SQLite is configured by Audirvana. I know that there are configuration parameters to tell SQLite how to handle UTF-8 chars.
That’s what I thought, but I find this almost unimaginable. Isn’t France the home of Audirvana? It’s virtually impossible that issues with accented characters would have gone unnoticed by the developers.
Perhaps it has to do with the locale Audirvana is running in. My locale is “en_AU.UTF-8”. The issue may not manifest itself if the locale is “fr_FR.UTF-8” or something like that.
Yes, that could be surprising indeed, altough accented chars are not only used in French.
I found this on StackOverFlow that clearly explains why sometimes problems can arise due to the way accented chars are represented in UTF-8.
Actually, problems stands with the possibility to represent accented chars in two different ways in UTF8, as explained in this post (macos - Different utf8 encoding in filenames os x - Stack Overflow)
Here I quote:
" Unicode allows some accented characters to be represented in several different ways: as a “code point” representing the accented character, or as a series of code points representing the unaccented version of the character, followed by the accent(s). For example, “ä” could be represented either precomposed as U+00E4 (UTF-8 0xc3a4, Latin small letter 1 with diaeresis) or decomposed as U+0061 U+0308 (UTF-8 0x61cc88, Latin small letter a + combining diaeresis).
OS X’s HFS+ filesystem requires that all filenames be stored in the UTF-8 representation of their fully decomposed form. In an HFS+ filename, “ä” MUST be encoded as 0x61cc88, and “ö” MUST be encoded as 0x6fcc88."
In a nutshell, when you have file names originating from an external OS (Linux for example) or stored in a DB using Mysql (With AS for example) and used in a MAC environment, you could have problems as far as I understand it.
But, not being an expert in that field, I could be wrong. Thing is that I noticed several cases (With my setup and in different context as well) where the problem is surfacing.
On my case, just to be sure that no problems will occur, I always convert all files to be imported in AS in UTF-8 represented in the MAC way. Since I did that, no problem occured with those accented chars.
It gets worse. I now discovered that none of the albums in my local library play anymore if they have accented characters or umlauts anywhere, even in the artists’ names. All of these used to play without issue for years. This is definitely a new bug introduced with version 2.3.0. @Antoine
I can’t rule it out. However, the tracks still play fine in Apple Music, Finder and QuickView. In fact, the only way of changing the umlauts and accented characters is by editing the metadata in Apple Music. Audirvana will not let me do it (it looks like it does, but the metadata remains unchanged).
It doesn’t seem possible to revert to the previous version of Audirvana, to test it there.
I understand your comment on this accented situation but for the time being, I have not been able to reproduce what you describe. It’s not easy at all to dig in such topic and I need to make more throughout tests on my side.
Note that I’m using Ventura 13.3.1 with a Synology NAS.
No problem, thanks Antoine. That is a kind of issue that could be hard to track if you never encountered the situation.
My understanding is that accented chars in UTF8 on Mac OS (at least in HFS) are encoded in the so called decomposed form (Letter+accent).
So, for example, if you create a file named ‘à’, it won’t be listed among files with only one letter in the name as in HFS the ‘à’ contains 2 chars… That’s weird.
So I guess that if you are using files from MAC (Created on MAC) their file names are encoded in the right way (2 chars for accented chars).
If you use files coming from another plateform (Such as Linux for example), then you may have trouble. With a SMB connection, when you access files created on a PC or on Linux, I don’t know precisely how it works but I already saw the finder being confused with this (Files were appearing in the list, and then disapearing).
That’s why I always convert my files to the MAC style before importing them on AS.
Hi Antoine,
I found this article that seems to me very much clear on the topic and the kind of issues we may encounter when manipulating files stored on an SMB share from a MAC.
I’m experiencing it with my local files.
It seems to be a pretty recent situation because I don’t remember experiencing this in the past. But today, I wanted to play an album from a turkish artist, and I couldn’t play it.
Firstly, Audirvana was looking for his albums in a wrong directory (it was removing the volumes/volume_name of the directory, while the files have always been located on an external drive on this computer’s database).
Weirdly enough, while it was looking for this file in a wrong directory, the tracks were displayed in white (instead of being greyed out like when the source is disconnected). And if I disconnect the external drive, it greys the track out (but it’s still showing a local directory).
When trying to play, I get the same message as @dotnet
So I created another directory (artist name), renamed the directory to get rid of special characters, renamed the subdirectory (album name), and it can play properly. The file name still contains special characters.
In my case, the artist’s name is Barış Manço.
My directory tree is like iTunes : Artist > Album > Track.
If the Artist or the Album directory contain a special character it doesn’t work. Renaming both makes it work properly, even if the file name and the tags contain those special characters.
