Beta-test: DeltaWave Null Comparison software

[pkane]

The null depth and PKEM values I can get with a bit of tuning the parameters (lots of guesses there, still) really start to scare me!
Original vs ADI-2 Pro Loopback, 100dB RMS null, 112dBr PKEM, residual completely inaudible in the noise, only some random glitches.

Can we really be sure only strictly linear and time-invariant transfer function deltas have been undone while keeping all the rest? Will need to convince myself -- doubting Thomas -- with synthesized test files that this myracle of a software isn't "overcorrecting" things that perhaps should remain in the residual.

If you don’t turn on non-linear EQ settings then the only corrections are: linear amplitude, linear clock drift correction and linear time offset. Turn off drift correction if you want just time offset and amplitude adjustments.

 

[Blumlein 88]

The null depth and PKEM values I can get with a bit of tuning the parameters (lots of guesses there, still) really start to scare me!
Original vs ADI-2 Pro Loopback, 100dB RMS null, 112dBr PKEM, residual completely inaudible in the noise, only some random glitches.

Can we really be sure only strictly linear and time-invariant transfer function deltas have been undone while keeping all the rest? Will need to convince myself -- doubting Thomas -- with synthesized test files that this myracle of a software isn't "overcorrecting" things that perhaps should remain in the residual.

If you aren't doing the extra processing of non-linear EQ it only adjusts gain, matches things in time and that is it. Paul beat me to it.

 

[KSTR]

If you aren't doing the extra processing of non-linear EQ it only adjusts gain, matches things in time and that is it. Paul beat me to it.

Yes, that is understood. It seems that time aligning via X-Cor has only sample period granularity, though.
Since most often we'll deal with sub-sample offsets, "non-linear calibration" is still needed even for simple true delays / dead times (no FR-dependent group delay). A half-sample offset as the worst case gives a tremendous "fake" HF residual content.

"non-linear calibration, Level EQ and Phase EQ" I've to mentally translate as "linear transfer function matching", which includes true delays (then only phase EQ is required) and actual freq. dependent transfer function, with mag and phase component (which can be non-minimum phase, in case of excess phase from allpass behavior etc).

 

[KSTR]

Coming back to this from the PKEM-Thread:

The filter is something you do have a lot of control over in DeltaWave settings. You can specify the type of filter, filter size, window, etc:

View attachment 109104

Filter size is clear now, but why do we need to specifiy a window type here? Normally, FIR-filtering (convolution) does not require setting a window (as it is rectangular), nor does IIR.

 

[Blumlein 88]

No, even without invoking non linear calibration it does sub sample matching. I forget, but think it goes down to 1/1000th of a sample. Paul can give the details when he sees this.

 

[MC_RME]

While the graph looks like that, DW's Quick Start Guide seems to say otherwise:

X-Correlated First step in aligning the two files to start on the same sample. This is done using cross-correlation. The result will be a better match in time, although the accuracy is +/- one sample (not very good).

 

[KSTR]

I've just checked with created 0.5 sample offset of the same pink noise source data. No sub-sample aligning, 90° phase offset at fs/2 as expected. Will post pic and file later, have to to go the office now, new PCBs have arrived that need production clearance asap.

 

[pkane]

Coming back to this from the PKEM-Thread:
Filter size is clear now, but why do we need to specifiy a window type here? Normally, FIR-filtering (convolution) does not require setting a window (as it is rectangular), nor does IIR.

Filters (FIR) are constructed dynamically. FFT Window is used in the construction.

 

[pkane]

Yes, that is understood. It seems that time aligning via X-Cor has only sample period granularity, though.
Since most often we'll deal with sub-sample offsets, "non-linear calibration" is still needed even for simple true delays / dead times (no FR-dependent group delay). A half-sample offset as the worst case gives a tremendous "fake" HF residual content.

"non-linear calibration, Level EQ and Phase EQ" I've to mentally translate as "linear transfer function matching", which includes true delays (then only phase EQ is required) and actual freq. dependent transfer function, with mag and phase component (which can be non-minimum phase, in case of excess phase from allpass behavior etc).

Here's the sequence:

1. First step is X-correlation to match to within 1 sample
2. Determine and correct for clock drift
3. Remove any remaining constant delay (sub-sample)
4. Match levels
5. Apply non-linear EQ

That's the order of operations, assuming the corresponding options are turned on in settings. Except for step 5, all of these are linear in phase.

 

