Develop a metric for CD Transport and CD Player performance

[Tangband]

Yes it is poor performance. Poor in the analog domain. Any reason to think the bits going over the Toslink are wrong?

The measurements shown are all in the digital domain .

 

[mansr]

I hadn't looked at the original post in some time. So you are comparing the analog output of a CD player to the SPDIF output of the CD player, and that to the ripped wav file. Is that correct? Step one is a waste of time. Unless broken or failing the SPDIF will match the wav file 100%. The analog capture will never, ever match the wav file because of analog noise.

I barely looked at the linked thread for various CD drives, but I'd assume those were all ripping at elevated speed not real time playback rates. There can sometimes be errors there. Real time with CD players I don't think I've ever encountered one.

So no I'm not re-doing something done a decade or more back because I don't need to reinvent the wheel every day of my life and I don't have all those drives. I have a Bluray player and I think the old Pioneer universal player I could use. Don't need to, already done that. And those results were posted to a couple forums at least. This was prior to the existence of ASR. I'm trying not to be too curmudgeonly, but what you are looking into is a waste of time of a solved problem.

What is your goal? To find the most reliable high speed ripping drives with least errors? To find a metric for accurate CD players for better sound? If the latter, also a waste of time. Even when errors occur they are corrected or interpolated. They occur so rarely it is never one player is slightly better sounding than another due to errors. You get glitches or dropped out playback or no issues. That is it. That is all.

I do know how to use Deltawave, I think I was beta tester #1 for it. It is terrific software.

For reasons I've never quite understood, CD-ROM drives can differ slightly in how they report track boundaries. The fancier ripping programs include a database of offsets for known drives. Even without this compensation, the audio data will be identical, although the track boundaries might be shifted by a few milliseconds.

 

[Blumlein 88]

The measurements shown are all in the digital domain .

Clearly that isn't bit perfect. I'd suspect issues with some kind of resampling going on. That kind of error isn't from errors in the Toslink SPDIF interface. The SPDIF is being fed bad information I'd suspect.

 

[Blumlein 88]

Okay, you wanted some data. Here is some data. First up is the Deltawave result of a 2 minute plus song with original file compared to the result from a burned CD-r played in my Panasonic bluray and output over Toslink. Toslink into an RME Babyface Pro Fs.

I could also show you the same file played over a Topping D10 balanced with the SPDIF Optical input into the Babyface. But a waste of time as it is identical other than the name of the compare file. A bit perfect result. And yes I did the test, I didn't assume the D10 would be identical, but of course as I expected it was.

 

[73hadd]

Thank you! Can you also use the CLI feature as noted here?

Beta-test: DeltaWave Null Comparison software

A quick update to DeltaWave version 2.0.1: Changes in 2.0.1 Fix: regression issue with color scaling of delta spectrograms Changed: IIR filter replaced with the maximally flat in passband Butterworth version Fix: FIR filter could previously cause a small error near DC frequency Added...

www.audiosciencereview.com

C:\Bin> DeltaWave "z:\test\reference.wav" "z:\test\comparison.wav" "z:\test\output.txt"

I am sure the results will be the same but for consistency in process I would like to have the output.

To start a table of data, the entries could look like:

Source media	Source device	Output interface	CPU interface	Result %
Burned CDR	Panasonic bluray	Toslink	RME Babyface Pro Fs	100
.wav	Topping D10	Toslink	RME Babyface Pro Fs	100

I did finally update the first post and specified "Audio CDs" as the preferred source, but I am sure the burned CDR test is useful, considering the topic I will lead into next.


Transmission Errors?
Even if every disc reader logically creates a perfect bitstream, I still find it unlikely that every spdif or toslink interface will output the bitstream perfectly enough to be captured as identical .wav files. This is not a stateful exchange, there is no error correction at this point, the receiving device cannot go back and say to the source "are you sure about that?"

Let's say for example you unplugged your toslink cable during the transfer. The .wav files would not be identical. How would a sudden over/under voltage to the toslink interface affect the bitstream? Or a poorly isolated coax interface picking up noise? Yes these are in the categories of "failures" but I expect that over a number of test devices some will be more prone to these failures than others.


Error Correction?
Aside from transfer issues, I was trying to read more about CIRC and found this article:

CD Ripping Terminology - LinnDocs

docs.linn.co.uk

Although the context is ripping, I wonder if the comments about CIRC also apply to other disc players:

"No practical error detection system can detect all possible error patterns. It will always be possible for random errors to mimic ‘good data’ which then appears correct to the error detection system. A good error detection system will try to minimise the probability of an error going undetected, but this probability will never be zero"

"Not all decoders exploit the full capabilities of CIRC, and some may only do so when running at low speeds. The C2 decoding process, for example, is capable of correcting up to 4 erroneous bytes in every 24, but some implementations can correct only 2."

