Beta-test: DeltaWave Null Comparison software

[KSTR]

@pkane, I think it depends on the use case, so may worth an option parameter?

My thinking is:
I load Ref==Comp, then Show, then apply gain=0.5 (to Comp) deliberately mis-match it.
Linearity should then should show up as a straight horizontal line (== perfectly linear) at -6.02dB as that is Comp's difference to Ref. Comp's level, values are all 6dB down at any Bit level but still a linear mapping.

Or, in my use case: I do a match that obtains a coarse gain for Comp, and then correct the gain by the amount the Linearity is off from 0dB in the region of interest. The initial gain was obtained from minimizing the diff in the first place (rms) but that optimized for a best Null overall and not neccessarily for a best Null in the region of interest.

A workaround, and that's what I did before I discovered the power of the linearity plot, is to do the match only on the quieter sections of the music and then apply it to the whole data but then again we don't know if there is any long enough quiet section (unless I stich some sections together before). Shifting the gain (with the dB value obtained from the plot) was very simple and reliable algorithm no matter the content. And there it was convenient to have the gain change reflected in the plot, also for presentation.

BTW, could you give a short summary how the linearity plot is actually calculated and what signal properties affect it, as that is not immediately clear?

 

[KSTR]

Looking at some more examples with the new version, I now figure that you shift the linearity trendline to 0dB at the highest level found so that the 0.5dB threshold detector (as output in the caption) has a baseline to work on, a normalisation basically. That explains why reading the corrective gain from the plot does not work as expected now because there is an additional offset, unknown to the user ;-)

 

[pkane]

Looking at some more examples with the new version, I now figure that you shift the linearity trendline to 0dB at the highest level found so that the 0.5dB threshold detector (as output in the caption) has a baseline to work on, a normalization basically. That explains why reading the corrective gain from the plot does not work as expected now because there is an additional offset, unknown to the user ;-)

You got it! I added the logic to normalize the first few bits to the zero dB line, removing any constant offset.

 

[KSTR]

So the fix/option would be to use that offset only for the threshold detector and leave it alone for the plot itself?

BTW, I think the plot is still showing Ref/Comp and not Comp/Ref (whicht would be more correct IMHO). I used a file (fading pink noise), applied some compressive odd order distortion so that the larger sample values come out with less than "unity gain" wrt Ref. Therefore, after a Show the linearity plot should be IMHO at 0dB for the lower bit levels, and going negative at the higher bit levels as those are softer in Comp.

 

[pkane]

I know... it's yet another release... v1.0.64 is now available.

The two notable changes are:

• Change: Added a View->Chart Options->Linearity index to 0 menu option to turn on/off linearity plot normalization (on by default)
• Added: FFT Scrubber processing and plot window with audio scrubbing

The first change is just for @KSTR

The second change is a way to view spectrum details using a scrubber control and short FFTs over time. This is almost like an unrolled spectrogram, except in 2-D, where you control which time interval you want to view. You can see only one interval at a time:

With the Signal control you can chose which Spectrum display you want to view: Reference & Comparison, Delta of Spectra or Spectrum of Delta.

Use the scrub control at the bottom by dragging the round ball across the time line (shown in seconds) or click anywhere on the control to jump to the desired time. The chart will update in real-time as you drag it around, and, of course you can zoom in or out and reposition the plot, as you can with all other plots in DeltaWave.

At the top, you can chose to play the sound of either Reference or Comparison waveforms whenever a new time interval is selected. Currently it will play for 1 second and stop, starting at the position where the chart starts as soon as you drag or click on a new scrub position. This is to give you an idea what part of the track the time interval represents.

The position display at the top shows the exact start of the interval used to compute the spectrum plot.

The FFT size for this chart is controlled by the spectrogram FFT setting (256 to 64k).

This is work in progress. I'm very open to suggestions on how to improve this view and whether it is useful. The reason I wanted to see the spectra this way is because the other spectrum plots in DW represent an average of frequencies across the entire track, which may hide some large but fast errors by averaging them out. Because the FFT Scrubber uses a short-time FFT plot (SFFT) some of the transient differences may be easier to catch.

 

