DeltaWave null-testing audio comparator (beta)

Arpiben · May 18, 2019

On 5/17/2019 at 2:13 PM, fas42 said:

Hallo !! What's going on here !? ... I was idly examining the comparison of Paul R's vinyl captures, and found these artifacts, in the Matched panel,

Of course the matching is very poor, because these are 2 distinct needle drops - and the prompt for using the alternative drift method was shown, which I said No to - but it gave these fairly regularly spaced jumps in the comparison waveform, only.

Results panel:

DeltaWave v1.0.28, 2019-05-17T21:27:46.7441291+10:00
Reference: Etude In G Flat Major(192).wav[L] 2416640 samples 192000Hz 32bits, stereo, MD5=00
Comparison: Etude In G Flat Major(44.1~192)wav.wav[L] 2402304 samples 192000Hz 32bits, stereo, MD5=00
Settings:
   Gain:True, Remove DC:True
   Non-linear Gain:False   EQ FFT Size:262144, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
   Correct Drift:True, Precision:30
   Upsample:False, Window:Hann
   Spectrum Window:Blackman, Spectrum Size:524288
   Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
   Dither:False
   Trim Silence:False

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

Initial peak values Reference: -24.598dB   Comparison: -24.516dB
Initial RMS values Reference: -39.846dB   Comparison: -39.68dB

Null Depth=18.449dB
X-Correlation offset: -3 samples
Drift computation quality, #1: Excellent (0.69μs)

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

Final peak values Reference: -24.598dB   Comparison: -24.616dB
Final RMS values Reference: -39.84dB   Comparison: -40.024dB

Gain= 0.101dB (1.0117x) DC=0 Phase offset=-0.044683ms (-8.579 samples)
Difference (rms) = -39.93dB [-41.63dBA]
Correlated Null Depth=29.15dB [29.48dBA]
Clock drift: -124.18 ppm

