We found a way for doing it 
It needs to be better implemented in the app but it’s a first step 
Unfortunately it seems this issue doesn’t show up in the logs… I don’t know about you patifr, but it doesn’t work for me.
Since this is a character issue, I don’t know if it is any interesting, but my internal drive and external drive both run APFS.
Hi Yohmi,
On my side, I tested the new version with the logging capability. Maybe I was lucky but I did not encounter any error so far that I could track with the logfile.
To make sure that if an error occurs I would have been able to track it, I decided not to apply my usual strategy with the ‘rsync’ command. So, I copied directly the audio files to the folder declared in Audirvana and nothing strange happen.
Maybe this problem has also something to do with the Mac OS version: on my side I’m still with Catalina, applying this wise principle “if it ain’t broken, don’t try to fix it”.
Maybe you could send the original audio files to Antoine (I would be by the way also interested to test it on my own platform) to see if he can reproduce the issue.
Having the same issue with Origin.
Oddly, I found some folder/file names with accents or other non-ASCII characters produce the “Unable to open an audio file for playback” message while other files with similar characters play just fine.
This is on two different Macs, both running Ventura 13.3.1. Removing the accented character in the folder name resulted in the album playing.
Hi guys,
Thank you for your feedback on this. We are looking for a way to reproduce the issue and fix it. I hope I will be able to try reproducing it next week.
Hi there,
Hi Antoine,
I found something interesting I guess on my side. As we have now a Mac version of Audirvana with loggging capabilities, I decided to bypass my specific procedure that converts files in the UTF-8 Mac format.
So, I copied and pasted a set of four albums coming from a Linux server (My guess) to a Synology NAS, and here are my findings:
- Out of the four albums, one was not processed by Audirvana
- In the log file, Audirvana listed the album (identified the directory) but found no audio files inside.
- When I looked at the folder from the Finder, using either a SMB or an AFP connection, the folder is visible but cannot be opened (From the finder AND from the command line).
- The folder is fully visible and accessible from the NAS GUI
- When I tried to rename the folder with the NAS GUI, I noticed that the “accented e” (é or è) are made of two characters: e + "’ "(or “`”)).
- Folders name that contain accented chars made of only one char are perfectly visible and reachable from the MAC.
So, in a nutshell, problem is not AFP or SMB, problem seems to be linked to the way accented chars are built.
I did not come to a clear conclusion so far and I’m still a little lost when contemplating the facts I collected so far.
Just my two cents.
3 Likes
In addition to this, I found that:
- Apparently, on a MAC, the way accented chars are represented is the “decomposed form”, which means char+accent, which in UTF-8 gives 3 digits for a é: 65 cc 80.
- On Linux, accented chars may be represented in both the compact or the decomposed form: you may have two file names with a “é” inside but differing from their inside representation (Not possible on a MAC apparently).
- On my side, files are firt obtained from another server using the LFTP tool. If I use FileZilla on the MAC and I get the very same files from the same server, I have no problem to read them on my MAC…
Confused I am, to say the least…
2 Likes
Ok, thank @patifr for your sharing your findings.
This is something I will need to figure out next week
I’m happy to report that all my issues with playing tracks which had umlauts, accented characters etc. (anywhere in the metadata) have vanished after the recent macOS update to version 13.4.
1 Like
Good to read it!
So, it was not a problem coming from AS but something introduced in a first version of Ventura.
Thing is that, at least on my side, I have sometimes the same problem on older MAC OS versions.
What I understand is that your problem appears with files stored on disks directly under the control of a MAC, and formatted accordingly.
Mine is apparently occuring when I mount disk volumes using AFP or SMB with some files inside that comes from an external platform (Most probably Unix or Linux but TBC) with malformed accented chars.
That explains that after a conversion to the MAC format (Or a simple copy to a pure MAC volume apparently), the issue disappears.
13.4 update fixed the issue for Origin as well.
Ventura 13.4 also solved the issue in my case 
13.4 didn’t solved the issue, they repaired their fucked up
Agreed! It’s a pitty to see Apple working more and more like MS… and so many others.
Apple Engineers are too busy with the next iPhone version, they don’t care bout your character issue!
That’s the sad reality, my friends…
macOS Monterey 12.6.5.
Still unable to work properly with a €5,000 machine.
I don’t want to migrate to Ventura!
Try Monterey 12.6.8, maybe.