I will state that CIRC really is amazing technology. Will every disc reader correct all C1 the same way? Probably. Will every disc reader detect and flag every C2 the same way? I am not sure.

I am not clear on what interpolation happens before transmission as spdif but I still find it unlikely for that result to be identical from multiple devices.

 

[RayDunzl]

I still find it unlikely that every spdif or toslink interface will output the bitstream perfectly enough to be captured as identical .wav files.

The format of the data sent across the S/PDIF interface does not resemble a .WAV file contents, due to the encoding of the bitstream for transmission between S/PDIF interfaces.

The .WAV file has a descriptive header and then left/right/left/right samples with no additional framing or encoding..

What goes across the coax or fiber is very different.

 

[mansr]

Transmission Errors?
Even if every disc reader logically creates a perfect bitstream, I still find it unlikely that every spdif or toslink interface will output the bitstream perfectly enough to be captured as identical .wav files. This is not a stateful exchange, there is no error correction at this point, the receiving device cannot go back and say to the source "are you sure about that?"

S/PDIF transmission and reception is pretty trivial, making errors exceedingly rare. Even if there was an error once an hour, say, that would not affect the overall "sound quality." You'd get a tick whenever an error did occur, and chances are good you wouldn't even notice.

"No practical error detection system can detect all possible error patterns. It will always be possible for random errors to mimic ‘good data’ which then appears correct to the error detection system. A good error detection system will try to minimise the probability of an error going undetected, but this probability will never be zero"

If a disc is so bad as to produce any significant number of undetected errors, it will no longer sound like music at all. It will emphatically NOT cause any of the usually described effects like lacking/excessive bass or treble, haze, glare, prat, etc. That is just not possible.

 

[LightninBoy]

I just don't get it. We routinely transmit terabytes of data error free across the world, under the ocean, and through space. We stream HD movies at extremely high bit rates error free through shared networks. But somehow folks think pulling simple music data off of a CD a foot away through a dedicated wire is fraught with errors.

 

[tonycollinet]

I just don't get it. We routinely transmit terabytes of data error free across the world, under the ocean, and through space. We stream HD movies at extremely high bit rates error free through shared networks. But somehow folks think pulling simple music data off of a CD a foot away through a dedicated wire is fraught with errors.

Bizarre isn't it?

 

[Blumlein 88]

Thank you! Can you also use the CLI feature as noted here?

Beta-test: DeltaWave Null Comparison software

A quick update to DeltaWave version 2.0.1: Changes in 2.0.1 Fix: regression issue with color scaling of delta spectrograms Changed: IIR filter replaced with the maximally flat in passband Butterworth version Fix: FIR filter could previously cause a small error near DC frequency Added...

www.audiosciencereview.com

C:\Bin> DeltaWave "z:\test\reference.wav" "z:\test\comparison.wav" "z:\test\output.txt"

I am sure the results will be the same but for consistency in process I would like to have the output.

To start a table of data, the entries could look like:

Source media	Source device	Output interface	CPU interface	Result %
Burned CDR	Panasonic bluray	Toslink	RME Babyface Pro Fs	100
.wav	Topping D10	Toslink	RME Babyface Pro Fs	100

I did finally update the first post and specified "Audio CDs" as the preferred source, but I am sure the burned CDR test is useful, considering the topic I will lead into next.


Transmission Errors?
Even if every disc reader logically creates a perfect bitstream, I still find it unlikely that every spdif or toslink interface will output the bitstream perfectly enough to be captured as identical .wav files. This is not a stateful exchange, there is no error correction at this point, the receiving device cannot go back and say to the source "are you sure about that?"

Let's say for example you unplugged your toslink cable during the transfer. The .wav files would not be identical. How would a sudden over/under voltage to the toslink interface affect the bitstream? Or a poorly isolated coax interface picking up noise? Yes these are in the categories of "failures" but I expect that over a number of test devices some will be more prone to these failures than others.


Error Correction?
Aside from transfer issues, I was trying to read more about CIRC and found this article:

CD Ripping Terminology - LinnDocs

docs.linn.co.uk

Although the context is ripping, I wonder if the comments about CIRC also apply to other disc players:

"No practical error detection system can detect all possible error patterns. It will always be possible for random errors to mimic ‘good data’ which then appears correct to the error detection system. A good error detection system will try to minimise the probability of an error going undetected, but this probability will never be zero"

"Not all decoders exploit the full capabilities of CIRC, and some may only do so when running at low speeds. The C2 decoding process, for example, is capable of correcting up to 4 erroneous bytes in every 24, but some implementations can correct only 2."

I will state that CIRC really is amazing technology. Will every disc reader correct all C1 the same way? Probably. Will every disc reader detect and flag every C2 the same way? I am not sure.

I am not clear on what interpolation happens before transmission as spdif but I still find it unlikely for that result to be identical from multiple devices.

