Jump to content
pkane2001

DeltaWave null-testing audio comparator (beta)

Rate this topic

Recommended Posts

On 6/26/2019 at 1:24 PM, esldude said:

Well what about the pane where we select FFT size, windowing type and it also has the setting for phase.  That has some space.  You are doing too good a job adding features maybe. :)

 

Is this something like what you're looking for (min=-110dB, max=-60dB)?

 

image.thumb.png.3896a8b606901ae46a1405ef6a286a13.png

Share this post


Link to post
Share on other sites
4 minutes ago, esldude said:

No that is not it.  Sorry for the misunderstanding.  I'm referring to spectrogram 1 and 2 the ones with all the pretty colors.  I'll add a screenshot in a minute. 

 

 Ah, now I understand. That makes more sense  :)

 

Share this post


Link to post
Share on other sites
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.

 

image.thumb.png.b864f99bff9168e003aef8aec44ebe87.png

 

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.

 

image.thumb.png.74318700332aa87292aa3d910d335416.png

 

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.

 

Share this post


Link to post
Share on other sites

Just noted what Pluto had to say on the ASR forum, and echo his thoughts on revealing ultrasonic content: remove all audible content and then apply various multiplicative factors would be the best approach, to my mind.

 

Machines I have running right now are not suited for playing with DW - so can't say whether what you've done so far tick boxes ... sorry!


Frank

 

http://artofaudioconjuring.blogspot.com/

 

 

Ahhh, Mankind ... Porsche intellect, Trabant emotions ...

Share this post


Link to post
Share on other sites
5 minutes ago, fas42 said:

Just noted what Pluto had to say on the ASR forum, and echo his thoughts on revealing ultrasonic content: remove all audible content and then apply various multiplicative factors would be the best approach, to my mind.

 

Machines I have running right now are not suited for playing with DW - so can't say whether what you've done so far tick boxes ... sorry!

 

Using factors is a bit problematic as this either doesn't move the ultrasonic frequencies low enough to be easy to listen to when used with a small reduction factor, or it compresses a large range of frequencies into a very narrow band, such as a few hundred Hz with a large factor. This also doesn't make it easy to listen to or to hear patterns. I've had a chance to play with this for a bit, but didn't find a good way to scale frequencies 'harmonically' using factors. 

 

Ideally, I'd want to be able to scale 20k-48k range, for example, into the 0-20k range. Easy enough to do this by applying a linear factor, but this would also destroy harmonic relationships.

Share this post


Link to post
Share on other sites

Making some progress on the variable group delay correction, aka, non-linear phase correction. Using Archimago's blind test files that didn't do so well with the standard (linear) phase/drift correction in the previous versions of DeltaWave.

 

Here's a teaser: white = non-linear phase-corrected, blue = uncorrected, as in the previous versions of DW. You can see why the match wasn't so great. The result also improves the null values. Still more improvement seems possible, but that data is fairly noisy.

 

Hope to have a preview version ready soon!

image.thumb.png.c360a495ec7ecb6dd03509f743f8190a.png

 

 

 

Same plot, but with phase unwrapped:

image.thumb.png.8e2af0e9ad58454856683f8f948cdfe8.png

Share this post


Link to post
Share on other sites

Bummer! The HP laptop is in bits, so tried the Dell beast which is running Vista - DW doesn't like it :( ; gives me a "The version of this file is not compatible with the version of Windows ... " message. 

 

Updated .net to 4.6, but no go - does DW absolutely have to have a 64 bit OS?


Frank

 

http://artofaudioconjuring.blogspot.com/

 

 

Ahhh, Mankind ... Porsche intellect, Trabant emotions ...

Share this post


Link to post
Share on other sites
10 minutes ago, fas42 said:

Bummer! The HP laptop is in bits, so tried the Dell beast which is running Vista - DW doesn't like it :( ; gives me a "The version of this file is not compatible with the version of Windows ... " message. 

 

Updated .net to 4.6, but no go - does DW absolutely have to have a 64 bit OS?

 

I can build a 32-bit version, but it will be very limited in the size of files it can process. There's just not much memory available in a 32-bit process to hold large arrays of data that DW needs. 

Share this post


Link to post
Share on other sites

Fair enough. If not a major exercise, would be handy to have a 32 bit version available, to at least try things out if the machinery that happened to be available wasn't up to 64 standard - this laptop has a 64 bit capable processor, but was installed with 32 software; I will look at doing something about that.

 

Thanks, Paul!


Frank

 

http://artofaudioconjuring.blogspot.com/

 

 

Ahhh, Mankind ... Porsche intellect, Trabant emotions ...

Share this post


Link to post
Share on other sites

Would the as yet unrealized potential target mp3 audiophiles still holding true to their core x86 principles and hardware?  I foresee 10th gen lossy format tests and other hilarity.  :P

 

I did just try installing DW on an older laptop with 3GB RAM running W10.  After double checking the PKAudio folder installs itself in Program Files (x86) on a 64 bit system.  Predictable results.  

 

