DeltaWave null-testing audio comparator (beta)

[rando]

I won't adamantly say mp3 comparison is useless.  In fact it might be educational for some who come across this program (no idea how large your download numbers have been above those active here).  Late night, early morning, I was amused at the idea of x86 version being so crippled it could only be usable with lower bit rate lossy files.  Certainly didn't expect any movement in this direction, but I do appreciate the willingness to accept any and all suggestions.  It must have been easy to add at least.  

 

 

Installed 32 bit DW and it opened without error.  Suspect loading files would have took more time than I wish to devote right now.  

[pkane2001]

16 minutes ago, rando said:

I won't adamantly say mp3 comparison is useless.  In fact it might be educational for some who come across this program (no idea how large your download numbers have been above those active here).  Late night, early morning, I was amused at the idea of x86 version being so crippled it could only be usable with lower bit rate lossy files.  Certainly didn't expect any movement in this direction, but I do appreciate the willingness to accept any and all suggestions.  It must have been easy to add at least.  

 

 

Installed 32 bit DW and it opened without error.  Suspect loading files would have took more time than I wish to devote right now.  

 

Adding MP3 reader took all of 5 minutes  The way I see it is that it's one more file format that someone can try to use to glimpse some real information about compressed audio rather than trying to guess as to the differences. I was curious to see the result myself!

[fas42]

5 hours ago, pkane2001 said:

 

Just for you, Frank, here's v1.0.33 in 32-bit form. Don't blame me if it doesn't work

 

https://deltaw.org/DeltaWaveSetup32.zip

 

 

You're a kind fellow, Paul ...

 

Not in the mood right now to fiddle with a happily working m/c - if absolutely necessary, I'll jump through the hoops to get 64 bit operation - or organise another laptop.

[mansr]

2 hours ago, pkane2001 said:

Adding MP3 reader took all of 5 minutes

Using which decoder? There's a lot of wiggle room in the spec, and some implementations are better than others.

[fas42]

3 hours ago, pkane2001 said:

 

Adding MP3 reader took all of 5 minutes  The way I see it is that it's one more file format that someone can try to use to glimpse some real information about compressed audio rather than trying to guess as to the differences. I was curious to see the result myself!

 

Have been doing that for years, using Audacity. Difference files are significant, but not staggeringly so - casual observation of waveforms doesn't reveal obvious anomalies, and listening to the difference file doesn't make it apparent that an MP3 file has suffered terribly degrading losses ... .

[pkane2001]

1 hour ago, mansr said:

Using which decoder? There's a lot of wiggle room in the spec, and some implementations are better than others.

 

Not that I paid attention, but apparently it’s the ACM decoder.

[fas42]

Getting somewhere - the 32 bit version of ver. 33 has fired up, on Vista. Had an issue with the precise version of .Net - you suggested 4.6 was enough, Paul,  and this was also the one that Microsoft claimed was the last viable one for Vista. But no ...

 

DW needs 4.6.1 - hmmm. Crossed my fingers, downloaded, and Vista was happy!! ... whoa! So, might be handy to note that on the web page.

[fas42]

Quite pleasing - DW32 was able to handle up to 15 secs of input, CD quality - speed is not a problem, if anything the processing is somewhat faster than the HP, 64 bit m/c. Careful resetting of memory helped a bit - the curious thing is that this is a 4G physical memory laptop, and monitoring memory usage never shows going much over 2G, even when DW then stops, with a memory error. Does the program demand 2G in one gulp, soon after initiating matching, and splutter to a stop when it can't get this?

[esldude]

10 hours ago, pkane2001 said:

 

This is a more fundamental limitation of the Fourier transform. Higher resolution in the frequency domain results in lower resolution in the time domain. Wavelet transform is one way around it, but I'm not quite ready to rewrite most of the algorithms in DW. Maybe in version 2 

No, I'm not suggesting any such re-write.  If doing so results in some greatly improved results then do it for that reason.  Otherwise I don't suggest changing how DW is working at its core right now. 

[Arpiben]

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

[pkane2001]

5 hours ago, esldude said:

No, I'm not suggesting any such re-write.  If doing so results in some greatly improved results then do it for that reason.  Otherwise I don't suggest changing how DW is working at its core right now. 

 

Ha! You don’t understand how my head works. When I start thinking about it, I must do it

 

[pkane2001]

59 minutes ago, Arpiben said:

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

 

Thanks, I’ll fix it. Needless to say, I didn’t try all the FFT sizes. Since the phase correction happens in the frequency domain there are just not enough samples to generate a phase delay function with just 32 values.

[pkane2001]

6 hours ago, fas42 said:

