Beta-test: DeltaWave Null Comparison software

[pkane]

Here is a downshift analysis of Pink Floyd's Dark Side of the Moon, "Time" track intro. Ripped from MFSL LP with 192k/24bit sampling, shared here under fair use doctrine.

Probably an extreme example, but it does indicate that there's some valid signal above the audible range. No claims about its audibility under normal listening conditions, though This is just meant to demonstrate the new downshift function of DW.

Here are the actual tracks you can listen to, the original rip and the downshifted version. Downshifted version is low in level, so you may need to increase the volume a bit to hear any details.

The original rip, unprocessed:

Down-shifted by 22.05kHz, so all the frequencies above 22k are shifted down to start at the 0Hz range. Note that none of the original 0-22k information is there in the downshifted version, this is purely ultrasonic content:

 

[pkane]

Here is a downshift analysis of Pink Floyd's Dark Side of the Moon, "Time" track intro. Ripped from MFSL LP with 192k/24bit sampling, shared here under fair use doctrine.

Probably an extreme example, but it does indicate that there's some valid signal above the audible range. No claims about its audibility under normal listening conditions, though This is just meant to demonstrate the new downshift function of DW.

Here are the actual tracks you can listen to, the original rip and the downshifted version. Downshifted version is low in level, so you may need to increase the volume a bit to hear any details.

The original rip, unprocessed:
View attachment 28659

Down-shifted by 22.05kHz, so all the frequencies above 22k are shifted down to start at the 0Hz range. Note that none of the original 0-22k information is there in the downshifted version, this is purely ultrasonic content:
View attachment 28660

By the way, I found that a very interesting mastering trick was used for this album. This track and some others were apparently processed through an Abbey Road "Frequency Translator" box. Curiously, this box was designed to shift frequencies, very similar to Downshift! How about that for a coincidence!

It worked like this. It shifted the audio spectrum in a linear fashion, not harmonic. eg 1000Hz becomes 1010Hz, 2000Hz becomes 2010Hz, 3000Hz becomes 3010Hz etc.

https://www.diyaudio.com/forums/tubes-valves/171047-variable-harmonizer-post2259126.html

 

[Blumlein 88]

What sort of numbers are you getting for jitter? I've been getting results that seem higher than expected. Like loopbacks that are in the few dozen nanosecond range. Or repeats where the same file two minutes later compared to itself is in the same range. Many non-loopback comparisons are in the high nano or low to mid microsecond range. I think my best result has been 5.8 nanoseconds between two files that were identical other than the analog cable used.

Now the jitter reported on the 8th generation test files I have do increase with each additional generation. That is what I would have expected.

Really dig the frequency shift feature btw. Very handy for Deltawave to do this for us.

 

[pkane]

What sort of numbers are you getting for jitter? I've been getting results that seem higher than expected. Like loopbacks that are in the few dozen nanosecond range. Or repeats where the same file two minutes later compared to itself is in the same range. Many non-loopback comparisons are in the high nano or low to mid microsecond range. I think my best result has been 5.8 nanoseconds between two files that were identical other than the analog cable used.

Now the jitter reported on the 8th generation test files I have do increase with each additional generation. That is what I would have expected.

Really dig the frequency shift feature btw. Very handy for Deltawave to do this for us.

I'm getting a few nano-seconds range as well in a loop-back test. I've seen as low as 2ns. This is RMS error over the entire track, with each sample timing error being included in the computation. Try two captures with the same interconnect to see if the number goes down lower -- I found that interconnects do make a measurable difference Interestingly, in my tests it seemed to have been related to the capacitance of the cable.

Microseconds-range jitter implies a large error. Could be due to non-linear clock drift or variable group delay/frequency-dependent phase error. Or an imperfect clock drift correction computed by DW.... nah! That can't possibly be it

 

[Blumlein 88]

I'm getting a few nano-seconds range as well in a loop-back test. I've seen as low as 2ns. This is RMS error over the entire track, with each sample timing error being included in the computation. Try two captures with the same interconnect to see if the number goes down lower -- I found that interconnects do make a measurable difference Interestingly, in my tests it seemed to have been related to the capacitance of the cable.

Microseconds-range jitter implies a large error. Could be due to non-linear clock drift or variable group delay/frequency-dependent phase error. Or an imperfect clock drift correction computed by DW.... nah! That can't possibly be it

