DeltaWave null-testing audio comparator (beta)

[pkane2001]

1 hour ago, fas42 said:

 

Just to echo Dennis's findings here - manual correction makes a better fist of things so many times, and it's the offset that is quite obviously out, just from eyeballing in the Matched panel. Merely by adjusting by the displacement observed in the visuals, a far improved alignment is achieved - this should be detectable by the software, and used for fine tuning matching.

 

I agree. And I thought it was doing that already, but apparently not in all cases. I'll see what I can do to improve this.

 

Quote

On another note, have you had any thoughts on trying to compensate for non-uniform group delay, Paul?

 

I actually had this as a feature early on. It was very hard to measure this kind of error precisely given the short samples DW usually works with. With only a few minutes of a recording, the precision was low enough to cause a larger error after correction than before. But, I did do a lot to increase the precision of the calculation since then, so it might be worth another try

 

[pkane2001]

7 hours ago, esldude said:

Again while working with Archimago's files I'm finding in nearly every case the sample offset can be done manually to 1 or 2 or sometimes more samples and get a better match. As if the sample offset has a problem or something about these files is causing a hiccup.  The results improve when you do this.  This btw is working on samples I've changed speed upon to get it less than 10 ppm different.  It happens with the unchanged version as well.  The change in speed by Deltawave seems on the money, but then it applies a wrong offset.  

 

When I use other files I'm not having this problem.  I've been trimming one or two seconds off the front which helps some.  But still the wrong offset is a persistent problem.  

 

Dennis, can you please give me an example of two files where this extra offset is necessary? (or Frank @fas42)? I'd like to make sure I can reproduce what you are seeing.

 

Also, I'm getting a significantly different result than you on the Archimago's files. For example, you posted:

Quote

Difference (rms) = -41.87dB [-45.68dBA]
Correlated Null Depth=49.56dB [47.91dBA]

 

For the same two files, I get this:

 

Difference (rms) = -57.51dB [-61.76dBA]
Correlated Null Depth=62.68dB [66.65dBA]

 

Not sure what’s different, as I tried to use the same settings as you.

 

And I think I do have the fix for the oscillations you noticed past the sharp filter cutoff. I'll post this in a bit:

 

[fas42]

Okay, I just arbitrarily grabbed two versions of the Crowd Chant track, A and B; and trimmed 50 secs off the end, to reduce processing load. These were WAV versions, which Audacity produced for me:

 

DeltaWave v1.0.30, 2019-05-26T16:59:00.4333665+10:00
Reference:  B - CC-01.wav[L] 3944448 samples 96000Hz 16bits, stereo, MD5=00
Comparison: A - CC-01.wav[L] 3950592 samples 96000Hz 16bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:262144, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:Blackman, Spectrum Size:524288
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=50s
Discarding Comparison: Start=0s, End=50s

Initial peak values Reference: -2.812dB   Comparison: -3.44dB
Initial RMS values Reference: -16.606dB   Comparison: -16.657dB

Null Depth=22.065dB
X-Correlation offset: 15 samples
Drift computation quality, #1: Excellent (0.45μs)

Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -2.812dB   Comparison: -3.557dB
Final RMS values Reference: -16.606dB   Comparison: -16.777dB

Gain= 0.1213dB (1.0141x) DC=0 Phase offset=0.194751ms (18.696 samples)
Difference (rms) = -30.75dB [-30.44dBA]
Correlated Null Depth=37.26dB [31.59dBA]
Clock drift: -3.78 ppm

Files are NOT a bit-perfect match (match=0.08%) at 16 bits
Files match @ 49.9861% when reduced to 4.95 bits

RMS of the difference of spectra: -113.825165773536dB
gn=0.986137024409971, dc=-1.33086695197182E-06, dr=-3.781838E-06, of=18.696127166

DONE!

Signature: a3fe46aa1f941d596ca853664dfa40e5

 

 

The comparison waveform was consistenly lagging by about 2.1 samples through the whole Matched panel,

 

 

 

 

 