No I will not do this again using CLI. Sorry.

Listen to what mansr is telling you. In years past I've run a usb to spdif converter testing for errors in the USB. Did it for 12 hours several times. Never found one error. USB will likely have more errors than spdif. Plus I'm not finding your reason for this. As mansr said, errors will not cause variables in sound quality. If some device has lots of errors it will glitch enough you'll quit using it.

So if you posit otherwise it's on you to show this. Some of us are trying nicely to tell you that you will be wasting your time.

 

[Prana Ferox]

I just don't get it. We routinely transmit terabytes of data error free across the world, under the ocean, and through space. We stream HD movies at extremely high bit rates error free through shared networks.

These are packetized and have error correction.

But yes, I agree with you, OP is wildly over-estimating the flakiness of local digital transmission. If this was an actual issue computers would constantly be corrupting and crashing. Think of it this way, the absolute flakiest component in most computers (which you might not even have) is the spinning-rust hard drive, and even extremely pessimistic manufacturer MTBF estimates assume one bit failure out of every 10^15 or so read.

I continue to think this thread comes from a bad misunderstanding of that dbPowerAmp database and the difference between 48x-speed disc ripping and normal CD reading.

 

[Blumlein 88]

Looking at your revised post #1, the 2nd method using analog capture will show differences. I can even tell you most results vs the original file will be poor. 30-50 db nulls mostly. I can further tell you the reason will be phase differences in the top half of the bandwidth caused by various filtering methods. Plus some from frequency response differences. Using a single % correct number will hide the details of these differences. Deltawave can correct for FR and phase if you ask it to do so. When it does the nulls drop into the 90 db or better range. Deep nulls are much more easily ruined by tiny things most people don't fully appreciate. That is also why getting a deep null of 90 db or more is impressive and convincing.

Here is a thread testing loopbacks of ADCs and DAC's that has been running since 2011 over at gearspace.

Evaluating AD/DA loops by means of Audio Diffmaker - Gearspace.com

Originally Posted by didier.brest here's the result with soft limiting Thanks, Didier!

gearspace.com

Here is a link to the latest results which have dozens of devices tested over the years. BTW, it was the unreliable functioning of Diffmaker which inspired Paul to write Deltawave.

Gearspace.com - View Single Post - Evaluating AD/DA loops by means of Audio Diffmaker

Post 16071097 -Forum for professional and amateur recording engineers to share techniques and advice.

gearspace.com

There is a place you can download all the uploaded files to that Gearspace page. Paul did that and ran all of them in Deltawave. Both the way they run them showing results from the Gearspace page and his results. He also ran them correcting for phase and FR. He has a list of all that at this link.

Gearspace.com AD/DA data analysis using DeltaWave | DeltaWave documentation

DeltaWave Analysis of Gearspace AD/DA results

deltaw.org

 

[73hadd]

S/PDIF transmission and reception is pretty trivial, making errors exceedingly rare. Even if there was an error once an hour, say, that would not affect the overall "sound quality." You'd get a tick whenever an error did occur, and chances are good you wouldn't even notice.


If a disc is so bad as to produce any significant number of undetected errors, it will no longer sound like music at all. It will emphatically NOT cause any of the usually described effects like lacking/excessive bass or treble, haze, glare, prat, etc. That is just not possible.

This test is not for audibility.

 

[73hadd]

I just don't get it. We routinely transmit terabytes of data error free across the world, under the ocean, and through space. We stream HD movies at extremely high bit rates error free through shared networks. But somehow folks think pulling simple music data off of a CD a foot away through a dedicated wire is fraught with errors.

Stateful data transmission with error correction is different.

 

[73hadd]

I will be happy with the conclusion found after reviewing data. It could be zero difference, one percent, or maybe closer to the CD ROM variance of 9%.

Apologies to anyone reading this and found it a waste of time.

 

[73hadd]

No I will not do this again using CLI. Sorry.

Listen to what mansr is telling you. In years past I've run a usb to spdif converter testing for errors in the USB. Did it for 12 hours several times. Never found one error. USB will likely have more errors than spdif. Plus I'm not finding your reason for this. As mansr said, errors will not cause variables in sound quality. If some device has lots of errors it will glitch enough you'll quit using it.

So if you posit otherwise it's on you to show this. Some of us are trying nicely to tell you that you will be wasting your time.

If you saved the files I think you just have to run the commands.

 

[617]

 

[mansr]

One of those slogans is not like the others.

 

[Blumlein 88]

One of those slogans is not like the others.

The one in the lower left corner? The laser sound in French.

 

[tonycollinet]

I will be happy with the conclusion found after reviewing data. It could be zero difference, one percent, or maybe closer to the CD ROM variance of 9%.

Apologies to anyone reading this and found it a waste of time.

Where are you getting CD rom variance of 9% from?