Beta-test: DeltaWave Null Comparison software

[Pluto]

Naudio.FLAC project appears to be mostly abandoned

I dare say they thought that FLAC was a deal done, a problem solved, old news with nothing more to be said.

Then along comes @pkane

Seriously though, how compatible is your work with ffmpeg? I realise that the latter has nothing to do with charting but as far as the audio is concerned, it seems to be cropping up everywhere – in both commercial and 'home-brew' packages.

 

[bennetng]

I guess it may have something to do with Naudio's .net nature.
How about BASS? It should be .net ready.
https://www.un4seen.com/

 

[pkane]

I dare say they thought that FLAC was a deal done, a problem solved, old news with nothing more to be said.

Then along comes @pkane

Seriously though, how compatible is your work with ffmpeg? I realise that the latter has nothing to do with charting but as far as the audio is concerned, it seems to be cropping up everywhere – in both commercial and 'home-brew' packages.

Naudio project itself is working and is well supported. It is NAudio.Flac that appears to be mostly dead. It's just the FLAC reader (a separate project) that's misbehaving, and it should be easy enough to rip out/replace or fix.

 

[pkane]

I guess it may have something to do with Naudio's .net nature.
How about BASS? It should be .net ready.
https://www.un4seen.com/

The fix turned out to be very straightforward. The author of the library forgot to clear buffers between successive reads, and in the case of zero values in the file, some of the samples from previous reads were not overwritten. I'll post an update soon.

 

[bennetng]

The fix turned out to be very straightforward. The author of the library forgot to clear buffers between successive reads, and in the case of zero values in the file, some of the samples from previous reads were not overwritten. I'll post an update soon.

Excellent. Thanks.

 

[pkane]

I wasn't quite done with all the changes planned for this release but @bennetng forced my hand
Version 1.0.32 includes some changes and fixes. Others are still in process and will be included in the next release.

Changes in 1.0.32b

• Fixed bug with FLAC reader library that could cause ‘echos’ in place of zero-valued samples
• Added Process->DownShift Frequency option to allow listening to ultrasonic frequencies
• Added Jitter metric measuring file mismatch as a timing error
• Added View->Status Bar options to control information displayed in the status bar
• Added Non-linear drift correction in Settings to allow the removal of residual non-linear clock-drift errors
• Changed Notch filter implementation for greater rejection
• Added labels displaying zoom setting in correct units in custom Zoom dialog

 

[pkane]

A bit more detail on the new features in 1.0.32:

1. DownShift frequency option. Allows to shift all frequencies down by a specified number of Hz. For example, down-shifting by 20kHz a 96k-sampled file will result in all the frequencies between 20k-48kHz in the original file being shifted to 0-28kHz. Everything above 28k in this case will be low-pass filtered. This preservers the relationship between adjacent frequencies, and so makes it possible to hear if the audio information in the audible band that would normally be outside the range. Because ultrasonic content is often at a very low level, you may need to raise the volume in DW by 20-50dB just to hear it. Be careful, though, raise the volume slowly while the audio is playing and don't do it before starting the playback to avoid nasty surprises!

2. Jitter metric measures the difference between two waveforms as an error in timing. Existing measures, such as RMS difference and correlated null are both related to the magnitude of the amplitude error, although correlated null is also related to timing.

This new measure computes an RMS timing error between the two waveforms. Assuming the amplitudes of the two waveforms are perfectly matched, this number would be the actual RMS jitter. Reported in seconds (microseconds, nanoseconds, picoseconds). The smaller the number, the smaller the overall match error. In effect, that's another number that can be used to judge the quality of the match.

3. Non-linear drift correction. Clock drift removal feature of DeltaWave works on any constant clock differences between the two waveforms, such as one clock is N times faster than the other. The new feature attempts to remove some of the remaining random variations in clocks that are non-linear. In effect, the result should be a much more 'flat' drift error plot after the correction. I'm still working on the non-linear phase correction part of the EQ feature (aka, variable group delay correction) so for now that option will remain disabled.

 

[Pluto]

Brilliant work yet again! 32 downloaded and first tests promising.

 

[Pluto]

DownShift frequency option. Allows to shift all frequencies down by a specified number of Hz

