Develop a metric for CD Transport and CD Player performance

[RayDunzl]

The exact readout rate from the disc is unimportant since every CD player/transport necessarily buffers the data and sends to the DAC/output under the control of a crystal oscillator. The rotation of the disc is controlled such that the average data rate into the decoding stage is within the bounds set by the buffer.

I opened my disc player 25 years ago.

The CD spun at obviously incremental speeds, Slower near the edge, faster near the center.

I put my thumb on the disc to slow and even stop it, and it became obvious the output was not directly related to the speed of the spin.

There was no change in the output (audible) until the READ buffer ran out of bits to send to the obviously separately clocked OUT buffer, which, as I remember, took a couple of seconds on complete disc stoppage on that device. Momentary thumb slowing had no audible effect.

 

[GXAlan]

“Error correction was superb, the PS1 suffering no glitches in its output until the gaps in the data spiral on the Pierre Verany test CD reached 1.5mm in length.”

“Overall, this is a pretty poor set of measurements. I wonder, therefore, if the "magic" of the PlayStation 1's sound lies not in its technical excellence but in the fact that it smears over and disguises much of what is wrong with typical CD sound quality, to which it adds a touch of low-level compression from the linearity error. Certainly, when I recently listened to a PS1 as the source in a system comprising an inexpensive Cayin tube integrated amplifier driving Definitive Technology Mythos ST speakers, it sounded relaxed and informative in a manner I would not have expected from this measured performance.” — @John Atkinson

Sony PlayStation 1 CD player

My home, which overlooks a dairy farm, is easy to see from a mile away, invisible from the end of its own driveway. Elevation: 1345'. Population: 3.

www.stereophile.com

Playstation 1 as CD transport (SPDIF output)

I have some playstation-1's, some modded some stock. During the mods I managed to zapped the audio section of one board..... Maybe it can still work as a transport, I thought, all I have to do is pipe out the signal and use it to drive an external dac. It turned out the AKM chip's input signal...

www.diyaudio.com

 

[Mart68]

I want a nice desktop sized CD player that can sit in a little stack with my Topping DAC and amp. I also don't want to pay $300 for it.

Stello did a desk top size transport with matching DAC, you'd have to buy used though as pretty sure they stopped making them.

 

[antcollinet]

Then I honestly don't understand why people spend thousands of dollars on CD transports. Any $20 cdrom drive can rip the CD bit perfect.
FYI: I still buy CDs from time to time, but rip them and play the flac files.

Exactly. There is no audio quality benefit to anything other than the cheapest CD mech. You may get better longevity by paying a little more, but not into the multi hundreds. As long as the device can read the data error free (and even my £20 DVD drive for my computer can do that) then there are no sound quality implications.

 

[73hadd]

Exactly. There is no audio quality benefit to anything other than the cheapest CD mech. You may get better longevity by paying a little more, but not into the multi hundreds. As long as the device can read the data error free (and even my £20 DVD drive for my computer can do that) then there are no sound quality implications.

Inaudible? probably.

"error free" and "bit perfect" definitely not. This is audio and not files.

Evidence is referenced in the first post: https://forum.dbpoweramp.com/showthread.php?43786-CD-Drive-Accuracy-2019

I was hoping that someone would have actually run the test by now. I may be able to do so myself after I obtain an SPDIF-Computer interface, something like a Motu perhaps.

There WILL be variance between devices under test.

 

[MC_RME]

I am not sure everyone here understood that this 'test' compares ripping to playing. These are two different ways to operate, and ripping always had its issues (an issue of the respective CD 'transport'), while playing on a real CD player via SPDIF should be 100% accurate unless you have defects in the medium itself.

 

[73hadd]

I think I have incorrectly explained the test and also the goal. Thanks @MC_RME for pointing it out.

The intent was not to compare ripping to playing. The intent was to compare spdif output from one device to spdif from another. Seeing the output as a % from DeltaWave added the required simplicity. I wanted to gather data for evaluating CD Transports.

It has been said that all spdif output is the same, so just use a dvd player or anything with an spdif output and it will be equal, due to cd error correction etc.

Here is an example test scenario:

1. Test file "ref.wav" ripped using a device or method so that the .wav is considered accurate compared to the data on the original optical disk.
2. Insert the original optical disk into various CD or DVD players or dedicated CD transports, output SPDIF to computer for conversion to a new .wav, one for each device.
3. Use DeltaWave to compare each device output .wav to ref.wav in % match results format.

Example FAKE output:

Sony CD player model xxxxx -> output Sony.wav -> compared to ref.wav -> 98% match
Pioneer DVD player xxxxxx -> output Pio.wav -> compared to ref.wav -> 97% match
JVC CD player model xxxxx -> output JVC.wav -> compared to ref.wav -> 99% match