Yes, I've done multiple loopbacks of several tracks with nothing changed. The nulls are very, very good. But the jitter is up into the nanosecond range above the 5.8 nanoseconds. Usually only a few dozen nanoseconds. Those in the microsecond range were usually files with more differences like different generations, or different DACs that sort of thing.

I would have expected jitter in loopbacks to be very low even if the actual jitter is high, because the same clock is controlling ADC and DAC. So if it jitters one it also jitters the other, and you'll see no difference. You'd expect that to mostly filter out jitter. So you get results showing 0 ppm drift, but nanosecond level jitter (which yes I understand is possible), but I would have thought in loopbacks you'd see less. I also don't think the devices used actually have jitter that high. Does the few nanosecond delay in traversing the analog cable throw off the jitter determination?

 

[KSTR]

Haven't tried the new features yet, but I would reason the actual jitter in a loopback measurement with DAC and ADC chips running of the same clock line is theoretically zero only when a) DAC and ADC behave well matched in introducing their own (data-dependant and random) jitter and b) there is zero analog time delay, neither from lowpass filter group delay nor from real time-of-flight from a cable length. If the signal reaches the ADC a week later then it is immediately clear equal amount of clock jitter won't cancel, rather they would RMS sum. Drift wouldn't be zero as well.

And I think we would need a really good overall S/N-ratio for this as well. Paul, did you check what impact any added noise has, by using one and the same test track and adding equal amounts of, say, white noise (which will dominate) to it, uncorrelated?

 

[pkane]

Yes, I've done multiple loopbacks of several tracks with nothing changed. The nulls are very, very good. But the jitter is up into the nanosecond range above the 5.8 nanoseconds. Usually only a few dozen nanoseconds. Those in the microsecond range were usually files with more differences like different generations, or different DACs that sort of thing.

I would have expected jitter in loopbacks to be very low even if the actual jitter is high, because the same clock is controlling ADC and DAC. So if it jitters one it also jitters the other, and you'll see no difference. You'd expect that to mostly filter out jitter. So you get results showing 0 ppm drift, but nanosecond level jitter (which yes I understand is possible), but I would have thought in loopbacks you'd see less. I also don't think the devices used actually have jitter that high. Does the few nanosecond delay in traversing the analog cable throw off the jitter determination?

One thing to realize is that jitter, in the case of DeltaWave, measures any error as a timing error. Since DW has only quantized sample amplitudes to go by, the uncertainty in the amplitude due to random or non-random errors in the DA/AD process, even things like random dither between two captures, can easily result in a measure of jitter that's above zero.

Even if the process is perfectly linear to 20 bits, the best accuracy that can be achieved, say at 100Hz, is in a few nanoseconds range due to quantization and truncation errors. And this is before random dither, or real clock jitter: both increase timing error in the samples.

I'll think about a way to extract correlated jitter measure, but that would seem to be a difficult task with complex music as the source.

 

[pkane]

And I think we would need a really good overall S/N-ratio for this as well. Paul, did you check what impact any added noise has, by using one and the same test track and adding equal amounts of, say, white noise (which will dominate) to it, uncorrelated?

I've not tried adding white noise. It would be interesting if this has an appreciable effect on jitter. What would you say this indicates, if it does?

 

[PierreV]

I've not tried adding white noise. It would be interesting if this has an appreciable effect on jitter. What would you say this indicates, if it does?

That the RNG used to generate the white noise is biased? (sorry thinking in terms of other field probably)

 

[pkane]

That the RNG used to generate the white noise is biased? (sorry thinking in terms of other field probably)

Dither is likely already added in the loopback processing. If it's random (white/pink/or other type), it will certainly have an effect on the jitter metric when comparing two different captures through the same hardware.

 

[Blumlein 88]

I've tried adding noise previously to identical files and Deltawave is unbothered by it. Leaves you with only a noise residual. Will have to try it and see if it tricks it into showing jitter.

 

[pkane]

1.0.33 version of DeltaWave is now available. This includes variable group delay correction and the following new features:

Changes in 1.0.33b

• Added non-linear phase correction option (correcting for variable group delays)
• Results tab now shows group delays in seconds and degrees for a few chosen frequencies
• Modified delta phase plot to show phase before and after correction, as well as the measured group delay when computed
• Changed the phase unwrap logic to produce a smoother curve
• Added support for reading MP3 files
• Added option to apply current volume control settings to the Reference and Comparison waveforms (under Process Menu)
• Added one level Undo option to undo previous matching/processing operation

