Hello from autosound-tuning-skill: a Helix bank format (PR ready), hardware-verified Helix notes, and a file-level bridge with REW / TCC

[ayukhno]

A note on how this was written: this text, and the branch it points to, were produced by an AI coding agent working under my direction and review — the same way, judging by your AGENTS.md, much of Resonalyze is written. So it is written to be read comfortably by whichever agent you point at it as much as by you: file and member names are exact, every claim names its evidence, and every "we can" is something I have actually authorised.

Contact, in case a conversation is easier than issues: ayukhno@gmail.com, or name a messenger and how to reach you there.

Hi — I run autosound-tuning-skill (MIT code, CC BY-SA docs): a REW-driven car-audio tuning method written for AI coding agents, with a Python rew_tool/ (joint-phase summation, an excess-phase EQ-boost gate, crossover realisation against acoustic targets, a versioned DSP-state ledger). Its desktop front-end, Autosound TCC (Apache-2.0, Qt, installs on macOS and Windows 11), is in development: it reads REW live over its API, shows the whole rig (crossovers, delays, gains, per-channel EQ) and puts the AI in a panel; it never writes to the processor. Same doctrine as yours — loopback-referenced sweeps on one time base for phase and timing, moving-mic RTA for magnitude — and the same target hardware (Helix DSP Ultra S is our reference processor).

I read dsp/ end to end (and built it on macOS arm64 — the 1089 tests pass there, which is a nice property of the split you kept). The AlignmentSelection tie-breaks, the sum-loss objective with the dip penalty, and above all the register of refuted ideas in TODO.md are the most useful field notes on multi-way alignment I have seen in the open. Thank you for writing the "why" down.

A few things we can offer, roughly in order of how ready they are:

1. PR ready: the Audiotec-Fischer "Full EQ (30 bands)" bank as an IEqProfileFormat

Branch: ayukhno/Resonalyze@feat/audiotec-fischer-format (one commit on top of main; I will open the PR if you want it). It writes and reads the tab-separated bank the HELIX / MATCH / BRAX PC-Tool imports per channel — the same block REW exports with its Audiotec Fischer equaliser — with PK bells and the LS_Q / HS_Q shelves, always 30 slots, REW's row shapes byte for byte. It is pinned against a real REW export of a 20-band channel. Two design points I would like your view on:

• The bank has no place for a preamp (channel gain is a separate PC-Tool control), so I added IEqProfileFormat.CarriesPreamp (default true, the same shape as SupportsShelvingFilters) and made the shared round-trip test assert 0 for such a format instead of failing. The EQ Wizard does not yet warn about a non-zero preamp left behind the way it warns about a dropped shelf — recorded as a residual on the "device profile" item in TODO.md. I can do that follow-up, but it is app-side and I cannot run Resonalyze.App.Tests here (macOS), so I kept the first PR to dsp/.
• More than 30 bands is refused on export (an ArgumentException, which the coordinator already surfaces) rather than truncated.

Verified: Resonalyze.Dsp.Tests 1104/1104 on macOS arm64; the whole solution compiles with -p:EnableWindowsTargeting=true. App/Audio tests will need your Windows CI.

2. Hardware-verified Helix facts for the Q crib / a device profile

From our own bench work on a Helix DSP Ultra S (single-variable A/B: sweep → change one thing → sweep):

• AP2 is the textbook 2nd-order all-pass. A free fit of the complex ratio recovered the entered f0/Q (fitted 4386 Hz / Q 3.82 against entered 4414 / 4.0, 31° RMS residual). Your AllPassFilter model matches.
• LS_Q / HS_Q at Q 0.7071 are the RBJ shelf with S = 1 — REW models them as its "LS Q" / "HS Q" types (plain REW "Low/High shelf" is a different definition). Your PeqBandType shelves therefore travel into the bank unchanged.
• Delays on the virtual-channel layer and the output layer SUM (max 20.82 ms each) — worth a line on any Helix sheet: enter a delay in one layer only.
• 30 bands per channel; the channel gain is a separate control (hence CarriesPreamp = false above).
• One honest caveat: the bell Q convention we have only from REW's list and from REW's own export (its Bandwidth column is exactly Fc / Q, i.e. RBJ). We have not measured Helix bell bandwidth at ±12 dB ourselves. If you want that data point, it is a 10-minute measurement on our side — say so.