[KSTR]

Linearity Plot Option : check ;-)

FFT Scrubbing : Slick feature! Currently I export the delta and FFT it in Audition (eg for sine sweep sections), so now that is integrated as well.
As far as I can see, the time spacing granularity is the SFFT block size, no overlap. Maybe one could use the spectrogram step size, for a finer granularity with larger SFFT sizes (like my usual 8k)? Bascally slicing the spectrogram in 2D view as is.
EDIT: And use autorepeat from keyboard for easier/faster scrolling. Currently you seem to use the final release event only, it seems (so as not to overrun the calculations and any enabled playback, I would guess... as it already happens when dragged with mouse).

Please ignore when you think this is too much feature creeping (which might produce some unforeseeable cluster fucks later ;-)

 

[pkane]

EDIT: And use autorepeat from keyboard for easier/faster scrolling. Currently you seem to use the final release event only, it seems (so as not to overrun the calculations and any enabled playback, I would guess... as it already happens when dragged with mouse).

I'll change the mouse wheel to move one SFFT frame at a time instead of jumping 20-30 seconds at a clip. It'll let you position more precisely without taking the hand off the mouse. Keyboard repeats can be a bit tricky to process.

 

[Pluto]

I'll change the mouse wheel to move one SFFT frame at a time instead of jumping 20-30 seconds at a clip. It'll let you position more precisely without taking the hand off the mouse

Talking of creeping featuritis... how about two user-definable jump rates on the wheel, the primary being the wheel alone and the secondary, holding down the control key while turning the wheel?

 

[pkane]

For your testing pleasure, I present DeltaWave v1.0.65b

Changes in 1.0.65b

• Added: Impulse Response averaging, correction, and export. Start of documentation is here https://deltaw.org/ir.html
• Added: Impulse Response plot with selectable units
• Added: Frequency response file exports in REW text format
• Changed: Reorganized File menu
• Added: In FFT Scrub control, hold down Control key while using mouse wheel to accelerate scrubbing by 50x
• Changed: selected zoom levels per chart are now saved with the settings and will be in effect next time DeltaWave is started
• Changed: added option to save/reload custom zoom settings for all plot windows
• Changed: Small adjustment in gain difference computation for improved accuracy

The biggest addition is the calculation and averaging of Impulse Response directly from nulled recorded music files -- a new (and previously undocumented) way of extracting IR. At least I could't find any references that describe this process! Documentation: https://deltaw.org/ir.html

IR can be pre-computed using one or more files averaged together and then saved to a file. The inverse of the resulting IR can be used in DeltaWave to correct for filter, phase, and frequency errors of a device. Alternatively, inverse IR can be exported as 32-bit WAV mono file to be used with a Convolver to correct for device time and frequency errors captured in the IR.

I expect this feature to take some time to mature, so please provide feedback and comments: I'm looking into improvements and any new and novel ways of using this technology! Some examples below.

IR extracted from a GearSlutz/GearSpace loopback recording of Eventide H9000R:

This one is from ADI-2 Pro FS (Sharp filter selected for DA/AD):

Another view of the same:

 

[pkane]

Here's an example of using the recorded, averaged IR to correct for device frequency/phase errors with ADI-2 Pro (16 averages).

Here's Sharp filter phase response, as measured without IR correction in DeltaWave:

And frequency response:

Now, using an average of 16 pre-computed IRs to correct for errors:

Phase (white line):

Frequency response:

Notice any improvement?

 

[KSTR]

Great, Paul!

Alas, I'm failing to get any result from it, and I feel a circular dependency here: The IR calc requires a match with the linear transfer function (LTF) factored out, and a match to do exactly this requires an IR?
The problem I'm having: In normal mode I cannot obtain a clean match, neither with Nonlinear Calibration off (obviously) nor with on (it cannot handle the very low frequency stuff, for example).
I was under the impression the IR extraction is there to exactly avoid the problematic Nonlinear Calibration alltogether and replace it with a better (less artifacts, etc) mechanism. So, the IR would be extracted from a match without Nonlinear Correction and then replaces it on future match attempts?

