DeltaWave null-testing audio comparator (beta)

[Arpiben]

First of all, congratulations for such a nice Audio tool!

I didn't have enough time to check Deltawave how much I wanted, anyhow please find a few comments dealing with release 1.015b.

- Lissajous with timings greater or equal to 100 ms tend to crash Deltawave

- Manual axis reset is needed for full bandwidth with sampling rates above 44.1 kHz

- Linear drift correction issues in case of phase inversion.

 

Dealing with phase drift correction, do you mind explaining the methodology used? Apparently frequency bands seem to be divided.....

 

New features candidate:

- marker on curves showing values

- Noise floor / Power density measurement for dither or others...

Rgds.

[Arpiben]

6 hours ago, pkane2001 said:

 

Hi Arpiben, thanks for your feedback!

 

Lissajous is experimental, and I'm not even sure it'll stay around. Do you find it useful?

 

That said, if something crashes, I'll need to see a log to know what happened. You can view the log from Help->Logging->View Log menu. Just post it here or PM me with the contents of the log file.

 

Phase reversal is fine as long as it's consistent throughout the track. This is detected automatically. If there are multiple phase reversals, the data can't be properly aligned. 

 

Axis Reset button doesn't work for rates above 44.1KHz? It should. 

 

The algorithm is using cross-correlation on equally-spaced chunks of the track to compute up to a sample differences, and then uses a frequency-space correlation analysis to determine the offset to a sub-sample precision. It then fits a line through those measured offsets to determine clock drift and DC offset. There's no division into frequency bands.

 

 

 

On almost any plot, hold down the shift key away from the point you're interested in -- this will anchor an arrow. Then drag the mouse to the point you want to show the value, while holding the shift key down. You can zoom in on the plot before doing this to get a more precise position of the arrow. You can place multiple arrows in the plot, if you'd like:

 

To remove them, you'll need to refresh the plot with the  button. There's not yet a way to remove an individual marker.

 

 

Good suggestions!

 

 

Thanks for the details.

Lissajous: for some cases like frequency drift when dealing with tones/chirps -> allow a quick view. 

Axis Reset Button: working fine. My point was that by default the frequency excursion in the charts  is not always full range but rather 22 kHz. Pressing axis reset normalises it .

Frequency drifts: comparing tones at fo with chirps [fo, fo + 10-4 ppm ] leads to errors in the matching process. Hereafter curves and debug for fo=11025 kHz .

Tones and Chirp generated with Audacity 176.400 kSps/32bits/30s 

 

N.B.: Folder Delta Phase has its curve labelled Phase:

 

 

 

 

 

 

2019-03-16 23:12:16.3373|DEBUG|Wave.WaveForm|Settings: 
    Gain:True, Remove DC:True
    EQ FFT Size:65536, EQ Frequency Cut: 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

2019-03-16 23:12:16.4296|INFO|Wave.WaveForm|Discarding: Start=0s, End=0s
2019-03-16 23:12:16.4306|INFO|Wave.WaveForm|Discarding: End  =0s, End=0s
2019-03-16 23:12:16.5599|INFO|Wave.WaveForm|
Initial peak values File 1: -6,021dB   File 2: -6,021dB
2019-03-16 23:12:16.5599|INFO|Wave.WaveForm|Initial RMS values File 1: -9,031dB   File 2: -9,031dB