Files are NOT a bit-perfect match (match=0.13%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 49.9875% when reduced to 6.78 bits

RMS of the difference of spectra: -72.3253449210009dB
gn=0.988443477510982, dc=0, dr=-0.000124180393, of=-8.5790526495

DONE!

Signature: 533a46dec359f59f99093ddd4eeff352

As previously mentioned by Paul, DW' s drift correction seems not to perform well when dealing with big values.

Another method/strategy has to be implemented for such cases.The current alternative correction, when proposed, is not helping.

Look at the phase amplitude ( before drift correction) in Paul R' s captures.

Arpiben · May 19, 2019

@pkane2001

As an alternate way you may consider correcting the drift between beginning and the point of phase slope change ( instead of end ).

Rgds.

Arpiben · May 21, 2019

@pkane2001

Sorry for that, but I am still struggling with the following:

Phase Difference in Result tab
Clock drift curves result when dr=0 ( drift correction not applied ).

In 1., the values are not in accordance with delta phase graph.

In 2. , what is the meaning of the drift corrected curve if correction not applied?

Do you mind elaborating? Thanks.

Arpiben · May 21, 2019

12 minutes ago, pkane2001 said:

Delta phase plot is the actual phase difference from the two waveforms after they are matched. A simple subtraction of phase angles for each of the FFT frequency bins.

Drift plot is the measurement of phase offset through a correlation and phase offset measurement on different parts of the waveform.

When curves are not matched delta phase and phase values in result tab have discrepancies. Not a big deal, but I would like to understand why. In Result tab phase is provided for a range 0 Hz- 10 kHz for example. Result may be 0.2° when inband phase noise can have values greater than 5° or more. Result may be 0.2° when delta phase curve indicates 0.5° at 10.000 kHz.

Drift plot shows corrected red curve when no correction applied in Result tab or logs, why?

Ex:

Arpiben · May 21, 2019

2 hours ago, pkane2001 said:

I'm not sure I understand the question. There's no drift correction in the above plot. The constant phase offset was adjusted to bring the overall phase difference closer to zero, that's all I see there.

You are perfectly right. I mix up things with the drift correction curve. My apologies Paul.

Arpiben · June 11, 2019

1 hour ago, pkane2001 said:

I tried a variation on the non-linear EQ that also adjusts phase, not just amplitude. Seems promising.

Here's the result of matching the two files with non-linear EQ engaged, as it exists in the current .31 version:

And here's the result using the amplitude and phase EQ (feature coming in the next version). Seems to produce an 8-9dB better null with phase correction:

I often try out the non-linear EQ function to see if the results will be improved. Sometimes they are, sometimes not by much. But I think these settings are a bit out of character for DeltaWave. They compensate for frequency and phase errors that really are true, complex, and possibly audible, errors. While I can certainly add more non-linear correction functions (and I'll do that, just for fun ), I see these as not being useful for the main purpose of what DeltaWave is designed to do: finding differences between two waveforms.

Do you mind sharing the phase delay chart for the studied case ( EQ enabled for Amplitude & Phase)? Just to have a better idea how it will perform 😉. Thanks for DW' s improvements.

Arpiben · June 30, 2019

18 hours ago, pkane2001 said:

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.

Hi Paul,

First of all many thanks for the added features.

I am rather happy with DW but still have some concerns or questions:

1° How is phase calculated: single FFT size /average of several FFT sizes/other method?

2° Characteristics of LP filter used in frequency downshift feature?

3° Jitter Metric:

- pointing the arrow on Jitter brings the help for Fit Quality (minor bug)

- it will probably be more useful to draw an estimated Jitter curve. The Phase delay curve ( delta phase ) is in degrees vs frequency.

T.I.E ( Time Interval Error ) is in time (us/ns/ps) vs duration (s). And finally Jitter curves in Time Domain, are in principle obtained from T.I.E. in taking the maximum value over a sliding time window = Tau (s) (M.T.I.E).

I am awaiting with great interest your EQ phase correction in order to better match files with non flat group delay.

Rgds.

Arpiben · July 6, 2019

@pkane2001

Hi Paul,

I am enjoying DW's new release.The status window for EQ/EQ+Phase/Non linear applied/etc... is perfect!

I encountered some unexpected behaviour if by chance in Non Linear Calibration window:

EQ FFT size is set to 64 bytes
Phase EQ is Enabled

Then applying Show or Match will lead to a process failure with whatever file I have tested.

I didn't check all FFT sizes but it seems that the issue disappears with FFT sizes greater or equal than 128 bytes.

Dealing with Group Delay correction, shall we set any FFT sizes or the process is automatic as per my initial understanding ?

Rgds.

Logs:

Stopped! A regression of the requested order requires at least 2 samples. Only 1 samples have been provided.

2019-07-06 00:18:23.3006|ERROR|Wave.WaveForm|Stopped!
at MathNet.Numerics.LinearRegression.SimpleRegression.Fit(Double[] x, Double[] y)
at MathNet.Numerics.Fit.LineFunc(Double[] x, Double[] y)
at Wave.Analysis.FindValidPhaseMax(Double[] coeff, Int32 freq, Int32 fft_size) in C:\Users\ypa\documents\visual studio 2015\Projects\Wave\Wave\Analysis.cs:line 2284
at Wave.Analysis.ApplyFreqCalibrationComplex(Double[]& LL, Double[]& L1, Int32 freq, Int32 size, Int32 cutoff, Double[]& polynomial, Int32& last_freq) in C:\Users\ypa\documents\visual studio 2015\Projects\Wave\Wave\Analysis.cs:line 2170
at Wave.WaveForm.ProcessAll(Double[] L, Double[] L1, Int32 freq, Int32 freq1, Int32 freq2, Int32 bits1, Int32 bits2, Boolean bMatch, Boolean bLoadOnly, Boolean bApplyManual, Boolean bUpdateCharts) in C:\Users\ypa\documents\visual studio 2015\Projects\Wave\Wave\WaveForm.cs:line 2406
2019-07-06 00:18:23.3078|INFO|Wave.WaveForm|Stopped! A regression of the requested order requires at least 2 samples. Only 1 samples have been provided.
2019-07-06 00:18:23.3078|DEBUG|Wave.WaveForm|Progress Stopped!, , 100%

Arpiben · July 7, 2019

9 hours ago, pkane2001 said:

Sorry, just saw this part of the question. FFT size, low/high frequency and threshold value are all used in group delay computation. I suggest a larger FFT size of 32768 or more as that helps feed more data into the computation of group delay.

The other values you can leave as default, as DW will attempt to automatically correct only the portion of the spectrum that measures well and where phase isn't overly chaotic. If you do see that DW tries to match very noisy data near the top of the spectrum, you could specify a lower top frequency so that it ignores values above it for delay curve determination. Here are the settings I used for a lot of testing that seem to do well on most captures:

Note that I also select the Non-linear Drift correction. That is a different type of correction that attempts to match variations in the clocks over time. This makes the residual/error drift plot appear flatter and can sometimes help improve the nulls just a bit more. Usually doesn't hurt anything if you leave this turned on. In contrast, the new Phase EQ option corrects for timing variations over frequency.

Thanks Paul.

For my own curiosity, I am trying to know if we can improve the phase estimation using different phase unwrapping methods.

But I am only at the beginning with little free time...

Rgds.

Arpiben · July 10, 2019

@pkane2001 &/or @fas42

Any link pointing to the original file looped? The one in Gearslutz seems to be broken.

Thanks.

Arpiben · July 12, 2019

On 7/11/2019 at 4:14 AM, pkane2001 said:

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):

Hi Paul,

I am having some new issues with DW's latest release 1.035b.

With Phase EQ enabled and some tests files. SHOW -> Stopped! Index was outside the bounds of the array.

at Wave.Analysis.FitPhaseCurve(Double[] x, Double[] y, Complex[] spectrum, Int32 sz, Int32 freq, Double[]& poly) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\Analysis.cs:line 0
at Wave.Analysis.ApplyFreqCalibrationComplex(Double[]& LL, Double[]& L1, Int32 freq, Int32 size, Int32 cutoff, Double[]& polynomial, Int32& last_freq, Func`2& func) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\Analysis.cs:line 2240
at Wave.WaveForm.ProcessAll(Double[] L, Double[] L1, Int32 freq, Int32 freq1, Int32 freq2, Int32 bits1, Int32 bits2, Boolean bMatch, Boolean bLoadOnly, Boolean bApplyManual, Boolean bUpdateCharts) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\WaveForm.cs:line 2416
2019-07-12 00:59:49.0550|INFO|Wave.WaveForm|Stopped! Index was outside the bounds of the array.
2019-07-12 00:59:49.0550|DEBUG|Wave.WaveForm|Progress Stopped!, , 100%

The above is not happening with DW R1.034 & same test files.I am interested in the possible reason for such ( not enough samples/etc).

Well my files are dealing with real TIE measurements;i.e: very low wander/jitter& drift ( ~1ns/~1ppb/day).

I applied the TIE to a single tone and very well know that DW's clock correction doesn't work with such signals.

Later I will apply them to other functions and check them with DW.

I am only surprised that DW allows MATCH to provide much worst results than original without control or warning.

As a side remark:

In standards, 10 Hz is the line between Jitter and Wander. A HP filter applied to phase reveals Jitter (Noise) while a LP filter applied to phase reveals wander. Wander or the phase long term variations allow to estimate and correct the clock 'long' term issues ( t>0.1s)

Dealing with audio files, I have no idea if the 10 Hz value can be kept for LP=HP frequency cut. If not 100 Hz could be a good candidate.

Rgds.

Arpiben · July 12, 2019

1 hour ago, pkane2001 said:

Hi Arpiben,

What size file are you processing and what FFT size did you select for Phase EQ? If you can post the text from the Results tab, that'll help me troubleshoot.

Generally, DW tries to detect any part of the process that goes off the rails. In some cases it writes the error to the Results tab, in others it displays a message to the user, when the error is too large. It also writes a lot more detail to the log, if you turn on logging. If the error is not obvious or large in any one step, DW may not report it at all. I can add a check to ensure that the Match results don't make the initial null values worse, but in some cases, the null might be somewhat worse, while the overall match might be better, so it would be a warning rather than an error.

With Wander vs Jitter distinction, I'm not sure there's a value to computing these separately for audio. From DW perspective, these are the same -- both are the result of timing errors. In fact, I hesitated to call this value Jitter (I did it only because that made for a shorter screen label . In the results list, I call it a timing error). It represents an RMS timing error over all the samples in the file. The value is computed in the time domain, so separating it into under 10Hz and over 10Hz values will take more work and processing time. Do you see a value to doing this, other than conforming to a naming convention? I'd rather change the label, then

Troubleshooting:

1.035b with Phase EQ Enabled: (same behaviour for smaller FFT sizes 4096 for instance)

Performing raw processing only -- all matching turned off
DeltaWave v1.0.35, 2019-07-12T15:11:33.1914654+02:00
Reference: A.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Comparison: B.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Settings:
   Gain:True, Remove DC:True
   Non-linear Gain EQ:False   Non-linear Phase EQ: True
   EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
   Correct Drift:True, Precision:30
   Non-Linear drift Correction:False
   Upsample:False, Window:Hann
   Spectrum Window:BlackmanHarris, Spectrum Size:16384
   Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
   Dither:False
   Trim Silence:True

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

Initial peak values Reference: 0dB Comparison: 0dB
Initial RMS values Reference: -3,01dB Comparison: -3,01dB

Null Depth=44,048dB
Stopped! Index was outside the bounds of the array.
Signature: 927dc3938d8b2ef0ffa840afa1c6ab02

1.035b with Phase EQ Disabled:

Performing raw processing only -- all matching turned off
DeltaWave v1.0.35, 2019-07-12T15:25:54.7967053+02:00
Reference: A.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Comparison: B.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Settings:
   Gain:True, Remove DC:True
   Non-linear Gain EQ:False   Non-linear Phase EQ: False
   EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
   Correct Drift:True, Precision:30
   Non-Linear drift Correction:False
   Upsample:False, Window:Hann
   Spectrum Window:BlackmanHarris, Spectrum Size:16384
   Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
   Dither:False
   Trim Silence:True

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

Initial peak values Reference: 0dB Comparison: 0dB
Initial RMS values Reference: -3,01dB Comparison: -3,01dB

Null Depth=44,048dB

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

Gain matching disabled.
Phase offset=0ms (0 samples)
Difference (rms) = -176,3dB [-178,69dBA]
Correlated Null Depth=44,05dB [210,28dBA]
Clock drift: 0 ppm

Jitter/Wander distinction:

Honestly, I don't care about wording distinction, already used with it. The point is without proper filtering, I am afraid that in some cases, one might not be able to correct the phase variations. A few posts back you already pointed out some differences with phase for frequencies above or below 1 kHz.

The following picture may be more explicit, just replace the 24 Hour window by a 5 min one ( or typical average audio file length)

The test files are based from TIE phase measurement dedicated equipment such as Annue 3500/Oscilloquartz/Symmetricom.

Obviously I am realistic and don't expect DW to reach such precision. My point is to compare real clock phase measurements (low and high jitter) with DW. This will only cover the frequency drift/offset correction and not the Phase EQ ( Group Delay from the different transfer functions:filters,etc...) 😉

Rgds.

Arpiben · July 12, 2019

Hi Paul,

Just notice that in the working case my pasted text was incomplete, sorry.

Here is the complete one:

Nothing to complain about the phase estimation. 😊

Rgds.

1.035b with Phase EQ Disabled:

Performing raw processing only -- all matching turned off
DeltaWave v1.0.35, 2019-07-12T17:25:43.7253820+02:00
Reference: A.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Comparison: B.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Settings:
   Gain:True, Remove DC:True
   Non-linear Gain EQ:False   Non-linear Phase EQ: False
   EQ FFT Size:4096, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
   Correct Drift:True, Precision:30
   Non-Linear drift Correction:False
   Upsample:False, Window:Hann
   Spectrum Window:BlackmanHarris, Spectrum Size:16384
   Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
   Dither:False
   Trim Silence:True

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

Initial peak values Reference: 0dB Comparison: 0dB
Initial RMS values Reference: -3,01dB Comparison: -3,01dB

Null Depth=44,048dB

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

Gain matching disabled.
Phase offset=0ms (0 samples)
Difference (rms) = -176,3dB [-178,69dBA]
Correlated Null Depth=44,05dB [210,13dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=100%) at 16 bits
Files are NOT a bit-perfect match (match=83,74%) at 32 bits
Files match @ 100% when reduced to 12,5 bits

---- Phase difference (full bandwidth): 4,33363026596958E-05°
   0-10kHz: 0,00°
   0-20kHz: 0,00°
   0-24kHz: 0,00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -217,121670899852dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: ab0aff5adad46408e9b5bdb788e5289a

Arpiben · July 12, 2019

@pkane2001

Paul, no need to waste your time with previous errors. Despite the fact that curves were properly presented ( with my files ) in releases 1.033 & 1.034, errors were already there. At the end, no need to worry about and 1.035 have no regression at this level.

Rgds.

Log with DW v1.033:

2019-07-12 19:13:33.9923|DEBUG|Wave.WaveForm|Settings:
   Gain:True, Remove DC:True
   Non-linear Gain EQ:False   Non-linear Phase EQ: True
   EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
   Correct Drift:True, Precision:30
   Non-Linear drift Correction:False
   Upsample:False, Window:Hann
   Spectrum Window:BlackmanHarris, Spectrum Size:65536
   Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
   Dither:False
   Trim Silence:True

2019-07-12 19:17:41.4493|INFO|Wave.WaveForm|DONE!

2019-07-12 19:17:41.4574|DEBUG|Wave.WaveForm|Progress [NOT Bit Perfect ] 83,74% Gain matching disabled. Phase offset=0ms Difference (rms) = -176,3dB [-178,69dBA] Correlated Null Depth=44,05dB [210,22dBA] Clock drift: 0 ppm, , 100%
2019-07-12 19:17:41.4574|INFO|Wave.WaveForm|Signature: 1ab5be21ec3cec9510f3874762dd16d0

Arpiben · July 19, 2019

@pkane2001

Hi Paul,

Please do you mind helping with the following questions ?

Print screens joined are dealing with 10 Hz/100 Hz pure tones sampled @10 kHz (3 million samples).

1 Manual Corrections:

I started using it since I was not satisfied with the automatic matching. Great feature indeed since I managed to correct phase offsets and drifts. Is it possible to customise the optimise feature? I mean a dichotomy for example, for the chosen parameter: Offset alone, Drift alone, etc. In my test cases the optimisation didn't work since it was acting at both offset and drift when it should not.

BTW correcting phase using zooming in original and matched waveforms is quite painful especially for tiny values where time scale is lost. 😉

2. Default Parameters:

How to retrieve default parameters in Deltawave setup?

3. Spectrum artefacts:

In average mode there are artefacts increasing with frequency ? How can you explain it? With other audio spectrum software I can manage clean averaged -200 dB floor with 32 bits files, most probably due to better windowing.

The issue is that those artefacts are spoiling the phase and jitter accuracy results.

4. 360° Phase jumps :

Is there a way to correct such 'fake' phase jumps? Purpose is same as above.

Thanks.

Arpiben · July 20, 2019

1 hour ago, pkane2001 said:

Optimize is just trying a gradient descent search for optimal parameters. I can certainly limit the number of parameters that it tries to optimize for and see if it works differently. You do have the choice of selecting the 'goal' for the optimization in the drop-down.

If you click a few times on the 'μs' checkbox you'll get to a state where it is just a filled-in rectangle. In this mode it will display actual sample numbers on the time-axis, so you don't need to worry about nanoseconds display.

I'll add an option to restore defaults -- wanted to do it for a while. For now, you just need to open the folder where DeltaWave stores settings and delete (or rename) the default settings file. To find the file, click on Help->Logging->Open Log Folder menu. In the folder, find the two _DeltaWaveDefault.* files and rename them/move them or delete them. This will restore all defaults to DW.

The calculations are done in 64-bit floating point format, window is applied per the selection under settings. FFT size chosen will also have an effect as it changes the resolution and the number of points being averaged. How was this waveform captured? ADC/DAC precision is rarely better than about 20-21 bits, so expecting 32-bit accuracy may be a bit optimistic

Can you share an example waveform and point me to another software that shows cleaner average that I could compare this to? There could be some precision issue in the libraries I'm using, I've already found a few such issues in the past.

Hi Paul,

Yes we do have the choice to select the optimisation goal but we can not force optimisation to act only with a single variable parameter: offset only, drift only, Dc only....Keep in mind that I was looking at pure tones drifts and phase offsets which are not standard files vs audio ones.Therefore I am not complaining about how optimisation actually works.

The wave-forms were not captured but generated either by Audacity and saved in 32.bits floating wav or software (Scipy/Mathlab).

Generating a pure 100 Hz in Audacity ( amp=0.5 /100 kSps) is enough to show the spectrum averaging anomalies.

I checked the same above files with MusicScope. You may use the free trial version limited to 30 seconds: https://www.xivero.com/musicscope/. The free version will not give you access to the UHR spectrum ( FFT= 65536 / 0.67Hz/Bin) but you are not losing so much. In principle, for spectrum they use Blackman Harris 7 term FFT windows.

With DW I tried different FFT sizes for spectrum with more or less same anomalies in averaged mode. I am expecting something flat with a noise floor level depending on window applied.

Well I do know that we are looking at the limits but I have the feeling that DeltaWave can perform even better 😊

Arpiben · July 20, 2019

40 minutes ago, pkane2001 said:

Tried a trial version of MusicScope on 24-bit WAV file. Doesn't seem all that flat to me below -160dB. Are you seeing something different?

😊 Paul, using the full rights you would have seen something like the above for the 32 bits version used in DW print screens:

(I will later verify your 24 bit)

1. No average / No Peak mode:

2. Averaged spectrum:

You will notice that we don't have here apparent amplitude artefacts increasing with frequency. With DW the amplitude is around 5-6dB close to Nyquist..

Rgds.

Arpiben · July 21, 2019

@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.

Arpiben · July 21, 2019

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.

Arpiben · July 22, 2019

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 · July 22, 2019

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.

Arpiben · July 27, 2019

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.

Arpiben · July 27, 2019

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. 😊

Arpiben · August 4, 2019

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.

Arpiben · August 5, 2019

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

DeltaWave null-testing audio comparator (beta)

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Create an account or sign in to comment

Create an account

Sign in