- Joined
- Feb 23, 2016
- Messages
- 20,784
- Likes
- 37,678
Looks like a fair size difference in the 30-50 hz range. And linearity is very low.
OK here are three example files. 100.wav is the reference. my Deltawave thinks mpd3 is reversed polarity but I told it not to invert. I see more than 10dB difference in the spectrum of delta. I deleted all the really bad ones but I can capture some more later.
https://www.dropbox.com/s/53spkr9hglakrl3/Dropbox.zip?dl=0
There is no chance to simply fix the level, and the "level difference" is much lower.And there is a 0.6dB level difference, quite visible in raw files which probably gave the main cues for your ABX
As I said in the other thread, using non-linear correction is in one sense cheating. However it is a tool to find what is causing the difference in null levels. In this case there is a low corner filter and some variable response in the devices between 400hz and 10 khz. Those should be measurable with a good FR test though it might slip thru on just doing 1 khz. It does show overly simplified testing has some blind spots.There is no chance to simply fix the level, and the "level difference" is much lower.
Initial peak values Reference: -2.654dB Comparison: -2.438dB
Initial RMS values Reference: -15.264dB Comparison: -15.224dB
Final peak values Reference: -2.654dB Comparison: -2.533dB
Final RMS values Reference: -15.264dB Comparison: -15.322dB
ABX works even with the "matched" file. The biggest difference is the timbre of the guitar in the left ear - try it. It is easy to hear it. Matched waveforms:
View attachment 253552
It does not make sense to make all sorts of corrections, because the files do sound different. The system that measures THD much better than -120dB and SINAD 112dB produces audibly different results. This only shows that the measuring methods we (yes not all of us) consider most important may not tell much and may not correlate with our hearing. We have known that. Only it is not always easy to bring the proof and this is one possible proof.
Hello Paul, I have come to an interesting problem today. Normally I prepare my files for listening tests through the soundcard which has the same clock for its ADC and DAC and when comparing the loop product to the original music file, Deltawave gives negligibly low error numbers and the files are indistinguishable in the ABX test. Today, I have decided the loop constituted of Topping D10s DAC (connected to PC through USB-ISO to cut the ground loop) and E1DA Cosmos ADC. For THD or IMD measurements, this loop gives excellent numbers. However, in a loop with a music file, and the result compared to the original file (both previously level matched and time aligned in AA), the result is horrible. Not only in pkmetrics and error distribution, but the difference between the original and the loop product is easily audible. Would you have an idea what could be the issue? It is definitely not the Deltawave itself.
View attachment 253509
View attachment 253510
There is no chance to simply fix the level, and the "level difference" is much lower.
Initial peak values Reference: -2.654dB Comparison: -2.438dB
Initial RMS values Reference: -15.264dB Comparison: -15.224dB
Final peak values Reference: -2.654dB Comparison: -2.533dB
Final RMS values Reference: -15.264dB Comparison: -15.322dB
ABX works even with the "matched" file. The biggest difference is the timbre of the guitar in the left ear - try it. It is easy to hear it. Matched waveforms:
View attachment 253552
It does not make sense to make all sorts of corrections, because the files do sound different. The system that measures THD much better than -120dB and SINAD 112dB produces audibly different results. This only shows that the measuring methods we (yes not all of us) consider most important may not tell much and may not correlate with our hearing. We have known that. Only it is not always easy to bring the proof and this is one possible proof.
I haven't made a listening test or ABX so far, but will do....after trying to do a better level match, or even better, stepping level differences in 0.1dB steps through range from -0.5dB to +0.5dB. Usually I find systematic "sound signature" differences other than simple level to survive a slight level mismatch. If not, it was just the level difference alone.It does not make sense to make all sorts of corrections, because the files do sound different.
It's important to understand the differences between linear and non-linear corrections. As Dennis said, non-linear EQ corrections are "cheating" in a sense that these will correct for errors that might be very audible. They exist in order to help diagnose what's causing the difference. Non-linear phase errors reduced by non-linear EQ tells you that there are timing variations that are not corrected by simple drift removal. These errors can very well be audible. Non-linear level errors are even more likely to be audible, so when non-linear level EQ causes a large decrease in error -- this is likely the cause.I haven't made a listening test or ABX so far, but will do....after trying to do a better level match, or even better, stepping level differences in 0.1dB steps through range from -0.5dB to +0.5dB. Usually I find systematic "sound signature" differences other than simple level to survive a slight level mismatch. If not, it was just the level difference alone.
And I would agree partly, DW has so many parameters that it's easy to get lost and "overcorrect". With a bit of fiddling I can arrive at -97dB correlated null and -102dB PKmetric.
Residual now is "clean" enough to expose slight dynamic gain drifts (reference voltage instabilities) and does not expose much distortion (as expected)
That sounds like the E1DA ADC was set to mono mode, where it produces a different result in left and right channels. The left channel is a combination of left and right to reduce noise, and the right channel is just the right channel in that case.@pkane, I'm still using DW 2.0.2 and I'm getting completely different results (without nonlin correction) than what you showed.... and now I found why:
I've used right channels for analysis (probably as selected from the last test I did) and this behaves much better than the left to left channel comparison where I now get similar results than you and those indicate somethning is broken in the DAC-->ADC chain for the left channels which then also explains the ABX.
Right channel results (nonlin cor. off):
View attachment 253563
There is passband ripple of the ADC and DAC but otherwise a close match.
And it is a linear phase ripple because phase is clean:
View attachment 253564
No signs of EQ errors as well:View attachment 253565
Clock stability after drift correction also is excellent:
View attachment 253566
@pma, Something is really broken in left channels as it is many orders of magnitude worse than right channels in all aspects.
Hi, this is exactly what I've reported some months ago using Tone2 Pro and Cosmos ADC, except that my results were not as bad as yours, so there's certainly a problem somewhere.Hello Paul, I have come to an interesting problem today. Normally I prepare my files for listening tests through the soundcard which has the same clock for its ADC and DAC and when comparing the loop product to the original music file, Deltawave gives negligibly low error numbers and the files are indistinguishable in the ABX test. Today, I have decided the loop constituted of Topping D10s DAC (connected to PC through USB-ISO to cut the ground loop) and E1DA Cosmos ADC. For THD or IMD measurements, this loop gives excellent numbers. However, in a loop with a music file, and the result compared to the original file (both previously level matched and time aligned in AA), the result is horrible. Not only in pkmetrics and error distribution, but the difference between the original and the loop product is easily audible. Would you have an idea what could be the issue? It is definitely not the Deltawave itself.
It was indeed frustrating, and I tried to add SPDIF, TOSLINK, AES, Word clock to get versatility and sync, but without success unfortunately (with the MCLK coming from the ESS chip).The lack of syncing means is what kept me from using a Cosmos ADC so far
The Cosmos ADC has a mono mode (for 3dB increased signal-to-noise ratio) which works like this:Now, how is it possible that the right channel of the recording was like the original right channel, but that the left recorded channel was like the mono mix of both left+right original channels? If it's what you found, what incorrect settings can lead to this? I will listen to the files to understand
Ohhh, I certainly never tried to send both L and R from DAC at the same time when using the Mono mode of the Cosmos ADC, I didn't know it was acting like that.The Cosmos ADC has a mono mode (for 3dB increased signal-to-noise ratio) which works like this:
- Left output (digital) is the mix of left and right analog inputs.
- Right output (digital) is right analog input.
@IVX, To avoid such pitfalls, the right output channel should either be silent or a duplicate of the left output channel or even better yet, the difference/2 of L and R channels... which would then be a L/R to M/S (and vice versa) encoder/decoder.
According to my ES9822 experience, such configurations are not supported. There isn’t even a direct way to chain ES9822 ADCs, so that you would get a dual mono configuration (I did it with an external mux). The only chaining config available is for TDM.To avoid such pitfalls, the right output channel should either be silent or a duplicate of the left output channel or even better yet, the difference/2 of L and R channels... which would then be a L/R to M/S (and vice versa) encoder/decoder.
this is not my idea, ESS made that this way.The Cosmos ADC has a mono mode (for 3dB increased signal-to-noise ratio) which works like this:
- Left output (digital) is the mix of left and right analog inputs.
- Right output (digital) is right analog input.
@IVX, To avoid such pitfalls, the right output channel should either be silent or a duplicate of the left output channel or even better yet, the difference/2 of L and R channels... which would then be a L/R to M/S (and vice versa) encoder/decoder.
Understood. I had assumed this mixing is done in software, after the conversion, in the XMOS USB interface custom(?) firmware.According to my ES9822 experience, such configurations are not supported.