12mic dataset observations for v0.8.1

[SDX-LV]

While working with https://github.com/DIMOSUS/Resonalyze-test-data/tree/main/UserContibutions/2026-09-17%2012mic%20dataset%20UMIK-X here are issues detected:

1 (possible significant bug!)
In virtual DSP v0.8.1 - The graphs jump in level from L to R even for mono subwoofer - which looks alarming. I forced all axis to be identical but the “UMIK-X virtual-dsp-session p3 with EQ.json“ from "12mic dataset" still has jumping graph behavior when switching from L to R side. Jumping usually appears after some EQ or other prorations were done, not when the data is just loaded.

• If the issue is not reproducible by loading the session json, I can provide more evidence from my side.
• (actually for all intents and purposes plot axis MUST always be identical for L and R plots - it only adds manual steps to enforce the the same axis scale manually)
• Related: “Sum Loss“ axis should also be the same for both L and R sides - it can freely change axis limits for L and R side i v0.8.1.

2
The “12mic dataset” has very strange “Frequency Response“ curves that do not match anything like the Array Average or any of the 12 measurements that Average uses. It means that before you press “Hybrid“ in Virtual DSP or Activate “show Array Average“ in Mode Settings for Frequency display you get something I can’t explain in v0.8.1.

3
In virtual DSP v0.8.1 with “12mic dataset” Auto Crossover always chooses -12dB on Midrange which clearly pushes midrange much too low in level to match tweeter or woofer. Strange.

4
In virtual DSP v0.8.1 - If I switch between “Mic Cal“ with "12mic dataset" I get 3 different curves:

• "Off" - (supposedly ignores the calibration used during the Array measurement)

• "Own (as measured)" - supposedly the correct calibration as used during capture and must be the Default (ideally all other Mic Cal options should get a warning on the graph when you have activated them)

• "0deg" - in "12mic dataset" case I have no idea what it uses, because there was no calibrations configured in this instance of Resonalyze and the resulting graph is not the same as in case of “Off“ or “Own“ - I suspect something is not right.

[SDX-LV]

Wanted to highlight the main possible bug from this ticket. Seeing this behavior raises questions about what is the actual level of Left and Right sides after EQ- are the levels as different as in the Virtual DSP graphs or is the reality different from graph? Either way very strange.

In virtual DSP v0.8.1 - The graphs jump in level from L to R even for mono subwoofer - which looks alarming. I forced all axis to be identical but the “UMIK-X virtual-dsp-session p3 with EQ.json“ from "12mic dataset" still has jumping graph behavior when switching from L to R side. Jumping usually appears after some EQ or other prorations were done, not when the data is just loaded.

[DIMOSUS]

I’ll get to this bug report, but it may take some time. Right now I have accumulated quite a bit of technical debt that I need to address first, since it is starting to limit further development of the project.

Once that is under control, I’ll return to the remaining bug reports, including this one.

[DIMOSUS]

Thanks for the dataset — it turned out to be a very good torture test, and it found real bugs. Fixes are in #232, #235, #236 and #237 and will be in the next release. Here is what we found, point by point, and one finding about the recording setup itself that explains most of what you saw.

The main finding: in these files the microphone hears the sweep before the loopback

In every file of the set, the direct sound arrives 39–52 ms before the loopback reference:

File	Arrival ahead of loopback
Subwoofer rear	38.8 ms
RearRight	39.1 ms
RearLeft	40.6 ms
FrRight Midrange	43.9 ms
FrRight tweeter	44.6 ms
FrLeft tweeter	49.6 ms
woofer Mono front	51.7 ms
FrLeft Midrange	51.9 ms

Nothing can reach a microphone before the signal that drives the speaker, so the loopback was not timing these measurements. The cause is the ASIO4ALL setup: the microphones are on the UMIK-X and the loopback on the RME, and ASIO4ALL joins the two devices into one. Each device starts its stream with its own buffering, so the offset between them is set anew every time a measurement starts. The clocks were locked over optical, so there is no drift within a measurement: the tweeters' coherence over the 5 averaged runs is 0.994–0.996 at 8–16 kHz, which would collapse if the offset moved during a run. But between measurements the offset jumps. The spread is 13 ms across the set, while the cabin geometry can account for only a few ms. The two tweeters were measured 33 seconds apart and still differ by 5 ms.

What this means for the data:

• Magnitude of each measurement: fine. Shapes are real, and the array averages are fine too. Once the arrival is placed correctly, every channel of your session sits within −1.0…+0.1 dB of its own array average.
• Timing between measurements: not usable. Every delay, sum, Sum Loss, Auto delay, Time Alignment result and junction evaluation in Auto Crossover reads the channels' relative arrival times, and those carry a random error of several ms per channel.