The non-linear phase/variable group delay correction depends on being fed a good number of samples (very short files may not work well or at all!) This is still experimental, but shows a lot of promise in my testing, especially when comparing different DACs, or ADC loop results with the original WAV file. I'll post some results a bit later.

Here is the setting to turn it on:


Let me know if anything is not clear or not working as expected.

 

[pkane]

As an example of variable group delay (VGP) option working, here's the analysis of @Archimago 's two captures, A and B with VGP option disengaged. You can see the RMS delta is fairly poor (-39dB), and phase plot shows an obvious deviation from flat -- that's the variable group delay. Higher frequencies have a larger, increasing phase error.

This is the difference in phase after the clock drift and phase offset have been removed by DW(!)



Keeping everything else the same, and turning on VGP, the result is as follows:



Note that the resulting phase (white line) is now flat out to about 21kHz. What's more, the RMS null has improved by nearly 15dB, correlated null is better, and the timing error (RMS jitter) value went from 15μs to 131ns! That's a 100x improvement in timing accuracy.

The brown/orange line is the computed group delay function. You can see that it tracks the original phase error (blue line) pretty well until about 21kHz.

Here are the results computed by DW for variable phase delay in the first plot, without VGP correction:

---- Variable Group Delay. Frequency matched from 0Hz to 21.0kHz:
    1kHz = 417.8ns (0.15°)
    2kHz = 889.1ns (0.64°)
    4kHz = 1.3μs (1.84°)
    8kHz = 4.4μs (12.79°)
    16kHz = 22.4μs (129.26°)

 

[pkane]

Running a few of the Gearslutz DAC/ADC loopback captures through phase EQ correction in DeltaWave 1.0.33 shows some of variable group delay shapes and sizes for some high-quality equipment.





@Blumlein 88 's capture of March Audio DAC1 shows what appears to be a lot of phase noise compared to the other ones here (also seen in the higher RMS jitter value), although the phase delay appears to be mostly linear until about 19kHz, meaning it's a constant group delay/timing offset:


And an interesting one. Phase is definitely a problem with this DAC/ADC combo. Looks like phase EQ wasn't able to fully correct these oscillations, but it certainly flattened the result quite a bit

 

[pkane]

Folks, please try a new version of DeltaWave, v1.0.34.

This version implements a different way of correcting for phase error that seems to work much better. Resulting phase looks clean and nearly perfect to me. But please, let me know what you find.

Some examples (check the null and jitter values, as well). Blue is the original phase delta, red is the corrected phase:

 

[Blumlein 88]

Might want to try 1.37b now.

 

[pkane]

Might want to try 1.37b now.

Should definitely be an improvement

 

[pkane]

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.

 

[modmix]

I found that interconnects do make a measurable difference

+1.
Using a Lynx L22 analog loopback, I did three recodings:

1. In-Out XLR break-out directly connected
2. 10m cable inserted
3. 90cm silver cable inserted

DW gives quite a difference when comparing Sectrum of Delta 1./2. with 1./3.:

Never ever saw such a clear result matching very well to the listening experience.
Thanks for that great software.
Ulli

PS:
Still not clear about the 2x5m result:

• below about 1 kHz delta is huge (in audiophile terms)
• delta drops with about -40 dB/decade (like a 2nd order filter)
• there are spikes in the dropping region where delta is in the order of low frequencies

How would I create a cable showing this result...?

 

[pkane]

+1.
Using a Lynx L22 analog loopback, I did three recodings:

1. In-Out XLR break-out directly connected
2. 10m cable inserted
3. 90cm silver cable inserted

DW gives quite a difference when comparing Sectrum of Delta 1./2. with 1./3.:
View attachment 31584
Never ever saw such a clear result matching very well to the listening experience.
Thanks for that great software.
Ulli

PS:
Still not clear about the 2x5m result:

• below about 1 kHz delta is huge (in audiophile terms)
• delta drops with about -40 dB/decade (like a 2nd order filter)
• there are spikes in the dropping region where delta is in the order of low frequencies

How would I create a cable showing this result...?

That’s a significant difference! Did you mean how to create a table of the results?