• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Beta-test: DeltaWave Null Comparison software

I seem to have encountered another potential issue.
It turns out that actually, just running the test more than once can yield different results.

See the video here: https://streamable.com/4hgab2
No settings or files are changed, but each time I run the test there is a slightly different result. I'm not entirely sure why this would be
 
Folks,

After a delay, there's now a new version of DeltaWave available for download and testing: v1.0.51.

This version should improve speed, add a few enhancements, and produce better, more predictable and stable results, even with higher sampling rate files (@GoldenOne - please test). The changes are as follows:

  • Change to automatically pick a better size FFT for cross-correlation
  • Change to reduce the number of iterations when computing drift
  • Added option to change the file trim end setting from how many to trim to how many to include (you can now set the starting point in the file and how many seconds to extract from that point)
  • Added larger size FIR filter setting, up to 1M taps
  • Fixed a bug that could result in a few zero samples being added at the very end of comparison file
  • Modified memory management to improve handling of files that are larger than a couple of minutes
Please give this version a try!
 
So I just got the ADI-2 Pro and gave deltawave another go.

Made two recordings @ 192khz on the ADC.

Depending on the settings, deltawave gave the following results:
192khz (Native): 61dB Null / -43dB diff
98khz (Downsampled): 115dB Null / -72dB diff
48khz (Downsampled): 143dB Null / -72dB diff

For comparison, audio diffmaker reports an 86dB correlation

I've uploaded deltawave reports, plus the original files here:
https://drive.google.com/drive/folders/1RY3QUqzibh8JhLpNF974tcFwSlDjzwFu?usp=sharing

Hopefully it can help track down what this bug is.
I'm not sure what the best way to get the most truly accurate result is. Do you have any advice?
Thanks!

Hi @GoldenOne,

Please give the new version (1.0.51) a try. On the two ADI-2 Pro files you uploaded, here's the result (this is without non-linear/eq correction, no resampling or low-pass filter):

1602727189903.png
 
Unfortunately it seems that its still struggling with higher sample rates, and with changing the result each time.

I've uploaded two files here: https://drive.google.com/drive/folders/1icXST5DS7XsaPF0gRwGCJy1mnARrC13N?usp=sharing
(sharp 1 and sharp 2)

Runs 1-3 were with resampling to 44.1khz
3-6 with resampling to 176400

1: 84dB
2: 82dB
3: 83dB
4: 70dB
5: 72dB
6: 71dB

This is all with a 20khz filter (R+C)
Turning the filter off doesn't seem to change much, the null still ends up roughly the same. (73dB @ 176400hz from a quick check)

These are my settings:
1602797314085.png


I'm not sure if this is just me configuring something wrong, but even with the same two files, the correlated null, regardless of filter settings, varies massively depending on sample rate.
And at sample rates of 384khz+ it sometimes struggles to properly x-correlate the waveforms, meaning it can't actually do the test at all.
 
Unfortunately it seems that its still struggling with higher sample rates, and with changing the result each time.

I've uploaded two files here: https://drive.google.com/drive/folders/1icXST5DS7XsaPF0gRwGCJy1mnARrC13N?usp=sharing
(sharp 1 and sharp 2)

Runs 1-3 were with resampling to 44.1khz
3-6 with resampling to 176400

1: 84dB
2: 82dB
3: 83dB
4: 70dB
5: 72dB
6: 71dB

This is all with a 20khz filter (R+C)
Turning the filter off doesn't seem to change much, the null still ends up roughly the same. (73dB @ 176400hz from a quick check)

These are my settings:
View attachment 88076

I'm not sure if this is just me configuring something wrong, but even with the same two files, the correlated null, regardless of filter settings, varies massively depending on sample rate.
And at sample rates of 384khz+ it sometimes struggles to properly x-correlate the waveforms, meaning it can't actually do the test at all.

Correlated null is a combination (multiplication) of amplitude and timing errors. Any timing errors are going to change significantly with resampling, so I'm not surprised that this value changes a lot. The lower the sampling rate, the smaller the timing errors, and so, the larger will be the correlated null. I would recommend that you don't resample, if possible, when doing critical null comparisons.

