DeltaWave null-testing audio comparator (beta)

[Arpiben]

@pkane2001

 

Hi Paul,

 

I had been comparing DW's spectra (different windows and FFT sizes) with the ones provided by another software Sonic Visualiser:

https://www.sonicvisualiser.org/download.html (full free).

I may be wrong but I am fearing that DW is not properly applying the windows/settings chosen in Spectrum parameters.

The anomalies I previously pointed out regarding increasing noise with frequency are normal, they may be emphasised by how one draw the lines in between  each  FFT bins ( Line/Step/Block/etc...).

 

Here the same 100 Hz file with a Blackman Harris 4 term:

 

 

I still hope that you can manage to add a 7 term Blackman-Harris window in order to have a quite clean -200 dB noise floor when requested.

 

Rgds.  

 

[pkane2001]

18 minutes ago, Arpiben said:

@pkane2001

 

Hi Paul,

 

I had been comparing DW's spectra (different windows and FFT sizes) with the ones provided by another software Sonic Visualiser:

https://www.sonicvisualiser.org/download.html (full free).

I may be wrong but I am fearing that DW is not properly applying the windows/settings chosen in Spectrum parameters.

The anomalies I previously pointed out regarding increasing noise with frequency are normal, they may be emphasised by how one draw the lines in between  each  FFT bins ( Line/Step/Block/etc...).

 

Here the same 100 Hz file with a Blackman Harris 4 term:

 

 

I still hope that you can manage to add a 7 term Blackman-Harris window in order to have a quite clean -200 dB noise floor when requested.

 

Rgds.  

 

 

Hi Arpiben,

 

