Measuring digital audio qualities of bit-perfect playback with Diffmaker’s correlation depth
Jul 10, 2016 at 12:55 PM Thread Starter Post #1 of 43

WindowsX

Member of the Trade: Fidelizer Audio
Joined
Apr 27, 2007
Posts
1,962
Likes
364
It’s been a challenge to measure digital audio’s qualities and most of the time audiophiles don’t know any measurement outside RMAA’s analog metrics and got failed evaluations as you can see below:

 

rmaa.jpg


 

This was done through pure software environment using VB-Audio Virtual Cable to make sure no hardware’s error is involved. After lengthy research in pro audio’s communities, I found DiffMaker being used in this thread below.

 


 

DiffMaker was used to test for audible effects of

  1. Changing interconnect cables (compensation for cable capacitance may be required)
  2. Different types of basic components (resistors, capacitors, inductors)
  3. Special power cords
  4. Changing loudspeaker cables (cable inductance may need to be matched or compensated)
  5. Treatments to audio CDs (pens, demagnetizers, lathes, dampers, coatings…)
  6. Vibration control devices
  7. EMI control devices
  8. Paints and lacquers used on cables, etc.
  9. Premium audio connectors
  10. Devices said to modify electrons or their travel, such as certain treated “clocks”
  11. Different kinds of operational amplifiers, transistors, or vacuum tubes
  12. Different kinds of CD players
  13. Changing between power amplifiers
  14. General audio “tweaks” said to affect audio signals (rather than to affect the listener directly)
  15. Anything else where the ability to change an audio signal is questioned

There’s interesting metric called ‘Correlated Null Depth’ that can detect most subtle changes as measurable data. Archimago refers to this metric as below if you’re following his measurement tests.

 

The higher this value, the more correlated the 2 samples are (ie. the “closer” they sound).

 

Now I hope you understand better about DiffMaker and correlation depth. Let’s proceed to the methodology part. After a few runs of Diffmaker’s tests for a few weeks, this was the method I used in final version.

1. Setup master file and audio playback/recording through digital domain. In this case, I’ll use VB-Audio Virtual Cable, foobar2000, and Audacity on Windows 10.
2. Prepare aligned master files with silence added. For basic demonstration, I’ll make 5 samples of aligned/before/after wav files with Audacity at 24/96 format (10ms latency).
3. Route bit-perfect recording from Virtual Cable’s master audio stream with Foobar2000’s WASAPI output to Audacity’s WASAPI input, export audio as before.wav
4. Use free version of Fidelizer at Purist user level with updated foobar2000 configuration from Fidelizer’s User Guide, record again, export audio as after.wav
5. Compare results using Audio DiffMaker with master file as reference.


Testing machine ran on AMD FX8350 with 8 cores 4.2GHz and 8MB cache for L2/L3. I also used high quality motherboard with 16GB RAM and Platinum grade PSU. Here’s the result from my experiment.

 

Perfected master

parameters: 0sec, 0.000dB (L),  0.000dB (R)..Corr Depth: 300.0 dB (L), 300.0 dB (R)

This is ideal result of exact comparison with 300.0 dB of correlation depth

 

Aligned master

parameters: -3.5sec, 0.000dB (L), 0.000dB (R)..Corr Depth: 175.6 dB (L), 174.0 dB (R)
parameters: -4.5sec, 0.000dB (L), 0.000dB (R)..Corr Depth: 168.5 dB (L), 168.6 dB (R)
parameters: -5.5sec, 0.000dB (L), 0.000dB (R)..Corr Depth: 167.4 dB (L), 167.5 dB (R)
parameters: -6.5sec, 0.000dB (L), 0.000dB (R)..Corr Depth: 166.3 dB (L), 167.0 dB (R)
parameters: -7.5sec, 0.000dB (L), 0.000dB (R)..Corr Depth: 172.5 dB (L), 176.1 dB (R)