The two captures at 705kHz are way too large a sampling rate for DW. Cross-correlation uses FFTs to find similarities between two waveforms. To find a mis-alignment of only 2 seconds, requires the FFT size to be larger than 2M. Not only will this be too slow, but I put a limit of 1M as the largest FFT size in DeltaWave, so it can't handle a 2 seconds or larger misalignment at such a high sampling rate. At 705kHz, you'll need to do some of the alignment manually to remove errors larger than about 1 second. You can do this by specifying the number of seconds to trim from the front of one or both files. At 192kHz, a

Here's the result when I did that, both files at 705kHz sampling rate, trim 3 seconds from file #1 and 2 second from file #2, no filter and no resampling:
1602804165760.png


And this result is actually not unreasonable. Gearslutz website has a running thread posting loop-back null analysis of files captured with various equipment. The latest update has the RMS difference listed for ADI-2 Pro, sharp-in/sharp-out filter, at 44.1kHz:

SD Sharp DA - SD Sharp AD: 0.4 dB (L), 0.4 dB (R), -44.5 dBFS (L), -45.5 dBFS (R)

This result is remarkably close to your files @ 705kHz generating an RMS difference of -44.3dB!
 
Correlated null is a combination (multiplication) of amplitude and timing errors. Any timing errors are going to change significantly with resampling, so I'm not surprised that this value changes a lot. The lower the sampling rate, the smaller the timing errors, and so, the larger will be the correlated null. I would recommend that you don't resample, if possible, when doing critical null comparisons.

The two captures at 705kHz are way too large a sampling rate for DW. Cross-correlation uses FFTs to find similarities between two waveforms. To find a mis-alignment of only 2 seconds, requires the FFT size to be larger than 2M. Not only will this be too slow, but I put a limit of 1M as the largest FFT size in DeltaWave, so it can't handle a 2 seconds or larger misalignment at such a high sampling rate. At 705kHz, you'll need to do some of the alignment manually to remove errors larger than about 1 second. You can do this by specifying the number of seconds to trim from the front of one or both files. At 192kHz, a

Here's the result when I did that, both files at 705kHz sampling rate, trim 3 seconds from file #1 and 2 second from file #2, no filter and no resampling:
View attachment 88103

And this result is actually not unreasonable. Gearslutz website has a running thread posting loop-back null analysis of files captured with various equipment. The latest update has the RMS difference listed for ADI-2 Pro, sharp-in/sharp-out filter, at 44.1kHz:

SD Sharp DA - SD Sharp AD: 0.4 dB (L), 0.4 dB (R), -44.5 dBFS (L), -45.5 dBFS (R)

This result is remarkably close to your files @ 705kHz generating an RMS difference of -44.3dB!

After doing the trim you recommended I can indeed get the files working at the native sample rate :D
Though, whilst (with the 20khz filter to limit to the audible band) there is an 82dB null, the RMS difference is only -44dB
I'm not sure I fully understand why two recordings from the same dac (a well performing one at that) could be so different?

Could you advise on what the best settings to use might be, or if I could perhaps alter my recording method in some way for an improvement?
Im not sure what the best option would be in terms of sample rate when recording, vs what I should/should not be resampling to etc etc.

Essentially, what I am currently trying to do is see how similar a result two dacs produce when playing music.

Two dacs can have the same SINAD, but handle transients differently, different filter designs, etc etc, and so I'm trying to do a very basic "How similar do dacs A and B sound overall" measurement.

I've found that dacs that are similar, say, the SU8 and Motu M2/M4, which are both well measuring ESS dacs, correlate very heavily, but then compare the SU8 to the ADI-2, Holo May, or UD501 etc, all of which are different topologies, and you suddenly get a way lower correlation (and they sound different to my ear too, some to quite a degree) even though they all measure well.