I haven't thought too much about this yet, but I wonder how useful this might be as, by definition, shifting the frequency of content by a fixed number of Hz will destroy any harmonic relationship between frequencies. How feasible would it be, not to reduce the frequency of ultrasonic residuals by a fixed number of Hz but, instead, to reduce the frequency of such residuals by a factor such as .5 or .25 and, thereby, preserve the harmonic relationship?

 

[pkane]

I haven't thought too much about this yet, but I wonder how useful this might be as, by definition, shifting the frequency of content by a fixed number of Hz will destroy any harmonic relationship between frequencies. How feasible would it be, not to reduce the frequency of ultrasonic residuals by a fixed number of Hz but, instead, to reduce the frequency of such residuals by a factor such as .5 or .25 and, thereby, preserve the harmonic relationship?

That makes sense, and would be interesting to compare the result to the downshift version. Downshift was easier to code and is enough to tell whether the sound is related to the audible range content or not.

 

[pkane]

I haven't thought too much about this yet, but I wonder how useful this might be as, by definition, shifting the frequency of content by a fixed number of Hz will destroy any harmonic relationship between frequencies. How feasible would it be, not to reduce the frequency of ultrasonic residuals by a fixed number of Hz but, instead, to reduce the frequency of such residuals by a factor such as .5 or .25 and, thereby, preserve the harmonic relationship?

One problem with such a factor-based frequency reduction is that it doesn't remove lower frequencies, it scales them down (compresses them) into the lower frequency range. If we use a factor 0.5x, then 20kHz will become 10kHz, 10kHz will become 5k, 100Hz will become 50, 20 will become 10Hz, etc. In other words, the lower/audible frequencies will still be represented in the resulting sound track. That makes it harder to separate ultrasonic content from audible. High-pass filtering is an option to remove lower frequencies, but the ultrasonic frequencies will still be left in the upper audible range, making them harder to hear and harder to listen to.

Give the downshift method a try. It helps to isolate and make audible higher frequencies (albeit not preserving harmonic relationships). I think it makes it very obvious if there's any valid signal content there. And, of course, I'm open to any suggestions for improvement

 

[MC_RME]

I wouldn't be surprised if you downshift a vinyl record you still hear 'music'. Which in case of the horrrible distorted LPs would not be real content, but just distortion aka medium related harmonics! Hopefully someone finds the time to try that...

 

[Pluto]

Give the downshift method a try

I certainly shall – to be honest, the real issue at this point is that I'm not entirely sure, in my own mind, what this facility can achieve. I appreciate that the underlying idea is to test whether particular HF artefacts are content-related or not, but this a venture into uncharted territory!

Might it be useful to apply a high-pass filter (at, say, 20kHz) to remove the normal, baseband, content before effecting the downshift? Doing so would effectively remove the original content from the audible region before replacing it with the ultrasonic downshifted stuff?

My early playing with this facility suggests that an "undo" would be very useful so the downshift can be tried, and easily undone if nothing of interest is revealed.

 

[pkane]

I certainly shall – to be honest, the real issue at this point is that I'm not entirely sure, in my own mind, what this facility can achieve. I appreciate that the underlying idea is to test whether particular HF artefacts are content-related or not, but this a venture into uncharted territory!

Might it be useful to apply a high-pass filter (at, say, 20kHz) to remove the normal, baseband, content before effecting the downshift? Doing so would effectively remove the original content from the audible region before replacing it with the ultrasonic downshifted stuff?

My early playing with this facility suggests that an "undo" would be very useful so the downshift can be tried, and easily undone if nothing of interest is revealed.

I don't make any claims about this feature

The way it came about is the desire to determine whether or not the difference (null) waveform has some signal-correlated content or not in the ultrasonic range. It's easy to listen to the null waveform in DW, but the differences are often most pronounced at 18khz and above. Downshift was designed to let me listen to the content I can't otherwise hear.

In addition, there are many ongoing threads here and on other forums claiming the importance of ultrasonic content in "proper" recording and reproduction. Downshift lets one listen to the ultrasonic content and decide if there's really any music or instruments or anything significant at all up there that standard equipment and processes would normally discard.

 

[pkane]

