Beta-test: DeltaWave Null Comparison software

[pkane]

I am trying to compare 2 audio files and I struggle to interpret results from this app. Could someone please help?

I recorded a short audio, while playing a test video on Youtube - it contains pure left, pure right and mixed audio. One file is just simple loop headphone out -> line in. Second file is recorded with an "audio gadget" in the path and I would like to know if it does anything audible (if yes, what does it do?).

Files were too large for an attachment, so I uploaded them here: https://ufile.io/f/vr1fy

Btw. I tried to match L channels and it seems to be working fine. But when I switched to R channels, no audio was detected nor matched. Are my files from Audacity "broken" or did I miss something in the app?

Thanks in advance!

I suspect the issue is the large parts that are silence (noise) that can't be matched between the two tracks. The drift computation requires more meaningful data to match than random noise throughout the track (usually -- music). Turn off drift correction and see if you can get a better result:

Here's the waveform showing large portions that are silence:

Comparing the right channels between the two files without drift correction, I get this:

Comparing left channels:

For left channels, bit perfect check:
--------
Files are NOT a bit-perfect match (match=9.22%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 50.0007% when reduced to 13.41 bits

 

[Pdxwayne]

I suspect the issue is the large parts that are silence (noise) that can't be matched between the two tracks. The drift computation requires more meaningful data to match than random noise throughout the track (usually -- music). Turn off drift correction and see if you can get a better result:

View attachment 140845

Here's the waveform showing large portions that are silence:
View attachment 140846

Comparing the right channels between the two files without drift correction, I get this:
View attachment 140841

Comparing left channels:
View attachment 140844

For left channels, bit perfect check:
--------
Files are NOT a bit-perfect match (match=9.22%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 50.0007% when reduced to 13.41 bits

Interesting, the correlated null are pretty low. Does this mean I should compare songs with no silent part?

 

[pkane]

Interesting, the correlated null are pretty low. Does this mean I should compare songs with no silent part?

Drift computation requires being able to match multiple parts of the track. If there are large portions of the track that are just noise, these cannot be matched, so drift computation should be turned off.

 

[Pdxwayne]

Drift computation requires being able to match multiple parts of the track. If there are large portions of the track that are just noise, these cannot be matched, so drift computation should be turned off.

Do you mean to get good correlated null, "correct clock drift" option should be ON? In some cases, the app won't compare two files with the option ON due to silence parts. Thus, need to turn OFF to compare. With the option OFF, the correlated null suffers?

 

[pkane]

Do you mean to get good correlated null, "correct clock drift" option should be ON? In some cases, the app won't compare two files with the option ON due to silence parts. Thus, need to turn OFf to compare. With the option OFF, the correlated null suffers?

I'm really not sure what you're asking.

Do you understand what correct clock drift does? If you have two devices that are using independent clocks, there's a good chance the clocks will not run at exactly the same rate. The option to correct for clock drift removes these differences, but it must be able to compute them, first.

To compute drift, DeltaWave requires data that can be matched throughout the track. Large portions of the track containing silence/random noise cannot be matched, so drift cannot be computed in this case. The problem in the tracks that were posted is that about half of the track in this test contained silence that is just random noise. Drift cannot be computed when such a large portion of the track cannot be matched. Short silence here and there is not a problem. Half of the track containing silence/noise -- is.

 

[Pdxwayne]

I'm really not sure what you're asking.

Do you understand what correct clock drift does? If you have two devices that are using independent clocks, there's a good chance the clocks will not run at exactly the same rate. The option to correct for clock drift removes these differences, but it must be able to compute them, first.

To compute drift, DeltaWave requires data that can be matched throughout the track. Large portions of the track containing silence/random noise cannot be matched, so drift cannot be computed in this case. The problem in the tracks that were posted is that about half of the track in this test contained silence that is just random noise. Drift cannot be computed when such a large portion of the track cannot be matched. Short silence here and there is not a problem. Half of the track containing silence/noise -- is.

My concern was not about drift.

My concern is about correlated null numbers in your examples at https://www.audiosciencereview.com/...ave-null-comparison-software.6633/post-844888

Remember in my other thread, you said something is very wrong with my chain because my correlated null were low? My correlated nulls were similar to your examples, but you said you get much better correlated null like -120db.

Your examples correlated null is -59dbA for the left channel comparison. What caused that?

Thanks!

 

[pkane]

My concern was not about drift.

My concern is about correlated null numbers in your examples at https://www.audiosciencereview.com/...ave-null-comparison-software.6633/post-844888

Remember in my other thread, you said something is very wrong with my chain because my correlated null were low? My correlated nulls were similar to your examples, but you said you get much better correlated null like -120db.

Your examples correlated null is -59dbA for the left channel comparison. What caused that?

Thanks!

I think you need to slow down, you're mixing up many things and multiple conversations that are not related.

First, I normally compare RMS nulls, not correlated nulls. The example here had a -72dBA RMS null, which is not a bad result at all.

Second, the -110dB RMS null I mentioned was using the same exact loopback, just running the test twice. The example above is running loopbacks through two different devices -- a very different type of comparison.

 

[Pdxwayne]

I think you need to slow down, you're mixing up many things and multiple conversations that are not related.

First, I normally compare RMS nulls, not correlated nulls. The example here had a -72dBA RMS null, which is not a bad result at all.

Second, the -110dB RMS null I mentioned was using the same exact loopback, just running the test twice. The example above is running loopbacks through two different devices -- a very different type of comparison.

Good thing that you explained! I was going to keep checking correlated null.
Will check RMS null going forward!

Thanks!
: )

 

[mysiak]

I suspect the issue is the large parts that are silence (noise) that can't be matched between the two tracks. The drift computation requires more meaningful data to match than random noise throughout the track (usually -- music). Turn off drift correction and see if you can get a better result:

View attachment 140845

Here's the waveform showing large portions that are silence:
View attachment 140846

Comparing the right channels between the two files without drift correction, I get this:
View attachment 140841

Comparing left channels:
View attachment 140844

For left channels, bit perfect check:
--------
Files are NOT a bit-perfect match (match=9.22%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 50.0007% when reduced to 13.41 bits

Thank you, results make more sense now. I am no expert and I frankly admit that I do not fully understand all the different settings and results, but when you compare these two files - do you think that there is an audible difference between them, beyond some natural recording/noise error?

Just to put it into a perspective, "the gadget" is a passive "crossfeed type" filter (not a crossfeed per se though), which should help to lessen the headphones listening fatigue. When doing manual A/B comparison, I can't hear the difference (but it takes some time to reconnect the headphones, so short audio memory could play its role). However when I listened to my music with the device in the path for several hours and then I accidentally removed it, I noticed that the sound was "different" and more in the head. I believe that there is a very subtle difference, but would like to understand more about its nature (and if it's real or just the good old placebo effect). It should be based on the work started by Alan Blumlein (so some kind of phase shift in lower frequencies?), but that's all I know. Schematic is unknown and components are not visible without destroying it.

The audio file was chosen deliberately in this way, standard crossfeed would "bleed" one channel to the other one and it would be visible, but it doesn't seem to happen when only one side is playing. If the filter does anything, it will happen only if both channels play some sounds and that part is quite hard for me to decipher.

Any idea/insight is welcome.

 

[pma]

Paul @pkane , is this a bad or good result of 2 music files captured with a single hardware change?

 

[pkane]

Paul @pkane , is this a bad or good result of 2 music files captured with a single hardware change?

View attachment 141777

Good.

 

[pma]

Paul (@pkane ), if I may ask once again - I have prepared 2 test files, purely mathematically. First is the ideal pink noise generator loaded by resistor, second is the pink noise through high pass 10uF + 10kohm. Both files saved as wav files.

The HP frequency response is as follows and I am 100% sure it is inaudible

Now the 2 files, the direct path and hp path are analyzed by Deltawave with following results

What shall I read from the pkmetric on audibility? Thank you.

The files are attached below.

 

[pkane]

Paul (@pkane ), if I may ask once again - I have prepared 2 test files, purely mathematically. First is the ideal pink noise generator loaded by resistor, second is the pink noise through high pass 10uF + 10kohm. Both files saved as wav files.

The HP frequency response is as follows and I am 100% sure it is inaudible
View attachment 142003


Now the 2 files, the direct path and hp path are analyzed by Deltawave with following results

View attachment 142004

View attachment 142005

View attachment 142006

View attachment 142007

What shall I read from the pkmetric on audibility? Thank you.

The files are attached below.

86dBFS is obviously very low and will not be audible (try switching to dBr to see how far below the main signal PKMetric levels are). There are small peaks at the start and end of the track, which I assume is due to the sudden start/stop of the track. Other than that, this should be inaudible.

Looks like some dither was applied since the delta spectrum levels off at -140dB (or was that the result of the high pass filter?)

 

[Pdxwayne]

@pkane , in general, when do we care about jitters number when comparing files?

I did comparisons yesterday and noticed one comparison has about 70 times higher jitter than the other. Does it matter?

See https://www.audiosciencereview.com/...on-noise-on-audio-equipment.25501/post-871115

 

[pkane]

@pkane , in general, when do we care about jitters number when comparing files?

I did comparisons yesterday and noticed one comparison has about 70 times higher jitter than the other. Does it matter?

See https://www.audiosciencereview.com/...on-noise-on-audio-equipment.25501/post-871115

Jitter error in DeltaWave is just another way to measure the difference between the two waveforms, except in the time domain. PKMetric and RMS null errors are measures of amplitude error. Jitter is the RMS value of the error in time between two waveforms. If the waveforms are not well aligned, the error will be large (both, in time and amplitude).

 

[pkane]

DeltaWave version 1.0.71b is now available!

Changes in 1.0.71b

• Added: option to show samples and sinc-interpolation on extreme zoom-in of waveform
• Added: non-linear EQ option to correct for small linearity errors
• Changed: log frequency display is now using more logical steps, showing easier to read frequencies instead of fractions
• Fixed: a number of edge conditions that could result in the match operation terminating prematurely
• Reverted: removed log-frequency display in spectrograms due to incorrect labeling at certain sampling frequencies. I’ll try to fix it in the future.

Sinc-interpolation waveform plot option is under Settings/Display Options:

The result is only visible when a waveform plot is zoomed in sufficiently to see individual samples. Samples are marked by a small dot, while both, interpolated and un-interpolated waveforms are visible. For example:

The new linearity correction option attempts to correct for the non-linear transfer function derived from the null waveform. This is experimental. Longer wave files are preferred for this to work properly (at least 2 minutes at 44.1k). Here's a result of correcting a small nonlinearity in a recent measurement.

Linearity without correction:

Linearity with correction turned on:

The difference in this case is minor, but does result in about a 1-2dB better null than without the correction.

Finally, log frequency axis are now labeled in a bit more human-readable form, instead of the hard to understand and read fractions:

Previously, this displayed like this:

 

[pkane]

Hi Everybody,

I'm pleased to announce that DeltaWave is now officially grown up and out of the beta test!

Release 2.0 celebrates this with a few additions and improvements:

Changes in v2.0.0

• This is the first official release without the “beta” designation (!)
• Added: fully functional version of the log-frequency spectrogram
• Changed: improved speed of update on spectrogram plots
• Added: additional menu options to hide/show multiple tabs on right click on a tab
• Improved: accuracy of the Sinc resampler
• Improved: accuracy of the subsample offset determination
• Improved: made charts update quicker during a match operation
• Fix: minor clean up to additional edge condition handling
• Added: new resampler rates, 352.8k, 384k, 705.6k and 768k
• Added: the full list of FFT Windows to all drop-downs on the Setup screen

While DeltaWave is no longer in a beta test, the software is still being enhanced and updated, and new features will be added when suggested or as I think of them

I'll continue to post updates in this thread, and as usual, all feedback, suggestions, and bug reports are welcome.

 

[pjug]

This is really great software. Just updated to the V2.

A question (sorry if you've answered this before but I can't find it):
For the HP or LP filter, what does @start, @end, @start/end mean?

 

[pkane]

This is really great software. Just updated to the V2.

A question (sorry if you've answered this before but I can't find it):
For the HP or LP filter, what does @start, @end, @start/end mean?

The @start / @end / both determines when the filter is applied to the waveform. @start is before any processing, as soon as the data is loaded from the file, @end is after all the corrections are done but before the final measurements are computed. @start/end applies the same filter at the beginning and at the end of processing.

 

[pjug]

The @start / @end / both determines when the filter is applied to the waveform. @start is before any processing, as soon as the data is loaded from the file, @end is after all the corrections are done but before the final measurements are computed. @start/end applies the same filter at the beginning and at the end of processing.

Thank you. I was guessing it was something like that but good to know for sure.