Would you be able to recommend a method/config to do this in a way that Deltawave would be able to perform best?
I've been struggling because obviously things such as long term clock drift are not really important to what a human will hear. A track playing at 99.8% speed will not be noticeable (though jitter could), but for this test, they do need to be aligned so that deltawave can make a proper comparison.

I've been getting inconsistent results correlating a given dac against itself, which means that I can't really make any sort of comparisons between dacs.
surely a -44dB null is somewhat woefully poor?
I've been able to get nulls of -110dB on some configs, but I'm not sure what the optimal configuration I should be using for this situation would be. As its hard to tell what is a genuine difference between recordings and what is simply my settings being odd.

Thank you so much for all your help, you've created some truly fantastic software and I really appreciate all the assistance you've given me and others here
 
  • Like
Reactions: SIY
After doing the trim you recommended I can indeed get the files working at the native sample rate :D
Though, whilst (with the 20khz filter to limit to the audible band) there is an 82dB null, the RMS difference is only -44dB
I'm not sure I fully understand why two recordings from the same dac (a well performing one at that) could be so different?

The RMS difference is heavily weighted towards larger errors (like all RMS metrics). So, in effect, it's designed to help bring out the effect of larger errors, even if they are few and far in between. It's really an engineering metric rather than audibility metric, since it doesn't weigh the differences based on their perceptual significance.

Could you advise on what the best settings to use might be, or if I could perhaps alter my recording method in some way for an improvement? Im not sure what the best option would be in terms of sample rate when recording, vs what I should/should not be resampling to etc etc.

Ideally, you want to test the equipment at the rate you'll be using it. Unless you're trying to measure something well outside the audible range, 24/96kHz should be plenty to capture every tiny audible nuance in a recording or playback. A 705kHz sampling rate isn't needed unless you are trying to detect and measure ultrasonics.

Essentially, what I am currently trying to do is see how similar a result two dacs produce when playing music.
For this, you'd want to use the same music track, at the same sampling rate, recorded with the same ADC but with different DACs.

Two dacs can have the same SINAD, but handle transients differently, different filter designs, etc etc, and so I'm trying to do a very basic "How similar do dacs A and B sound overall" measurement.

Well, that's not quite for the null metric will tell you. As I said, this is more of an engineering quality metric. dBA numbers as reported by DeltaWave will give A weighting to the result, making it a little more related to audibility. For example, your two files show this:

1602811926574.png


8dB improvement in overall RMS difference and about the same in Correlated Null when looking at A-weighted values.

I've found that dacs that are similar, say, the SU8 and Motu M2/M4, which are both well measuring ESS dacs, correlate very heavily, but then compare the SU8 to the ADI-2, Holo May, or UD501 etc, all of which are different topologies, and you suddenly get a way lower correlation (and they sound different to my ear too, some to quite a degree) even though they all measure well.

The differences that I find are often the cause of large discrepancies in otherwise excellent measurements are the timing/phase errors. One obvious one is caused by different filter designs and implementations that can result in a variable group delay, and sometimes ringing/oscillations. Others have to do with clock rate differences. The others are caused by jitter. While I tried to deal with as many of these timing issues in DW as I could, they are not all easy to measure and/or to correct.

Would you be able to recommend a method/config to do this in a way that Deltawave would be able to perform best?
I've been struggling because obviously things such as long term clock drift are not really important to what a human will hear. A track playing at 99.8% speed will not be noticeable (though jitter could), but for this test, they do need to be aligned so that deltawave can make a proper comparison.

Constant clock drift is detected, measured and corrected by DW, so in most cases, it'll not have an appreciable effect on the result.

Jitter, on the other hand, is not correctable in a general way, especially jitter caused by random noise sources.

Variable group delay is something DeltaWave can measure and correct for, but it requires a larger track (a couple of minutes) to get a better, cleaner result out of it. Getting a few minutes at high sampling rates can eat up all available memory on the computer. Another reason not use high sampling rates.

At lower sampling rates, you can easily use the Non-linear EQ options to compute and correct for the effects of variable group delay. Here are some settings I usually try when I want to see and correct for it:

1602813590745.png