Share this post


Link to post
Share on other sites
48 minutes ago, rando said:

Would the as yet unrealized potential target mp3 audiophiles still holding true to their core x86 principles and hardware?  I foresee 10th gen lossy format tests and other hilarity.  :P

 

Sounds like you really want to be able to use MP3 with DeltaWave. I can certainly look into adding it, just for hilarity sake :)

 

Share this post


Link to post
Share on other sites
14 hours ago, fas42 said:

Fair enough. If not a major exercise, would be handy to have a 32 bit version available, to at least try things out if the machinery that happened to be available wasn't up to 64 standard - this laptop has a 64 bit capable processor, but was installed with 32 software; I will look at doing something about that.

 

Thanks, Paul!

 

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

 

Share this post


Link to post
Share on other sites

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(!)

image.thumb.png.d495f7dd80de36d9d82127d098d0781d.png

 

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

image.thumb.png.126695dec6f2a43359aadf7d9e47efd0.png

 

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 original curve, 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°)

 

Share this post


Link to post
Share on other sites
1 hour ago, pkane2001 said:

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

 

@esldude

 

Dennis, the frequency range setting for spectrograms will need to be in a later release. It's not as simple as I had hoped, as it requires increasing frequency resolution when zooming in, meaning that it will require larger and larger FFTs to be performed. Considering that there are many thousands of FFTs being calculated for each spectrogram, this will slow things down considerably. I'll do some more thinking to see if there's a better way to do this.

 

For now, you can simply chose a larger size FFT in the spectrogram settings to see just how slow it may become. Once you do, this will also let you zoom-in further without losing as much resolution.

 

 

 

Share this post


Link to post
Share on other sites
6 minutes ago, pkane2001 said:

 

@esldude

 

Dennis, the frequency range setting for spectrograms will need to be in a later release. It's not as simple as I had hoped, as it requires increasing frequency resolution when zooming in, meaning that it will require larger and larger FFTs to be performed. Considering that there are many thousands of FFTs being calculated for each spectrogram, this will slow things down considerably. I'll do some more thinking to see if there's a better way to do this.

 

For now, you can simply chose a larger size FFT in the spectrogram settings to see just how slow it may become. Once you do, this will also let you zoom-in further without losing as much resolution.

 

 

 

Thanks for looking at this Paul.  And don't worry about it further.  It is a useful difference only very rarely.  And I can export the files from Deltawave to look at with other software on those rare occasions.   So I wouldn't bother with it.  What your software does already is something quite special in its overall capabilities. 


To paraphrase Rick James, "sighted listening is a helluva drug".

Share this post


Link to post
Share on other sites
1 minute ago, esldude said:

Thanks for looking at this Paul.  And don't worry about it further.  It is a useful difference only very rarely.  And I can export the files from Deltawave to look at with other software on those rare occasions.   So I wouldn't bother with it.  What your software does already is something quite special in its overall capabilities. 

 

But if you do need to zoom in, just increase FFT size in settings. Here's a 96kHz file zoomed in on lower 21kHz, FFT size at 8192:

image.thumb.png.f4eefacb6a08918eb1b1c86f55b0adb9.png

Share this post


Link to post
Share on other sites
21 minutes ago, pkane2001 said:

 

But if you do need to zoom in, just increase FFT size in settings. Here's a 96kHz file zoomed in on lower 21kHz, FFT size at 8192:

image.thumb.png.f4eefacb6a08918eb1b1c86f55b0adb9.png

The reason that sometimes won't do is because shorter term events get missed by large FFT values.  It uses a larger number of samples to generate the FFT and something short enough is no longer resolvable.  Lowering the FFT values will catch it, but raises the noise floor so sometimes you obscure what you are looking for.  It only comes up very rarely, and only would apply to short events just above, but not too far above the noise floor.  So like I said, it is a rare and peculiar thing.  So not worth you spending extended time or effort to address because it has such marginal utility. 


To paraphrase Rick James, "sighted listening is a helluva drug".

Share this post


Link to post
Share on other sites
9 minutes ago, esldude said:

The reason that sometimes won't do is because shorter term events get missed by large FFT values.  It uses a larger number of samples to generate the FFT and something short enough is no longer resolvable.  Lowering the FFT values will catch it, but raises the noise floor so sometimes you obscure what you are looking for.  It only comes up very rarely, and only would apply to short events just above, but not too far above the noise floor.  So like I said, it is a rare and peculiar thing.  So not worth you spending extended time or effort to address because it has such marginal utility. 

 

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

Share this post


Link to post
Share on other sites

For @rando:

 

Here's a comparison between the original 24/44.1 WAV file and an Audacity/Lame converted MP3 copy at 170-210kbps.

 

A fairly decent match, although a large timing error and a start of a low pass filter @ 17kHz are some of the obvious differences:

 

Capture.thumb.PNG.f42d50a6829c6de6cf36b77c00c7e544.PNG

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...