There is a method here worth more than the software, and it applies to any black box that processes sound.
On 10 October 2026, Austin Shijo published an account of reverse-engineering a commercial spatial audio effect on epestr.com. The result is mTvare6/saqol, “a real-time easy to use audio enhancer for Linux”, written in Rust under MPL-2.0 — created 28 February 2026, last pushed 12 October, two days after the post. We verified the repository and that the GitHub account carries the same name and links to the same blog.
The goal: a Linux equivalent of a Windows program that “processed the audio being played in real time” and “made the sound feel farther away and a bit lighter to hear”, less pressed against the ears.
The first attempt, and why it failed
The obvious route is to work out what the effect is and rebuild it. That route was taken, with PipeWire as the base, and it went nowhere.
The path ran through HRTFs — head-related transfer functions, which describe how sound from a given direction reaches each ear given the listener’s geometry. The MIT KEMAR database came first and sounded, in the author’s words, “awful”, and the reason is a good lesson: KEMAR was recorded in an anechoic chamber, so it contains no room reflections — and the room reflections were a desirable part of the effect being chased. The result “sounded cheap and more inwards to the ear”.
SADIE II, which ships room responses, “sounded much closer”. But the approach stalled anyway, and the account of why is the most quotable passage in the post:
The LLM began talking about things like “perceptual envelopment”, “late-field decorrelation”, “spectral diffusion” and “diffuse spatial energy”. … While I could hear that something was wrong, those descriptions didn’t point to anything I could understand or use to improve the effect.
That is a precise description of a failure mode worth naming. The vocabulary was real; the guidance was not actionable. A model asked to explain a perceptual deficiency in psychoacoustic terms will produce fluent psychoacoustic terms, and fluency is not a next step. The project was abandoned for a while with “no obvious direction to proceed with”.
The re-attempt: treat it as a filter and measure it
The second idea was to stop asking what the program does internally and study the behaviour of the filter.
The constraint that shaped everything: the author did not own a copy. It ran on a friend’s laptop, available briefly. So there could be no iterate-compare-adjust loop — one capture had to be enough.
That forces a nice piece of experimental design. If a filter is linear and time-invariant, its entire behaviour is one impulse response, because any input decomposes into scaled, shifted impulses:
y[n] = Σ x[k]·h[n−k] = (x ∗ h)[n]
For stereo, you need four, as a matrix: the response at each output to an impulse at each input.
| from L | from R | |
|---|---|---|
| to L | h_LL | h_LR |
| to R | h_RL | h_RR |
So a single file was generated, played through the program once, and recorded. What went into it:
- impulses at three amplitudes, in both channels — to test for level-dependent processing, since a linear filter’s response to a louder impulse must be proportionally louder
- the same impulse in both channels, then again with the right channel inverted — the outputs should equal the isolated responses added, then subtracted, which tests additivity
- a logarithmic sine sweep, steady tones and a multitone
- repeated sections, to test time-invariance — the same input later must give the same response later
- a noise segment
- clicks at the start, for alignment
- enough silence between events for responses to decay
Each item tests one property. That is what makes one playback sufficient: the file is not a recording, it is a battery of experiments bundled into ten minutes of audio.
The honest result
The checks confirmed the main surround mode was linear and time-invariant, so four impulse responses captured it completely. Convolution reproduces it exactly, and that is what saqol does.
And then:
Two other modes changed gain over time and could not be reproduced with a fixed convolution.
A time-varying system is not an LTI system, so no set of impulse responses describes it. The author does not paper over this or claim an approximation is equivalent. Two of the modes are simply out of reach of the method, and the post says so.
Why this belongs in your toolkit
The generalisation is not about audio plugins. It is this: when you want to replicate a black box’s behaviour, measuring is often cheaper and more reliable than inferring — and the measurement is only valid if you first test the assumptions that make it valid.
The sequence is the reusable part. Hypothesise the system class (LTI). Design stimuli that would falsify that hypothesis if it were wrong (amplitude scaling, additivity, repetition). Run them in one pass. Confirm. Then capture. And when a mode fails the falsification test, report it as unreproducible rather than shipping something that sounds roughly similar.
For interface work specifically, it is also a reminder that the thing being modelled was a perceptual effect — “farther from the ears”, “less blocked after listening for a while” — and that the successful approach treated it as a measurable signal transformation rather than as a perceptual theory. The subjective target was real. The route to it was arithmetic.
Sources
- Reverse engineering a commercial spatial audio effect — epestr.com
- mTvare6/saqol — GitHub
- Reverse engineering a commercial spatial audio effect — Adafruit
- SADIE II HRTF database, University of York
- PipeWire