3. An excess-phase criterion for the boostability mask (method offer, before any PR)

Your EqBoostabilityMask refuses boosts in low-coherence bins and narrow deep nulls. Ours (rew_tool/eq_gate.py) refuses them where the dip is non-minimum-phase: a sliding RMS of the excess-group-delay z-score against a ±1-octave baseline, ANDed with local depth and with the candidate filter actually delivering gain there. The reason we went that way: cabin mids are phase-rough almost everywhere (30–50 % of the band shows anomalies), so phase alone over-blocks, and depth alone cannot tell a fillable shape deficit from an interference null. On the build history of one car it reproduced 7/7 real boost outcomes; on an analytic family of minimum- vs non-minimum-phase combs at matched magnitude — where any depth-only rule is at chance — it scores 90/90 at the operating point. You already have MinimumPhase / ExcessDelay, so the machinery is there. If this interests you I would bring it as a criterion the mask can consult, plus that synthetic test family (it fits your deterministic-DSP-tests style). If not, no PR.

4. Robustness of near-tie candidates (a field observation, for discussion)

One thing our loop learned the hard way: deep interference nulls are chaotic — same-session sweep ratios breathe 4–6 dB RMS (1/12 oct), and a razor-tuned all-pass optimum did not survive one hour between snapshots. We now score joint-phase candidates by the worst null under a small perturbation set (±20 µs delay, ±0.5 dB level, and combinations) rather than at the point. Your candidate list already exposes near-ties; a robustness figure could be a cheap extra tie-break there. Happy to share the perturbation set and the data behind it.

5. A file-level bridge: REW loopback IR → Resonalyze, and Resonalyze → skill / TCC

Today a REW user with a two-input interface and a loopback measures on the same absolute time base you require, but the only way in is your own IR JSON. REW exports IRs as text/WAV with its timing-reference fields (we have a documented list of the API/format quirks — startTime / delay, float32 encoding, loopback offsets — from a year of driving it). If you would accept a "REW impulse response (loopback-referenced)" import that keeps absolute time — as opposed to the recorded-sweep WAV path, which rightly refuses to sum — Virtual DSP and Auto delay would open to the whole REW-with-loopback world, and our skill / TCC could hand IRs and PEQ profiles both ways with no retyping. I can write the spec first and let you say whether it belongs.

6. A second cabin for your calibrations

Your TODO.md says the field data lives outside the repo and several thresholds are field-anchored on your own cabins. We can share ours: a VW Passat B8 sedan, LHD, three-way front (door woofers, A-pillar mids and tweeters) plus a sealed-box sub in the trunk, Helix DSP Ultra S at 96 kHz, measured with a Behringer ECM8000 (0° / 90° calibration files) on a Focusrite Scarlett 2i2 4th gen with a physical loopback — i.e. exactly the rig your README describes. What exists: per-driver loopback-referenced sweeps of all seven channels (sub, woofer L/R, mid L/R, tweeter L/R; measured with the protective high-passes the drivers need engaged (mid ~100 Hz LR4, tweeter ~1 kHz LR4; the exact DSP state of every set is in the audit trail) — which your new ProtectiveHighPassCompensation is for), the matching moving-mic RTA of each channel, several REW sessions across the tune, and the DSP state / audit trail that the ear finally accepted (delays, polarity, crossovers, EQ) so you can score against a real end point, not only against a metric. Tell me the form you would want — REW's IR export (text or WAV, loopback timing kept) per channel plus the measurement settings, or your IR JSON v7 if you would rather I write a converter — and I will prepare it.

One question

Your sub-precedence preference (AlignmentSelection — a slightly leading sub reads as "bass up front", a trailing one as detached) is a rule we do not have. Our L/R-image experience is that below ~150 Hz the image is level/proximity-driven and timing barely moves it — which is a different axis (left/right vs front/attack), so I do not think we disagree, but I would like to understand what evidence pinned it: listening, or a measured figure? It would go straight into our references with attribution.

How would you like to receive these — one issue per topic, PRs, or a thread here? I am fine either way; the format PR is the concrete first step and needs nothing from you but a review.

If a conversation would be easier than issues, e-mail me at ayukhno@gmail.com, or name a messenger and how to reach you there — happy either way.

[DIMOSUS]

Hi! Thanks — there is a lot of useful stuff here.

