Audacity AUP vs AUP3 Project Files Explained

Audacity transitioned from its legacy .aup format to the modern .aup3 format with the release of version 3.0.0, fundamentally changing how projects store and manage audio data. While the legacy .aup format relied on a split system combining an XML document with a directory of thousands of fragmented audio blocks, the .aup3 format consolidates the entire project into a single, unified SQLite 3 database. This architectural shift eliminates project breakage from missing files, enhances data integrity, and simplifies file management.

The Legacy .aup Architecture

The legacy .aup format is not an audio file; it is an XML file that serves as an index for the project's structure.

The Pointer File (.aup): This file contains project metadata, track arrangements, envelope points, labels, and references pointing to the audio blocks stored elsewhere.
The Data Folder (_data): Alongside the .aup file, Audacity created a companion folder named <ProjectName>_data. This folder housed audio data split into small, uncompressed segments, typically around six seconds each, stored as .au files organized across multiple subdirectories.

Because the XML file and the _data folder had to exist in the exact same directory and maintain matching names, projects were notoriously fragile. Moving, renaming, or deleting the _data folder severed the links, causing "missing audio block" errors and project corruption.

The Modern .aup3 Architecture

The .aup3 format replaces the multi-file architecture with a self-contained, relational database powered by SQLite 3.

Unified Storage: All metadata, envelope information, edit history, and raw audio samples are stored as binary large objects (BLOBs) inside a single .aup3 file.
Temporary Working Files: While a project is open, SQLite creates temporary cache files in the same directory (such as .aup3-wal for write-ahead logging and .aup3-shm for shared memory). These allow fast read and write operations and protect against data loss in the event of an unexpected crash. They are automatically merged and removed once the project is safely closed.

Key Structural Comparisons

Feature	Legacy `.aup` Format	Modern `.aup3` Format
File Structure	Multi-file (XML `.aup` file + `<ProjectName>_data` folder)	Single-file (SQLite 3 relational database)
Audio Block Storage	Fragmented `.au` files in deeply nested subfolders	Compressed or uncompressed BLOBs inside the database
Portability	High risk of data loss when moving or renaming files	Easily moved, copied, or backed up as a single unit
Integrity & Recovery	Prone to orphan blocks and broken relative paths	ACID-compliant transactions prevent silent data corruption
Disk Space Behavior	Deleting clips instantly removed `.au` files	Database maintains allocated space until compacted/saved

Operational Impact

The move to .aup3 eliminates the primary cause of corrupted projects in older versions of Audacity. Because SQLite uses write-ahead logging, transactions are atomic; an incomplete write during an operating system crash will roll back safely rather than leaving an inconsistent set of orphaned block files.

However, because .aup3 acts as an active database, working across external drives or network storage can cause latency or file-locking conflicts. For optimal performance, .aup3 files should be opened and edited on local storage drives.