Beta-test: DeltaWave Null Comparison software

[solderdude]

Repeat the measurements (cold start) but sweep using REW.
Set to 44.1kHz sample frequency.
It is pointless to use music for this unless you listen to it.

In that case you have shown 'warm-up' effects. Not burn-in effects (that would be permanent).

 

[Pdxwayne]

A little bit of phase shift at HF is completely irrelevant.
Your source file doesn't have enough energy at HF, better use pink noise for this kind of test.

If you want to verify whether a tiny phase shift at HF has any audibility to it, then better test exactly that with the same DAC, manipulating a source file so that there is a few 10 degrees of phase difference at HF. But I can tell you the result already: it's totally inadible ;-)

I am curious about echo trails. For example, what freq range are those typically? Also, it would need to reduce by how many dB before we can't hear the echo trails anymore? Curious about the PK Metric numbers and how echo trails dB are related.

 

[Pdxwayne]

Repeat the measurements (cold start) but sweep using REW.
Set to 44.1kHz sample frequency.
It is pointless to use music for this unless you listen to it.

In that case you have shown 'warm-up' effects. Not burn-in effects (that would be permanent).

OK. Will put the x16 out in garage again.

E30 is very stable and I see no point checking warm up effect for it.

Thanks!

 

[solderdude]

I would suggest to keep it all in one thread. Now this is spread over 3 threads and cannot be followed easily.

 

[KSTR]

I am curious about echo trails. For example, what freq range are those typically? Also, it would need to reduce by how many dB before we can't hear the echo trails anymore? Curious about the PK Metric numbers and how echo trails dB are related.

These are somewhat funny questions.
Freq Range of echo trails? You mean the reverberant sound field captured in the recording, ranging from none (news speaker recording) to "infinite" (cathedral)? The frequency range is what it is, there is no "typical" value (except that very high frequencies are seldom present in reverbs from real rooms).
The point where those stop to be heard depends on the listening level.
PK metric has no relation to differences (if any) in the decay of reverb tails.

 

[KSTR]

@pkane, am I correct in that the Linearity Plot depicts Reference vs Compare?
If the Compare is the same file with -6dB level then the line is at +6dB.

I would find the reciprocal more intuitive (what does the Compare do vs the Reference). For example, if the Compare has compressive 3rd order distortion (or some real compression mechanism) then that would show up as the line bending downwards at higher levels which I find logical, the compare being softer.

This is a linearity plot of a DUT having compressive odd order distortion...

... but visually, it seems to indicate expansion (loud signals undergo more gain than softer signals).

 

[pkane]

@pkane, am I correct in that the Linearity Plot depicts Reference vs Compare?
If the Compare is the same file with -6dB level then the line is at +6dB.

I would find the reciprocal more intuitive (what does the Compare do vs the Reference). For example, if the Compare has compressive 3rd order distortion (or some real compression mechanism) then that would show up as the line bending downwards at higher levels which I find logical, the compare being softer.

This is a linearity plot of a DUT having compressive odd order distortion...
View attachment 115806
... but visually, it seems to indicate expansion (loud signals undergo more gain than softer signals).

Well, again, I wouldn't read too much into a plot where the scale of the error is less than 0.00005dB I'll check to see how I implemented it, I would agree that it should be comparison file vs. reference and not the other way around.

 

[KSTR]

Oh, the data is stable, see the new thread I will post in a minute or so...

 

[pkane]

Just added a page to DeltaWave website with data reprocessed from the Gearslutz AD/DA loopback test page.

It's a subset of all the files. Since this was done automatically, by a script, there may be some things that are mislabeled. Let me know and I'll fix them:

https://deltaw.org/gearslutz.html

Ordered by increasing value of PK error metric, here are a few top contenders:

 

[Pdxwayne]

Just added a page to DeltaWave website with data reprocessed from the Gearslutz AD/DA loopback test page.

It's a subset of all the files. Since this was done automatically, by a script, there may be some things that are mislabeled. Let me know and I'll fix them:

https://deltaw.org/gearslutz.html

Ordered by increasing value of PK error metric, here are a few top contenders:
View attachment 118372

AD/DA in each row of the table performed by same device?