I wouldn't be surprised if you downshift a vinyl record you still hear 'music'. Which in case of the horrrible distorted LPs would not be real content, but just distortion aka medium related harmonics! Hopefully someone finds the time to try that...

I have some hi-res LP rips I can try this on

 

[Pluto]

What do you think of....

Might it be useful to apply a high-pass filter (at, say, 20kHz) to remove the normal, baseband, content before effecting the downshift? Doing so would effectively remove the original content from the audible region before replacing it with the ultrasonic downshifted stuff?

 

[bennetng]

BTW, the frequency shift operation would be better with musical scale, in cents or semitones:
https://en.wikipedia.org/wiki/Cent_(music)
https://en.wikipedia.org/wiki/Equal_temperament

 

[pkane]

What do you think of....

In how I implemented it, there's no need for a high-pass filter. The low frequencies get replaced completely by higher frequencies.

With the method you suggested, I think it might work, but will need larger reduction factors to make anything easily audible. After all, a reduction factor of 0.5x will make the lowest audible frequency at 10kHz if we high-pass filter at 20k. In any case, I'll give this a try, as well

 

[pkane]

View attachment 28655

BTW, the frequency shift operation would be better with musical scale, in cents or semitones:
https://en.wikipedia.org/wiki/Cent_(music)
https://en.wikipedia.org/wiki/Equal_temperament

What was the length of the waveform you were trying to downshift? I can see this happening if it's too short (a few seconds). I'll add some checks into the code to handle this.

The frequencies listed in the downshift menu are a mix of octave-per-step values and some commonly useful frequencies (like 20k, 22.05k, 24k, etc.)

 

[bennetng]

What was the length of the waveform you were trying to downshift? I can see this happening if it's too short (a few seconds). I'll add some checks into the code to handle this.

DeltaWave v1.0.32, 2019-07-01T00:23:47.6140876+08:00
Reference: no gpu_48kHz.wav[L+R] 949920 samples 48000Hz 24bits, stereo, MD5=00
Comparison: ALC892_48kHz.wav[L+R] 950880 samples 48000Hz 24bits, stereo, MD5=00
Settings:
Gain:True, Remove DC:True
Non-linear Gain:False EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
Correct Drift:True, Precision:30
Non-Linear drift Correction:True
Upsample:False, Window:Hann
Spectrum Window:Hann, Spectrum Size:32768
Spectrogram Window:Hann, Spectrogram Size:4096, Spectrogram Steps:2048
Dither:False
Trim Silence:False

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

Initial peak values Reference: -2.981dB Comparison: -7.896dB
Initial RMS values Reference: -11.858dB Comparison: -16.77dB

Null Depth=14.028dB
X-Correlation offset: -1011 samples
Drift computation quality, #1: Excellent (0.11μs)


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


Final peak values Reference: -2.981dB Comparison: 1.975dB
Final RMS values Reference: -11.858dB Comparison: -6.954dB

Gain= -9.8735dB (0.3209x) DC=0 Phase offset=-21.429583ms (-1028.62 samples)
Difference (rms) = -14.22dB [-15.91dBA]
Correlated Null Depth=9.31dB [6.26dBA]
Clock drift: 47.57 ppm


Files are NOT a bit-perfect match (match=2.41%) at 16 bits
Files are NOT a bit-perfect match (match=0.01%) at 24 bits
Files match @ 49.9986% when reduced to 3.7 bits


Phase difference (full bandwidth): 103.761977355399°
0-10,000Hz: 104.018508239229°
0-20,000Hz: 103.870015062889°
0-24,000Hz: 103.761977355399°
0-44,100Hz: 103.761977355399°
0-48,000Hz: 103.761977355399°
RMS of the difference of spectra: -54.1886895225997dB
Timing error (rms): 99.5μs
gn=3.11656897199226, dc=0, dr=4.7566722E-05, of=-1028.6199738479

DONE!

Signature: b7805c8d20e2a5a1fda0147fd68a8c58
Phase difference (full bandwidth): 104.017312219896°
0-10,000Hz: 104.696844200809°
0-20,000Hz: 104.292013701913°
0-24,000Hz: 104.017312219896°
0-44,100Hz: 104.017312219896°
0-48,000Hz: 104.017312219896°