Project
DAW Toolkit
An offline toolkit for music project files. It decodes a proprietary binary format with no host application running, measures what actually differs between two mixes rather than trusting a description of the difference, and builds plugin chains from the command line.
It is 3am and I am reading a file format in a hex editor, looking for the four bytes that mean "volume".
I want to be clear that I never set out to reverse-engineer anything. I set out to avoid clicking. I had a few dozen projects carrying the same dull mistake, and fixing it properly meant opening a few dozen projects. So I opened none of them and started reading the files instead.
That was the lazy option. It has not stopped yet.
What it is
A toolkit that reads music project files offline. No DAW running, no GUI automation, no script inside the host, works on any machine.
It rests on one small idea. Plugin settings are per plugin and per track, so they have to be stored in the file. If they are in the file, the program is optional.
The rest is a decoder that proves its own decode, a measurement engine that separates level from tone, and a template generator that writes plugin chains into new project files from the command line.
What measuring actually found
- Six of eight renders were over 0 dBTP with limiters on them.
- One was +0.6 dBTP with a true-peak limiter enabled. The limiter’s own saved settings explained it: four gain stages sat after it. A limiter with gain after it is furniture.
- Another measured 0.70 correlation in the low mid, with a widener engaged on the master. A master widener decorrelates everything, including the band that carries the weight.
Not one of those was a plugin problem. All three were ordering problems, and all three were invisible from the mix bus.
The part where it stopped being funny
The file format was read off the bytes. There is no specification, so the framing came from finding a known string in the payload and counting. The acceptance test is that the events consume the payload exactly. Not approximately. Not with a remainder nobody looks at.
An earlier version searched five candidate framings. I deleted it rather than keep it, because the alternatives are all wrong and one of them winning silently is worse than no decoder at all.
Where the laziness paid
A plugin chain can be assembled from bytes. A plugin has to exist in a file once before it can be copied, but after that it can be cloned into any slot, on any track, in any project, with no GUI at all. A template stops being something you build by hand and becomes a list of (track, slot, plugin, source) operations that a script applies. Every step is gated, and the run stops at the first failure rather than handing you a half-built file.
That is the part I would point at. It exists because I could not be bothered to open forty projects.
What it got wrong, four times
- I believed a third-party reference that said a vendor’s package format was a ZIP. I built one. The host ignored it silently. There is no error to read, which makes it the worst failure mode available.
- I wrote a test harness whose mock was kinder than the real host. It returned a device list where the live host returns nothing. The harness stayed green while the real script crashed.
- I shipped a "read-only" audit that rearranged the interface on every run, and returned no new information while doing it.
- I built the same template twice by taking a channel strip out of a finished song, because I assumed any instance of a plugin was a neutral one. It is not. A measurement settled it: most of those instances were byte-identical, and the one I had been copying was the one that was not.
Every one of those is the same mistake wearing different clothes. Believing an output instead of checking it.
Status
Working, and in daily use. The decoder, the measurement engine and the template generator are all doing their jobs.
What is not finished gets named rather than implied. Per-track level and equaliser values are still unidentified in the format, so the tools can read a chain but cannot yet tune one. One project file has a section that resists the known layout and I have stopped arguing with it. And the second DAW’s scripting interface exposes no way to read or write an effects chain at all, which is a boundary rather than a puzzle I intend to keep poking.
There is no link to the source here. It is in a private repository, because it was built around a personal music catalogue and the code carries enough of that to be nobody else’s business.
I still have not found the four bytes.
Tech stack
Python / PowerShell / JavaScript / binary format decoding