[esldude]

On 5/25/2019 at 8:14 PM, pkane2001 said:

 

Dennis, can you please give me an example of two files where this extra offset is necessary? (or Frank @fas42)? I'd like to make sure I can reproduce what you are seeing.

 

Also, I'm getting a significantly different result than you on the Archimago's files. For example, you posted:

 

For the same two files, I get this:

 

Difference (rms) = -57.51dB [-61.76dBA]
Correlated Null Depth=62.68dB [66.65dBA]

 

Not sure what’s different, as I tried to use the same settings as you.

 

And I think I do have the fix for the oscillations you noticed past the sharp filter cutoff. I'll post this in a bit:

 

I don't know what the difference is.  I get near your results if I use the 30 ppm slowed file for compare.  Nowhere close for the non speed corrected file.  I'm including the results page here and checked MD5 checksum.  So you can see if we indeed have the same files or not.   Also will include a screen shot.  I do noticed the MS of offset is very slightly different between yours and mine. 

 

 

DeltaWave v1.0.30, 2019-05-26T20:39:03.6116467-05:00
Reference:  D - Crowd Chant.flac[L] 8747008 samples 96000Hz 24bits, stereo, MD5=20e71bf32010376c2b91b42cae62ece4
Comparison: A - Crowd Chant.flac[L] 8761344 samples 96000Hz 24bits, stereo, MD5=f1cdf415085ed847759e4b502a4cf2e2
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -144dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:65536
    Spectrogram Window:BlackmanHarris, Spectrogram Size:4096, Spectrogram Steps:4096
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=0s
Discarding Comparison: Start=0s, End=0s

Initial peak values Reference: -3.167dB   Comparison: -3.441dB
Initial RMS values Reference: -16.38dB   Comparison: -16.473dB

Null Depth=13.067dB
X-Correlation offset: -14935 samples
Drift computation quality, #1: Excellent (0.62μs)

Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -3.167dB   Comparison: -3.418dB
Final RMS values Reference: -16.38dB   Comparison: -16.725dB

Gain= -0.0179dB (0.9979x) DC=0 Phase offset=-155.671577ms (-14944.471 samples)
Difference (rms) = -36.46dB [-39.58dBA]
Correlated Null Depth=54.44dB [82.79dBA]
Clock drift: 33.29 ppm

