Beta-test: DeltaWave Null Comparison software

[pkane]

Ah, sorry, gain error test file to come... (if that was the message).
EDIT: It wasnt ;-) x-posting micro-timing issue, haha

Ah, yes, need the reference/comparison files to run the test

 

[KSTR]

Gain modulation test file (left: original, right: modulated, and seperate modulator file)

The low frequency gain modulator (10 seconds, otherwise Audition's display goes corrupt):

DW's display (showing the modulation envelope clearly in the diff, note the full cancellation at the points where the modulator was exactly 1.0):

Time axis values look a bit funny, though ;-) Values are displayed correctly when zooming in.

The "gain error" graph is a bit harder to correlate visually, due to the low number of measurement points shown. Also, it does show the signal level difference rather than the ratio, which makes the plot looking additionally modulated by the signal envelope. It took me some time to figure this out (note: for a noise file with quasi-constant level/envelope this is less of an issue, though).
Suggestion, maybe rename to "delta level"? And add the ratio plot as new "gain error" since "gain" is more associated with a factor.

 

[pkane]

New version of DeltaWave is available: v1.0.57

Changes in this version:

• Added: ERB trend-line option for FFT plots in settings
• Added: PK Error Metric and plot
• Changed: phase unwrap behavior and algorithm

PK Error Metric is a beta version of a new audibility metric meant to supplement the more engineering-focused RMS error metric. I'll start a new thread to describe and to get feedback on it. Here's an example:

ERB-smoothed trend-lines for frequency plots can be enabled in Settings:

The trend-line looks like this:

 

[pkane]

Just started the PK Error Metric thread with some details on the new metric and request for feedback.

 

[KSTR]

Trendline feature is cool, thanks.

I'm having a issue with trimming and/or FLAC. Convert any FLAC to WAV, load in DW, compare without trimming --> all is fine (identical files reported, in all details).

Trimming one second at start and end of both files gives strange results. Sample counts start to differ, random sample offsets are introduced (visible in the raw waveforms). Matchings still works, though.

 

[KSTR]

And, trend-line labelled "group delay" in phase plot.

 

[KSTR]

Phase-Unwrapping looks suspicious.
Using compare=reference, but manually shifting compare by +3 samples:

Testfile is the one from post #456 (using L-channel for ref and comp)

 

[pkane]

Trendline feature is cool, thanks.

I'm having a issue with trimming and/or FLAC. Convert any FLAC to WAV, load in DW, compare without trimming --> all is fine (identical files reported, in all details).

Trimming one second at start and end of both files gives strange results. Sample counts start to differ, random sample offsets are introduced (visible in the raw waveforms). Matchings still works, though.

View attachment 108955

It's possibly due to the differences in file format. Trimming is done while reading the file (to avoid loading unnecessary samples into memory), and may not be exactly the number you request if the two files are stored in different-size blocks, say due to different file formats. Something I should look at fixing. The auto-trim option takes care of the differences at the beginning and the end, so I've never bothered to make file read more precise, up to the sample.

 

[pkane]

And, trend-line labelled "group delay" in phase plot.
View attachment 108958

That's actually what it represents in the phase plot, and what it's been labeled as before, so I kept it.

 

[pkane]

Phase-Unwrapping looks suspicious.
Using compare=reference, but manually shifting compare by +3 samples:
View attachment 108961
Testfile is the one from post #456 (using L-channel for ref and comp)

Interesting. The trend (group delay line) is computed from the unwrapped phase, as well, and that is obviously computed correctly, so I may have inadvertently left some old code in the plot unwrap function. Let me check on that.

 

[KSTR]

That's actually what it represents in the phase plot, and what it's been labeled as before, so I kept it.

Hhm, does not compute, in my book. Phase and Group Delay describe the same thing (except for any constant in the phase that is dropped when doing gd(f)=-d(ph(f))/df. But they don't have the same units and generally never have the same shape.
There seems to be some form of misunterstanding here between us regarding the terminology. I'm fine with whatever you do, though ;-)

 

[pkane]

Hhm, does not compute, in my book. Phase and Group Delay describe the same thing (except for any constant in the phase that is dropped when doing gd(f)=-d(ph(f))/df. But they don't have the same units and generally never have the same shape.
There seems to be some form of misunterstanding here between us regarding the terminology. I'm fine with whatever you do, though ;-)

Variable Group Delay is what this represents.

 

[KSTR]

It's possibly due to the differences in file format. Trimming is done while reading the file (to avoid loading unnecessary samples into memory), and may not be exactly the number you request if the two files are stored in different-size blocks, say due to different file formats. Something I should look at fixing. The auto-trim option takes care of the differences at the beginning and the end, so I've never bothered to make file read more precise, up to the sample.

Understood, that's where the offset is comming from. Position seeking in a compressed format is always a hassle ;-)

 

[pkane]

Understood, that's where the offset is comming from. Position seeking in a compressed format is always a hassle ;-)

Not a big hassle, just me being lazy By the way, trimming at the front of the file works exactly as you'd expect, up to the sample. It's the end trim that may wind up including more samples than needed if the desired size doesn't end at the end of a file block.

 

[KSTR]

It's the end trim that may wind up including more samples than needed if the desired size doesn't end at the end of a file block.

Good to know. I had some strange result that a marker pulse that was only 10 samples away from the end of the file wasn't trimmed (with a 0.1sec setting) in the flac while the wav was OK, spoiling things.
Er, would unchecking "trim from end" fix it, or does this only change the calculation of the trim point but not the algorithm?

 

[pkane]

Good to know. I had some strange result that a marker pulse that was only 10 samples away from the end of the file wasn't trimmed (with a 0.1sec setting) in the flac while the wav was OK, spoiling things.
Er, would unchecking "trim from end" fix it, or does this only change the calculation of the trim point but not the algorithm?

No, the same problem with or without "trim from end." I've already fixed it, it turned out to be simpler than I thought. My laziness, as it turns out, wasn't justified

 

[KSTR]

Spent the last two hours searching/reading the whole thread to collect information what the program is actually doing on a more detailed level.
Still many many white spots for me.
For example, I couldn't locate info nor could I figure out myself what the @start, @end and @start/end qualifiers in the filter section mean/do?

 

[pkane]

Spent the last two hours searching/reading the whole thread to collect information what the program is actually doing on a more detailed level.
Still many many white spots for me.
For example, I couldn't locate info nor could I figure out myself what the @start, @end and @start/end qualifiers in the filter section mean/do?

@start means apply the filter before any matching/processing, @end means after all matching/corrections are completed. @start&end means apply both.

 

[KSTR]

OK, pre/post processing basically, I hope I will remember....

 

[KSTR]

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.