Average: 0.000dB (0.000-0.000)..Corr Depth: 170.35 dB (166.3-176.1)
Median: 0.000dB..Corr Depth: 168.55 dB


Dropped to nearly 50% of perfect data but still above 150 dB. With 9.8 dB swing range, it’s safe to assume about 5% threshold for evaluation.

 

Before Fidelizer

parameters: -1.581sec, 0.001dB (L), 0.001dB (R)..Corr Depth: 90.6 dB (L), 91.5 dB (R)
parameters: -1.184sec, 0.001dB (L), 0.001dB (R)..Corr Depth: 87.2 dB (L), 87.3 dB (R)
parameters: -1.018sec, 0.001dB (L), 0.001dB (R)..Corr Depth: 88.1 dB (L), 88.1 dB (R)
parameters: -946.4msec, 0.001dB (L), 0.001dB (R)..Corr Depth: 88.3 dB (L), 86.3 dB (R)
parameters: -686.3msec, 0.001dB (L), 0.001dB (R)..Corr Depth: 90.2 dB (L), 87.6 dB (R)

Average: 0.001dB (0.001-0.001)..Corr Depth: 88.52 dB (86.3-91.5)
Median: 0.001dB..Corr Depth: 88.1 dB


Real world result arrived with quite narrowed range. It’s only  5.2 dB between min/max of correlation depth. At least it’s more reliable than aligned result.

 

After Fidelizer

parameters: -563.4msec, 0.001dB (L), 0.001dB (R)..Corr Depth: 104.0 dB (L), 95.9 dB (R)
parameters: -1.025sec, 0.001dB (L), 0.001dB (R)..Corr Depth: 93.5 dB (L), 94.0 dB (R)
parameters: -1.286sec, 0.001dB (L), 0.001dB (R)..Corr Depth: 87.2 dB (L), 87.3 dB (R)
parameters: -1.025sec, 0.001dB (L), 0.001dB (R)..Corr Depth: 88.1 dB (L), 88.2 dB (R)
parameters: -856.4msec, 0.001dB (L), 0.001dB (R)..Corr Depth: 90.4 dB (L), 87.6 dB (R)

Average: 0.001dB (0.001-0.001)..Corr Depth: 91.62 dB (87.2-104.0)
Median: 0.001dB..Corr Depth: 89.3 dB


It started great with over 100 dB but the rest seems to wear down over time a bit because I also opened Chrome to chat in Facebook while during the experiment for daily usage tests. Strict tests for high quality result may lead to faking data abuse from people who can’t do a proper job.

With Fidelizer’s optimizations, we detected 3.1 dB increment of average and 12.5 db increment of maximum correlation depth with general improvements on other metrics too. I shall conclude that there’s measurable improvement with bit-perfect playback in digital audio.

You can also try running performing this test on your own and adjust DiffMaker configuration to show different kinds of data without rounding error or with other standards. Have fun measuring audio software optimizations with DiffMaker!

Regards,
Keetakawee


 
Jul 11, 2016 at 7:10 AM Post #2 of 43
Like I said the first time, if you're not getting bit-identical results from source to recorded output (-300dB Diffmaker results) you're doing it wrong anyway.

http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/360#post_12372879
http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/360#post_12372976

Edit: after 3 pages of bickering I have produced perfect nulling results using WiondowsX's own method:


http://www.head-fi.org/t/813763/measuring-digital-audio-qualities-of-bit-perfect-playback-with-diffmaker-s-correlation-depth/30#post_12713846
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:16 AM Post #3 of 43
Like I said the first time, if you're not getting bit-identical results from source to recorded output (-300dB Diffmaker results) you're doing it wrong anyway.

http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/360#post_12372879
http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/360#post_12372976

 
-300dB Diffmaker can be archived only from comparing the exactly same file using Diffmaker's default configuration. Otherwise, you'll never get -300dB from different recordings with mastering file as reference. Try it yourself and show me if I'm wrong.
 
Regards,
Keetakawee
 
