Audacity 4 can't open a file with diacritics in the name

Newrone · September 13, 2026, 3:12am

Very first test of Aud4 & it couldn’t open the file!

Apparently because the name of the file has diacritics (accented characters) in it.

Presumably this will be prioritised in a later update as it applies to most of the non-English-speaking part of the world?

billw58 · September 13, 2026, 1:37pm

It looks like the devs are on top of this.

github.com/audacity/audacity

Audacity 4.0 No puede abrir archivos con caracteres del español como "á"

opened 07:46PM - 06 Sep 26 UTC

holasoyalecito-cyber

bug

### Bug description Al intentar abrir un archivo de Audacity 3 (aup3) que conti…ene caracteres especiales luego de la conversión a aup4 dice: "no se puede leer el archivo (ruta) El Archivo (ruta) no se encuentra o no esta accesible..." ### Steps to reproduce 1. Crear un archivo en Audacity 3 y guardar con un nombre que contenga un acento (´) por ejemplo 2. Abrir el Archivo con Audacity 4 y esperar la conversión 3. Luego de la conversión abrir el archivo (aup4) 4. Sale el error No se puede leer ### Expected behavior Poder tener proyectos con los caracteres del español ### Actual behavior No se puede tener un proyecto con los caracteres del español ### Audacity Version Audacity 4.0.0 ### Operating system Windows ### Additional context _No response_ In English: Operating System: Windows 11 Version: Audacity 4.0.0 Bug: When trying to open an Audacity 3 (aup3) file that contains special characters after converting to aup4, it says: "Can't read the file (path) The file (path) is not found or not accessible..." Expected Behavior: Being able to have projects with Spanish characters Actual Behavior: You can't have a project with Spanish characters

github.com/audacity/audacity

Decode command line arguments as UTF-8 so non-ANSI project names open (#11985)

master ← jonata:fix-nonascii-path-argv

opened 08:55PM - 05 Sep 26 UTC

jonata

+3 -2

Resolves: https://github.com/audacity/audacity/issues/11976 Related: https://git…hub.com/audacity/audacity/issues/11973 Project names containing characters outside the Windows ANSI code page — Cyrillic, Japanese, CJK generally — could not be opened. ### The defect `prepareArguments()` decoded `argv` with `QString::fromLocal8Bit()`, but every producer hands it **UTF-8**: | Producer | Encoding | |---|---| | `main.cpp:137` — `CommandLineToArgvW` → `QString::toUtf8()` | UTF-8, with a comment saying it does this to avoid losing non-ANSI characters | | `guiapp.cpp:41` — `muse::StringList::toStdStringList()` | UTF-8 | | POSIX `argv` | UTF-8 | `main.cpp:195` reads *the same buffers* back with `fromUtf8()`. The parser was the only place reading them as something else. On Windows in Qt 6, `fromLocal8Bit` decodes with the process ANSI code page, so the UTF-8 bytes of `тест.aup4` are re-read as CP1251 and become mojibake — which is exactly what #11976 describes ("Audacity tries to access the file using a corrupted (mojibake) filename"). Off Windows this changes nothing at all. From Qt 6.10.1's own header: ```cpp struct Q_CORE_EXPORT QLocal8Bit { #if !defined(Q_OS_WIN) || defined(QT_BOOTSTRAPPED) static QString convertToUnicode(QByteArrayView in, QStringConverter::State *state) { return QUtf8::convertToUnicode(in, state); } #else ... // system ANSI code page ``` So `fromUtf8` is correct on all three platforms, and a no-op on two of them. Three routes reach the parser and were all affected: double-clicking a project, the single-instance handoff (`guiapp.cpp:162`), and the in-app route that opens a project in a new window when one is already open (`projectactionscontroller.cpp:997`). `QTextCodec::setCodecForLocale(UTF-8)` in `main.cpp:127` does **not** protect against this. It is a Qt 5 mechanism; Qt 6 routes `fromLocal8Bit` through `QStringConverter::System` inside QtCore, which never consults `QTextCodec` (a separate Qt5Compat module). It is worth deleting, but I have left it alone here rather than widen the change. ### Second commit: a dangling buffer on the same open path While tracing this I found unrelated but real UB in `DBConnection::OpenStepByStep`: ```cpp const char* name = fileName.ToUTF8(); // buffer freed at the end of this statement int rc = sqlite3_open(name, &mDB); // ...then read here, and again at line 199 ``` `ToUTF8()` returns a `wxScopedCharBuffer` by value; where `wxString` is not internally UTF-8 (Windows, macOS) it owns its memory. It usually survives because nothing allocates in between, which is why it has not been obviously broken — but it is a read of freed memory on the path that opens every project. `ProjectFileIO::ReadThumbnail` already does this correctly by calling `uri.ToUTF8().data()` *inside* the call. ### On #11973 — why "Related" and not "Resolves" #11973 (Cyrillic name, fails on first attempt, works on the second) is very likely the same defect: the in-app new-window route sends the path through the parser on the first attempt, and the second attempt — with no project open — opens in-process and never touches it. That fits the reported asymmetry exactly. But the second screenshot in that issue shows the Cyrillic name rendered **correctly** in "Failed to open database file: …тест.aup4", which is not what a mojibake path would produce. So either the message is built from a different string than the one used to open, or something else is involved — possibly the dangling buffer above. I have not claimed to resolve it. ### Verification, and its limits Both reports are Windows-only and this was developed on Linux, where `fromLocal8Bit` is already UTF-8 — so I **cannot demonstrate either fix working**. What I can show: - The mechanism is fully determined by the Qt 6 source quoted above. - Building and opening a Cyrillic-named file on Linux still works (`Open(…тест.wav) succeeded`), confirming no regression where the code path was already correct. - `ctest` green, codestyle clean. **This needs testing on Windows with a non-ANSI project name before it should be trusted.** - [x] I signed [CLA](https://www.audacityteam.org/cla/) - [x] The title of the pull request describes an issue it addresses - [x] If changes are extensive, then there is a sequence of easily reviewable commits - [x] Each commit's message describes its purpose and effects - [x] There are no behavior changes unnecessary for the stated purpose of the PR Recommended: - [x] Each commit compiles and runs on my machine without known undesirable changes of behavior QA: - [ ] Testflow test cases have been run