Files are NOT a bit-perfect match (match=0.41%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files match @ 49.9917% when reduced to 7.94 bits

Phase difference (full bandwidth): 43.0735971347464°
                 0-10,000Hz: 64.629845836155°
                 0-20,000Hz: 45.7120284473142°
                 0-24,000Hz: 41.7291928068088°
                 0-44,100Hz: 34.5564258887453°
                 0-48,000Hz: 43.0735971347464°
RMS of the difference of spectra: -84.2579577220821dB
gn=1.00206204776414, dc=0, dr=3.3289789E-05, of=-14944.4713477928

DONE!

Signature: 7dc1e64a6ac1e672c4bda03833c02735

 

 

 

[esldude]

Results using speed adjusted compare file.   I also used auto trim which improved results about 3 db. 

 

DeltaWave v1.0.30, 2019-05-26T21:27:04.0694268-05:00
Reference:  D - Crowd Chant.flac[L] 8747008 samples 96000Hz 24bits, stereo, MD5=20e71bf32010376c2b91b42cae62ece4
Comparison: A - Crowd Chant 30 ppm slo.wav[L] 8762827 samples 96000Hz 24bits, stereo, MD5=0915995c80b41fecc81190db862eed3a
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -144dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:16384
    Spectrogram Window:BlackmanHarris, Spectrogram Size:4096, Spectrogram Steps:4096
    Dither:False
    Trim Silence:True

Discarding Reference:  Start=0s, End=0s
Discarding Comparison: Start=0s, End=0s

Initial peak values Reference: -3.167dB   Comparison: -3.436dB
Initial RMS values Reference: -16.38dB   Comparison: -16.473dB

Null Depth=13.742dB
X-Correlation offset: -14944 samples
Trimming 0 samples at start and 1 samples at the end that are below -90.31dB level

Drift computation quality, #1: Excellent (0.68μs)

Trimmed 93177 samples ( 970.59375ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -3.167dB   Comparison: -3.351dB
Final RMS values Reference: -16.357dB   Comparison: -16.357dB

Gain= -0.085dB (0.9903x) DC=0 Phase offset=-155.672959ms (-14944.604 samples)
Difference (rms) = -57.14dB [-60.96dBA]
Correlated Null Depth=65.23dB [68.82dBA]
Clock drift: 3.29 ppm

Files are NOT a bit-perfect match (match=0.78%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files match @ 50.0175% when reduced to 9.43 bits

Phase difference (full bandwidth): 33.6468912334159°
                 0-10,000Hz: 65.4363632952387°
                 0-20,000Hz: 46.2863545911077°
                 0-24,000Hz: 42.2526792438908°
                 0-44,100Hz: 33.2056720476031°
                 0-48,000Hz: 33.6468912334159°
RMS of the difference of spectra: -87.86810016035dB
gn=1.00983540437225, dc=6.14371468395743E-07, dr=3.286429E-06, of=-14944.6040518008

DONE!

Signature: 395c485f162ef9a499460e7ef79c8d79

[esldude]

Here is a nice little bug I just noticed.  Unrelated to the other things in Arch's files I assume. 

 

I just ran a match and will show first Original spectra and then Matched spectra.  They are slightly different plus the noise up high in the Matched spectrum. 

 

 

 

Now I do one thing.  I check the microseconds box.  The Original spectra now shows the Matched spectra.  Unchecking microseconds or swapping around doesn't change that.  Original Spectra shows Matched spectra until you run a new match.  

 

 

 

[pkane2001]

1 hour ago, esldude said:

I don't know what the difference is.  I get near your results if I use the 30 ppm slowed file for compare.  Nowhere close for the non speed corrected file.  I'm including the results page here and checked MD5 checksum.  So you can see if we indeed have the same files or not.   Also will include a screen shot.  I do noticed the MS of offset is very slightly different between yours and mine. 

 

 

DeltaWave v1.0.30, 2019-05-26T20:39:03.6116467-05:00
Reference:  D - Crowd Chant.flac[L] 8747008 samples 96000Hz 24bits, stereo, MD5=20e71bf32010376c2b91b42cae62ece4
Comparison: A - Crowd Chant.flac[L] 8761344 samples 96000Hz 24bits, stereo, MD5=f1cdf415085ed847759e4b502a4cf2e2
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -144dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:65536
    Spectrogram Window:BlackmanHarris, Spectrogram Size:4096, Spectrogram Steps:4096
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=0s
Discarding Comparison: Start=0s, End=0s

Initial peak values Reference: -3.167dB   Comparison: -3.441dB
Initial RMS values Reference: -16.38dB   Comparison: -16.473dB

Null Depth=13.067dB
X-Correlation offset: -14935 samples
Drift computation quality, #1: Excellent (0.62μs)

Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -3.167dB   Comparison: -3.418dB
Final RMS values Reference: -16.38dB   Comparison: -16.725dB

Gain= -0.0179dB (0.9979x) DC=0 Phase offset=-155.671577ms (-14944.471 samples)
Difference (rms) = -36.46dB [-39.58dBA]
Correlated Null Depth=54.44dB [82.79dBA]
Clock drift: 33.29 ppm

Files are NOT a bit-perfect match (match=0.41%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files match @ 49.9917% when reduced to 7.94 bits

Phase difference (full bandwidth): 43.0735971347464°
                 0-10,000Hz: 64.629845836155°
                 0-20,000Hz: 45.7120284473142°
                 0-24,000Hz: 41.7291928068088°
                 0-44,100Hz: 34.5564258887453°
                 0-48,000Hz: 43.0735971347464°
RMS of the difference of spectra: -84.2579577220821dB
gn=1.00206204776414, dc=0, dr=3.3289789E-05, of=-14944.4713477928

DONE!

Signature: 7dc1e64a6ac1e672c4bda03833c02735

 

 

 

 

Thanks for posting these, Dennis.

 

File hashes are the same, so that's not the issue. Let me finish troubleshooting the offset discrepancy, and then I may need your help to run the same tests again with the new version. Perhaps this is caused by the same bug that's occasionally messing with the offset calculation.

[fas42]

Something to add to the ToDo list ... the Recent Anaysis list is good, but it doesn't show the Comparison file in the dropdown; often the Reference file is the same, I have about 5 of the nominally same analysis to pick from the list. Perhaps something like "<Reference Path>; .../<Comparison File Name>"?

[esldude]

Related to my last post about mixing up Original and Matched spectra.  If you run the match with the microseconds box checked.  Everything is fine.  If you then uncheck microseconds, it also begins showing the Matched spectra in both Matched and Original spectra.  So the bug shows up if you change the microseconds check box no matter which way you approach it. 

[fas42]

1 hour ago, esldude said:

Related to my last post about mixing up Original and Matched spectra.  If you run the match with the microseconds box checked.  Everything is fine.  If you then uncheck microseconds, it also begins showing the Matched spectra in both Matched and Original spectra.  So the bug shows up if you change the microseconds check box no matter which way you approach it. 

 

Dennis, see my post here,

about this, and Paul's reply.

[pkane2001]

8 hours ago, fas42 said:

Something to add to the ToDo list ... the Recent Anaysis list is good, but it doesn't show the Comparison file in the dropdown; often the Reference file is the same, I have about 5 of the nominally same analysis to pick from the list. Perhaps something like "<Reference Path>; .../<Comparison File Name>"?

 

I thought about it, but the name will become too long with file path listed. I agree it can be useful, especially when comparing multiple versions of the file to the same reference. Let me see what it looks like.

 

[pkane2001]

8 hours ago, esldude said:

Related to my last post about mixing up Original and Matched spectra.  If you run the match with the microseconds box checked.  Everything is fine.  If you then uncheck microseconds, it also begins showing the Matched spectra in both Matched and Original spectra.  So the bug shows up if you change the microseconds check box no matter which way you approach it. 

 

Yes, it's just limited by how much data I can keep in memory from the match operation. Each copy of a waveform adds a significant amount, especially for higher resolution files. I'll change this to show blank plots where there is no data available to avoid confusion.

[pkane2001]

Here's an early (pre-release) version of DW 1.0.31, with the changes meant to address the issues brought up in the last couple of days by @fas42 and @esldude. This includes a fix for large oscillations at the point of a sharp filter cutoff in some hi-res files, and an incorrect offset reported for some comparisons.

 

Primarily, I'd like to verify that this is working as expected on more files, those that you have run previously. I've tested this on my standard suite of tests, including Archimago's blind test, and it appears to be working well. But, there may be still some combination of inputs where it may not behave as expected. If you find some strange behavior, please post the details and the results text.

 

https://drive.google.com/open?id=1yM41F5_g1gdNeBcrQhxb3hIiuaBbfB5-

 

Thank you!

 

PS: I'm aware that the Manual Adjustment window results may produce a slightly different outcome when Applied again, even with the exactly the same set of parameters. This is due to the changes to fix the offset issue. I'll try to correct this before releasing the next update.

[fas42]

9 hours ago, pkane2001 said:

 

I thought about it, but the name will become too long with file path listed. I agree it can be useful, especially when comparing multiple versions of the file to the same reference. Let me see what it looks like.

 

 

That's why I suggested "<Reference Path>; .../<Comparison File Name>" , above.

 

An actual example: "D:\DELLTOP\My\downloads\Audio\Sounds\CA\Bob Marley\Bob Marley original.wav; ...\Bob Marley 1st gen.wav". Most times the comparison file will be in the same directory, so should be enough for most situations.

[pkane2001]

3 minutes ago, fas42 said:

 

That's why I suggested "<Reference Path>; .../<Comparison File Name>" , above.

 

An actual example: "D:\DELLTOP\My\downloads\Audio\Sounds\CA\Bob Marley\Bob Marley original.wav; ...\Bob Marley 1st gen.wav". Most times the comparison file will be in the same directory, so should be enough for most situations.

 

Let me know how you like it in v.31

 

 

[esldude]

Now that I've had sufficient BBQ, I've a chance to try this new version out.  Looks to be right as rain.  Everything looks good so far.  Much better results, no weirdness.  Offset seems dead on.  I can change the offset by one more or one less on the smallest decimal and I get identical results and they are less good than the default.  Makes me think offset if dead on.  Same for drift rate.  

 

Also the results are very nearly identical whether on files that differ by 34 ppm or one I've slowed by 30 ppm.  

 

And showing both file paths in the Recent analysis tab is much nicer. 

 

Thanks. 

[fas42]

Sorry I didn't get back earlier, Paul; busy sorting out a fallen tree, . Haven't given it a thorough run through, but like Dennis, all looks good so far - Recent Analysis layout is fine.

[esldude]

4 hours ago, fas42 said:

Sorry I didn't get back earlier, Paul; busy sorting out a fallen tree, . Haven't given it a thorough run through, but like Dennis, all looks good so far - Recent Analysis layout is fine.

Was wondering how long that tree would take you.  Glad it wasn't multiple days.  Had that problem each of the last two years.  Amazing how much wood is in a moderate sized tree once it hits the ground. 

[pkane2001]

Decided to release 1.0.31 unchanged from the previously posted preview, since the feedback was so positive

 

https://deltaw.org/release_notes_1.0b.html#changes-in-1031b

 

I'm working on a few additions for the next release:

• Improve manual adjustment window to make sure the processing matches the main window results
• Process synthetic/repeating waveforms for measurement purposes. I've found what I think is a solution, but need to implement and test it
• Work on a better notch filter implementation, the one I have implemented has a fairly low level of rejection

[fas42]

19 hours ago, esldude said:

Was wondering how long that tree would take you.  Glad it wasn't multiple days.  Had that problem each of the last two years.  Amazing how much wood is in a moderate sized tree once it hits the ground. 

 

Ummm, I cheated. It was an insurance job, because the tree was adjacent to the carport, and nicely leant itself on that structure - so, get the cars out, and start ringing. Went from insurance mob to home builder to aborist, who turned up, and judged that only a crane could handle it. A 10 ton crane arrived, and needed to work out how to access that tree, because there are quite a few trees on our block; it ended up going down a laneway, and parking in a neighbour's drive, who I had summon from a bath so he could get his car out of the way, . Crane hoisted the tree upright, and then the operation became a vertical sawbench; drop the tree so far, slice off the bottom with chainsaw, and repeat. Also did a nearby dead tree, which the neighbour was concerned with.

 

Still have to tidy up the mess of timber; we have a slow combustion fire, so that takes care of heating requirements for another year or two or three, .

 

Now, have to sort the carport ...

[fas42]

A minor issue ... I use the Set custom zoom level button to get an easy readout of offsets, and when the axes are unlocked, this button is disabled.

[fas42]

Been looking at the Crowd Chant tracks B and C from Archimago's samples, and group delay differences are preventing a good nulling. As a experiment, using trial and error adjusting of the delays of one track as a function of frequency so that they are a much closer match, this allows DW to achieve a much better null.

 

The before comparison, which used upsampling and just a short snippet yielded this - no manual tuning,

 

 

Note the sharply upturned tail at the end of the audible spectrum, which doesn't exist in the original spectrums; caused by the changing group delay at above about 8kHz.

 

Now, with that phase variation compensated for in the comparison file, and again no manual adjustments,

 

 

There's a sharp peak right at the end of the audible BW because the phase adjustment could only work up to exactly 20kHz, and no further.

 

This indicates that including varying delay compensation in DW would be very useful, in terms of achieving deeper nulls ...

[pkane2001]

3 hours ago, fas42 said:

Been looking at the Crowd Chant tracks B and C from Archimago's samples, and group delay differences are preventing a good nulling. As a experiment, using trial and error adjusting of the delays of one track as a function of frequency so that they are a much closer match, this allows DW to achieve a much better null.

 

The before comparison, which used upsampling and just a short snippet yielded this - no manual tuning,

 

 

Note the sharply upturned tail at the end of the audible spectrum, which doesn't exist in the original spectrums; caused by the changing group delay at above about 8kHz.

 

Now, with that phase variation compensated for in the comparison file, and again no manual adjustments,

 

 

There's a sharp peak right at the end of the audible BW because the phase adjustment could only work up to exactly 20kHz, and no further.

 

This indicates that including varying delay compensation in DW would be very useful, in terms of achieving deeper nulls ...

 

What kind of nulls are you seeing (without making any manual adjustments vs with)? Did you try engaging non-linear EQ correction? 

[pkane2001]

4 hours ago, fas42 said:

Been looking at the Crowd Chant tracks B and C from Archimago's samples, and group delay differences are preventing a good nulling. As a experiment, using trial and error adjusting of the delays of one track as a function of frequency so that they are a much closer match, this allows DW to achieve a much better null.

 

The before comparison, which used upsampling and just a short snippet yielded this - no manual tuning,

 

 

Note the sharply upturned tail at the end of the audible spectrum, which doesn't exist in the original spectrums; caused by the changing group delay at above about 8kHz.

 

Now, with that phase variation compensated for in the comparison file, and again no manual adjustments,

 

 

There's a sharp peak right at the end of the audible BW because the phase adjustment could only work up to exactly 20kHz, and no further.

 

This indicates that including varying delay compensation in DW would be very useful, in terms of achieving deeper nulls ...

 

I tried a variation on the non-linear EQ that also adjusts phase, not just amplitude. Seems promising.

 

Here's the result of matching the two files with non-linear EQ engaged, as it exists in the current .31 version:

 

 

And here's the result using the amplitude and phase EQ (feature coming in the next version). Seems to produce an 8-9dB better null with phase correction:

 

I often try out the non-linear EQ function to see if the results will be improved. Sometimes they are, sometimes not by much. But I think these settings are a bit out of character for DeltaWave. They compensate for frequency and phase errors that really are true, complex, and possibly audible, errors. While I can certainly add more non-linear correction functions (and I'll do that, just for fun  ), I see these as not being useful for the main purpose of what DeltaWave is designed to do: finding differences between two waveforms. 

 

[fas42]

1 hour ago, pkane2001 said:

 

What kind of nulls are you seeing (without making any manual adjustments vs with)? Did you try engaging non-linear EQ correction? 

 

Will try that, anon. No, EQ correction not turned on.

 

I'm particularly interested in getting the best nulling at the HF end, because I find that's "where the action is", in determining SQ. In the above exercise, there's almost 40dB better nulling at the top of the audio spectrum - which I find very worthwhile .

 

Quote

I often try out the non-linear EQ function to see if the results will be improved. Sometimes they are, sometimes not by much. But I think these settings are a bit out of character for DeltaWave. They compensate for frequency and phase errors that really are true, complex, and possibly audible, errors. While I can certainly add more non-linear correction functions (and I'll do that, just for fun  ), I see these as not being useful for the main purpose of what DeltaWave is designed to do: finding differences between two waveforms.  

 

Very pleased that phase correction is coming up ... what I would like to see are the best facilities for linear distortion adjustment, using frequency and phase manipulation, thus leaving mostly non-linear distortion as the remainder after doing a comparison. Reason being, IME this is where the important stuff lies ....