1. Audiotec-Fischer format
   Yes, please open the PR. Supporting another popular DSP format would be great. CarriesPreamp also sounds reasonable given that the bank itself cannot represent channel gain.

2. Helix measurements
   Definitely useful. My own DSP hardware is considerably simpler and does not implement the same all-pass functionality, so those models had to be implemented analytically rather than verified against the actual hardware. Hardware measurements from a real Helix are therefore very valuable. If you don't mind doing the bell-Q measurement you mentioned, I'd be interested in that as well.

3. Excess-phase boostability
   I actually considered using excess group delay for this before, but ran into exactly the problem you describe: in a car cabin it is very noisy and easy to over-interpret, so I eventually shelved the idea. Your results sound interesting, though. I'd like to see the synthetic test family and the real 7/7 cases first. If they are convincing, I'm open to integrating it, possibly initially as an optional criterion rather than making it a hard gate.

4. Robustness of alignment candidates
   This one I'd like to investigate rather than accept on faith. I've spent a lot of time trying to keep Auto Alignment based on physically explainable criteria rather than accumulating empirical constants. Some of my own next ideas were to look at the width of candidate lobes and compare phase-slope derivatives through the overlap band. However, after giving much more priority to the PATH-based search, the delay tuner became remarkably reliable, so the remaining failure rate is now very low.

That said, your observation is interesting. If you're enthusiastic about the robustness approach, I'd definitely like to see the measurements behind it and/or an experimental implementation. If it turns out to solve cases that the current approach genuinely cannot, having it as an alternative alignment strategy could make sense.

5. REW IR import
   I'm absolutely in favor of this if it can live as a separate IR import path and preserve the absolute timing accurately. Timing uncertainty is the part that worries me most. Resonalyze's current arrival estimator routinely resolves timing to roughly a tenth of a sample, and that precision is important for automatic alignment. So if the REW format/API allows us to reconstruct the loopback-referenced time axis without losing that information, this would be a very useful feature. I agree that writing down the timing/format semantics first is the right way to start.

6. Passat dataset
   Yes, I'd very much like to have it. If possible, Resonalyze IR JSON v7 would be the most convenient format because I could immediately run the existing algorithms against it.

Real-car data is something I badly lack: most of the current field-derived heuristics were developed against measurements from only three cars. My own car dataset is here: https://github.com/DIMOSUS/Resonalyze-test-data (I actually have newer measurements as well; I just haven't published them yet).

Regarding the sub-precedence preference: I originally based it on "On the perception of time-alignment between full-range speakers and subwoofers for sound reinforcement". Looking at the paper again, though, I think I may have over-interpreted its conclusion. The study does support an asymmetry — temporal degradation was reported more often when the subwoofer lagged the mains — but my stronger explanation that a slightly leading sub specifically reads as “bass up front” because of the precedence effect may not actually be established by that paper. I need to revisit that part before claiming it as evidence.

[DIMOSUS]

By the way, just to avoid any misunderstanding: I have no plans to change the license. This project is driven purely by enthusiasm, and I intend to keep it under the MIT license. My original goal was simply to tune my own car, and only afterwards did I decide to share the work with the community.

I actually started the project several years ago and wrote it manually for most of that time. Over the last two months, however, I switched to working with coding agents, which accelerated development dramatically and finally gave me the confidence to publish it here.

I suggest we continue the discussion here on GitHub. Feel free to create sub-issues or separate issues for any topics you would like to explore further.

[ayukhno]