Would it mean RME ADI-2 pro is the best for checking a DAC's outputs?

 

[pkane]

AD/DA in each row of the table performed by same device?

Would it mean RME ADI-2 pro is the best for checking a DAC's outputs?

AD/DA components vary between tests and should be described in the comments/description columns. All of these come from the Gearslutz thread, so if something is hard to understand, try looking it up there. That's also where you'll find the links to the original test files.

 

[Pdxwayne]

AD/DA components vary between tests and should be described in the comments/description columns. All of these come from the Gearslutz thread, so if something is hard to understand, try looking it up there. That's also where you'll find the links to the original test files.

I see. In the case of your table, first row's comment only mentioned one device. So I would assume one device does AD/DA for that first row.

Since the table is sorted based on PK metric, I can assume the top row is typically the best one to use for checking other devices, am I correct?

Thanks!

 

[pkane]

I see. In the case of your table, first row's comment only mentioned one device. So I would assume one device does AD/DA for that first row.

Since the table is sorted based on PK metric, I can assume the top row is typically the best one to use for checking other devices, am I correct?

Thanks!

Yes, check all three first columns, just to be sure what devices are being described. The data and the descriptions were derived from an inconsistently formatted web page, so each column by itself may not be sufficient to describe what was tested.

For example, the first in the list is RME ADI2 Pro (comment) and description column reads: Sharp DA - Sharp AD -- this implies it was tested with the same unit for both, DA and AD and in both cases the filter was set to "Sharp". Again, best to refer to the original page for a more readable description.

The data is ordered from best to worst PK Error metric, so the top line is the best one measured.

 

[Blumlein 88]

Interesting that the chart topping devices for raw RMS, MSB to MSB with adc clocking, and Forsell to Focusrite 245 with adc clocking show almost no improvement for EQ+phase correction or PK metric. Any ideas Paul about that? I'll download those files and see what is what there.

It is also interesting that the Focusrite 245 blue is only a 20 bit converter not 24 bit. First released in 1996.

 

[pkane]

Interesting that the chart topping devices for raw RMS, MSB to MSB with adc clocking, and Forsell to Focusrite 245 with adc clocking show almost no improvement for EQ+phase correction or PK metric. Any ideas Paul about that? I'll download those files and see what is what there.

Same as I described in the other thread: when two devices are driven by the same clock, there's very little phase difference, so that EQ/Phase correction in DW has nothing to improve.

 

[Blumlein 88]

Believe it or not I have a new feature request. Two even.

From time to time I run into files that when I apply a filter to them, it causes clipping where without filtering there is none.

Would it be possible to add the option to reduce one or both files by -4 db prior to filtering. Just messing around with it, I've found almost never is more than a 4 db reduction needed unless you are using pure high level white noise.

The other is to add the PK metric result as one of the columns in the Manual Corrections window. And I'm not sure if it makes sense to do so, but maybe also add it as a choice in the drop down list for Optimize!

 

[KSTR]

I think the clipping is only happening when applying pre-filters and when source level is high. I've seen clipping warnings several times but it doesn't seem to spoil the residual so I simply ignored it.

I also have feature requests, in order of importance to me:

- Bug fix: Apply trim ranges even when a manual correction is still open, so a simple apply does just that, apply it on the new range. This one is a bit annoying. I often obtain gain fine trim values by choosing a section of the file but want to apply this on the total file, atm it goes like this: match within trim range, open window, copy gain value to somewhere, close window, set new trim range, do a load-only, open window, paste value, apply.

- Bug fix / check : Polarity of the linearity plot.

- In the manual correction page, allow an additive dB correction value for the gain ("shift"). This would help a lot when fine-tuning the gain using the linearity or delta of spectra plots. Currently, correction by a certain amount of dB read from a section of the linearity plot goes like this: Read desired shift value from plot and covert to a factor, then divide current gain factor by this factor, paste the value, apply.

- A button to copy current time zoom area to trim range. And a convenience shortcut: value 0 for trim end means "all" also in the "duration/length" mode (currently, a zero length causes an exception anyway).

- Play only current zoomed range, maybe an extra play/stop button in the bottom "playback bar".

