Recover a corrupted .aup4 or .aup3 project
Error code 11, error code 101, or a crash before you saved — the recording is almost always still inside the file. This page checks the database, finds the newest usable copy of the project, fills the gaps, and hands the audio back. Nothing is uploaded.
Can a corrupted Audacity project be recovered?
Usually a large part of it, yes. Audacity stores audio in immutable blocks and never rewrites one, so damage tends to hit the database structure or the project document rather than the audio itself. Recovery means finding a document that still decodes — the saved one, the autosave copy, or an earlier generation Audacity 4 keeps in the file — listing which blocks can still be read, and rebuilding a project from those. Blocks that are genuinely gone become silence, and the report says exactly how much.
Drop the damaged project, or the .aup4unsaved / .aup3unsaved file Audacity left behind.
The integrity check runs on your machine and reports what survived.
Play the recovered mix and export it, free.
Pro rebuilds a clean project Audacity opens, or rolls back to an earlier save.
What the recovery report looks like
An unretouched screenshot of this site in Chrome 154 on macOS 27, 7 October 2026. The project in it is a test file from Audacity's own source repository — the same file this site's automated tests open.
Recover a corrupted .aup4 or .aup3 project
Audacity's own recovery utility, audacity-project-tools, is a terminal program. It gained a macOS build in January 2026, its support article asks for roughly four times the project's size in free disk space, and it was written for .aup3: a 4.x version stamp is treated as broken, and it reads only the project and autosave tables, not the earlier saves Audacity 4 keeps inside the file. This page runs the same sequence of checks in the browser: the SQLite integrity check first, then a fallback from the saved document to the autosave copy and on to the earlier saves Audacity 4 keeps inside the file, then a census of which audio blocks can actually be read.
Checking the project, playing what survives and exporting it are free; rebuilding a clean project file and rolling back to an earlier save are Pro.
On a Mac? Audacity's own recovery utility only gained a macOS build in January 2026, and it is still a terminal program that asks for about four times the project's size in free space. Everything on this page runs in the browser instead, on any operating system.
How an Audacity project breaks, and what is left
A project is an SQLite database, and SQLite reports two failures Audacity surfaces by number. Error code 11 means the database structure itself is damaged: a page that should hold part of a B-tree does not, usually after a crash mid-write, a full disk, or a drive disconnected before the write was flushed. Error code 101 means the structure is fine but a row the project points at is not there.
Underneath both, the audio is unusually resilient. Audacity never updates a sample block — every edit writes new blocks and repoints the document — so blocks that were written successfully stay valid even when later writes failed. It is common for the whole recording to be readable in a file Audacity refuses to open.
There are also up to three chances at the document. `project` holds the last save; `autosave` holds the copy written after every edit, which is what Audacity offers to restore after a crash; and Audacity 4 added `project_history`, a handful of earlier saves kept so a bad document can be rolled back. Recovery tries them in that order and reports which one it used.
Rebuilding writes a fresh database with the chosen document and only the blocks it references, so unused blocks left over from editing are dropped at the same time. References to blocks that cannot be read are rewritten as silent runs, which is how Audacity itself represents silence — a non-positive block id meaning that many samples of nothing.
One refusal is not damage at all. Audacity 4.0.0 on Windows decodes a project path handed to it on the command line with the system ANSI code page rather than UTF-8, so a name or folder with Cyrillic, Japanese, Hebrew or accented characters is mangled before the file is ever opened, and Audacity reports it as unreadable or not found. It happens to an .aup3 opened for conversion as much as to a saved .aup4. The integrity check here passes on such a file, because the database was never touched — the parser fix, Audacity pull request 11985, was merged into master on 15 September 2026 and the maintainers' wider code-page fix, pull request 12115, on 17 September, and both shipped in Audacity 4.0.1 on 30 September.
- Not corruption
- Audacity 4.0.0 on Windows fails on paths with non-ASCII characters (fixed in 4.0.1, 30 Sep 2026: PR 11985 and PR 12115)
- Error code 11
- Database structure damaged — a page failed to read
- Error code 101
- A referenced sample block row is missing
- Document copies
- project · autosave · project_history (Audacity 4)
- Audio durability
- Blocks are immutable; written blocks stay valid
- Gaps
- Unreadable blocks become silent runs, and are counted in the report
- Compaction
- Blocks no clip references are dropped from the rebuilt file
- Official tool
- audacity-project-tools — terminal only; macOS build since v1.0.5 (January 2026); written for .aup3
- Companion files
- <name>-wal holds edits not yet copied into the project; -shm is the log's index. Keep them with the project; a clean close merges and removes them
New to the format? What an .aup4 file is, table by table — and how it differs from .aup3.
Sources
Where the facts on this page were checked. Audacity's code is cited at the tagged release it was read from.
- audacity-project-tools README (Audacity) — Error codes 11 and 101 as Audacity reports them, the recovery command order (-drop_autosave, -check_integrity, -recover_db, -recover_project, -compact), and that Audacity never updates a block. The tool reads the project and autosave tables only; there is no project_history handling.
- audacity-project-tools v1.0.5 release notes — macOS support arrived in this release on 27 January 2026, with the supported project version raised to 3.7.
- AudacityDatabase.cpp in audacity-project-tools — MaxSupportedVersion is 3.7.0.0; a project whose major version is not 3 is reported as a broken user_version and clamped to that ceiling, and the recovered copy is written with it.
- Audacity support: Recovering corrupted projects — The four-times-the-project-size free disk space guidance and the 15–30 minutes per GB estimate. The article still says macOS is not supported, which the v1.0.5 release superseded.
- SQLite result codes — 11 is SQLITE_CORRUPT, the database disk image is malformed. 101 is SQLITE_DONE, what a query returns when no row matches — which is why Audacity reports it for a missing block.
- SqliteSampleBlock.cpp, Audacity 3.7.9 — Silent blocks are encoded with a non-positive block id, the representation a rebuilt project uses for audio that could not be read.
- Audacity pull request 11985: decode command-line arguments as UTF-8 — Why Audacity 4.0.0 on Windows cannot open a project whose name or folder path has characters outside the ANSI code page: the command-line parser decoded the path with fromLocal8Bit instead of UTF-8, which on Windows in Qt 6 is the system code page. Double-clicking a project, the single-instance handoff, and opening a project while another is open all go through that parser; macOS and Linux are unaffected. Approved by a maintainer on 10 September 2026 and merged into master on 15 September (merge commit e24c106), and shipped in Audacity 4.0.1 on 30 September, whose command-line parser decodes with fromUtf8. Its second commit fixes a separate read of freed memory on the same open path: DBConnection::OpenStepByStep took a char pointer from a temporary UTF-8 copy of the path that was released before sqlite3_open read it — an owning buffer on Windows and macOS, where wxString is not UTF-8 internally, as the pull request notes.
- Audacity issue 12004: accented characters in the project path — An accented letter in a parent folder alone (D:\Téléchargements) makes Audacity 4.0.0 report the project as not found or not readable, on an already-converted .aup4 as well as on one converted from .aup3.
- Audacity issue 11973: Cyrillic project name fails on the first try — The dialogs users see — "Unable to read file" and "Failed to open database file" — and the report that the same project opened on a second attempt, which the fix attributes to File → Open with no project open bypassing the command-line parser.
- Audacity issue 12124: an .aup3 with a Japanese name fails in Audacity 4 on Windows 11 — The refusal is not specific to .aup4: an existing .aup3 named 録音テスト.aup3 could not be opened, its path shown garbled in the error dialog, while the same file renamed to test.aup3 opened and converted. A maintainer asked the reporter to try a build of pull request 12115.
- Audacity pull request 12115: fix codepage conversion issues — The maintainers' own Windows code-page fix, opened 10 September 2026 and approved 11 September: input device names, metadata fields, translated undo entries, the recent-files records written after opening a project from a non-ASCII path, export error messages, effect preset names and the ffmpeg path. It does not touch the command-line parser, which pull request 11985 changes. Merged into master on 17 September 2026 (merge commit df54269); its last commit, added that day and titled "Fix a crash when canceling a recovery", changes ProjectFileIO::LoadProject so a project with no saved document and no usable autosave is marked temporary and keeps its file name instead of leaving the connection uncommitted. Shipped in Audacity 4.0.1 on 30 September 2026.
- Audacity 4.0.1 release notes — Released 30 September 2026. Its bug fixes include opening projects and files with non-ASCII characters in their name or folder (issues 11973, 11976, 12004 and 12057) and other non-ASCII text issues on Windows — the release that carries both pull requests above.
- DBConnection.cpp, Audacity 3.7.9 — The project connection is configured with journal_mode = WAL and wal_autocheckpoint = 0, so SQLite never checkpoints on its own; Audacity installs a WAL hook that wakes its own thread to run passive checkpoints, forces a truncating checkpoint when the connection closes ("moves data from wal to main project file"), and when a checkpoint fails with a full disk shows "Disk is full" naming the <name>-wal file. Audacity 4.0.0 carries the same code under au3/libraries/au3-project-file-io.
- ProjectFileIO.cpp, Audacity 4.0.0 — AuxiliaryFileSuffixes lists the companion files Audacity renames and deletes with a project: -wal always, -shm only on Windows (NO_SHM is defined on every other platform). MoveProject moves them with the project because they "might yet exist, as when checkpointing failed for limited space on the drive … or else lose data", and the Audacity 4 thumbnail reader opens a project with immutable=1 precisely so that no -wal or -shm is created.
- SQLite: Write-Ahead Logging — When the last connection closes it checkpoints and deletes the WAL and its shared-memory file; a database separated from its WAL file can lose committed transactions or be corrupted; the WAL is part of the database's persistent state and must travel with it; and the first connection after a crash runs recovery.
audacity-project-tools vs Waveward
| audacity-project-tools | Waveward | |
|---|---|---|
| Runs on macOS | Since v1.0.5 (January 2026), from the terminal | Yes, in any modern browser |
| Install needed | Download and run from a terminal | None |
| Free disk space | About four times the project size, per Audacity's support article | None beyond the download you save |
| .aup4 projects | Treats the 4.x version stamp as broken and writes the recovered copy as 3.7.0 | Read as Audacity 4 projects, earlier saves included |
| Reads the autosave copy | Yes | Yes, and Audacity 4's earlier saves too |
| Shows what survived first | Command output after the run | A report before you commit to anything |
| Cost | Free | Free to check and export; rebuilding is Pro |
Recovering a project
Q. Audacity 4.0.0 on Windows says it cannot read or find my project. Is it corrupted?
Often it is not. Audacity 4.0.0 on Windows cannot open a project whose file name or folder path contains characters outside the system's ANSI code page — Cyrillic, Japanese, Hebrew, or an accented letter in a parent folder such as Téléchargements. Its command-line parser decodes the path with that code page instead of UTF-8, so double-clicking the file, or opening it while another project is already open, looks for a mangled name that does not exist and reports the file as unreadable or missing. An .aup3 you open in Audacity 4 hits the same wall before it is even converted: in issue 12124 a project named 録音テスト.aup3 failed on Windows 11 and the same file, renamed to test.aup3, opened and converted. The parser fix, pull request 11985, was merged into Audacity's master branch on 15 September 2026, and the maintainers' own code-page pull request 12115 — which repairs the recent-files entries, metadata fields, export error messages and preset names that the same decoding corrupts, but not the parser — followed it into master on 17 September. Both shipped in Audacity 4.0.1 on 30 September 2026, whose release notes list "Fixed opening projects and files with non-ASCII characters in their name or folder", so updating to 4.0.1 is the cure. If you stay on 4.0.0, move the project to a folder with plain ASCII names, or — per the fix's analysis of the report where a second attempt succeeded — start Audacity with nothing open and use File → Open. macOS and Linux are not affected. This page reads the project from its bytes and never looks at the path, so dropping the file here shows within seconds whether the database is actually damaged.
Q. Which errors can this recover from?
The two Audacity reports most often: error code 11, where the database structure is damaged, and error code 101, where a sample block the project references is missing. Also unsaved projects after a crash, and a saved document that no longer decodes while an autosave or an earlier save still does.
Q. What cannot be recovered?
Audio in blocks that were never written to disk — a drive that filled up mid-recording, or a file truncated by a failed sync. Those gaps become silence, and the report says exactly where they are.
Q. Is my original file changed?
No. It is opened read-only and every rebuilt project is written as a new download.
Q. There are -wal and -shm files next to my project. Can I delete them, and does this page read them?
Do not delete the -wal file, and if you move or copy the project, take it along. Audacity opens a project in SQLite's write-ahead-log mode with automatic checkpointing switched off, so every edit is committed to <name>-wal first and Audacity's own background thread copies it into the .aup4 or .aup3 in passes; the last pass runs when the project closes, and SQLite then deletes the -wal and the -shm index. A -wal still sitting beside a project means Audacity has it open, was killed or crashed with it open, or could not finish copying — a full disk is the case Audacity's code reports by name. SQLite's documentation is blunt about what separating the two costs: committed transactions can be lost. This page reads only the file you drop, never the -wal beside it, so the newest edits may be missing from what it shows: close the project in Audacity first, or after a crash let Audacity open it once so the log is merged, then drop the project file. Dropping the -wal itself is identified as such rather than reported as a damaged project. The -shm file is the shared-memory index SQLite uses to coordinate access to the log; Audacity's own list of files it renames and deletes together with a project is -wal on every platform and -shm on Windows only.
Q. Why is rebuilding a paid step when the export is free?
The export gets your audio out, which is the urgent part. Rebuilding produces a project Audacity opens again with its clips, tracks and structure intact, and that is the part that takes real work to get right.
Free to open, play and export the stereo mix for projects up to 256 MB; larger projects still open and play free, and downgrading to .aup3 is free up to the same size. Recovery, per-track stems, and exports or downgrades above that size are a one-time $19 license — no subscription, no recurring fees.
Every job an Audacity project needs
Same local-first engine, one page per task.