2019-03-16 23:12:16.5599|INFO|Wave.WaveForm|Null Depth=118,145dB
2019-03-16 23:12:16.5599|DEBUG|Wave.WaveForm|Progress Updating Charts, , 23,0769230769231%
2019-03-16 23:12:16.7332|INFO|Wave.WaveForm|Trim: skipping 1 samples at start, and 1 samples at end that are below 3,72529029846191E-09 level
2019-03-16 23:12:16.7703|INFO|Wave.WaveForm|Trim: skipping 1 samples at start, and 1 samples at end that are below 3,72529029846191E-09 level
2019-03-16 23:12:16.8083|DEBUG|Wave.WaveForm|Progress Cross-correlation, , 11,5384615384615%
2019-03-16 23:12:18.2818|INFO|Wave.WaveForm|X-Correlation offset: 0 samples
2019-03-16 23:12:18.2818|DEBUG|Wave.WaveForm|Progress Cross-correlation offset: 0 samples, , 15,3846153846154%
2019-03-16 23:12:18.3740|DEBUG|Wave.WaveForm|if (drift)
2019-03-16 23:12:18.3740|DEBUG|Wave.WaveForm|Computing drift, up to 10 iterations, threshold=7,55859041359095E-08
2019-03-16 23:12:18.3740|DEBUG|Wave.WaveForm|Progress Update Xcorr Charts, , 30,7692307692308%
2019-03-16 23:12:19.1275|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=79870: xcorr=0, offs=0,00048828125
2019-03-16 23:12:19.1561|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=119805: xcorr=0, offs=-0,0009765625
2019-03-16 23:12:19.1887|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=0: xcorr=0, offs=-0,011962890625
2019-03-16 23:12:19.9041|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=399350: xcorr=0, offs=0,005859375
2019-03-16 23:12:19.9041|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=758765: xcorr=0, offs=-0,0104166666666667
2019-03-16 23:12:19.9041|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=359415: xcorr=0, offs=-0,00537109375
2019-03-16 23:12:20.5749|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=678895: xcorr=0, offs=-0,01953125
2019-03-16 23:12:20.5749|TRACE|Wave.WaveForm|ComputeDriftSpline: pos=718830: xcorr=0, offs=-0,013671875
2019-03-16 23:12:20.5749|ERROR|Wave.WaveForm|Stopped!
   at System.Threading.Tasks.Task.WaitAll(Task[] tasks, Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Wave.Analysis.ComputeDriftSpline(Double[] L, Double[] L1, Int32 freq, Int32 data_length, Int32& inc, Int32 steps, Boolean fractional, Double& error, Double& drift, Boolean bLinear) in C:\Users\ypa\documents\visual studio 2015\Projects\Wave\Wave\Analysis.cs:line 887
   at Wave.WaveForm.InitialDriftCorrect(Double[]& L, Double[]& L1, Double& spline_drift, Int32 data_length, Int32 freq, Double min_drift) in C:\Users\ypa\documents\visual studio 2015\Projects\Wave\Wave\WaveForm.cs:line 2223
   at Wave.WaveForm.ProcessAll(Double[] L, Double[] L1, Int32 freq, Int32 freq1, Int32 freq2, Int32 bits1, Int32 bits2, Boolean bMatch) in C:\Users\ypa\documents\visual studio 2015\Projects\Wave\Wave\WaveForm.cs:line 1617
2019-03-16 23:12:20.5899|INFO|Wave.WaveForm|Stopped! One or more errors occurred.
2019-03-16 23:12:20.5899|DEBUG|Wave.WaveForm|Progress Stopped!, , 100%
2019-03-16 23:12:20.5899|INFO|Wave.WaveForm|Signature: 67be077f79437bef4a4d4d9715f7c726

[Arpiben]

9 hours ago, pkane2001 said:

 

Thanks for the log -- I'll review ASAP.

 

Axis reset to 22KHz is a leftover from the days when the plots were painfully slow to render. I had to rewrite large parts of the plot library to speed this up. Back then, I tried to limit the initial display to just the audible range. I'll fix this, but for now, it's easy enough to zoom out to the full range.

 

As far as chirps are concerned, that's a known problem. Something I've been discussing with @esldude recently. The issue is that a sine chirp consists of a repeated waveform. While the amplitude is changing, the frequency remains the same. For a phase-driven alignment algorithm there is nothing to distinguish between one period of a sine wave and another. All of them produce the same perfect match, and this is where things fall apart. There are too many possible solutions. I do intend to come up with a solution to this, but for now, 'naturally occurring' waveforms will produce a much better result than anything generated

 

 

 

No worries.

All started with why correct clock drifts with non linear interpolation taking into account how oscillators behave?

Then I wanted to evaluate the linear correction applied....I guess I will need to change method 😉

 

[Arpiben]

 I am having sample counting discrepancy issues with beta release v1.0.19 ( not tested with previous ones ).

 

Whenever comparing two identical files with one of them having 1 sample truncated at the beginning then DeltaWave truncates or counts 7 samples less systematically from 44.1 kSps up to 768 kSps .

The above discrepancy value is valid, for example, when dealing with 30s chirps from 1Hz to Nyquist Hz amplitude 0.5

 

File 1:  pitched.wav[L] 1323000 samples 44100Hz 32bits, MD5=00
File 2: pitched_drift.wav[L] 1322992 samples 44100Hz 32bits, MD5=00  (Instead of 1322999)

 

A probable consequence is that the matched result may sometimes be compromised; observed with high sampling rates (768/384 kSps)

Rgds.

 

 

 

[Arpiben]

1 hour ago, pkane2001 said:

 

The number of samples shown next to the file name is what's reported by the file reader, this is before DW does any processing. Are you saying that the file actually has 7 more samples in it, but DW reports 7 less?

 

File 2 has one sample less than File 1.

DW is reporting 7 samples difference without any matching processing.

In Audacity, the reported samples value is correct even when reimporting it several time in 32 bits floating.

 

I will look at it again a bit later.

[Arpiben]

14 minutes ago, mansr said:

Sounds like something is limiting the number of samples to multiples of 8.

 

That was my first assumption.

In fact it seems related to Mono/Stereo files... With a mono Audacity chirp, DW read the correct samples value when set with Right or Left+Right channel. With Left setting in DW, I got samples discrepancy. Anyhow still not fully clear why?

[Arpiben]

38 minutes ago, pkane2001 said:

 

I assume a bug  I’ll see if I can reproduce and then fix.

 

Most probably...😉

 

A mono 11 520 000 s vs 11 519 999 s is seen by DW v1.0.20b as:

 

Reference:  pitched.wav[L] 11520000 samples 384000Hz 32bits, MD5=00
Comparison: pitched_drift.wav[L] 11519992 samples 384000Hz 32bits, MD5=00

 

Reference:  pitched.wav[R] 11517187 samples 384000Hz 32bits, MD5=00
Comparison: pitched_drift.wav[R] 11517186 samples 384000Hz 32bits, MD5=00

 

Reference:  pitched.wav[L+R] 11517187 samples 384000Hz 32bits, MD5=00
Comparison: pitched_drift.wav[L+R] 11517186 samples 384000Hz 32bits, MD5=00

[Arpiben]

6 hours ago, pkane2001 said:

I think I see the problem... With mono files, there is no Right or Left channel, and no L+R mix-down possible

It's a bug that DW is trying to process channels that are not there, but then you probably shouldn't be selecting them. I'll put in a check for this condition.

 

Thanks.

If it helps pay attention that transforming my test files into Stereo ( L=R ) also brings DW sample reading issues.

Now DW reads 11 519 996 samples  instead of 11 519 999 samples for all comparison: Left / Right / Left + Right

 

Reference:  pitched.wav[L+R] 11520000 samples 384000Hz 32bits, MD5=00
Comparison: pitched_drift.wav[L+R] 11519996 samples 384000Hz 32bits, MD5=00

[Arpiben]

50 minutes ago, pkane2001 said:

 

Thanks, I'll dig into it some more. You mentioning that this was a different behavior between mono and stereo files set off the alarm bells  yesterday 

 

 

You are correct. But you know that the more one digs the more one finds ☺️

Looking at @TomCapraro files you will also notice discrepancies among samples count depending on DW L/R/L+R selection....

Thanks. 

[Arpiben]

Hi @pkane2001

 

Please do you mind bringing more details regarding:

Phase difference information: 

• The phase values are not provided above 48 kHz, any reason or limitation? 
• Phase difference (full bandwidth): 0,00147477068670476°
                   0-10,000Hz: 0,00423158331862641°
                   0-20,000Hz: 0,0030270942735478°
                   0-24,000Hz: 0,00277569901502977°
                   0-44,100Hz: 0,0021632420867899°
                   0-48,000Hz: 0,00201385547662473°

Matching Gain:

 

• When selected the Reference Spectrogram (N°1) may be altered when it is not supposed to. Only comparison file or spectrogram N°2 is supposed to be modified. Chart inversion or  samples truncation ?
• Unmatched gain:
• Matched gain:

Thanks.

[Arpiben]

5 hours ago, pkane2001 said:

 

 

These are just RMS values of phase differences between the two signals, for the specified frequency range.

 

The first number (full bandwidth) includes all the frequencies up to Nyquist. The other ranges are just the ones that I wanted to see I can certainly add others, if there's interest.

 

Well if the partial ones are only a linear interpolation of the full bandwidth phase difference, IMO, it is useless adding ranges.

In the contrary, it helps characterising the different types of Frequency Offsets and/or Time/Phase Errors (cf picture)

I am not expecting DW to retrieve the exact ADCs' Quartz Oscillator clock drift at track or even at mix level...

But your tool can be interesting not only for audio digital comparisons.☺️

Rgds.

 

[Arpiben]

6 hours ago, fas42 said:

Just tried to mimic your processing, and this is what I got,

 

DeltaWave v1.0.21, 2019-03-29T13:45:28.8077270+11:00
Reference:  BM,44.1,orig,16b.wav[L] 1574918 samples 44100Hz 16bits, stereo, MD5=00
Comparison: BM,44.1,orig,1s,16b.wav[L] 1574918 samples 44100Hz 16bits, 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=0s
Discarding Comparison: Start=0s, End=0s

Initial peak values Reference: -1.548dB   Comparison: -1.49dB
Initial RMS values Reference: -17.93dB   Comparison: -17.93dB

Null Depth=41.005dB
X-Correlation offset: 0 samples

Final peak values Reference: -1.548dB   Comparison: -1.548dB
Final RMS values Reference: -17.216dB   Comparison: -17.216dB

Gain= -0.0042dB (0.9995x) Phase offset=0.011338ms (0.5 samples)
Difference (rms) = -97.01dB [-100.29dBA]
Correlated Null Depth=97.09dB [90.24dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=40.61%) at 16 bits
Files match @ 50% when reduced to 15.55 bits

RMS of the difference of spectra: -153.906915713764dB
DONE!

Signature: ad8435877892e550bd89ff9189ae2442

 

 

Okay, will wait for update - at least this tells one how careful one should be in doing this sort of exercise; the slightest variation in procedure is critical.

 

Just in case of, pay attention that the files you and @pkane2001 are comparing are quite different:

• different length
• different bit depth

Yours:

Reference:  BM,44.1,orig,16b.wav[L] 1574918 samples 44100Hz 16bits, stereo, MD5=00
Comparison: BM,44.1,orig,1s,16b.wav[L] 1574918 samples 44100Hz 16bits, stereo, MD5=00

 

@pkane2001:

Reference:  Bob Marley B.wav[L] 1377378 samples 44100Hz 16bits, stereo, MD5=00
Comparison: Bob Marley B-0.5sample.wav[L] 1377378 samples 44100Hz 32bits, stereo, MD5=00

 

Rgds

[Arpiben]

7 hours ago, pkane2001 said:

For example, since I know that the precision of the phase offset calculation is at or above 0.0001 samples, I can safely ignore everything below 0.0001.

 

For curiosity only, how do you calculate or estimate the precision? 1:1000 sample is at best around 0.13ns. 

Congratulations for the quality of information provided in DW's site. 

 

Phase correction

Determines and corrects for fractional phase offset down to 1/1000 of a sample

[Arpiben]

Easter wish list:

° waveform abscissa option in sample 

Christmas wish list:

°  scale improvement for the zoomed max magnifier factors 

°  marker reading true values ( for above point cases )

°  circle/glider improvement in Lissajous ( disappearing approx above 10% of total samples)

°  phase measurements improvement when dealing with certain signals such as pure tones, etc...

 

Sorry if it has already been asked/answered but I don't understand the Relative Phase box action? I was expecting it to be a kind of wrap/unwrap phase selection but it seems to have no action with the files I have been dealing with.

Thanks.

[Arpiben]

2 hours ago, pkane2001 said:

 

Funny. Your Easter wish was a feature in an early version of DW. I removed it out since nobody seemed to like it

 

Scale/label improvements are a little harder, as I don't have much control over a third-party charting library. I've already modified parts of it heavily to speed it up, but computing label spacing and positioning for different scales seems like a complex problem. I'll take a look by Christmas :)

 

Not sure what you mean by Relative Phase box. There is an Inv ϕ checkbox. That shows that the absolute phase is inverted between the two waveforms. This is handled automatically, by DW unless you check the option to prompt, in the settings. Then, you'll be asked if phase inversion should be fixed or not.

I've added an unwrap phase option under View->Charts menu, but I don't think that's what you are talking about?

 

 

 

I had been verifying how good DW is for correcting phase offset. Dealing with high sample rates I find useful to have Samples in abscissa especially when zoom is bugged for very low values. 

 

Inv ϕ box ('relative phase' when mouse on top):

Thanks for the clarifications. Since I always have prompt selected in option, I understand now the behaviour.....

 

Unwrap phase option: 

Indeed it is the option I am interested in but it doesn't appear under view ? 😂

Any cure Doctor ?

[Arpiben]

 

Out of concern but by curiosity, which type of Blackman Harris FFT window are you using? 3- 4  terms one ?

I do appreciate the availability of all spectra views since they allow  fast detection of buried details.

DW v1.0.22b:

Phase unwrapping is working as expected 😊 

Lissajous cursor is still disappearing in certain extreme  circumstances (768kSamples * 30s) but I can manage. 😉

 

Sincerely you have been doing a very great job 👍

[Arpiben]

44 minutes ago, pkane2001 said:

 

This one: https://en.wikipedia.org/wiki/Window_function#Blackman–Harris_window

 

 

I was expecting one of those but it doesn't matter since it is possible to retrieve which one DW is using. 

7-term is having lower side lobes at the expense of a wider main lobe.

 

 

[Arpiben]

My suggestion would be to generate an audio file with the type of drifts one wants to correct (linear /quadratic / etc...) with maths tools like Matlab or Scipy. Then it will be easier to evaluate how DW performs. Nothing wrong with Audacity just lacking knowledge about library performances....

 

I am still not yet very clear in which domain DW is evaluating and correcting the clock drifts: Time or Frequency ?

 

 I am guessing that the  purpose of clock drift correction is to take into account timing issues between DACs & ADCs, let's say long  term stability rather than short term (noise). In other words correct the oscillators' clock aging or differential aging ...

 

I am not expecting DW to correct frequency drifts sensu stricto (Drift is due to aging plus changes in the environment and other factors external to the oscillator).

 

Hope the following curves will help illustrating my comments without adding further complexity.

Rgds.

 

 

 

 

[Arpiben]

1 hour ago, pkane2001 said:

 

Hi Arpiben, 

 

DW calculates and corrects (only linear) clock differences in the frequency domain, but reports the drift in the time-domain units of samples. I did write a time-domain only drift calculation algorithm, but it produced worse precision than the frequency-domain one.

 

The goal of drift correction is not to fix any problems with a clock, not the temperature-related or age-related drift, but the difference in clock speeds between the DAC and the ADC. Unless a master clock is used for both units, some rate difference is guaranteed to be present, and this is not a difference that I'd like to see when nulling two waveforms.

 

Out of curiosity, where are you pulling these charts from?

 

Thanks for the provided details, clear.

I used to work with synchronization issues and the charts are taken from some generic papers.

I will post or pm them asap.

 

[Arpiben]

6 hours ago, Arpiben said:

 

Thanks for the provided details, clear.

I used to work with synchronization issues and the charts are taken from some generic papers.

I will post or pm them asap.

 

 

Charts taken from the following document:

https://apps.dtic.mil/dtic/tr/fulltext/u2/1038555.pdf

(Not sure if the charts are genuine since you retrieve them in various docs)

 

Introducing Oscillator specs:

http://docplayer.net/34332187-Understanding-oscillator-specs-hugo-fruehauf-fei-zyfer-inc-august-2004.html

https://www.testworld.com/wp-content/uploads/understanding-frequency-accuracy-in-crystal-controlled-instruments.pdf

 

Clock error prediction: 

Don't ask me to help 😉. Just an example of how predictions can be done.

http://perso.utinam.cnrs.fr/~vernotte/publis/metrologia01.pdf

[Arpiben]

Clock drifts correction is sometimes applied without any mention in reports ( 0 ppm / 0 us).

Will it be possible to notify it whatever value applied?

[Arpiben]

I have been out and busy those last days but should have more time left for a few tests.

@esldude Dealing with your last tests and queries keep in mind that DW only correct linear drifts in time domain .

In other words it is correcting only Frequency Offsets (steady) in Frequency Domain.

Clocks have frequency offset, frequency aging, frequency accuracy, etc....

A linear frequency drift ( Frequency Domain) is a parabolic curve in time domain.

 

Forgetting temperature, warming time (30min), DC fluctuations, vibrations, etc, when you compare two clocks or sampled signals based on them you need to take into account the linear frequency drift ( clock aging) or differential one ( 2 clocks ) especially when comparing signals recorded with big time lapse ( day(s), month).

Hope it helps.

Rgds.

[Arpiben]

@esldude Do you mind repeating one of your tests with a 3-4min white noise file?

I understood your point now 😉. 

I consider myself as an audio layman, but @Jud's point is quite valid since I think that during DAW or mixing, tracks may undergo or not some drift correction...  

As far as I understand things ( surely wrongly), the encountered behaviour may be due to:

1. File

2. DAP

3. ADC

4. DW

Need to eliminate variables. Not so easy as it may appear 😊.

 

[Arpiben]

@pkane2001

 

Hi Paul,

I don't understand how is drift / frequency offset corrected in cases like :

I was expecting to have the red corrected drift not straight after  ~1:47.

 

The Clock Drift window is still only refreshed in case of new drift correction applied or a close/open sequence in DW.

 

Rgds.

 

 

  

[Arpiben]

8 minutes ago, pkane2001 said:

 

Hi Arpiben,

 

It's possible that the cross-correlation computation is thrown off if the offset becomes too large. This would happen more towards the end of the track, since the error keeps increasing from left to right. DeltaWave tries to ignore large outliers when computing drift value, and so corrects for the drift despite the large apparent error at the end.

 

Once corrected, all the offsets fall within measurable range, and so the final, corrected drift is flat. DW corrects for linear drift only, so any jumps that disappear between raw and corrected plots are usually due to the error being too large in the raw measurement.

 

 

 

 

Thanks. I found this behaviour when dealing with @Archimago different DACs files ( C&D).

IMO the drift curves are a bit misleading at the end even though the spectrum induced artefacts are clearly visible once drift correction is applied.