Repository navigation
v1.3.1
Download
Ready to run - the filters are already inside. Unzip, run aura-engine.exe, drop a track on it. The app opens on the filter that came with it.
| Bundle | Filter | Output rates | Size | |
|---|---|---|---|---|
| Compact | 5k taps | every FS multiplier (FS2-FS16) | 7 MB | Download |
| Starter | 1M taps | every FS multiplier (FS2-FS16) | 135 MB | Download |
| Standard | 10M taps | FS8 (352.8 / 384 kHz) | 327 MB | Download |
| Reference | 30M taps | FS8 (352.8 / 384 kHz) | 967 MB | Download |
Unzip more than one into the same folder and the app offers every tap count you have.
Already have the filters, or want to build from source? The plain app zip is below, and the individual filter packs are on the 1.0.0 release.
Checksums (SHA-256)
4cc79b5625276b395ca25465834082f8072b34a1c3df8e90522372de739f58ba aura-engine-v1.3.1-bundle-5k-windows-x64.zip
4e8dcb4244e993e93b2da8f2f95008db1847696e954d8763659f4e1cae6a96c1 aura-engine-v1.3.1-bundle-1M-windows-x64.zip
a68a2f36b53f891e1401b50d94a1128168bde98abb475bac7ea687160afda078 aura-engine-v1.3.1-bundle-10M-windows-x64.zip
60e38af22c9a6c637d4cca67536659125497363cc9bc828141ef8557794cdf57 aura-engine-v1.3.1-bundle-30M-windows-x64.zip
What changed in 1.3.1
Nothing here changes what comes out. It changes how long you wait for it.
Two of the most expensive stages in the pipeline were each using a single
thread, which on a modern machine is simply time thrown away.
Declip now splits by channel
The two channels are independent in every respect that matters — their own
buffers, their own rails, nothing shared — so they run together. On material
with real clipping this stage was about a quarter of a conversion.
What does not split is the window loop inside a channel. Windows advance by
2048 samples with a 4096-sample span, and each one crossfades into what the
one before it wrote, so their order is load-bearing and is untouched. The
output is the same sample for sample, and a test holds the parallel pair
against two solitary passes to keep it that way.
XTC now splits by transform
Four FFTs per block — two forward, two inverse — pairwise independent, so they
run in pairs.
The block loop stays sequential, and that is deliberate rather than
unfinished. The crosstalk filter runs to some 28 000 taps against an
8192-sample block, so one output sample collects contributions from three or
four blocks through overlap-add, and floating-point addition is not
associative: any other order would move the last bit of every sample in the
overlap. Only the transforms moved. The accumulation is the same loop, in the
same order, so the agreement here is structural rather than measured.
A seam for an alternate polyphase pass
dsp/polyphase_engine.rs lets whoever embeds the engine supply their own
convolution. Nothing installs one in this build, and with none installed the
pass runs exactly the code it always has.
It exists because the convolution is the one stage whose result depends only
on the input, the filter and the ratio — which makes it the one stage that can
be computed somewhere else without a second implementation of the DSP. That is
what the browser version uses it for; see below.
CI builds again
The repository compiles with target-cpu=native, which is right for a machine
you own and wrong for a hosted runner fleet: a build cache filled on a CPU with
instructions the next runner lacks brought the compiler itself down with
STATUS_ILLEGAL_INSTRUCTION. CI now pins the same portable baseline the
release workflow has always used.
There is a browser version now. The same engine, the same filters, nothing
to install — up to thirty million taps, eight tracks at a time:
Try it on Hugging Face.