Hunter Karman

HK24 HEALED (2026)

(batch relinking of a fifteen-year Ableton archive)
Doc. ref: HK-HK24-HEALED-2026
Category
Tools & Infrastructure
Medium
Python, Ableton .als XML (both FileRef schemas), rsync, APFS clonefile, libfsapfs
Venue
private repository
State
complete
Tags
archiving, ableton, recovery

Ableton Live projects reference their samples by absolute path. Across fifteen years, six drives and several machines, most of mine no longer resolved: opening an old set meant a missing-media dialog and a hunt per sample, so the sets stopped being opened. This is a set of scripts that catalogues every project file on every drive, measures which sample references can be resolved, and exports the recoverable projects into a self-contained library that opens clean, without modifying an original.

Per-drive indexes feed a master catalogue of unique sets; a health scan classifies every sample reference; fully recoverable sets are exported through a staging pool and APFS clones into self-contained projects, accepted only when they open in Live.
Per-drive indexes feed a master catalogue of unique sets; a health scan classifies every sample reference; fully recoverable sets are exported through a staging pool and APFS clones into self-contained projects, accepted only when they open in Live.

Each drive is walked into a flat index of project files and audio files with their sizes. A master catalogue holds one row per .als copy on every drive, 87,736 rows, deduplicated by name and size into 10,594 unique sets. A schema census classifies each set’s file-reference format, because Live 9-era sets store paths as RelativePathElement children beside an alias blob while modern sets carry Path attributes, and the parsers read both.

For every sample reference in every set, health_scan.py classifies it as resolving project-relative, resolving absolute, recoverable (a file of the same name and size exists on an indexed drive), or gone. On the main archive drive that is 2.03 million references across 7,858 sets. A set whose every reference is resolvable or recoverable is marked fully healable.

heal_export.py plans, fetches, applies and verifies. Every unique sample the healable sets need crosses the network once into a staging pool of 121 GB. Each project folder then receives its samples as APFS copy-on-write clones, so about 233 GB of self-contained projects occupies no additional disk; the set’s references are rewritten project-relative; and the project’s own info directory is written alongside, because Live resolves relative paths only when it can find the project root. Every placed file is byte-verified against its source. The run is resumable at each phase and logs every action to a JSONL manifest. 3,345 projects were exported from the main archive and 466 from a 2019 backup drive.

For a single set, reconnect.py copies its recoverable samples into the project’s own Samples/Imported/ folder, so Live’s Locate step relinks them itself and no project XML is touched. It handles both schemas.

One of the six drives failed partway through, its APFS space manager destroyed. It was read without ever being mounted, through libfsapfs; 3,837 files were pulled by path or by inode and size-verified, and the loss among reachable files was measured at 0.05 percent.

Acceptance is in the DAW: a set counts as healed when it opens in Live with no missing-media dialog. The playable share of the main archive went from 8.5 to 51 percent. The rest is classified, not lost: name-only matches awaiting a size rule, recordings that may yet surface on an unindexed drive, reference tracks that can be re-acquired. Every mutation along the way has a per-file backup and a restore script, and nothing was deleted. The reconnect method is the basis for a planned rebuild of ableton-proj-mcp.

Last updated: 2026.10.11 22:33:12 UTChunter@hnsk.site