Quite pleasing - DW32 was able to handle up to 15 secs of input, CD quality - speed is not a problem, if anything the processing is somewhat faster than the HP, 64 bit m/c. Careful resetting of memory helped a bit - the curious thing is that this is a 4G physical memory laptop, and monitoring memory usage never shows going much over 2G, even when DW then stops, with a memory error. Does the program demand 2G in one gulp, soon after initiating matching, and splutter to a stop when it can't get this?

In 32 bit windows a process usually doesn't get a lot more than 1GB of usable memory. For Deltawave, that's nothing when allocating and processing samples, especially at higher sample rates. If the computer runs out of pysical memory, Windows might start trying to use your hard disk as a memory extension, and that can slow things down considerably.

[pkane2001]

15 hours ago, Arpiben said:

@pkane2001

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

Rgds.

 

 

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.

 

[fas42]

Some more good news! ... Found a memory organiser utility which does a garbage collection of the RAM space, and allows DW32 to access the core it wants more successfully - meaning, program can handle longer clips, do more processing, etc ... nice!

[Arpiben]

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.

 

[pkane2001]

22 minutes ago, Arpiben said:

 

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.

 

 

Phase unwrapping was perhaps one thing that mattered quite a bit more than I had expected. I tried all the documented methods I could find, but in the end had to create my own. My method may not look pretty, but works much better for curve fitting.

[pkane2001]

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. 

 

 

 

@esldude'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 phase oscillations, but it certainly flattened the result quite a bit 

 

[fas42]

Paul, only going slowly with exploring ver. 33, but in looking at a Gearslutz sample got a Delta Phase with EQ correction that oscillated; whereas the uncorrected phase variation looked quite reasonable. This was with the Edirol UA-1000 (gollumsluvslave) posting.

 

Just to confirm that DW32 was behaving itself I checked out two of the Gearslutz samples that you just posted, and apart from being much noisier, because I was only processing 30 secs of the 2 min tracks, the graphs match your results.

 

Do you get a similar ripple with that Edirol sample?

[Arpiben]

@pkane2001  &/or @fas42

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

Thanks.

[fas42]

Arpiben, the latest update in that Gearslutz thread is https://www.gearslutz.com/board/showpost.php?p=13947046&postcount=1743, 26th April this year. The original file is linked to in the line, "DA-AD loops from this wav file evaluated by means of Audio DiffMaker."

[pkane2001]

3 hours ago, fas42 said:

Paul, only going slowly with exploring ver. 33, but in looking at a Gearslutz sample got a Delta Phase with EQ correction that oscillated; whereas the uncorrected phase variation looked quite reasonable. This was with the Edirol UA-1000 (gollumsluvslave) posting.

 

Just to confirm that DW32 was behaving itself I checked out two of the Gearslutz samples that you just posted, and apart from being much noisier, because I was only processing 30 secs of the 2 min tracks, the graphs match your results.

 

Do you get a similar ripple with that Edirol sample?

 

I’ll try, but I do have a small improvement that I’m testing that might help here. The resulting oscillations are usually because the phase curve isn’t fitted properly, this may be the result of an unusually sharp original phase or one that has sudden changes.

 

What I found is that the phase below 1kHz often behaves differently than phase above, so I now have a version that creates two curves, one for below 1k and one for above. This seems to fit real oscillating phase much better as well as handle those cases where the behavior below 1k is significantly different.

 

There will always be some pathological cases where the phase fit will not work well — very noisy or discontinuous phase might easily do this. It’s important to look at the fitted curve to see how well it tracks the original phase.

 

By by the way, a phase curve that is straight indicates zero or linear phase filters, while phase curving up or down towards high frequencies indicates non-linear or minimum phase filters. Oscillating phase appear to be poorly implemented filters with significant ripple in the pass band.

[fas42]

8 minutes ago, fas42 said:

Arpiben, the latest update in that Gearslutz thread is https://www.gearslutz.com/board/showpost.php?p=13947046&postcount=1743, 26th April this year. The original file is linked to in the line, "DA-AD loops from this wav file evaluated by means of Audio DiffMaker."

 

You're right, the mediafire link is playing up ... I downloaded it only a few days ago, so hopefully it's just a transient problem - Gearslutz people will be complaining too, so it should be sorted soon, I would imagine.

[pkane2001]

13 hours ago, fas42 said:

Paul, only going slowly with exploring ver. 33, but in looking at a Gearslutz sample got a Delta Phase with EQ correction that oscillated; whereas the uncorrected phase variation looked quite reasonable. This was with the Edirol UA-1000 (gollumsluvslave) posting.

 

Just to confirm that DW32 was behaving itself I checked out two of the Gearslutz samples that you just posted, and apart from being much noisier, because I was only processing 30 secs of the 2 min tracks, the graphs match your results.

 

Do you get a similar ripple with that Edirol sample?

 

The good news it looks like the new curve fitting algorithm works without oscillations on the UA-1000 file. Is this better than what you saw? 

 

 

 

[pkane2001]

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