A second cabin: VW Passat B8 front set as IR JSON v7 (item 6 of #86)

[ayukhno]

Item 6 of #86 — the second cabin, in your format.

Where: https://github.com/ayukhno/autosound-measurements → cars/vw-passat-b8-sedan-lhd/2026-06-15_front-set-01/ (CC BY 4.0; the repository is laid out to be consumed as a submodule, like your test-data one).

What: VW Passat B8 sedan (LHD), Helix DSP Ultra S at 96 kHz, ECM8000 on a Scarlett 2i2 with a physical loopback — the rig your README describes. Eight channels of the front set (sw, w_L, w_R, m_L, m_R, tw_L, tw_R, c), each as ImpulseResponseFile v7:

• ir-v7/ — the transfer IRs as REW measured them: sample 0 = the loopback reference, levels as fractions of full scale (so the channels' relative levels are the measured ones), nothing rounded in time (REW puts t = 0 at a fractional sample; the transfer IR was rotated by the exact fraction), REW's pre-roll wrapped to the tail as your H1 leaves it.
• ir-v7-compensated/ — the same with the protective high-passes the mids/centre (100 Hz LR24) and tweeters (1 kHz LR24) had during the sweep removed by your ProtectiveHighPassCompensation.RemoveFromImpulseResponse (maxBoost 40, peak re-found as ApplyAverageResult does) and saved through your SaveAsync — open these for Virtual DSP / Auto delay / Auto crossover; sw/w_L/w_R are identical in both sets.
• rta-mmm/ — the moving-mic RTA of each channel (dB SPL vs Hz), the level/voicing view the tune was made with.
• dsp-state.json — two end points to score against: the attested v1 (2026-07-12) and the current SQ preset (2026-08-18), crossovers / delays / polarity / gains / PEQ / the two tweeter all-passes.
• manifest.json + a rewSource block in every file (your reader ignores it): REW title/uuid/date, its own delay estimate, peak dBFS, the fractional shift, the HPF in force, the compensation record.

Checked before sending: every file was loaded through your ImpulseResponseFile.LoadAsync (compiled verbatim from d11186e, app types stubbed) and read back with Resonalyze.Dsp.TimeAlignmentAnalysis — on the mids and tweeters its first arrival lands on REW's own delay within 0.01 ms; woofer and sub reads are your estimator's opinion of an onset that leads the peak. Caveats are in the set's README (one sweep per channel, SNR 34–51 dB, mic cal not applied to the IRs, rears on another time base and omitted).

How it was made: autosound-tuning-skill/skills/autosound-tuning/rew_tool/resonalyze_ir.py — REW's API → your v7, validated with a port of your Validate(). Two REW facts it took, which will matter for the REW-import path (item 5, its own issue to follow): REW's impulse-response endpoint peak-normalises by default (?normalised=false gives the raw IR), and REW anchors its buffer on the mic-IR peak so t = 0 falls at a fractional index.

Nothing is required of you. If you do run Auto delay / Auto crossover on it, I would be glad to see what it proposes next to the two states in dsp-state.json — that is the comparison the whole exercise is for. The bell-Q measurement (item 2) and the REW-import spec (item 5) come next.

[DIMOSUS]

What speakers did you use in your car? This is important for understanding their optimal operating range.

[DIMOSUS]

I'm also very confused by the measurement of your left woofer. I suspect that an extraneous sound was interfering during the measurement. Could you re-measure the car using Resonalise with a setting of about 4 repetitions? This will improve the SNR and add a coherence graph, which is also used in the tuning. You can also increase the sweep time, which will also improve the SNR.
Sorry if this is too much to ask, but your measurement is breaking my auto-tuning heuristics, which worked perfectly in other cars, and I can't figure out why.

[ayukhno]

Two small requests about the data going the other way — yours.

A licence on Resonalyze-test-data. The repository has none, which by default means all rights reserved: strictly speaking nobody can redistribute it, and a published analysis that quotes numbers from it stands on shaky ground. If you add one — CC BY 4.0 is what our set uses, and it costs you nothing but a LICENSE file — those cabins become citable field data for anyone, and I can use them openly rather than only reading them.

A line of metadata per cabin. The README describes the systems (4-way stereo, rates, averages) but not the cars, and for anything about what a body does to a response that is the missing half. What would make your two sets far more useful to a third party:

• car and body (make/model, saloon / hatchback / estate / SUV, LHD or RHD);
• roughly where each driver sits and where it aims — doors, A-pillars, kick panels, dash firing at the windscreen, sub in the boot, sealed or ported;
• where the microphone stood (driver's headrest? centre of the car? both ears?), and whether it stayed there across the set;
• the protective high-passes in force during the sweeps, if any.

Nothing needs re-measuring — it is what you already know about your own cars. We publish the same for ours (CAR.md next to the set), so the two would be readable side by side.

Why I ask is in the issue I am about to open next — a research direction where a second and third cabin change what can be said at all. Either way, thank you for publishing what you already have; it is more than most people do.

[DIMOSUS]

I will update the repository and add the license as you suggest.

[ayukhno]

Both answers, and a plan for the left woofer.

The drivers

channel	driver	placement / aim
w_L / w_R	Ground Zero GZNK 165SQ-K (6.5" midbass)	front doors, stock locations, doors treated
m_L / m_R	Hertz ML 700.3 (3" midrange)	A-pillars, low, near the dash; L aimed at the centre, R at the driver
tw_L / tw_R	Hertz ML 280.3 (dome)	A-pillars, above the mids, ~2 cm deeper; same aiming
c	Hertz MP70.3	dash centre
sw	Ground Zero GZUW 10SQ-D2 (10", DVC)	sealed 35 l box, boot

Datasheet passbands: ML 700.3 — 200–20 kHz, Fs 110 Hz, Xmax ±1.1 mm (a true midrange, not a midbass), rated HPF 250 Hz / 12 dB/oct. ML 280.3 — 1–28 kHz, Fs 900 Hz, rated HPF 1.8 kHz / 12 dB/oct. GZUW 10SQ-D2 — Fs 40.2 Hz, Xmax 20 mm, Vas 21.8 l.

More useful than any of that, since you asked about operating range: installed Fs, measured as impedance sweeps in the car (REW, 2026-07-10):

driver	free-air Fs	installed Fs (L / R)
ML 700.3 (mid)	110 Hz	194.8 / 196.7 Hz — +78 %
ML 280.3 (tweeter)	900 Hz	939.7 / 948.9 Hz — +4–5 %
GZNK 165SQ-K (midbass)	no datasheet on file	52.4 / 52.4 Hz
GZUW 10SQ-D2 (sub)	40.2 Hz	43.9 Hz (test tone, not yet a proper in-box impedance sweep)

The mid is the one to watch: any rule of the form "keep the corner N octaves above Fs" gets a very different answer here from the datasheet number, because the pillar enclosure moves it by nearly an octave. The dome barely moves, as expected for a flush-mounted tweeter.

Protective filters in force during the published sweeps: mids and centre 100 Hz LR24, tweeters 1 kHz LR24, woofers and sub none — declared per channel in manifest.json so ProtectiveHighPassCompensation has what it needs.

The left woofer

Not too much to ask, and the better answer is to stop sending you REW files: I have Parallels here, so I will run Resonalyze itself under Windows (Focusrite 2i2 passed through, the same physical loopback on the interface) and re-measure the front with 4 repetitions and a longer sweep, so you get the coherence traces and the native format rather than my conversion. If the VM's audio path turns out to add jitter, the repeat sweeps will show it and I will say so instead of shipping the data.

Two things I can tell you before that, so you can judge whether they explain what you see:

• The two woofers are not two samples of the same thing. Left-hand-drive car, mic at the driver's headrest: the left door is right beside the seat, the right one is across the cabin. Direct-to-reflection ratio, door-cavity loading and the first floor bounce all differ, and the published peak levels carry that — w_L peaks at −49.4 dBFS against w_R at −45.1 (the files carry REW's absolute levels, not peak-normalised ones, so those differences are real).
• The oddity is repeatable, not a one-off. In a separate session in July that same channel showed a deep cancellation across 200–400 Hz that responded to delay and not to EQ — the same feature, two months apart, on two different captures. So at least part of what you are looking at is this cabin rather than a stray noise during one sweep.

What would help me aim the re-measurement: which band, and what does it look like to you — noise floor, energy before the arrival, phase that will not settle, a null too deep to be real? Your heuristics see something mine did not flag, and I would rather reproduce your view than guess at it.

One caveat I would rather state than have you find: the ECM8000's calibration file is in the data repository, but I cannot now establish whether it was loaded in REW when the June set was captured. It is a smooth curve that matters mostly above 10 kHz, so it does not manufacture a woofer anomaly — but it will definitely be loaded for the re-measurement.

Near-field sweeps per driver come with the same session, since they separate what the driver does from what the cabin does to it.

[DIMOSUS]

I updated https://github.com/DIMOSUS/Resonalyze-test-data
I uploaded my latest measurements (version 5) and added a license file so they can be used.

[DIMOSUS]

I dug into the measurements a bit deeper, and I think I found a more specific reason why this dataset is confusing Resonalyze.

Initially I noticed a suspicious synchronous increase in the noise / harmonic-distortion region of the measurement, which is why I first suspected some extraneous sound during the sweep. But after looking more closely at the impulse responses, there is another, probably more important asymmetry: the right midbass has noticeable pre-ringing / energy before the main arrival, while the left midbass does not.

Resonalyze deliberately has logic to suppress pre-ringing when estimating the meaningful acoustic arrival. This is useful when the pre-arrival energy is an artifact rather than part of the actual direct sound. In this particular dataset, however, that logic makes the two midbass channels get evaluated differently. As a result, their estimated arrivals are no longer directly comparable, and the automatic alignment cannot establish the delays correctly.

Pre-ringing appearing strongly on only one of two otherwise equivalent midbass measurements looks suspiciously like a measurement/deconvolution artifact to me, rather than something I would immediately trust as a real acoustic property of the car. So your plan to re-measure the system directly in Resonalyze with 4 repetitions and a longer sweep now makes even more sense.

The new measurements should tell us pretty quickly whether this pre-arrival energy is repeatable. If it is still there with good coherence and repeated sweeps, then I will treat it as a legitimate real-world case that Resonalyze needs to handle correctly. If it disappears, we will know the current dataset was exposing a measurement artifact rather than an alignment edge case.

[ayukhno]

Re-measured, and you were right to be suspicious of that channel — though not for the reason either of us assumed. New set published, superseding the June one for analysis:

https://github.com/ayukhno/autosound-measurements/tree/main/cars/vw-passat-b8-sedan-lhd/2026-08-20_front-set-02

Measured in Resonalyze itself first (Windows 11 arm64 in a VM, Focusrite ASIO, 4 runs averaged, coherence included), then the same eight channels in REW minutes later with the microphone, the interface gain and the processor untouched between the two. Processor cleared and written down this time — no EQ, no delay, no crossover, unity gains, RTC off, protective high-passes only.

First, the thing I owe you

The June set was captured with the microphone in my hand. I had never measured the cost of that, so this session started by measuring it: hand-held, two captures 25 s apart differ by 0.9–2.4 dB RMS over 100 Hz–16 kHz and their arrivals wander by ±2 samples, drifting 5 samples — 18 mm of path — over a quarter of an hour. On a tripod the same repeats agree to 0.18–0.25 dB RMS and 0.09 samples.

So every inter-channel timing in the June set carries a few samples of position noise that nothing in the data reveals. Your delay tuner resolves a tenth of a sample; it was being handed a geometry that quietly contradicts itself. That alone could account for heuristics that hold in your cars failing on mine, and I would treat the June arrivals as ±3 samples rather than as measurements.

Now the left woofer

Near-field captures of both door woofers (7 cm from the grille, on axis) say the drivers are a matched pair: 1.55 dB RMS apart over 40 Hz–2 kHz once a 1.8 dB level difference is removed. Nothing wrong with the left one.

What the cabin does to each, though — in-car minus near-field, normalised at 40–80 Hz:

Hz	left	right
100	+9.9	−2.8
125	+6.3	−2.0
160	−8.9	−1.3
250	+1.7	−11.0
315	+2.6	−11.1
400	+0.7	−19.0
630	+1.9	−14.2
1000	−1.0	−9.1

The left door is the near one, beside the listening position: a boundary/modal pair puts +10 dB at 100–125 Hz and −9 dB at 160 Hz — nineteen decibels of swing inside half an octave. The right door, across the cabin behind the console and the occupant, is flat at the bottom and shelved down 9–19 dB from 250 Hz up.

Two identical drivers, mirrored positions, one cabin, and acoustically they are not the same instrument. An algorithm that expects a stereo pair to be each other's mirror has no consistent solution to find here. That is what your heuristics were hitting, and it is a property of this installation rather than of the measurement.

It is also, incidentally, the experiment we were discussing in #91 — the same driver in two places in one cabin, with near-field proof that the drivers themselves match.

Your program and REW agree

Since both measured the same cabin on the same microphone position forty minutes apart, the set is also a cross-check between the two programs. Arrivals:

channel	REW	Resonalyze	difference
m_L	2.6216 ms	2.615 ms	0.6 samples
w_L	8.6203	8.615	0.5
m_R	3.9828	3.979	0.4
tw_L	2.6828	2.677	0.6
tw_R	4.0094	4.010	0.1
sw	16.2144	16.323	6.4

One finding you will care about. On w_R and c the two programs report peaks a millisecond and a half apart — REW 6.3914 ms against Resonalyze 4.792 for w_R, 3.8245 against 4.208 for c — while their first arrivals agree (4.573 / 4.656 and 3.354 / 3.396). Those two impulse responses have two nearly equal maxima, and which one wins is a coin toss between implementations, or between two takes of the same channel. Anything that keys alignment to "the peak" will flip between them. Both files are in the set if you want to look at the pair.

What else is in it

• Coherence per channel from Resonalyze's four runs, as coherence/<channel>.txt — the woofers and sub sit at 0.997–1.000 through their working band.
• Drift controls. Cabin air temperature moves every arrival in proportion to its acoustic path — 0.43 samples per degree on a 0.9 m path at 96 kHz — so each block carries three captures of one channel as its own thermometer. Block A drifted +1.09 samples over 445 s while the cabin warmed after ventilation; block B −0.64 as it cooled. The per-channel correction is in manifest.json, computed from the controls and scaled by each channel's own path, and deliberately not applied to the files.
• dsp-state.json with the cleared state, so the set can be reproduced from one file.
• The same ten channels also captured 9 dB louder; a back-to-back pair shows the system linear across that range to 0.17 dB RMS.

Resonalyze's own v7 files are not in the repository — each is about 95 MB, mostly a 2.1-million-sample transfer response and a million-bin coherence array. Say the word and I will put them up as a release asset; they are your program's native output and might be more useful to you than my conversion.

The bell-Q measurement you asked for in #86 did not fit in this session — the car was getting unpleasantly hot — and is first on the list for the next one.

[DIMOSUS]

Yes, please send the native Resonalyze v7 files — these are extremely valuable data for debugging and regression testing.

Since the files are mostly JSON arrays, they should compress very well, so an archive is probably the easiest option. You can publish the archive as a release asset, or send it to me directly by email if that is more convenient.

I would definitely like to keep the native files with coherence rather than only the converted versions. The new tripod-mounted set, the REW cross-check, and especially the w_R / c cases with competing peaks make this a very useful real-world test corpus for the alignment code.

[DIMOSUS]

By the way, you have very nice tweeters. I seriously considered the Hertz ML 280.3 for my own car as well, but in the end I got a bit stingy and bought its younger brother, the Hertz MP 28.3 Pro instead.

I wrote a bit about that part of my setup here:
https://www.drive2.ru/l/739756097165863418/

[DIMOSUS]

I have now simulated your current SQ setup using the new measurements, including the crossover filters, PEQ and the tweeter all-pass filters.

First of all: this is very interesting hardware. But after looking at the complete simulated system, I think there are several parts of the current tuning that are worth experimenting with.

Subwoofer ↔ midbass

Your subwoofer is currently low-passed at 88 Hz with BW36. That is not unreasonable by itself, but for this particular system I think it is somewhat high.

The GZNK 165SQ-K is a very capable midbass driver and has plenty of usable extension below this point. I would try moving the crossover down to approximately 65–70 Hz. This also lets the door woofers handle more of the upper-bass region instead of asking the rear-mounted subwoofer to play so high.

I actually like the BW36 low-pass you use on the subwoofer — I use the same topology in my own system.

What I find more unusual is pairing it with LR12 at 92 Hz on the midbass. The very different slopes create quite different phase slopes and group-delay behaviour through the crossover region. In addition, the shallow LR12 high-pass leaves a very wide frequency range where both the subwoofer and midbass contribute significantly, so any phase mismatch affects a fairly large part of the spectrum.

This is what the phase relationship looks like with the current filters:

As an experiment I changed both sides of this junction to BW36 at 65 Hz and then adjusted delay/polarity.

The resulting phase relationship is dramatically cleaner:

The Sum Loss metric agrees with this: in this experiment I get approximately −0.08 dB average / −0.17 dB worst dip at the junction. In other words, in the simulation the two drivers are contributing almost perfectly constructively.

Interestingly, the slight amplitude rise produced by this BW/BW combination is actually useful here because it fills a small dip in the measured response.

I am not claiming that BW36/BW36 is a universally correct crossover topology — it is not a textbook flat-summing electrical crossover. But with these particular measured acoustic responses, it works extremely well.

Midbass ↔ midrange

The next thing that caught my attention is the LR12 low-pass at 215 Hz on the midbass.

Because the slope is so shallow, its acoustic contribution extends far above the nominal crossover frequency. At the same time the midrange is high-passed much higher, at 460 Hz with BW24. The result is a very broad interaction region, and the phase relationship around roughly 350–400 Hz is not particularly good.

My current experiment is much simpler:

• Midbass LP: LR48 @ ~350 Hz
• Midrange HP: LR48 @ ~350 Hz

This greatly reduces the frequency range in which both spatially separated drivers contribute significantly.

Steep filters do have trade-offs — particularly additional phase rotation/group delay with IIR filters — but they also substantially narrow the acoustic overlap region. One reason they can be inconvenient in a traditional tuning workflow is that accurate timing becomes much more important.

That is exactly the kind of problem I want Resonalyze to solve automatically.

Midrange ↔ tweeter

This is probably the most interesting junction.

The ML 700.3 has excellent upper-frequency extension, while the ML 280.3 is an unusually capable tweeter that can safely operate much lower than a typical small automotive tweeter. You have some seriously nice hardware here.

I would therefore experiment with moving this crossover to approximately 4 kHz, again using LR48 on both drivers.

There is one complication: the existing EQ was designed around your current crossover. On the left tweeter in particular there are cuts around 4.0–4.3 kHz, exactly where the new crossover would sit. So the EQ around this region would need to be redesigned together with the crossover rather than simply copied from the old tune.

With the steeper crossover, the region where midrange and tweeter simultaneously radiate is also much narrower, reducing the bandwidth over which phase-dependent interference between the two physical locations can occur.

The original C/D junction is actually the worst one according to Sum Loss in my current simulation, so I think there is quite a lot to gain here.

All-pass filters

An interesting consequence is that with this alternative crossover structure I currently do not need either tweeter all-pass filter at all.

I do not consider all-pass filters bad — they are a very useful tool when they solve a problem that cannot be solved conveniently with crossover choice and delay.

But if I can get the same or better phase tracking without them, I prefer the simpler solution with fewer degrees of freedom.

Subwoofer EQ

One more thing I want to investigate is the subwoofer EQ.

There are several relatively narrow corrections in the low-frequency range, and they create noticeable structure in group delay / phase. That does not necessarily mean the EQ is wrong, but it gives the crossover optimizer a more complicated phase shape to work with.

I want to analyse this part more carefully before suggesting changes.

Centre channel

I have deliberately ignored the centre channel for now.

This is new territory for me, and I would rather understand how you intend to use the centre before pretending I know the correct way to integrate it.

Overall result of the experiment

With the alternative crossover structure and timing, the overall Sum Loss becomes almost flat and stays very close to 0 dB through most of the working range. That is exactly what I want to see: very little destructive interaction between adjacent bands.

Your measurements have also exposed several weak points in my own alignment heuristics. This is exactly why this dataset is so valuable to me.

I am working through those cases now and modifying the algorithms accordingly. Once I am satisfied with that, I would like to send you a complete Resonalyze session containing my version of the tune rather than just isolated crossover experiments.

If you are willing to try it in the actual car, I would be very interested in how it compares by ear with your current SQ preset. Looking at the drivers and the measurements, I think there is still quite a lot of performance left to extract from this system. In fact, I suspect the potential of the hardware is a step above the competition class in which the car has participated, and it would be interesting to see how much more can be extracted from it.

One question before I go further:

How do you prefer to build the stereo image? Do you normally centre the stage mainly with L/R level differences, or do you intentionally use a combination of level differences and additional L/R delay offsets?

That choice affects how I should constrain the final automatic alignment.

---

Just for transparency: the technical content and conclusions here are mine. I wrote the original text myself, and used AI only to clean up the wording and translate it into English.

[ayukhno]

How I build the stereo image

In the order I actually work:

1. Impulses, left and right by the peaks. I set the delays so the left and right impulses coincide at
   their peaks.
2. Bands against each other by the onset of the rise. Different criterion here, not the peak.
3. Sub ↔ midbass: after the impulse I look at the phase.
4. Midbass ↔ midrange: I correct the phase here too.
5. Polarity. Where I can, I try to have all impulses going the same way — rising. It does not always
   work out; I experiment, I am a beginner-amateur myself.
6. And only then a little with levels. What matters most to me is the frequency balance between left
   and right.

To answer your question exactly: my delays are of course different left and right — the distances are
different. But that is alignment, not aiming the stage. Beyond the value alignment gives me, I do not add
anything extra to push the image to one side.

The problem I have not solved

My right side is louder. The image itself sits where it should — under the rear-view mirror, slightly
to the left of it — but many listeners still feel the stage is pulled to the right. I would be interested
in what you make of that.

The native v7 files

Published as a release asset:

https://github.com/ayukhno/autosound-measurements/releases/tag/v7-passat-2026-08-20

10 files, 351 MB compressed (1.0 GB raw), all version: 7 with transferCoherence present — which is
exactly what the converted set in the repository does not have.

Every file: 96 kHz / 24-bit, LoopbackTransfer / SynchronizedLoopback, 4 of 4 averages accepted,
band 15 Hz – 28.13 kHz.

Contents — the front block, measured in one sitting on 2026-08-20:
m_L ×3, w_L, w_R, m_R, tw_L, tw_R, sw, c

The three m_L repeats are at 12:34:48, 12:37:26 and 12:42:13 — the start, the middle and the end of the
block, as a repeatability control across the whole session.

CC BY 4.0, like the rest of the repository.

[DIMOSUS]

Thanks, that clarifies your approach.

I have one concern about the first step, though: I would not rely on aligning the L/R impulse peaks as the final timing criterion.

Two different acoustic paths can produce noticeably different impulse shapes. Making the maxima occur at the same time does not guarantee that their phases are aligned over the useful frequency range. In a car this is especially likely because the left and right speakers see very different reflections and loading.

I would treat peak alignment only as a rough initial estimate of propagation delay. For the final alignment, I think it is more meaningful to choose the delay that gives the best phase agreement over the frequency range where the two channels actually contribute.

The same applies even more strongly when aligning different bands: onset or peak position is useful as a starting point, but the final criterion should be phase agreement and constructive complex summation around the crossover.

So I think our approaches are actually fairly close — I just put much less weight on the exact position of the impulse peak.

[ayukhno]

Yes — send it. I will change the whole tune.

Not a filter or two: I am willing to take out the current preset entirely, load your version and live with it,
including dropping both tweeter all-passes. Nothing in my tune is precious.

Let me be clear about what I am and am not, because my last comment on #91 said the same thing from the other
side. I am not going to be the one who settles the acoustics — that is past my depth and I said so. What I do
have is the part this field is actually short of:

• a car, with the install and the rig documented, and the willingness to re-measure it as often as it
  takes;
• a measurement setup that repeats — the tripod set showed 0.19 dB RMS repeat-to-repeat below 150 Hz, and
  I can run 4-repetition sweeps with coherence natively in Resonalyze now;
• willingness to test something I did not design and report what I hear, including when the answer is that
  it sounds worse;
• and time on the AI side to do the reading, the conversions and the tooling around it.

Everything I learn goes into a free, open tuning method, so nothing here gets locked up.

What would make the comparison worth something

Tell me what you want and I will follow it exactly rather than improvise:

1. Before/after in one session. I would capture the current tune and yours on the same day, same mic
   position, same rig, so the only difference is the DSP state. Both sets published as v7 with coherence
   alongside the ones you already have.
2. What to listen for, in your words. You have a specific claim — Sum Loss near 0 dB through the working
   range. I would rather listen for what you predict than tell you what I liked.
3. The centre channel. You left it alone deliberately and asked how I intend to use it. That deserves its
   own answer rather than a line here, and I owe you one. For the comparison itself, say whether you want it
   muted — a cleaner A/B without it is fine by me.
4. The order. If you would rather I ran a partial change first — say, only the sub/midbass junction at
   BW36 65 Hz — so the effect of each junction is separable, that is a better experiment and I will do it that
   way. Your call; you know what your algorithms need to learn.

One thing worth flagging honestly: my right side is louder, and listeners hear the stage pulled right even
though the phantom centre sits where it should. If that survives your tune, it is the car and not the tune,
which is itself worth knowing.

No hurry. Send it when your heuristics are where you want them.

[ayukhno]

On the centre channel, since I owe you that answer.

What it is fed. I use the Helix algorithm that sends the centre only the mono component — the content
present in both the left and the right channel. So it is not a third source carrying new material; it carries
the part of the signal that was already meant to be in the middle.

Why it is there. To compensate for cabin dips in the midrange. My reasoning is that because it only
carries what is already common to L and R, it should not disturb the stage — it fills in rather than adds.

What I hear. With the centre on there is a clear gain in the fullness of the stage and in its height.
That is a listening result, not a measurement; I have not run it as a controlled comparison.

In fairness I should say the idea was suggested to me rather than something I arrived at myself, and I have
never tested it against the alternative. So it is an open question, not a design I am defending.

For the A/B I would lean towards muting it, so that what your tune does is not mixed up with what the centre
does — but if you would rather see the system as I actually listen to it, say so and I will leave it in. Your
call either way.