Here we go ....
78 responses Add your response
It should not. Bits are bits. However, noise from servo motors (reading the disk) can induce modulation distortion back through the power supply and create a jittery input to the internal DAC. There is also logic induced modulation that may affect the internal DAC. And then how the internal DAC does conversion. So in practice differences can be substantial listening to the analog out of different transports. If you are taking a digital feed from the transport then it is the jitter that is inherent in that digital signal which might affect whatever DAC is downstream. If you get a DAC with complete jitter rejection (below audibility) and then all transports played to that DAC will sound the same because as you said yourself, apart from clock timing (jitter), it is all 1s and 0s. |
Actually it’s not 1s and 0s. It’s not 1s and 0s until the data gets to the A to D converter. The laser is simply reading ON and OFF depending on whether the laser beam is hitting a pit or land. Actually the laser reading process is an analog process, not digital. Also, the length of the lands, which are variable, helps determine what the actually digital data is. There are several problems that make the reading of the “data” on the CD imperfect. One is wobbling of the CD due to out of round condition, various types of vibration and/or not being absolutely level during play. Another is background scattered laser light that makes its way into the photodetector. The photodetector is kinda stupid and can’t tell the difference. Yes, I know what you’re thinking, “But the Reed Solomon Error program is supposed to take care of all that.” |
The operative word here is JITTER. Jitter is the variability in the timing of the bits coming out the end of the S/PDIF cable from the CD transport. At 44.1kHz sample-rate, the bits frequency is around 2.8MHz. ANY variability in the timing of these bits, one bit to the next bit, will cause the D/A conversion to be distorted. The output voltage will not be at the correct value at each point in time, creating analog distortion. Jitter in a typical CD transport is caused by: 1) inaccurate reads of the pits because of imperfect disk and vibration in the disk while spinning - this can be improved by re-writing on a good CDROM disk and by applying treatments to the disk. Some older disk players used a platter like a turntable to eliminate the vibration. 2) jitter in the internal Master Clock oscillator - selected by the designer 3) power subsystem deficiencies that power the oscillator and associated circuits due to the design 4) imperfect S/PDIF output driver due to the design 5) imperfect S/PDIF cable - get the best one you can afford When one refers to a CD player as a "Transport", it means they are using the digital output over a S/PDIF cable from the device, in conjunction with an external DAC or D/A converter. Here is a typical jitter plot from a transport: http://www.audiocircle.com/index.php?topic=154408.0 Here is how the S/PDIF cable adds jitter to the equation: http://www.audiocircle.com/index.php?topic=154425.0 You can see from these measurements what a Synchro-Mesh reclocker can do to reduce jitter from ANY transport or server. None of the disk treatments are needed if a Synchro-Mesh is used, and it provides galvanic isolation, breaking ground loops. Also, see how good a $275 S/PDIF cable can be. Steve N. Empirical Audio |
Background scattered light has not been addressed by any manufacturers, at least not to any great extent. So there’s that. And magnetism and static electricity are still problems, there’s that, too. I suspect maybe “jitter” isn’t the do-all end-all for various problems involved with CD playback. There’s also the nagging question of why they can’t make the clear layer in CDs a little more transparent. 😬 |
Background scattered light has not been addressed by any manufacturers, at least not to any great extent. So there’s that. And magnetism and static electricity are still problems, there’s that, too. I suspect maybe “jitter” isn’t the do-all end-all for various problems involved with CD playback. There’s also the nagging question of why they can’t make the clear layer in CDs a little more transparent. All of these problems are addressed by two current solutions: 1) reclock the S/PDIF output from the transport 2) design a transport using a CDROM and a computer motherboard and memory. Buffer in memory and spool it out over S/PDIF And JITTER is the THE ONLY issue with the S/PDIF output on a transport, period! I am a EE that has designed digital systems for 42 years and have designed dozens of digital audio interfaces including S/PDIF, AES/EBU, I2S, differential I2S, 6 generations of USB, Ethernet. I know what I'm talking about. There are obviously other issues that come up if you use the D/A inside the player and the analog outputs. Steve N. Empirical Audio |
Frankly if you dont spend $20K on a transport, you will not get the kind of low jitter that the Synchro-Mesh can provide. Even then, I'm not convinced. dCS Vivaldi, dCS Scarlatti, MBL do not publish jitter numbers and neither does PSAudio for their memory player. The dCS has word-clock input, so it can synchronize to the Master Clock in their DAC's. So it's the DAC clock that needs to be low jitter. Simaudio 260D says their "intrinsic jitter" is 1 psec. I think this means their oscillator spec. This is not unusual for a good oscillator, however by the time the signal goes out the S/PDIF BNC or RCA, it will usually have 100's of psec of jitter. My clocks have 1psec of intrinsic jitter, but that's not what I advertise. I advertise the jitter at the end of a 1.5m cable with a 75 ohm termination. Steve N. Empirical Audio |
@audioengr If I understand you correctly, you are saying that putting the Synchro-Mesh between any transport and DAC, will essentially turn the SQ of the transport (not the DAC) into something roughly equivalent to dCS, MBL, Esoteric, MBL. Is that accurate? (I'm assuming here you are talking about SQ only and not build quality.) I'm asking because I'm in the market for a transport. |
audioengr Geoffkait: “Background scattered light has not been addressed by any manufacturers, at least not to any great extent. So there’s that. And magnetism and static electricity are still problems, there’s that, too. I suspect maybe “jitter” isn’t the do-all end-all for various problems involved with CD playback. There’s also the nagging question of why they can’t make the clear layer in CDs a little more transparent.” All of these problems are addressed by two current solutions: 1) reclock the S/PDIF output from the transport 2) design a transport using a CDROM and a computer motherboard and memory. Buffer in memory and spool it out over S/PDIF And JITTER is the THE ONLY issue with the S/PDIF output on a transport, period! I am a EE that has designed digital systems for 42 years and have designed dozens of digital audio interfaces including S/PDIF, AES/EBU, I2S, differential I2S, 6 generations of USB, Ethernet. I know what I'm talking about. There are obviously other issues that come up if you use the D/A inside the player and the analog outputs. Steve N. Empirical Audio >>>>Obviously, I’m talking about CD players and transports. Furthermore the scattered laser light issue is not (rpt not) a jitter (timing) issue. So jitter is not the only issue (for the majority of audiophiles). |
For a lot of insight into errors inherent in reading CD optical disks, try ripping a CD with DBpoweramp and learn. It will give you actual metrics using reference database web service that gets updated and enhanced over time as new user rips occur. It provides metrics on how accurate the rip is compared to the current reference maintained in the database. No need to guess. More popular CDs can have up to 200 rips for reference available during ripping in the database. Very cool! Good quality CDs tend to rip fast and clean using my laptop’s disk reader. I’d estimate 60-70% of the time. More errors encountered and longer ripping time needed for rereads maybe 20-25% of the time with visually good quality disks. . Damaged CDs with visible scratches or flaws will almost always require multiple rereads to assure acuracy and take longer. If you turn the accurate rip feature off, rips happen faster and you will be told how many errors occur per track. The good news is that in most cases you will have to listen very hard on a really good system to hear most errors that do result with accurate rip off. I know of one CD out of several thousand I have ripped where the errors in the form of dropouts are clearly heard every time streamed. Is there any CD transport that can do all that in real time as required? Also provide quality metrics as reading? I do not know of one. Most people would rather not know and never will need to I suppose. That’s why I never play CDs anymore. I rip them to my library correctly once then stream from there. |
Is there any CD transport that can do all that in real time as required? Actually, the PSAudio Memory Player transport might do error correction because it is essentially a computer with CDROM drive. This will not make a big difference in sound quality however, because the difference between corrected reads by this transport and uncorrected reads by a typical non-computer transport is almost zero. In other words, errors are not common and even if they do occur, you will not hear it. It is the jitter that is prevalent and will make one transport sound bad and another one good. Steve N. Empirical Audio |
audioengr, Based on the data I have seen ripping thousands of CDs and having DBPoweramp detect and show the errors, I would concur that when errors occur you will hardly ever if ever actually hear them. However, they may not be as uncommon as some might think. Also I agree, in reality and for all practical purposes, jitter is a much bigger concern and has stood in the way of good sound with CDs for many for many years. Much better but certainly not extinct these day, at least with cheaper low quality transports. Ripping and streaming is much more reliable. Even good quality and modest cost streamer/DAC combos can deliver very good, detailed, non fatiguing sound. |
I would be quite interested in hearing from anyone who uses tweaks when ripping from a CD. You know, colored CDs, colored tray, demagnetization, edge beveling, ionizers, Silver Rainbow Foil, insuring the CD is absolutely level, things of that nature. Anybody? Can you tell I don’t really buy into the whole Read until Perfect thing? Anymore than I buy into the Reed Solomon Error Code thing? Is it just me? The word perfect has been so overused. Ever since the very beginning. |
The jitter effect of all of these "tweaks" can be measured. Most of them make audible changes, but not that significant. The best CD disk tweak is to apply a rubbery coating to the top of the CD to prevent vibration while spinning. This is where the majority of the jitter comes from. The best transport tweak is to use a reclocker. Steve N. Empirical Audio |
How abour MSB's Data CD? They seems to take care of both the "read until right" (CDROM drive and memory buffer) and ”jitter/timing" (proprietary I2S connection by using ethernet network connection) problems? MSB's "Pro I2S interface" is a good implementation, along with being a "computer" CD transport. This locates the Master Clock in the DAC rather than the transport. The Transport has a PLL that synchronizes to the DAC Master Clock. This is the optimum way to do the CD transport protocol. dCS does a similar method, but not I2S. I2S is really not necessary when using this scheme, but it simplifies the DAC to use it. I also put I2S inputs and outputs on my products, as does PSAudio, but they don't do the Master Clock in the DAC like MSB and dCS, with a clock cable going from DAC back to the Transport. Steve N. Empirical Audio |
Jitter is an interface issue and will always be affected by the data stream no matter what cables you use. The detection of the clock timing embedded in the digital audio is always jitter prone - no matter what device is upstream. The ONLY thorough solution is to accept interface jitter as a fact of life and use a DAC that rejects it. No matter how much jitter is reduced upstream there is still going to be jitter. Select a DAC that rejects interface jitter and then all that you will hear is the inherent jitter in its own internal asynchronous clock driving the DAC. |
Have you ever directly compared the Canare LV-77s and Belden 8281F coaxial cables for jitter? No, but if you send these, I will be glad to make measurements and post it. Here are the ones I had on-hand and compared: http://www.audiocircle.com/index.php?topic=154425.0 Steve N. Empirical Audio |
Select a DAC that rejects interface jitter and then all that you will hear is the inherent jitter in its own internal asynchronous clock driving the DAC. Absolutely true, and this is precisely the problem. You are trapped with a substandard Master Clock implementation that you cannot improve upon. Steve N. Empirical Audio |
No interface problem, but you are stuck with this jitter that you can do nothing about: http://www.audiocircle.com/index.php?topic=154408.msg1650944#msg1650944 That is unless you open it up and mod it, and even then, the results will never be as good a an external reclocker. Steve N. Empirical Audio |
Perfect, ship them to: http://www.empiricalaudio.com/about-empirical-audio/contact Thanks, Steve N. Empirical Audio |
Found this on PSA forums if anyone is interested...Reply about the Synchro-Mesh via Ted Smith. https://forum.psaudio.com/t/titan-audio-helen-that-can-be-used-wtih-dmp-and-perhaps-dsd/5060/9 ASRC (asynchronous sample rate conversion) is the mechanism it uses to lower jitter. I’m not a fan of that - but some like the change in the sound. My problem with ASRC is that it resamples the input with a more accurate clock - but tho the output clock may indeed have less jitter than the input, to do that it changes the data (it calculates the values needed on the output to represent the input signal including it’s jitter) - the input jitter is now encoded in the data and can never be removed downstream. Beside any philosophical issues, this breaks bit perfect playback and hence will break DSD playback, etc. |
ASRC (asynchronous sample rate conversion) is the mechanism it uses to lower jitter. I’m not a fan of that - but some like the change in the sound. My problem with ASRC is that it resamples the input with a more accurate clock - but tho the output clock may indeed have less jitter than the input, to do that it changes the data (it calculates the values needed on the output to represent the input signal including it’s jitter) - the input jitter is now encoded in the data and can never be removed downstream. Beside any philosophical issues, this breaks bit perfect playback.. Absolutely true. I also used to believe this was an issue. Then I discovered a really good chip and a good way to implement the circuit. The problem in the past was the chip implementations. Not a problem anymore. Telling the difference between a 44.1 native track and the same 44.1 track output from the Synchro-Mesh is almost impossible. This is a very good chip. This is the reason that my customers don't have any issue with the resampling, and the Synchro-Mesh is so popular. The latest version is much better than the previous version BTW, so older feedbacks are likely about a different product. Steve N. Empirical Audio |
In my experience, CD Transports can make a big difference in the sound. Having said that, less expensive transports use cheaper mechanisms, which tend to sound the same. You’ll need to spend more to get one with a really good mechanism. Also, you want a dedicated CD mechanism, not a universal one. I have a CEC TL-5, which uses their in-house belt drive system, rather than the standard direct drive. It has an analog-like ease and musical flow, that I really enjoy. I believe it is currently the least expensive way to get a CD Transport with a seriously good mechanism. The current US price is around $2800. Another option is one that uses the long discontinued Phillips CD Pro mechanism, but that will cost you quite a bit more. |
Steve N. well said. I have a PS Audio DirectStream DAC and transport, interconnected with an HDMI cable over their I2S interface. From what I understand, they reduce jitter (timing errors) with the separation of the bits from the timing on that interface. Long-story-short, when I replaced my prior transport with the DirectStream...WOW, nice upgrade! |
Actually, the separation of data, control and clocks in I2S bypasses the S/PDIF receiver and any upsampling that might be in the DAC, so the signal goes directly to the D/A without conditioning or synchronizing of clocks. I2S is the native interface for the D/A chip. This does not actually reduce jitter very much, except for this bypassing. The jitter of the source is what you get to hear, so the lower that jitter is, the better the sound quality. I like this approach because as new sources achieve lower jitter, the same DAC sounds better and better. My own Overdrive SX DAC is like this. If you think the PSAudio transport is good, you should hear my Ethernet Renderer, the Interchange, connected with HDMI I2S cable to your DAC. This will deliver signal with ~15psec of jitter. This can play files from any computer running Jriver or Minimserver. I hope you are using a very good silver I2S cable. This makes all the difference. FYI, I sell one of the best on the market. Steve N. Empirical Audio |
I promised to measure jitter for two cables for jc4659, a Belden and a Canare BNC cable. Here are the results: http://www.audiocircle.com/index.php?topic=154425.msg1669506#msg1669506 Steve N. Empirical Audio |
erj1953, I totally agree with you about the PS Audio Direct Stream player it is fantastic as a transport for the PS Direct Stream Dac. On the other hand, when I bought (new) the Synchro Mesh it degraded the sound in my system. I sent it back for a refund. And I must say that I was given quite a hard time getting my money back. Perhaps the owner has now seen the errors in his customer relations. ozzy |
ozzy - First, you purchased an older model Synchro-Mesh. Not all DACs respond well because some have internal resampling already. It is also critical to use a good output cable. Second, I always refund within 2 weeks if returned within 30 days. Did you return within 30 days? How long did it take to get the refund? Steve N. Empirical Audio |