Remember the example from Gearslutz website I posted earlier that showed -44.5dB RMS difference? That same track processed in DeltaWave with the non-linear EQ options enabled, produces this result:

1602812881306.png


Nearly doubling all the null and difference values. Eliminating a predictable phase error, such as can be caused by a poor or non-linear phase filter, can help improve the null significantly.

I've been getting inconsistent results correlating a given dac against itself, which means that I can't really make any sort of comparisons between dacs.

surely a -44dB null is somewhat woefully poor?
I've been able to get nulls of -110dB on some configs, but I'm not sure what the optimal configuration I should be using for this situation would be. As its hard to tell what is a genuine difference between recordings and what is simply my settings being odd.

Yes, a -44dB null is not great when considering that the same device is used. There are a number of things you need to consider, and DeltaWave gives you the graphs to find the source of the error. Here's one possible problem: the track you're capturing appears to be very clipped, so you may be using the wrong gain settings or not adjusting the volume properly for the recording:

1602813485603.png


Thank you so much for all your help, you've created some truly fantastic software and I really appreciate all the assistance you've given me and others here

Appreciate the kind words! And I hope I didn't confuse you!

DeltaWave was designed more as a toolkit to help run multiple types of analysis and to give some insight into what a device is doing. To me, the plots and the comparison spectrograms is where the value is. A single number, like the RMS difference or a correlated null are good for quick look, but they can't fully describe the audible differences between devices. Don't forget, that you can also listen to the difference track to see what the difference sounds like. If there's obvious music components, or just the high notes or noise in it. You can also compare difference tracks recorded from two different DACs to see which one is quieter, and has less music or is mostly noise.
 
I long ago gave up on the correlated nulls. I ignore them. Couldn't figure out what was going on with them consistently. I go by the difference level. I also noticed last time I looked at the long running loopback null thread on Gearslutz they also have recently discarded correlated null as a measure.

Well had more to say, but just noticed pkane's post and it says much of it.

I noticed in my multi-generation tests comparing original to 1st gen copy gave almost the same RMS difference as comparing 1st gen copy to a 2nd gen copy or 7th gen copy to 8th gen copy. So what the devices are doing is consistently portrayed by Deltawave.

As pkane wrote it seems the phase of filtering causes most of the poor results in the difference levels. The biggest corrupter is when one device goes to or near DC and another has a slow rollout at 20 hz. Digital filtering difference at the high frequencies also ruins difference levels though not quite as much. And using the EQ and phase correction can fix much of that. I do still find when I use the extra processing there is usually a sweet spot for the size of FFT chosen. Larger or smaller will give a less good result, and the only way to know is to run the match at different FFT sizes.

Listening to difference files helps. If the difference is low, and you get a tinny thin sound of the amplified difference it usually is some residual timing mismatch or possibly on going random jitter. I have now and again gotten a difference file which was bass heavy, and I've not determined what aspect causes that.

I've also noticed in my own testing and those in the gearslutz thread the very best results come from two separate devices with locked clocks or being clocked from the same external clock. You'd think loopbacks using the same clock on both ends would be the best. My theory is you have delay between the DAC signal going thru an external cable and back into the ADC. About 3 nanoseconds per meter. If you use the same length cable between the DAC and ADC for the clock signal with the DAC the master they have the same delay or close to it of the analog cables. As good as Deltawave is I suppose it still helps when it doesn't need to fix a delay between files of 3 nanoseconds or more.
 
LP filters @start don't appear to function in this version. They do function @end. HP filters function at start or end. But LP at start don't change anything, and don't change the results.

@pkane
 
LP filters @start don't appear to function in this version. They do function @end. HP filters function at start or end. But LP at start don't change anything, and don't change the results.

@pkane

I’ll check it out. If you have a chance, can you please try using the second filter instead of the first? I’m not sure how I messed this up since I didn’t touch filter logic at all, but I’m pretty sure that the second filter works correctly, as I was using it for all the testing.
 