Thanks for the detailed answers — and for the sub-precedence re-read; that is exactly the note I wanted for our references (I'll cite the paper with your caveat).

On the licence: no concern on our side at all — MIT is what we hoped for, and everything we bring comes on permissive terms too (the PR under this repository's MIT, the dataset under CC BY), so I see nothing in the way of working together.

• Item 1: PR opened — Add the Audiotec-Fischer 30-band bank as an EQ profile format #87.
• Item 2: the bell-Q ±12 dB measurement on the Ultra S goes into our next in-car session; I'll post the ratio data and the fit.
• Item 6: I'll prepare the Passat set as IR JSON v7 (converter written against the format as your code writes it, absolute time kept from the loopback reference, protective HPFs declared so ProtectiveHighPassCompensation has what it needs) and open a separate issue for it with the rig and the DSP-state description.
• Items 3, 4, 5: separate issues as you suggest, each when there is something concrete to look at — the REW-import timing/format spec first (5), then the excess-phase criterion with the synthetic family and the real 7/7 cases (3); (4) only with the measurements and an experimental implementation, as you asked.

Happy to keep it here on GitHub.

[ayukhno]

Off the technical thread for a moment: thank you for the star on the skill — noticed it today, and it is a nice thing to find from the one person whose code I have been reading all week.

Since you looked at that side, the other repository may interest you more than the v7 files themselves: https://github.com/ayukhno/autosound-measurements. It is small on purpose — one cabin so far — but the parts beyond the impulse responses are the ones I would have wanted when reading your dsp/:

• hardware/helix/dsp-ultra-s/FACTS.md — the bench-verified Helix facts, each with the measurement that settled it and, where a claim is still folklore, a line saying so. Given you had to model the all-pass analytically, fact 1 (AP2 is the textbook second-order all-pass, fitted f0/Q recovered to 4386 Hz / Q 3.82 against 4414 / 4.0) is the one to check against your model. The bell-Q measurement you asked for in this thread is listed there as pending, and lands there when the car session happens.
• hardware/.../formats/ — real PC-Tool banks including the Modal rows from the PR discussion, next to REW's own filter-settings text for the same filters.
• cars/.../rew-export-samples/ — the files behind every timing claim in the import spec (Spec: importing a REW loopback-referenced impulse response (item 5 of #86) #90), including the WAV that showed REW snapping a measurement's start time.

It is laid out to be consumed as a submodule, like your test-data repo. And if you do put a licence on yours, I would gladly list your cabins from our README as the companion set — two cars is not a dataset yet, but it is twice what either of us has alone.

[ayukhno]

The bell-Q measurement you asked for, done today. Short answer: the Q you type into a Helix is the RBJ Q, and boost is the exact mirror of cut.

Method is the single-variable A/B — one band at 400 Hz on an otherwise cleared output channel, microphone on a tripod and untouched, sweep before and after, and the ratio of the two fitted freely against an RBJ peaking response with f0, Q and gain all free:

entered	fitted f0	fitted Q	fitted gain	residual
400 Hz, −12 dB, Q 1	398.0 Hz	1.031	−12.00 dB	0.97 dB
400 Hz, −12 dB, Q 4	400.0 Hz	4.028	−11.95 dB	0.56 dB
400 Hz, +12 dB, Q 4	400.5 Hz	3.991	+11.85 dB	0.19 dB

A "symmetric" definition would have shown up as a factor of two in Q at this depth. It did not, at either Q.

The boost row is the one I did not expect to be able to state: cut and boost at the same nominal Q come back 0.9 % apart in Q and 0.10 dB apart in level, so the processor really does realize H_boost = 1/H_cut rather than something merely similar. That also answers the obvious objection to measuring a boost at all — a band that loud could have pushed the midbass into compression or woken a rattle, and the fit would have shown it as lost level and structure in the residual. Instead the boost has the smallest residual of the three.

Evidence published as the before/after pairs rather than my ratios, so the fit can be redone and disagreed with:

https://github.com/ayukhno/autosound-measurements/tree/main/hardware/helix/dsp-ultra-s/measurements

(fact5-bell-{cut-q1,cut-q4,boost-q4}-{before,after}.txt — REW's unsmoothed magnitude and phase at 1/96 octave. FACTS.md next to them carries the fact and the conditions.)

One methodological note that cost me an hour and may be useful to you. Two unfiltered references taken 74 seconds apart agree to 0.16 dB RMS; two taken thirteen minutes apart differ by 0.95 dB RMS, 4 dB at 166 Hz — it rained in between. So every filter here is ratioed against the reference nearest it in time, and the control sweeps are why that was possible at all. In a car, an A/B pair separated by more than a couple of minutes is measuring the weather as much as the change.

Item 2 of this issue is now closed. The dataset from the same session is in #88.

[DIMOSUS]

Thank you — this is exactly the discriminating experiment done right. At ±12 dB a Symmetric convention would have come back with twice the entered Q and Classic would have split boost and cut by a factor of four; your fit excludes both with margin, on a mic-untouched single-variable A/B, with the raw before/after pairs published so the fit can be redone rather than taken on faith. That level of rigor is rare and much appreciated.

It also means something I could not claim before: Resonalyze's filter models are now hardware-confirmed against a Helix on all three fronts — your AP2 fit for the all-pass, the LS_Q/HS_Q facts for the shelves, and now the bell (RBJ Q, with boost realized as the exact inverse of cut, which is precisely what the RBJ peaking biquad assumes). So I'm now comfortable stating that Resonalyze is valid for virtual simulation of a Helix: an EQ designed in Virtual DSP / EQ Wizard and exported through the #87 bank should land on the hardware as simulated, boost and cut alike. Until today the "Audiotec Fischer = RBJ" line in PeqQConvention rested only on REW's equaliser reference; now it points at a measurement.

The weather note goes straight into my methodology notes as well — 0.16 dB RMS at 74 seconds versus 0.95 dB RMS at thirteen minutes is a number worth quoting whenever an A/B pair spans a coffee break. It is also a nice quantitative anchor for the same-session breathing you described under item 4.

[ayukhno]

Two updates and a question.

What I am building. A session importer on my side: your resonalyze-virtual-crossover JSON read into my own tuning application's ledger, reconciled against the DSP's capability profile — so a plan like the one you sent me in #88 arrives as editable channel settings, and its four LR48 junctions are reported as "this processor cannot enter that" rather than silently rounded. This is the same direction as the bridge you asked for in #90, one layer up: measurements both ways, and now the tune itself.

What I would like to build next, and will not build without your word. Beyond importing a session, I could run the deterministic calculation over a set of base measurements — auto delay, auto crossover — inside my own application, visualise the result, and continue tuning from there with AI assistance. The licence permits it. That is not the question. It would put part of what your application does inside mine, and I am not doing that behind your back or presenting it as a fait accompli.

I would like to build it — that is why I am asking rather than assuming. So, plainly: are you comfortable with that, would you rather I did not, or would you rather the seam were somewhere you chose — for example my tool calling Resonalyze rather than reimplementing any of it? Tell me your actual preference and I will follow it.

If you do want a seam, tell me which surface is convenient for you to support — a command-line entry point, a documented session format, something else — and I will build to that instead of around it.

[ayukhno]

Separate from anything else, one piece of user feedback.

I find the application hard to learn by exploring it: which settings matter, and in what order the work is meant to go. The capability is visible; the path through it is not. I get there with AI help, but a short statement of the intended sequence — even a few sentences per tool in the README — would carry a beginner a long way.

I am saying it because I would rather you heard it from someone who is using the tool seriously than not hear it at all.

[DIMOSUS]

I'm completely fine with you implementing it on your side.

I chose the MIT license deliberately, so if parts of Resonalyze are useful to another project, I have no objection to them being reused or reimplemented. If implementing Auto Delay / Auto Crossover directly in your application is the simplest architecture for you, please go ahead.

I would rather not introduce a dedicated CLI or public integration API at this point, because that would also mean taking on an additional compatibility and maintenance commitment. I want to keep Resonalyze free to evolve internally without having to preserve another integration surface.

So there is no boundary you need to worry about from my side. Use the code, algorithms, or ideas in whatever way is most practical for your project. That's one of the reasons I chose MIT in the first place.

In short: copy it if you can. :)

[DIMOSUS]

Separate from anything else, one piece of user feedback.

I find the application hard to learn by exploring it: which settings matter, and in what order the work is meant to go. The capability is visible; the path through it is not. I get there with AI help, but a short statement of the intended sequence — even a few sentences per tool in the README — would carry a beginner a long way.

I am saying it because I would rather you heard it from someone who is using the tool seriously than not hear it at all.

Did you show him my post with instructions?
https://www.diymobileaudio.com/posts/6482123/

[ayukhno]

Thank you — on both counts.

On reimplementing. Understood, and that settles it: I will implement Auto Delay / Auto Crossover
on my side and not ask you for an integration surface. The session import already works, so your
plan for my car arrives as editable channel settings; the deterministic part I will build myself.
No CLI, no API commitment from you — for a project you want free to change internally, that is the
right call.

On the manual — you are right, and the joke was mine to begin with. What I actually said, in my
own words, was that this is an RTFM case: my problem, not yours. That did not survive the trip
through my AI assistant, which turned it into a polite feature request for documentation. So: your
post is the answer, I had not seen it, and I am working through it now.

One thing does block me there, and it is not documentation — I cannot read the dark theme well
enough to follow instructions against it. That is a separate matter and I have opened it as its own
issue rather than burying it here.