Jul 11, 2016 at 7:24 AM Post #4 of 43
Like I said the first time, if you're not getting bit-identical results from source to recorded output (-300dB Diffmaker results) you're doing it wrong anyway.

http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/360#post_12372879
http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/360#post_12372976


-300dB Diffmaker can be archived only from comparing the exactly same file using Diffmaker's default configuration.


That's exactly what you should aim for with a digital loopback (bit identical input and output) and exactly what I got after some trial and error.

Try it yourself and show me if I'm wrong.

I already told you why your previous tests aren't valid for that.

Regards,
Keetakawee


I already documented my results and told you that they are authentic digital recordings made through a real SPDIF cable. It's not my fault if you wouldn't believe me.
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:25 AM Post #5 of 43
That's exactly what you should aim for with a digital loopback (bit identical input and output) and exactly what I got after some trial and error.
I already documented my results and told you that they are authentic digital recordings made through a real SPDIF cable. It's not my fault if you wouldn't believe me.

 
I already told you why your previous tests isn't comparison with actual mastering file as a reference. Your tests was between cropped file from recording A and B not mastering file and cropped file from recording.
 
It's not that I don't believe you but you didn't perform tests based on real mastering file. Don't use cropped recording as a reference. Use mastering file you play as a reference and crop your recording to compare. Show me if you can make perfect -300dB that way.
 
Regards,
Keetakawee
 
Jul 11, 2016 at 7:26 AM Post #6 of 43
That's exactly what you should aim for with a digital loopback (bit identical input and output) and exactly what I got after some trial and error.

I already documented my results and told you that they are authentic digital recordings made through a real SPDIF cable. It's not my fault if you wouldn't believe me.


I already told you why your previous tests isn't comparison with actual mastering file as a reference. Your tests was between cropped file from recording A and B not mastering file and cropped file from recording.

It's not that I don't believe you but you didn't perform tests based on real mastering file. Don't use cropped recording as a reference. Use mastering file you play as a reference and crop your recording to compare. Show me if you can make perfect -300dB that way.

Regards,
Keetakawee


My reference is a crop from the original file, not any recording. Should I flag you for this misrepresentation?
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:33 AM Post #7 of 43
My reference is a crop from the original file, not any recording. Should I flag you for this misrepresentation?

 
My apologies. I saw the pictures and mistook it as recording from being stated as cropped input. So you trimmed the output file before comparison. If you directly compare it, you won't archive -300dB as shown below.
 

 
Allow me to remind you again that extracting data from VSTHost may not be real capturing. It could be extracting waveform data like from wave editor software. Can you try doing real recording without relying on VST plugin?
 
Regards,
Keetakawee
 
Jul 11, 2016 at 7:38 AM Post #8 of 43
My apologies. I saw the pictures and it stated as cropped input. So you trimmed the output file before comparison. If you directly compare it, you won't archive -300dB as shown below.


If the only difference between the original file and the recorded output were an unreleated lead-in and lead-out and those are interfering with obtaining a perfect result, why shouldn't I trim them?

Allow me to remind you again that extracting data from VSTHost isn't actual capturing. You're just extracting waveform data like from wave editor software. Try to do complete round trip recording first and see if you can get exactly matched data that way.


You apparently have no understanding of what VSTHost does. It taps my physical digital line input. I even use it to improve my Skype calls by having it capture input from my actual microphone, apply processing and output to a Virtual Audio Cable (equivalent to your VB-Audio cable) and have Skype use that as the mic feed.
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:42 AM Post #9 of 43
In any case I'd offered my explanatory observations for why you're not getting bit-identical results:

There are several possibilities for this happening, but the two main factors are:

1. The bits being played out are being mapped to a smaller range of bits on the recording side. This could be due to a desire to prevent clipping, or a simple programming error.
2. The bits are being dithered. This often happens due to assumptions about the nature of the recording made by the software that cannot be overriden.

As I point out, others have gotten a bit-perfect recording
https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html