I expect there to be accuracy variations, if nothing else due to varied SPDIF implementation. With DAC technology the differences may not be audible.

The goal will be to assign a metric for decision making. Does the cheapest DVD player output the same SPDIF accuracy as a dedicated CD transport?

(edited "Example fake output:" to "Example FAKE output:"

 

[Blumlein 88]

I think I have incorrectly explained the test and also the goal. Thanks @MC_RME for pointing it out.

The intent was not to compare ripping to playing. The intent was to compare spdif output from one device to spdif from another. Seeing the output as a % from DeltaWave added the required simplicity. I wanted to gather data for evaluating CD Transports.

It has been said that all spdif output is the same, so just use a dvd player or anything with an spdif output and it will be equal, due to cd error correction etc.

Here is an example test scenario:

1. Test file "ref.wav" ripped using a device or method so that the .wav is considered accurate compared to the data on the original optical disk.
2. Insert the original optical disk into various CD or DVD players or dedicated CD transports, output SPDIF to computer for conversion to a new .wav, one for each device.
3. Use DeltaWave to compare each device output .wav to ref.wav in % match results format.

Example fake output:

Sony CD player model xxxxx -> output Sony.wav -> compared to ref.wav -> 98% match
Pioneer DVD player xxxxxx -> output Pio.wav -> compared to ref.wav -> 97% match
JVC CD player model xxxxx -> output JVC.wav -> compared to ref.wav -> 99% match

I expect there to be accuracy variations, if nothing else due to varied SPDIF implementation. With DAC technology the differences may not be audible.

The goal will be to assign a metric for decision making. Does the cheapest DVD player output the same SPDIF accuracy as a dedicated CD transport?

SPDIF output should be identical 100 % unless there is a problem. I've checked Panasonic Bluray players, Pioneer DVD and Philips DVD (olds ones). Pioneer universal player, and a couple of expensive CD players. SPIDF out either optical or coax to the same input on a recording interface. 100% perfect on all I've checked. Are you using digital to digital comparisons?

 

[MC_RME]

There are no differences in 'SPDIF implementation' that would alter the audio bits. Some sophisticated players try to extend the 16 bit of CD by dithering, but I am not sure such things are found on the SPDIF output then (should be easy to check on a bitscope meter) - maybe only at the analog output. Your three examples are either rare exceptions or a fault in the method (ripped file not correct, comparison not working as it should.....).

 

[73hadd]

SPDIF output should be identical 100 % unless there is a problem. I've checked Panasonic Bluray players, Pioneer DVD and Philips DVD (olds ones). Pioneer universal player, and a couple of expensive CD players. SPIDF out either optical or coax to the same input on a recording interface. 100% perfect on all I've checked. Are you using digital to digital comparisons?

Thank you. Can you replicate your testing using the method above and publish the data?

 

[73hadd]

There are no differences in 'SPDIF implementation' that would alter the audio bits. Some sophisticated players try to extend the 16 bit of CD by dithering, but I am not sure such things are found on the SPDIF output then (should be easy to check on a bitscope meter) - maybe only at the analog output. Your three examples are either rare exceptions or a fault in the method (ripped file not correct, comparison not working as it should.....).

The test is intended to find out whether or not the audio bits are different.

 

[Tangband]

SPDIF output should be identical 100 % unless there is a problem. I've checked Panasonic Bluray players, Pioneer DVD and Philips DVD (olds ones). Pioneer universal player, and a couple of expensive CD players. SPIDF out either optical or coax to the same input on a recording interface. 100% perfect on all I've checked. Are you using digital to digital comparisons?

Maybe dedicated cd transports are more alike and dont mess up the sound like some new streamer transport sometimes does ?
So I think theres a need to measure and test also digital gear. One such example are the streamer Yamaha wxc50 which in pre amp mode does SRC to 48 KHz on every material and in this case its unfortunately audible, also when you use the digital out from the Yamaha into a dac. My Mac computer with a good DDC is much better sounding feeding the digital input on my Genelecs, and its only the digital signal that suppose to be ”perfect”, regardless of transport….

As you know, in modern digital streaming a lot can go wrong - wrong settings If using Windows as a player, USB package noice at 8 kHz, jitter, sample rate conversion done in a less good way, bit truncation and digital volume controls thats not well done, dsp thats not transparent . Its like modern streamers in the digital domain sometimes not turned out to be any better , -an older cd transport is often superior putting out 16 bit 44,1 kHz without tricks.

Amirm has tested more than 10 digital streaming products, including sonos ( bit truncation ) , chromecast ( terrible amount of jitter ) and bluesound ( broken toslink input ) that behaved very strange in some ways in the digital domain.

 

[Blumlein 88]

Thank you. Can you replicate your testing using the method above and publish the data?

That is the method I used. Deltawave wasn't around, but as there are no timing issues in wav files whether ripped or taken from an SPDIF output, I lined them up and flipped one versus the other. Complete zero signal every time indicating a perfect match. I had ripped the files three times to make sure the ripped files had no error. Then used the ripped files vs the file as it was recorded coming out of the SPDIF jack. No trip thru the analog world. No errors, no differences. I did this years ago, and satisfied myself digital errors weren't a problem for CD play. Later did the same for early devices using wav files over USB.

I cannot say about streamers, but if they get the correct file I don't see why they'd be any different. Any error from a CD transport that cannot be interpolated will cause a glitch in playback. So there is nothing to developing a metric. Jitter can happen real time, and will vary with the source player and how well the receiving DAC rejects jitter. Even so, jitter has to be extremely high to be mildly audible, and nearly no devices have that much jitter with very few exceptions.

Now if you are sourcing from Windows and not using ASIO then all bets are off. Curiosity is good, but this is a solved problem.

 

[Blumlein 88]

The test is intended to find out whether or not the audio bits are different.

The answer is they aren't. I've rarely seen ripped files have errors. It is possible. If you only ripped your file once you might want to do it a few times to make sure you are getting a correctly ripped file. Once you have that I don't think it at all likely you'll find bit differences vs an SPDIF capture. Maybe you can post files that aren't matching and let us look at it in Deltawave to see why. It should not be happening.

 

[73hadd]

Your comment is an anecdote until the data is published. Can you re-do your test and publish the DeltaWave %?

The advent of DeltaWave is the key to making this interesting.

I have been told that CD ROM uses the same error correction as CD for audio? If all ripped .wav output was equal there would not be a 9% difference in accuracy between ROM drives. It's possible the 9% difference can be attributed to other issues in the ripping chain but I expect to see the 9% variance or greater in SPDIF outputs.

 

[mansr]

I have been told that CD ROM uses the same error correction as CD for audio?

It has to. There is no other way to recover the data, even when there are no errors.

 

[Blumlein 88]

Your comment is an anecdote until the data is published. Can you re-do your test and publish the DeltaWave %?

The advent of DeltaWave is the key to making this interesting.

I have been told that CD ROM uses the same error correction as CD for audio? If all ripped .wav output was equal there would not be a 9% difference in accuracy between ROM drives. It's possible the 9% difference can be attributed to other issues in the ripping chain but I expect to see the 9% variance or greater in SPDIF outputs.

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.

 

[73hadd]

My apologies, my first post isn't very clear, I am going to clean it up.

The goal is to record performance data on spdif outputs, similar to what is available on the dbpoweramp forum for ripping drives.

I understand you are not interested in participating. I also believe it is unfair to consider it solved without published data.

 

[Tangband]

The test is intended to find out whether or not the audio bits are different.

That is the method I used. Deltawave wasn't around, but as there are no timing issues in wav files whether ripped or taken from an SPDIF output, I lined them up and flipped one versus the other. Complete zero signal every time indicating a perfect match. I had ripped the files three times to make sure the ripped files had no error. Then used the ripped files vs the file as it was recorded coming out of the SPDIF jack. No trip thru the analog world. No errors, no differences. I did this years ago, and satisfied myself digital errors weren't a problem for CD play. Later did the same for early devices using wav files over USB.

I cannot say about streamers, but if they get the correct file I don't see why they'd be any different. Any error from a CD transport that cannot be interpolated will cause a glitch in playback. So there is nothing to developing a metric. Jitter can happen real time, and will vary with the source player and how well the receiving DAC rejects jitter. Even so, jitter has to be extremely high to be mildly audible, and nearly no devices have that much jitter with very few exceptions.

Now if you are sourcing from Windows and not using ASIO then all bets are off. Curiosity is good, but this is a solved problem.

Agree , Windows without using ASIO i terrible.

By the way - here is two examples of two popular streamers :

Doesnt look good , dont you agree ?
This are horror examples what can go wrong in the digital domain - but those streamers are also two of the most commonly used by ordinary hifienthusiasts.

 

[Blumlein 88]

Agree , Windows without using ASIO i terrible.
View attachment 228579

By the way - here is two examples of two popular streamers :
View attachment 228577
View attachment 228578

Doesnt look good , dont you agree ?
This are horror examples what can go wrong in the digital domain - but those streamers are also two of the most commonly used by ordinary hifienthusiasts.

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