I have loopback files which are full frequency and "noiseless" (time-domain averaged), exactly trimmed etc, how would I use these, in order to compare the results to my own LTF-compensation, notably wrt cleanliness of the residual?

 

[KSTR]

Glitches: The Y-Axis of the IR view always labels as dB regardless of settings, and the values are garbage

dBFS:

Starting with -infinity where it should be close to 0dBFS. Looks like taking dB of |dBs| here.

in %:

The values itself are correct (at least the top value, 40dB == 100)

in V (though, how can DW know about Volts, anyway?):

I'd prefer two settings only: factor (not %) in linear view, and in log view (dBr, with r = 1) -- though almost never use log view for time-domain bipolar entities (which requires sign removal), does not make that much sense to me, with the occasional exception like examining decay in room response measurements and such.
Additionally, maybe a convolution with a unit step (--> step response), so that the LF region can be better visualized?

After some time, Impulse display comes up only as blank page. Restart required.

Samples display is not using sinc upsampling to mimic a reconstruction filter, just connecting the dots. Not that useful to gain more insight (this is also the case for the normal waveform displays).


With non-linear cal off, IR in add mode doesn't add an IR (counter does not update). Cycling through the IR button turns on non-linear cal in the background (no notice). OK, so be it, doing a match now. When I use this IR to redo the match without nonlin cal, it does nothing (does not apply it). With nonlin cal on, it also does nothing (same result as with no IR loaded). The exported IR is not a dirac, so something should have happened/changed?

 

[KSTR]

Test data here: https://www.dropbox.com/s/fmdhonbh7qvthdr, use "Orig.wav" and "S2-ba.wav".

The others are the versions with my LTF-comp via IR's applied criss-cross, IR's extracted from the sweep section. The goal for the new method is to approach that level of compensation wrt to artifacts (read: none, practically) and best possible Null so as to extract the distortion and "gain pumping".

 

[pkane]

Test data here: https://www.dropbox.com/s/fmdhonbh7qvthdr, use "Orig.wav" and "S2-ba.wav".

The others are the versions with my LTF-comp via IR's applied criss-cross, IR's extracted from the sweep section. The goal for the new method is to approach that level of compensation wrt to artifacts (read: none, practically) and best possible Null so as to extract the distortion and "gain pumping".

Hi Klaus,

To clarify a few things that may not have been obvious:

The IR extraction is using the non-linear EQ logic internally. This is still using the nulled versions of the two files to compute IR, so a null must be performed with the best possible settings to achieve the lowest null possible, including the non-linear calibration.

In effect, IR computation is an add-on to the non-linear EQ rather than a separate function or a replacement. For IR functionality to work, non-linear EQ must be engaged (and will be turned on automatically when you enable to collect or to use IR settings):

1. When collecting IR averages, both nonlinear-eq settings must be turned on (and will be by default). You can configure FFT settings but leave Level EQ and Phase EQ turned on:

2. When applying inverse IR, IR itself must be loaded into memory and FFT size must match the setting here. If not, DW will prompt you to change it. When applying inverse, one or both of the Level EQ and Phase EQ settings must be checked. You can chose to only correct phase or only correct frequency response, if desired. Normally, you'll want to keep both of them on.

3. I think I see the reason you're having problems with units: the plot uses the "In dB" setting at the top to change the Y axis to log-view. It appears this also happens if the units are already in dB so you get a log-log display Uncheck "In dB" setting and see if the units behave better in the IR plots. Uncheck the "dB" setting to get better units:

4. Yes, I intentionally didn't turn on sinc interpolation to speed up the display with millions of points. I'll see if this can be done without incurring too much of a delay.

5. I've not seen the IR plot go blank before. It will not show IR if no IR is loaded or it has been cleared. Sometimes the zoom level is such that between two IR computations the display could be pointing to a region where there's no data. Just click Reset Axis to get it zoomed out to see all of the data in that case. If you can reproduce this blank behavior at another time, please share the details (and the log file, accessible from Help->Logging->View Log menu).