[MC_RME]

Step 2. ‘Correct phase drift’. I wonder if a better name would be ‘Correct Phase Offset’. Isn't option 5, Non-Linear Phase EQ, the ‘phase drift correction’?

‘Correct phase drift’ also has a confusing mouse tip description: ‘Correct any clock drift detected between the two files’. So does it perform a fine, global subsample shift to perfectly match the files, and at the same time processes the content so that digital clock drifts are removed?

Sorry if this is a dumb question, I try to understand the processing as best as I can.

Also: Like KSTR I do simple analog out to in loopbacks, where AD/DA run from the same clock. So there is no clock drift between the files at all. Clock drift says 0ppm, but the graph is an up and down of 0.001 whatsoever (unit, please)? Does that cause computation errors that could be avoided if there were an option to disable clock drift correction, but keep the always necessary sub-sample alignment?

 

[pkane]

Step 2. ‘Correct phase drift’. I wonder if a better name would be ‘Correct Phase Offset’. Isn't option 5, Non-Linear Phase EQ, the ‘phase drift correction’?

‘Correct phase drift’ also has a confusing mouse tip description: ‘Correct any clock drift detected between the two files’. So does it perform a fine, global subsample shift to perfectly match the files, and at the same time processes the content so that digital clock drifts are removed?

Sorry if this is a dumb question, I try to understand the processing as best as I can.

Also: Like KSTR I do simple analog out to in loopbacks, where AD/DA run from the same clock. So there is no clock drift between the files at all. Clock drift says 0ppm, but the graph is an up and down of 0.001 whatsoever (unit, please)? Does that cause computation errors that could be avoided if there were an option to disable clock drift correction, but keep the always necessary sub-sample alignment?

Step 2 actually does both, clock drift and sub-sample alignment. Units in the clock drift plot are in samples. 0.001 means that at that time the samples are offset by 1/1000 of a sample.

 

[MC_RME]

Thanks. Looks like I can answer my other question. It seems activating 'Measure simple waveforms' deactivates clock drift correction, but not sub-sample alignment.

 

[pkane]

Thanks. Looks like I can answer my other question. It seems activating 'Measure simple waveforms' deactivates clock drift correction, but not sub-sample alignment.

No, measure simple waveforms just changes the algorithm used for cross-correlation and clock drift computation. Periodic signal that repeats over multiple time periods can't be uniquely matched by cross-correlation, that's why there's a need for a different approach for simple generated signals that repeat over time.

 

[pkane]

Thanks. Looks like I can answer my other question. It seems activating 'Measure simple waveforms' deactivates clock drift correction, but not sub-sample alignment.

If you're trying to do sub-sample alignment without clock drift correction and without phase EQ, then that's not a selectable option at the moment. I can add a separate option to turn on/off sub-sample alignment, if that will help.

 

[MC_RME]

Don't think so. I think I found a problem with PK Metric and will send a PM first.

 

[KSTR]

If you're trying to do sub-sample alignment without clock drift correction and without phase EQ, then that's not a selectable option at the moment. I can add a separate option to turn on/off sub-sample alignment, if that will help.

Ah, that explains it. I almost never use non-sample-sync'ed data so that's why I turned clock drift correction off.

 

[pkane]

Ah, that explains it. I almost never use non-sample-sync'ed data so that's why I turned clock drift correction off.

I'll add a separate option for sub-sample delay correction when clock drift is unselected.

 

[KSTR]

I occasionally get hard program hangs during playback of the residual. Typically when it has stopped at the end and I want to start it again, status line displaying 00:59, 00:00 remaing when I play a 60s snippet with a 180s start offset (of long enough enough wav files).
The program seems to update its settings on exit only, so changes are lost after aborting.
0% cpu, 1GB of memory used, in this case.

 

[pkane]

I occasionally get hard program hangs during playback of the residual. Typically when it has stopped at the end and I want to start it again, status line displaying 00:59, 00:00 remaing when I play a 60s snippet with a 180s start offset (of long enough enough wav files).
The program seems to update its settings on exit only, so changes are lost after aborting.
0% cpu, 1GB of memory used, in this case.

What kind of audio driver is it? I've had a few occasions where WASAPI would not terminate for whatever reason. You can save settings and load new ones if you want at any time, but yes, changes you make during a session are auto-saved only on exit.

 

[KSTR]

I've just used the default which is WASAPI, and the explanation sounds logical. Will use ASIO from now on.