I see some increasing amplitude jumps with higher frequencies, some approaching 4-5dB in size in Sonic Visualizer (something MusicScope didn't show).

 

Isn't that what you thought the problem was with DW? DW just connects dots with lines, there's no interpolation or smoothing in the FFT chart.

 

[Arpiben]

29 minutes ago, pkane2001 said:

 

Hi Arpiben,

 

I see some increasing amplitude jumps with higher frequencies, some approaching 4-5dB in size (something MusicScope didn't show).

 

Isn't that what you thought the problem was with DW? DW just connects dots with lines, there's no interpolation in the FFT chart.

 

Yes correct.  I have same behaviour with Sonic Visualizer when connecting dots with lines. Using steps or blocks reduces them.

I also played with overlapping/oversampling but it doesn't improve the presentation.

Musicscope due to its improved windowing do not allow us to see it, i guess.

 

Now the windows types are not matching between DW and Sonic Visualizer.

  

 

[pkane2001]

2 hours ago, Arpiben said:

 

Yes correct.  I have same behaviour with Sonic Visualizer when connecting dots with lines. Using steps or blocks reduces them.

I also played with overlapping/oversampling but it doesn't improve the presentation.

Musicscope due to its improved windowing do not allow us to see it, i guess.

 

Now the windows types are not matching between DW and Sonic Visualizer.

  

 

 

I’ll double check.

[pkane2001]

6 hours ago, Arpiben said:

 

Yes correct.  I have same behaviour with Sonic Visualizer when connecting dots with lines. Using steps or blocks reduces them.

I also played with overlapping/oversampling but it doesn't improve the presentation.

Musicscope due to its improved windowing do not allow us to see it, i guess.

 

Now the windows types are not matching between DW and Sonic Visualizer.

  

 

 

By the way, checking Sonic Visualizer, the chart you posted only used 64k samples for a 64k FFT. Not a good test for a window or averaging. If you include say 10-15 seconds of the same signal, you'll get a result that is much, much closer to what I posted with DW.

I really don't see a huge difference between these, although DW seems to have a higher dB rejection, perhaps SV is using fixed point arithmetic that limits its precision.

[Arpiben]

7 hours ago, pkane2001 said:

 

By the way, checking Sonic Visualizer, the chart you posted only used 64k samples for a 64k FFT. Not a good test for a window or averaging. If you include say 10-15 seconds of the same signal, you'll get a result that is much, much closer to what I posted with DW.

I really don't see a huge difference between these, although DW seems to have a higher dB rejection, perhaps SV is using fixed point arithmetic that limits its precision.

 

What I am pointing out is that windowing in DW is not applied according to settings. There is barely any difference between choosing a Blackman/Hann/Rectangle/... with DW.

Again, I may be wrong. In DW, whatever window is selected it is looking like a Hann one. By default, Sonic uses Hann, you need to change it in preferences. Select Blackman Harris in Sonic and the shapes will differ Vs DW (from 16k FFT up to 512k ).

Thanks.

 

Edited: I will double check why I was using only 64k samples. Good clue.

[Arpiben]

29 minutes ago, Arpiben said:

 

What I am pointing out is that windowing in DW is not applied according to settings. There is barely any difference between choosing a Blackman/Hann/Rectangle/... with DW.

Again, I may be wrong. In DW, whatever window is selected it is looking like a Hann one. By default, Sonic uses Hann, you need to change it in preferences. Select Blackman Harris in Sonic and the shapes will differ Vs DW (from 16k FFT up to 512k ).

Thanks.

 

Edited: I will double check why I was using only 64k samples. Good clue.

 

Paul,

 

You are 100% right! 👍

The range used for comparisons was the culprit. 

Points closed. Now I owe you a couple of beers 😊

Rgds.

 

[pkane2001]

3 hours ago, Arpiben said:

 

What I am pointing out is that windowing in DW is not applied according to settings. There is barely any difference between choosing a Blackman/Hann/Rectangle/... with DW.

Again, I may be wrong. In DW, whatever window is selected it is looking like a Hann one. By default, Sonic uses Hann, you need to change it in preferences. Select Blackman Harris in Sonic and the shapes will differ Vs DW (from 16k FFT up to 512k ).

Thanks.

 

Edited: I will double check why I was using only 64k samples. Good clue.

 

Some MathNet provided filters lack the asymmetric/periodic form needed for FFT. DW will always try to use the periodic version of the selected filter, but if MathNet doesn't provide one, DW will use Hann, instead.

 

I'll be away from my computer for a couple of weeks. When I get back, I'll change DW to generate the asymmetric filters automatically, so it's not limited by what MathNet provides, and I'll add BlackmanHarris 7.

 

[Arpiben]

On 7/22/2019 at 1:23 PM, pkane2001 said:

 

Some MathNet provided filters lack the asymmetric/periodic form needed for FFT. DW will always try to use the periodic version of the selected filter, but if MathNet doesn't provide one, DW will use Hann, instead.

 

I'll be away from my computer for a couple of weeks. When I get back, I'll change DW to generate the asymmetric filters automatically, so it's not limited by what MathNet provides, and I'll add BlackmanHarris 7.

 

 

Sharing my point of view regarding spectrum curves in DW:

 

1. Spectrum leakage:

The noise artifacts I pointed are due to discontinuities in the DFT/FFT process*.

(* It is assumed that the signal within the time record is repetitive.Therefore if the samples in the time record do not start and stop within the same value at the end points in the the time domain frame , this is interpreted as a discontinuity in the waveform.These artificial discontinuities turn up at very high frequencies and may aliases within Nyquist .They are not present in the original signal.The best approach to minimize its effect is to multiply the time record by a suitable window function before performing DFT)

Since I had been using single tones the spectrum leakage was more noticeable.

 

2. Discrepancies in windowed spectrum results in DW vs expected:

It seems that DW is zero padding samples before/after windowing.If not something is wrong with the averaging.

A pure tone will repeat the same pattern at every time record. The averaged or full record will again have same pattern with spurious and side lobes averaged.

 

DW shows something like:

 

 

Sonic zero pads the first and the last time record. it is also zero padding when requested range is greater than samples provided.As such for those cases the spectrum is not correct.

 

Does it really matter ? Probably not so much unless one is looking at single tones.

 

3. Miscellaneous:

- Rectangle window seems to be missing in the available list

- How does Peak Hold works? 

 

Paul, enjoy being away from your computer. All the above can wait until you are back 😏

Thanks to you and DW I improved my knowledge in windowing and Sonic. Merci.

Rgds.

 

[pkane2001]

1 hour ago, Arpiben said:

 

Sharing my point of view regarding spectrum curves in DW:

 

1. Spectrum leakage:

The noise artifacts I pointed are due to discontinuities in the DFT/FFT process*.

(* It is assumed that the signal within the time record is repetitive.Therefore if the samples in the time record do not start and stop within the same value at the end points in the the time domain frame , this is interpreted as a discontinuity in the waveform.These artificial discontinuities turn up at very high frequencies and may aliases within Nyquist .They are not present in the original signal.The best approach to minimize its effect is to multiply the time record by a suitable window function before performing DFT)

Since I had been using single tones the spectrum leakage was more noticeable.

 

2. Discrepancies in windowed spectrum results in DW vs expected:

It seems that DW is zero padding samples before/after windowing.If not something is wrong with the averaging.

A pure tone will repeat the same pattern at every time record. The averaged or full record will again have same pattern with spurious and side lobes averaged.

 

DW shows something like:

 

 

Sonic zero pads the first and the last time record. it is also zero padding when requested range is greater than samples provided.As such for those cases the spectrum is not correct.

 

Does it really matter ? Probably not so much unless one is looking at single tones.

 

3. Miscellaneous:

- Rectangle window seems to be missing in the available list

- How does Peak Hold works? 

 

Paul, enjoy being away from your computer. All the above can wait until you are back 😏

Thanks to you and DW I improved my knowledge in windowing and Sonic. Merci.

Rgds.

 

 

Hi Arpiben,

 

DW does zero pad the first and the last window. It must be done as DW needs to process samples at the start and the end of the track, they can’t be discarded.

 

The noise near Nyquist is quantization noise, not spectral leakage or window artifacts. You’ll see a lot more of it once I’m done with the changes  

[Arpiben]

2 hours ago, pkane2001 said:

 

Hi Arpiben,

 

DW does zero pad the first and the last window. It must be done as DW needs to process samples at the start and the end of the track, they can’t be discarded.

 

The noise near Nyquist is quantization noise, not spectral leakage or window artifacts. You’ll see a lot more of it once I’m done with the changes  

 

Thanks Paul. It clarifies a few things.

There is always room for improvement starting from myself. 😊

[esldude]

I know you were going to be away from working on Deltawave for a while.  When you get back to it, I've run across a small bug in 1.37B.  In the original spectra tab.  And only in that tab, if you select or de-select log axis, this tab doesn't get updated.  If shows whichever way the software opens.  If Log axis is checked it stays log regardless of the selection.  If log axis is unchecked when it opens then the scale stays linear.  All the other tabs update properly, but not the Orignal Spectra display. 

[Arpiben]

On 7/27/2019 at 2:20 PM, pkane2001 said:

 

...... You’ll see a lot more of it once I’m done with the changes  

 

@pkane2001

 

Hi Paul,

From my side, tools and man are ready to cope with DW's quantization noises.

 

 

 

[pkane2001]

4 hours ago, Arpiben said:

 

@pkane2001

 

Hi Paul,

From my side, tools and man are ready to cope with DW's quantization noises.

 

 

 

 

May take a bit longer to get this working, unfortunately. My development VM is refusing to work after me being away for a bit (runs extremely slow for no apparent reason), and I'm not yet sure if it's something with the Mac OS, VMWare, or Mac itself. Going to build a new development VM now. Hope to have something for you to look at soon...

[pkane2001]

7 hours ago, Arpiben said:

 

@pkane2001

 

Hi Paul,

From my side, tools and man are ready to cope with DW's quantization noises.

 

 

 

 

The new VM is slowly becoming usable. Here are some examples of optimized FFT windows with the original signal we looked at a couple of weeks ago (100Hz sampled at 100k in Audacity). Blue is 24 bit, red is 32 bit WAV:

 

Using BlackmanHarris7 with 512K FFT:

 

 

Same waveforms, but with Kaiser window, also at 512k FFT. This one digs a lot deeper, so you can see all the quantization noise in much more detail, down to about -270dB:

 

And finally, Kaiser window at 1M points FFT. You can see that in reality, the quantization noise is not increasing in amplitude with frequency!

 

 

There's still a lot of work left to do to get all the windows working properly for this edge case. The important thing to note is that it isn't a problem with any normal/natural recordings with the current version of DW -  this really is an extreme case!  

 

Thanks for bringing this up, as it forced me to review, clean-up and optimize FFT windows used in DW.

 

 

[Arpiben]

7 hours ago, pkane2001 said:

 

The new VM is slowly becoming usable. Here are some examples of optimized FFT windows with the original signal we looked at a couple of weeks ago (100Hz sampled at 100k in Audacity). Blue is 24 bit, red is 32 bit WAV:

 

Using BlackmanHarris7 with 512K FFT:

 

 

Same waveforms, but with Kaiser window, also at 512k FFT. This one digs a lot deeper, so you can see all the quantization noise in much more detail, down to about -270dB:

 

And finally, Kaiser window at 1M points FFT. You can see that in reality, the quantization noise is not increasing in amplitude with frequency!

 

 

There's still a lot of work left to do to get all the windows working properly for this edge case. The important thing to note is that it isn't a problem with any normal/natural recordings with the current version of DW -  this really is an extreme case!  

 

Thanks for bringing this up, as it forced me to review, clean-up and optimize FFT windows used in DW.

 

 

 

Thanks Paul.

I fully agree that it is an extreme case. Especially when dealing with single frequencies. One may get tricked if not sampling coherently with or without windows.

(Remove window (or rectangular) and choose coherent sampling -> quantized noise will be almost uniform with frequency. Odd or/and Even harmonics will be generated depending on N number of samples & Np Number of periods over which samples are taken)

 

BTW, windowing apart, dealing with mathematically generated files, I am having consistent results with Python and DW.

Even if not physically related at all, you may have 64 bits 100% matching with -500 dB or more delta spectrum.

Well done!

 

N.B. Thanks to DW I reviewed and improved my knowledge in DFT.👍

 

Files are a bit-perfect match at 16 bits
Files are a bit-perfect match at 64 bits---- Phase difference (full bandwidth): 0°

    0-10kHz: 0,00°
    0-20kHz: 0,00°
    0-24kHz: 0,00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -506,532176832268dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: e59a0c26b9ecd6496e927fdd6d8987e7

[pkane2001]

On 8/5/2019 at 7:49 AM, Arpiben said:

 

Thanks Paul.

I fully agree that it is an extreme case. Especially when dealing with single frequencies. One may get tricked if not sampling coherently with or without windows.

(Remove window (or rectangular) and choose coherent sampling -> quantized noise will be almost uniform with frequency. Odd or/and Even harmonics will be generated depending on N number of samples & Np Number of periods over which samples are taken)

 

BTW, windowing apart, dealing with mathematically generated files, I am having consistent results with Python and DW.

Even if not physically related at all, you may have 64 bits 100% matching with -500 dB or more delta spectrum.

Well done!

 

N.B. Thanks to DW I reviewed and improved my knowledge in DFT.👍

 

Files are a bit-perfect match at 16 bits
Files are a bit-perfect match at 64 bits---- Phase difference (full bandwidth): 0°

    0-10kHz: 0,00°
    0-20kHz: 0,00°
    0-24kHz: 0,00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -506,532176832268dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: e59a0c26b9ecd6496e927fdd6d8987e7

 

Hi folks,

 

Life has been taking priority for a bit, interfering with fun. I've been working on the FFT Windowing in the spare moments, and have reworked most of the FFT logic in DeltaWave. Primarily this was to improve accuracy, I don't believe this will result in any significant improvement in the actual null calculation, since the errors we are talking about are well below -180dB or more. New version needs a lot of testing, so that's what's been holding up its release. I may post an early cut to get your feedback in a day or two.

 

@Arpiben, the noise you were noticing in the pure generated sine-wave is absolutely a numerical truncation/quantization error in floating point calculations. Consider that 32-bit floating point is actually about 23-bits of the actual number (mantissa) and about 7 bits of an exponent -- the precision can be less than a simple 24-bit integer format! Here's a spectrum plot of a 500Hz sine wave sampled @ 88.2k, all pure double floating point format with no conversions:

 

And now, the same exact data, but converted to 32-bit floating point (i.e., losing some precision). All the calculations are still performed using 64-bit floating point, so the only difference from above is the truncation of data when reducing sample size:

 

The only thing that can fix this is using higher-precision samples, so I added a 64-bit WAV file export option to DeltaWave.

I also added a number of new FFT Windows, some with excellent side lobe rejection, such as Kaiser and Taylor (1M point Taylor window is what's used in the plot above).

 

[rando]

As someone without a lifetime devoted to technical side of audio.  It has been illustrative seeing where and how changes are effected across the versions.  

 

One thing I've had in the back of my mind is how delta playback could be (already has been) improved.  Having established amateur interest and appreciation of your efforts not being ruined by feature additions.  What limitations are placed on hearing the delta by program operations/amplification?

 

Thanks

 

 

[pkane2001]

16 minutes ago, rando said:

What limitations are placed on hearing the delta by program operations/amplification?

 

DeltaWave generates the delta as a PCM waveform at the same sample rate as the two files being compared. It can be played back through ASIO or WASAPI drivers directly from inside DeltaWave, or the file can be exported as a WAV file and then played back using any player software you like. 

 

Because the delta waveform is often very low in level, DeltaWave provides the ability to increase the volume by up to 100dB so you can hear the differences. This is done using 64-bit floating point arithmetic, so any errors in increasing levels are far, far below audible.

 

You can even shift ultrasound frequencies into the audible range, so that anything left-over in those frequencies can be examined to see if it's pure noise or something related to the audio content of the file.

[rando]

That much I was clear on.  However, playing file A or file B inside DW the player itself does not treat the ears to an experience similar to using ASIO in a dedicated player program.  Don't expect lab equipment to sing angelically.  I do wonder if the sound signature serves a very utilitarian purpose and if that was defined by the levels at which delta noise is exhumed from. 

 

Merely as a talking point since this aspect has not been visited in a few months.

 

 

[pkane2001]

2 hours ago, rando said:

That much I was clear on.  However, playing file A or file B inside DW the player itself does not treat the ears to an experience similar to using ASIO in a dedicated player program.  Don't expect lab equipment to sing angelically.  I do wonder if the sound signature serves a very utilitarian purpose and if that was defined by the levels at which delta noise is exhumed from. 

 

Merely as a talking point since this aspect has not been visited in a few months.

 

The audio playback is performed by audio library that feeds the appropriate driver with PCM samples provided by DeltaWave. I guess if the audio portion library is poorly implemented it might sound different than dedicated player software. On my PC speakers (Mac, actually) , it sound good enough for me to tell the differences if any are audible. But there's always room for improvement. I've tested DW with headphones through an 'audiophile' DAC using ASIO, and also was happy with the results.

[pkane2001]

DeltaWave v1.0.38 is now available for download!

• Major changes in FFT Windowing routines for improved accuracy at very low levels
• Additional FFT Window selections, including
  • Blackman-Harris 7-term
  • Chebyshev
  • Sum of Cosines 23-term
  • Kaiser
  • Taylor
  • Improvements to existing windows precision
• Added Spectrum setting to reduce spectral leakage to help reduce the averaging effect of overlap-add FFT
• Added Edit menu option to reset all settings to their defaults
• Added Manual Adjustment window selector to chose what parameters to use for optimization
• Fixed a bug in the Manual Adjustment window that occasionally reset the offset parameter
• Improved look and feel of the UI when running on high-DPI displays, e.g., on Windows 10
• Added WAV file export option support for 64-bit floating point PCM samples
• Improved upsampling/downsampling algorithms
• Fixed a bug that caused Original Spectra window not to refresh when changing certain display options

A lot of changes in some core functions have gone into this version,  so please continue to report any issues, problems, or suggestions for improvement.

 

[fas42]

Good to see you've been busy, Paul!

 

Okay, straightaway got something peculiar with the last comparison I was doing in v.37:

 

DeltaWave v1.0.38, 2019-08-18T21:42:13.2813609+10:00
Reference:  Original2.wav[L] 5304320 samples 44100Hz 24bits, stereo, MD5=00
Comparison: YamahaSteinbergMR816X.wav[L] 5345280 samples 44100Hz 24bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:True    Non-linear Phase EQ: True
    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -0.536dB   Comparison: -1.808dB
Initial RMS values Reference: -17.32dB   Comparison: -18.741dB

Null Depth=15.559dB
X-Correlation offset: -93 samples
Drift computation quality, #1: Excellent (0.02µs)

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

Final peak values Reference: -1.071dB   Comparison: -1.068dB
Final RMS values Reference: -20.034dB   Comparison: -20.034dB

Gain= -1.3625dB (0.8548x) DC=0 Phase offset=-2.109496ms (-93.029 samples)
Difference (rms) = -80.07dB [-88.62dBA]
Correlated Null Depth=82.94dB [86.74dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=12.99%) at 16 bits
Files are NOT a bit-perfect match (match=0.05%) at 24 bits
Files match @ 50.0061% when reduced to 13.44 bits

---- Phase difference (full bandwidth): 7.02795042833081°
    0-10kHz: 9.99°
    0-20kHz: 7.06°
    0-24kHz: 7.03°
---- Variable Group Delay. Frequency matched from 0Hz to 21.1kHz:
    1kHz = 1.3µs (0.48°)
    2kHz = 569ns (0.41°)
    4kHz = 358ns (0.52°)
    8kHz = 251.7ns (0.72°)
    16kHz = 71.2ns (0.41°)
Timing error (rms jitter): 103.3ns

RMS of the difference of spectra: -130.194487736745dB
gn=1.16983539545706, dc=1.72169093541618E-06, dr=0, of=-93.0287597317

DONE!

Signature: deff77fc96016a1a76ea87dcc90c8298

 

... versus,

 

DeltaWave v1.0.38, 2019-08-18T21:34:42.8741917+10:00
Reference:  Original2.wav[L] 4907008 samples 44100Hz 24bits, stereo, MD5=00
Comparison: YamahaSteinbergMR816X.wav[L] 4947968 samples 44100Hz 24bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:True    Non-linear Phase EQ: True
    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -0.709dB   Comparison: -1.914dB
Initial RMS values Reference: -17.701dB   Comparison: -19.06dB

Null Depth=15.721dB
X-Correlation offset: -93 samples
Drift computation quality, #1: Excellent (0.01µs)

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

Final peak values Reference: -1.071dB   Comparison: -1.296dB
Final RMS values Reference: -20.343dB   Comparison: -20.331dB

Gain= -1.205dB (0.8705x) DC=0 Phase offset=-2.109495ms (-93.029 samples)
Difference (rms) = -34.23dB [-37.8dBA]
Correlated Null Depth=34.63dB [35.05dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=0.06%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files match @ 49.9985% when reduced to 5.52 bits

---- Variable Group Delay. Frequency matched from 0Hz to 21.1kHz:
    1kHz = 1.8µs (0.66°)
    2kHz = 655.4ns (0.47°)
    4kHz = 338.7ns (0.49°)
    8kHz = 105.2ns (0.30°)
    16kHz = 338.7ps (0.00°)
Timing error (rms jitter): 86.6µs

RMS of the difference of spectra: -97.1062794467593dB
gn=1.14881537562309, dc=2.06974616579266E-06, dr=0, of=-93.0287170279

DONE!

Signature: 926e32160abba9f8bc09c918b4d3b38d

 

The only difference between these two runs was the time trimmed from the end of the 120 sec samples; 1 sec, versus 10 secs.

[pkane2001]

10 hours ago, fas42 said:

Good to see you've been busy, Paul!

 

Okay, straightaway got something peculiar with the last comparison I was doing in v.37:

 

DeltaWave v1.0.38, 2019-08-18T21:42:13.2813609+10:00
Reference:  Original2.wav[L] 5304320 samples 44100Hz 24bits, stereo, MD5=00
Comparison: YamahaSteinbergMR816X.wav[L] 5345280 samples 44100Hz 24bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:True    Non-linear Phase EQ: True
    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -0.536dB   Comparison: -1.808dB
Initial RMS values Reference: -17.32dB   Comparison: -18.741dB

Null Depth=15.559dB
X-Correlation offset: -93 samples
Drift computation quality, #1: Excellent (0.02µs)

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

Final peak values Reference: -1.071dB   Comparison: -1.068dB
Final RMS values Reference: -20.034dB   Comparison: -20.034dB

Gain= -1.3625dB (0.8548x) DC=0 Phase offset=-2.109496ms (-93.029 samples)
Difference (rms) = -80.07dB [-88.62dBA]
Correlated Null Depth=82.94dB [86.74dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=12.99%) at 16 bits
Files are NOT a bit-perfect match (match=0.05%) at 24 bits
Files match @ 50.0061% when reduced to 13.44 bits

---- Phase difference (full bandwidth): 7.02795042833081°
    0-10kHz: 9.99°
    0-20kHz: 7.06°
    0-24kHz: 7.03°
---- Variable Group Delay. Frequency matched from 0Hz to 21.1kHz:
    1kHz = 1.3µs (0.48°)
    2kHz = 569ns (0.41°)
    4kHz = 358ns (0.52°)
    8kHz = 251.7ns (0.72°)
    16kHz = 71.2ns (0.41°)
Timing error (rms jitter): 103.3ns

RMS of the difference of spectra: -130.194487736745dB
gn=1.16983539545706, dc=1.72169093541618E-06, dr=0, of=-93.0287597317

DONE!

Signature: deff77fc96016a1a76ea87dcc90c8298

 

... versus,

 

DeltaWave v1.0.38, 2019-08-18T21:34:42.8741917+10:00
Reference:  Original2.wav[L] 4907008 samples 44100Hz 24bits, stereo, MD5=00
Comparison: YamahaSteinbergMR816X.wav[L] 4947968 samples 44100Hz 24bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:True    Non-linear Phase EQ: True
    EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -0.709dB   Comparison: -1.914dB
Initial RMS values Reference: -17.701dB   Comparison: -19.06dB

Null Depth=15.721dB
X-Correlation offset: -93 samples
Drift computation quality, #1: Excellent (0.01µs)

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

Final peak values Reference: -1.071dB   Comparison: -1.296dB
Final RMS values Reference: -20.343dB   Comparison: -20.331dB

Gain= -1.205dB (0.8705x) DC=0 Phase offset=-2.109495ms (-93.029 samples)
Difference (rms) = -34.23dB [-37.8dBA]
Correlated Null Depth=34.63dB [35.05dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=0.06%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files match @ 49.9985% when reduced to 5.52 bits

---- Variable Group Delay. Frequency matched from 0Hz to 21.1kHz:
    1kHz = 1.8µs (0.66°)
    2kHz = 655.4ns (0.47°)
    4kHz = 338.7ns (0.49°)
    8kHz = 105.2ns (0.30°)
    16kHz = 338.7ps (0.00°)
Timing error (rms jitter): 86.6µs

RMS of the difference of spectra: -97.1062794467593dB
gn=1.14881537562309, dc=2.06974616579266E-06, dr=0, of=-93.0287170279

DONE!

Signature: 926e32160abba9f8bc09c918b4d3b38d

 

The only difference between these two runs was the time trimmed from the end of the 120 sec samples; 1 sec, versus 10 secs.

 

Thanks, Frank. It appears the level matching isn’t working the same between the two results, the rest of the values appear the same. I’ll check, as there are two ways DW calculates level differences, and one of them is based on spectrum average. That’s not what’s normally used, it’s only done as the first approximation. Seems like for some reason that’s what’s being used in your second result, which shouldn’t happen.

[fas42]

It's worse than that, Paul - the matching is completely failing in the run with 10 secs trimmed, visually in the Matched panel the correlation is terrible.