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.
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.
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.
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.
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.
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…
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.
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.