Okay, yes it is just filter one. Filter two works. Perhaps this hidden bug has been there in the previous version. Right now LP@start in filter one does nothing, and it works as expected in filter two.
 
Okay, yes it is just filter one. Filter two works. Perhaps this hidden bug has been there in the previous version. Right now LP@start in filter one does nothing, and it works as expected in filter two.

Yes, that’s why I didn’t notice it before, since I was testing with the second filter. I have a couple of other issues to address, but should post an update with a fix by the end of the day.
 
A quick update to version 1.0.52 fixing some regression items:
  • Fix: error on some computers with no permission to query memory statistics
  • Fix: filter 1 settings for LP and HP filters @ start were not being processed
  • Fix: measure simple waveforms option interrupted alignment process
Thank you for all the bug reports, and please continue to test!
 
A quick update to version 1.0.52 fixing some regression items:
  • Fix: error on some computers with no permission to query memory statistics
  • Fix: filter 1 settings for LP and HP filters @ start were not being processed
  • Fix: measure simple waveforms option interrupted alignment process
Thank you for all the bug reports, and please continue to test!
Hi pkane, changing the options in "DSD conversion" and reload the files sometimes crashes DeltaWave (about 10% chance?)
This happens with previous versions as well.
 

Attachments

  • DeltaWave.exe.2472.dmp.zip
    6.6 KB · Views: 95
Hi pkane, changing the options in "DSD conversion" and reload the files sometimes crashes DeltaWave (about 10% chance?)
This happens with previous versions as well.

The dump file is giving me some errors about thread information being invalid, so I can't really read the details. It appears some thread is out of stack space, so either out of memory or some infinite recursion. Can you please explain at what point you get this? Is it during loading of the file? At the start of the load, the middle, the end? How large is the file, and at what DSD rate?
 
The dump file is giving me some errors about thread information being invalid, so I can't really read the details. It appears some thread is out of stack space, so either out of memory or some infinite recursion. Can you please explain at what point you get this? Is it during loading of the file? At the start of the load, the middle, the end? How large is the file, and at what DSD rate?
Thanks for looking into this. I sometimes check DSD64, sometimes 128, in dff and dsf files. Just recently I found that changing the FFT size and window settings in the" Spectrum" section can result in crashes as well. I often use Process -> Load Only or the "Show" button without additional processing to make things faster, so should be unrelated to phase/gain matching. If a successful analysis is 100% in terms of time, I think it usually crashes at around 20-30%.

I also have some bigger dump files. If you think they are useful I can send you via PM.
dump.PNG


[EDIT] After trying different things I guess the crash is related to the length of files. Files with less than for example 500000 samples are more likely to crash.
 
Last edited:
New version available: 1.0.53b

Changes are as follows:
  • Added: support to process .mp4, .m4a, and .alac files
  • Added: 2M FFT size for non-linear EQ settings
  • Added: new Cosine and Flattop FFT windows
  • Fixed: when using the manual adjustment window Gain setting was ignored and recalculated each time
  • Changed: group delay computation changed to reduce time and memory needed to process
  • Added: double-clicking on the trim label “End” or “Take” will now switch between these two modes. This setting can also be changed in Settings window.
 
Hi Paul,
I have created an account here just to say that I love your software. DeltaWave is amazing. Finally, I'm able to ditch DiffMaker.

Many thanks for this program and for making it better and better with each new release!

Is there any way to support the development?
 
Last edited:
I'm not sure whether you've seen this one, from the "sound of DSD" thread:
Speaking of DeltaWave, or null test in general, for example, here are two files with a simple tone and they look pretty similar in DeltaWave, but no matter what settings I use I can never get a reasonable null depth figure or DF Metric. The generation of these files are totally unrelated to white noise, DSD and resampling. @pkane could this situation be improved?

View attachment 84425
By the looks of it the offending samples differ by time delay (non-integer number of samples) only. I tried matching them up in Audacity manually and had to resample to a 1 MHz sample rate to even get a -60 dB null. Still, I would imagine that dealing with arbitrary time delays is kind of basic and important.
 
Back
Top Bottom