It would be trivial to compare the peak levels of your original and your recording and observe any consistent difference that is always in favor of one over the other.
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:43 AM Post #10 of 43
If the only difference between the original file and the recorded output were an unreleated lead-in and lead-out and those are interfering with obtaining a perfect result, why shouldn't I trim them?
You apparently have no understanding of what VSTHost does. It taps my physical digital line input. I even use it to improve my Skype calls by having it capture input from my actual microphone, apply processing and output to a Virtual Audio Cable (equivalent to your VB-Audio cable) and have Skype use that as the mic feed.

 
I do and that's why I'm asking you to perform real recording not from VST host. You don't seem to understand the importance of my request. These parameters will affect real-time recording.
 

 
Have you tried performing real recording and check with Diffmaker before?
 
Regards,
Keetakawee
 
Jul 11, 2016 at 7:44 AM Post #11 of 43
If the only difference between the original file and the recorded output were an unreleated lead-in and lead-out and those are interfering with obtaining a perfect result, why shouldn't I trim them?

You apparently have no understanding of what VSTHost does. It taps my physical digital line input. I even use it to improve my Skype calls by having it capture input from my actual microphone, apply processing and output to a Virtual Audio Cable (equivalent to your VB-Audio cable) and have Skype use that as the mic feed.


I do and that's why I'm asking you to perform real recording not from VST host. You don't seem to understand the importance of my request. These parameters will affect real-time recording.




Have you tried performing real recording and check with Diffmaker before?

Regards,
Keetakawee


How is a program that can record samples from a physical microphone in real time not making REAL recordings?
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:47 AM Post #12 of 43
You on the other hand admits yourself that you're recording in a "pure software environment", i.e. no physical digital interconnect is involved. If THAT's not a fake recording I don't know what is! And you STILL manage to screw it up--and tout your software's ability to somehow make it appear that you're screwing up less as an achievement...
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:48 AM Post #13 of 43
How is a program that can record samples from a physical microphone in real time not making REAL recordings?

 
As I stated before, it might be just buffered data in VST host that was recorded like copying files. Not virtual software environment performing as emulated hardware. Try to record for real without relying on VST host first and see if you can do it right with -300db.
 
Regards,
Keetakawee
 
Jul 11, 2016 at 7:50 AM Post #14 of 43
How is a program that can record samples from a physical microphone in real time not making REAL recordings?


As I stated before, it might be just buffered data in VST host that was recorded like copying files. Not virtual software environment performing as emulated hardware. Try to record for real without relying on VST host first and see if you can do it right with -300db.

Regards,
Keetakawee


Right, so when VSTHost is recording my microphone input it's actually bypassing my microphone and recording the buffered source of... WHAT?

:rolleyes:

Why can't I level the same accusation at your foobar recording, btw? Foobar even has direct access to the source file, unlike VSTHost!
 
HiBy Stay updated on HiBy at their facebook, website or email (icons below). Stay updated on HiBy at their sponsor profile on Head-Fi.
 
https://www.facebook.com/hibycom https://store.hiby.com/ service@hiby.com
Jul 11, 2016 at 7:56 AM Post #15 of 43

Right, so when VSTHost is recording my microphone input it's actually bypassing my microphone and recording the buffered source of... WHAT?

rolleyes.gif

 
Let's see if you can still do it right with -300dB without using VST host. VST host recording method will grab transport 0101 back into waveform in buffering as recording logical data domain. It's not real-time capturing application. Recording from I/O directly works like recording physical data domain with latency to capture packets in real-time.
 
Like most people who believe in buffering will eradicate jitter completely, they won't listen or think differently. If you won't do the tests in ways I requested, fine by me. But you're just doing invalid tests that was data extraction from buffering not real-time packet capturing. I bet you won't believe in software like Rewrite Data that can realign audio file for better sound quality as well.
 
Regards,
Keetakawee
 

Users who are viewing this thread

Back
Top