6. "V" display is actually a misnomer, it's really just a factor from -1 to 1. I had started with dBV referenced to 1v, but then changed it to linear units, so kept the "V" designation. Would "Factor" be a better label for it in your opinion?

I'll try your data a little bit later today.

Regards,

-Paul

 

[pkane]

Additionally, maybe a convolution with a unit step (--> step response), so that the LF region can be better visualized?

If you're talking about limiting the frequency response of IR to a portion of the spectrum, you have two choices:

1. Turn on a low-pass/high-pass/band-pass filter in DeltaWave settings while collecting IR

2. Change the effective frequency range of IR computation in non-linear EQ settings:

That will have the same effect as a convolution with a step function.

Regards,

-Paul

 

[KSTR]

I'll try your data a little bit later today.

Yes, please... as of now, no matter what I try, I only get garbage results. And DW now hogs CPU big time (like several minutes for that 30second snippet).

dB scale: check.
empty panel: looks like this was user error (no IR --> no display ;-)

 

[pkane]

Yes, please... as of now, no matter what I try, I only get garbage results. And DW now hogs CPU big time (like several minutes for that 30second snippet).

dB scale: check.
empty panel: looks like this was user error (no IR --> no display ;-)

Trying your data, I get this, in a matter of a minute or less [EDIT: Sorry, just realized I used wrong files for comparison, let me try it the way you indicated]:

 

[pkane]

Yes, please... as of now, no matter what I try, I only get garbage results. And DW now hogs CPU big time (like several minutes for that 30second snippet).

dB scale: check.
empty panel: looks like this was user error (no IR --> no display ;-)

Comparing Orig2 to S2-ba.wav (took 20 seconds):

Here are the settings I used for this (note the FFT size, maybe you have a very large size selected?) Note, FFT of a large size will take some time the first time you use it. Next time should be a lot faster.

 

[KSTR]

Ahm, use "Orig.wav" (original) and "S2-ba.wav" (the loopback). The ones "*_X_*.wav" are the cross-convolved version (which can be used against each other, simple load only).

With your settings ("drift correction" is not needed, btw, all is sample-sync'ed) I get the usual scrambled artifact-laden residual as with any other nonlin correction setting, effectively unusable for my test case. OK, at least an IR is obtained, but how do I use it? As explained, re-running the match with IR set to "apply" does not change anything whatsoever. Where would it come into play actually, and how would it help to reduce the artifacts?

Somehow there is a fundamental misunderstanding (from my side) how this should work. I don't understand why the IR obtained can't simply be applied without anything else (plain load only), in the hope that the fixed global convolution with one single clean kernel should give lower artifacts, finally approching the quality of my method.

 

[pkane]

Ahm, use "Orig.wav" (original) and "S2-ba.wav" (the loopback). The ones "*_X_*.wav" are the cross-convolved version (which can be used against each other, simple load only).

With your settings ("drift correction" is not needed, btw, all is sample-sync'ed) I get the usual scrambled artifact-laden residual as with any other nonlin correction setting, effectively unusable for my test case. OK, at least an IR is obtained, but how do I use it? As explained, re-running the match with IR set to "apply" does not change anything whatsoever. Where would it come into play actually, and how would it help to reduce the artifacts?

Somehow there is a fundamental misunderstanding (from my side) how this should work. I don't undertand why the IR obtained can't simply be applied without anything else (plain load only), in the hope that the fixed global convolution with one single clean kernel should give lower artifacts, finally approching the quality of my method.

Creating an IR from a single nulled sample will be equivalent to doing a non-linear EQ on that sample, so no changes would be expected from previous attempts.

IR averaging is what is meant to help build a lower-noise IR. For that, you'll need to run more than a single match, against multiple captures while averaging IR responses.

PS: But I see what you're driving at. You want to compute IR without applying non-linear EQ. That should also be doable. Let me think about it.