How the app handles it now (#232): a measurement whose arrival leads its loopback is recognised, both when it is captured and when an older file is opened. It is filed as having no absolute time, like an imported recording, and its arrival is placed at 10 ms. It still works in the analyzer and the EQ Wizard, but Virtual DSP and Time Alignment decline it and say why. So this particular set will no longer load into Virtual DSP. That is intentional: summing it would give a confident-looking answer built on random delays. After a capture like this, the app now shows a notice with the measured lead and what to change.

How to measure it so the timing is real: the microphone that times the measurement and the loopback must be on the same physical device (the same clock and the same stream). With your hardware that means a measurement mic into the RME, with the loopback on the RME too. A driver that joins two interfaces can't give you that, however well the clocks are locked. Note also that if the offset had landed the other way round (loopback ahead of the mic), no single file could reveal it: the arrival would just look later.

Point 1 — L/R level jumping, even for the mono subwoofer

A real bug, and not only cosmetic. In the Hybrid view, the spatial averages were shifted onto the impulse responses' level by one offset, the median over the channels of the active side only. Left and right have different mids and tweeters, so the offset differed per side (−16.6 dB vs −18.3 dB on your session), and every curve, the mono sub included, jumped 1.7 dB when you switched sides. Worse, the EQ Wizard received each side's curves with its own shift, so an EQ fitted on one side would have ended up about 1.7 dB louder than the other in reality.

Fixed in #232:

• Arrays take no offset at all. They are referenced to the same loopback as the impulse responses, so they are already on the same level axis. Instead, each array is now checked against its own impulse response, and a warning appears if one stands more than 1.5 dB off. On your set that check would have flagged the problem immediately: before the timing fix, the arrays read 14–30 dB off.
• Moving-mic (MMM) sets use one offset for both sides when both sides form one set, so a mono channel no longer moves when you switch.

And the axes (#237): the magnitude and Sum Loss axes now span both sides, so switching L↔R changes the curves and nothing else, with no limits to set by hand. Your zoom is kept.

Point 2 — "Frequency Response" curves that match nothing

A consequence of the finding above plus a bug. Because the arrival had wrapped to the far end of the circular impulse response, the start estimate (which looks only at the beginning of the record) found a "start" in the wrapped reverberant tail. Every window then opened 40–50 ms after the direct sound, so the curves sat 13–43 dB low and matched none of the 12 microphones. With the arrival placed correctly (#232), each impulse response agrees with its own array average in level to within −1.0…+0.1 dB, read through Virtual DSP's steady-state window. What remains in shape is the ordinary difference between one position and the average of twelve.

Point 3 — Auto Crossover putting the midrange at −12 dB

Almost certainly the same cause: the levels it read came from those broken windows, a different error for each channel. On the corrected impulse responses, the crossover proposal gives the midrange about −4 dB and the mid/tweeter junction around 3.35 kHz (instead of 0 dB and 6.65 kHz on the broken data). That is consistent with the array levels (midrange 3–4 dB above the tweeter) and with your note that the tweeters shouldn't go below 2.5–3 kHz. I couldn't reproduce your exact −12 dB, since that came from the full wizard with your options, but with the timing issue above the junction search couldn't have worked on this set anyway.

Point 4 — three different "Mic Cal" curves, and the mystery "0°"

You were right to be suspicious. Off and Own were correct: they differ by exactly the UMIK-X curve, and Own reads each of the 12 positions through its own file. "0°" was a bug: a leftover calibration file from a very early version, a curve of some other microphone, was shipped next to the executable. Whenever no 0° calibration was configured, the app silently used it, and on a first run it was even the default. So on an install where you had configured nothing, "0°" was that unknown microphone.

Fixed in #235:

• The file is gone, and the installer removes the old copy. Calibrations come only from what you set in Record Settings.
• An empty 0° slot now reads as Off, and a fresh install starts uncalibrated. The list shows an empty slot as "0° (not set)".
• Virtual DSP now says when the plot is not read through the calibration a channel was measured with: a warning for a different curve, an information line for Off, naming each channel and its own file. In the Hybrid view it compares the calibration of the capture actually drawn.

And you were right that Own should be the default (#236): a new Virtual DSP project now starts on "Own (as measured)". A project you saved keeps whatever you chose, and Reset now keeps the calibration, as its message always said it would.

Thanks again. The dataset exposed several separate problems, and the ASIO4ALL one would have been very hard to find without a set recorded exactly this way. If you re-measure with the timing mic and the loopback on one device, I'd be glad to look at it.