- I know that I originally suggest saving the settings whenever leaving the settings screen but I've found this to be suboptimal when working with several instances (which I do most of the time). It looks like opening the settings window does actually re-read the settings file every time which makes it hard to have different settings applied to several instances. Solution could be to read the settings only at startup but still save them whenever the settings screen is left. By this, settings would be local and private to the instance during its lifetime.

 

[pkane]

Believe it or not I have a new feature request. Two even.

From time to time I run into files that when I apply a filter to them, it causes clipping where without filtering there is none.

Would it be possible to add the option to reduce one or both files by -4 db prior to filtering. Just messing around with it, I've found almost never is more than a 4 db reduction needed unless you are using pure high level white noise.

The other is to add the PK metric result as one of the columns in the Manual Corrections window. And I'm not sure if it makes sense to do so, but maybe also add it as a choice in the drop down list for Optimize!

Clipping isn't a bad thing when it happens in DeltaWave, it just tells you that some samples fall outside the normal -1/+1 range. Since all computations are done in 64-bit floating point, the result isn't destroyed or altered by clipping, it just happens to exceed the desired range. You can actually fix this (with no ill effects on the actual samples) by using the Process->Correct Clipping menu after clipping has been detected. This will reduce the level of both, Reference and Comparison files by the same amount, just enough to ensure no clipped samples occur in either. You may want to do this, for example, before saving the clipped file.

PK Metric is still officially in beta test but I agree, it would be useful in the manual corrections window. I'll put this on the to-do list.

 

[pkane]

I think the clipping is only happening when applying pre-filters and when source level is high. I've seen clipping warnings several times but it doesn't seem to spoil the residual so I simply ignored it.

I also have feature requests, in order of importance to me:

- Bug fix: Apply trim ranges even when a manual correction is still open, so a simple apply does just that, apply it on the new range. This one is a bit annoying. I often obtain gain fine trim values by choosing a section of the file but want to apply this on the total file, atm it goes like this: match within trim range, open window, copy gain value to somewhere, close window, set new trim range, do a load-only, open window, paste value, apply.

- Bug fix / check : Polarity of the linearity plot.

- In the manual correction page, allow an additive dB correction value for the gain ("shift"). This would help a lot when fine-tuning the gain using the linearity or delta of spectra plots. Currently, correction by a certain amount of dB read from a section of the linearity plot goes like this: Read desired shift value from plot and covert to a factor, then divide current gain factor by this factor, paste the value, apply.

- A button to copy current time zoom area to trim range. And a convenience shortcut: value 0 for trim end means "all" also in the "duration/length" mode (currently, a zero length causes an exception anyway).

- Play only current zoomed range, maybe an extra play/stop button in the bottom "playback bar".

- I know that I originally suggest saving the settings whenever leaving the settings screen but I've found this to be suboptimal when working with several instances (which I do most of the time). It looks like opening the settings window does actually re-read the settings file every time which makes it hard to have different settings applied to several instances. Solution could be to read the settings only at startup but still save them whenever the settings screen is left. By this, settings would be local and private to the instance during its lifetime.

Thank you, Klaus!

1. Trim ranges. Currently these are remembered when you open the manual corrections window, and the same ones are automatically applied to anything you do inside that window. Are you saying you want to be able to change these while inside the manual corrections window?

2. Polarity of linearity: I did check it and it appears to be computed correctly

3. Manual gain correction in dB: makes sense

4. Copy current zoom to trim range: this should be useful!

5. Play current zoom range: makes sense

6. I don't think settings are re-read when opening settings window, but I'll check.

 

[Blumlein 88]

Clipping isn't a bad thing when it happens in DeltaWave, it just tells you that some samples fall outside the normal -1/+1 range. Since all computations are done in 64-bit floating point, the result isn't destroyed or altered by clipping, it just happens to exceed the desired range. You can actually fix this (with no ill effects on the actual samples) by using the Process->Correct Clipping menu after clipping has been detected. This will reduce the level of both, Reference and Comparison files by the same amount, just enough to ensure no clipped samples occur in either. You may want to do this, for example, before saving the clipped file.

PK Metric is still officially in beta test but I agree, it would be useful in the manual corrections window. I'll put this on the to-do list.

I should have known that as I knew it worked in float. Sorry. Also forgot about the clip repair.