Okay, I'll admit my ignorance. Why should a CD (or any other digital format) transport make a difference? When I install a program on the computer from a CD or when I transfer large digital files via CD-R, there are almost never any errors (e.g., dropping every 11th bit). It would be intolerable if there were. Nevertheless, I have read many claims over the years about the superiority of this or that audiophile CD transport. In what sense could it possibly be superior if the most basic transport is capable of reading (clean, unscratched) discs accurately? Of course, I well appreciate the advantages of a superior digital-to-analog converter, but what warrants someone manufacturing a separate, megabuck transport? Is this just a sham, or am I missing something?
Something I've never understood...
- Thread starter CCH
- Start date
Help Support MartinLogan Audio Owners Forum:
sleepysurf
Well-known member
It's not so much the transport process, as much as the subsequent downstream processing via the DAC, clock, and ultimate quality of the analog output stage. That's why I've committed to a 100% digital front end. As long as I've ripped (or d/l) lossless streams, and able to "deliver" them "bit-perfect" to a capable DAC/preamp setup, with mimimal jitter, I should (theoretically, anyways) be able to play them back with pristine sound.
Yes, that much is clear, but why would the transport itself matter? For a while, at least, it seemed like everyone was offering separate transports. Why would that be of any use if the transport is delivering the right bits?
sleepysurf
Well-known member
I think the "audiophile argument" is that transports can vary in their ability to accurately get the "bits" off the physical media, due to vibration or laser issues, etc.
Gordon Gray
Well-known member
Check out the Esoteric site.
They have lots of info as to why this matters.
GG
They have lots of info as to why this matters.
GG
Okay, I read their descriptions and claims, but it still leaves me puzzled. I transfer gigabytes and gigabytes of data on an almost daily basis using hard drives, CDs and DVDs, and I almost never encounter an error. Can you imagine moving a 500 page file and discovering that every page contained corrupted data? No one would put up with that kind of inaccuracy. The implication of what they are saying is that inferior transports are introducing or allowing all sorts of data-read errors, but I cannot see that happening in my day-to-day experience. I am not by any means certain that I am right and will happily yield to anyone with a superior understanding of drive mechanics. Perhaps the way of asking my question is to inquire, not what is right about expensive transports, but what is wrong with inexpensive transports that otherwise seem quite capable of delivering data reliably?
amey01
Well-known member
Let's just say that the transport does matter. To understand fully, you need to understand a little bit about digital theory and as others have suggested - reading widely will help you understand. If PCM, word clocks and jitter mean little to you then you've no hope of understanding.
I have two things to add. First of all - understand that digital playback is real time - it is certainly not like a computer where bits can go back and forth until error correction says it is correct. When a transport is delivering a stream, it is "one-way" - if the bits are wrong the transport moves on - it can't stop the music right at the climax of Overture 1812 and re-read to make sure!
NOW......with this in mind, the issue that makes the biggest impact on digital sound is jitter - or digital timing errors. A digital clock should be operating at 44,100 hz. That is - delivering a digital word every 1/44,100 of a second. Not only that, but a correct digital word every 1/44100th of a second.
What if these get out of sync and one bit comes at 1/44050th of a second after the first, and the next comes in at 1/44200 seconds later? This has a major impact on the DAC and its ability to convert those bits to the sound you hear. Worse if the bit is actually wrong, although a certain amount of error correction is applied by the DAC.
Digital cables can also apply these timing errors by causing reflections in the signal. This is why a separate word clock connection to slave the DAC or the transport to the others' clock provides a major improvement. Suddenly, the DAC is no longer dependant on the actual music stream for its clock signal!
So as you can see - it is NOT about delivering the data correctly (which most transports can do very well - heck - even $2 computer ROM drives can do that reliably), but about delivering the correct data at the correct timing rate for "live" decoding and playback.
Hope this clears one (but a MAJOR one) of many aspects up for you. When it's all said and done though, if I had to cheap out on a DAC or on a transport, it would be the transport every time. The DAC (or more accurately - its analogue output stage) still has a greater impact on sound!
Last edited:
Thanks. I was thinking the answer might well have something to do with timing, but I was unsure, especially since data transfer rates have gotten so high, even on very inexpensive drives. I do a lot of video editing, and the amount of data moving through my computer system at any given moment vastly exceeds the demands of the normal CD player. Anyway, I am quite willing to accept that (1) real-time accuracy makes a tangible difference to audio quality, but also that (2) inexpensive drives have gotten more and more accurate (and fast) over the years. The only way I can think of to know how much an expensive transport would offer over a relatively inexpensive one would be to feed the output of both through the same DAC and compare them directly. I own a good CD player (Cambridge Audio Azur 840C), but not a separate transport. Still, it might be fair to assume that the Azur's transport is superior to that of an inexpensive CD drive built for a computer. One of these days, I'll have to run the latter through the Azur's DAC, run the Azur's digital output back through the DAC using an identical cable, and do a direct comparison. Not a perfect test, I realize, but it would be interesting to see if I could notice any difference. Anyway, thanks for the info. I am always interested in learning about this great hobby. It is easy for me to understand what the downstream processing adds to the mix, but I was a lot less clear about the transport itself. As they say, the proof is in the pudding. I'll run an experiment when I get the chance.
Last edited:
sleepysurf
Well-known member
Exactly! That's why I have invested in computer (actually NAS) streaming to my Squeezebox/Benchmark DAC. All I need to do is "fill the Squeezebox buffer" with all the bits in the proper order, and let the Benchmark handle the timing!
amey01
Well-known member
This - of course - is the only way!!
I too, use a Squeezebox. While hard-drive systems are at an advantage (because of the buffer), they still have the ability to deliver bits at the incorrect time intervals.
The Transporter on the other hand, does have a master clock connection. Again, while this doesn't eliminate jitter, it vastly reduces it - assuming you have a DAC that has a similar connection.
Last edited:
Isochronous vs Asynchronous data
This is not 100% a direct answer to your questions, but it does explain why transports might have an impact on sound quality (this was written in context of some debates about why DenonLink was a good thing vs just HDMI LPCM):
It seems there is a bit of confusion caused by the very different natures of two types of audio data streams sent from BluRay players to AVP’s.
I’ll try and give my attempt at explaining the differences and what the impacts are in the context of our Denon gear.
First, some terminology:
Isochronous – something that occurs on equal time intervals, as applied to audio, it means audio data packets, such as PCM samples from a CD occur one every 44,100/sec and contain 16 bits.
Asynchronous – something that occurs at varying intervals but with a defined sequence. An example is the FTP transfer of a ZIP file between two computers. The TCP-based transfer is an asynchronous operation. The timing of the arrival of the packets does not affect the integrity of the file.
In audio, most data was isochronous and timing was critical, thus why everyone is jittery about jitter (sorry couldn’t help myself
).
When a CD player output its PCM datastream over SPDIF, it had to rely on its own clock to send out the samples, this clock may or may not have been aligned with the receiving units D/A clocks, or gaps would be introduced, and the resulting slight timing variations would result in slightly different waveforms than intended by the original PCM encoding.
With the introduction of DolbyDigital, we began to see the arrival of ‘packetized’ and compressed (whether lossy or lossless doesn’t matter for now, so don’t get too hung up on that aspect) formats that combined multiple audio channels along with structured data about the packet contents (such as: is it 2.0, 3.0, 5.1, is the Dialog normalized or not, etc.). These structured packets could be transmitted asynchronously, as timing was not critical (although clearly, there is a maximum allowable time between packets or buffers run dry).
So while PCM is sensitive to mili and / or pico-second errors, a packetized stream can survive hundreds of milliseconds delay between packets.
The processor that decodes the packetized formats first buffers multiple packets in a FIFO buffer and then the processor unwraps the packets, processes the metadata and uncompresses the PCM data packets into another set of FIFO buffers. It then pulls data from the output FIFO buffers, synch’s them to the video (if part of a video dataset) and clocks them to the processors master PCM Digital clock and sends them on their way to the D/A converters.
So, for PCM sourced data, such as a multichannel PCM track on a BluRay disc, the isochronous nature of the data stream means timing of delivery is critical to accurate reproduction. And while most PCM survives the HDMI transmission just fine, there is opportunity for error and drift if clocks are not synched. Ergo, the introduction of DL4.
Prior to this, all the other audio formats (SACD,DVD-A,CD) were susceptible to jitter errors unless transported over synched transports such as DL3 or Meridian Digital Link.
For all packetized formats (Dolby TruHD, DTS-MA, etc.), they can be transmitted asynchronously with no loss in resulting accuracy. This is called ‘bitstreaming’ the codec from player to AVP.
We’ve been ‘bitstreaming’ DolbyDigital from our DVD players to our processors for a decade, and now with the new HD codecs on BluRay and new AVP’s like the AVP-A1, we can now bitstream these as well and obtain the benefits
Note that since the player sends the bsitreams to the AVP over HDMI, it is actually clocked pretty tightly, but it’s not clock synched (except in a DL4 player/AVP pairing). However, since its asynchronous data, it doesn’t matter to resulting audio waveform accuracy once decoded.
Hope this helps clear up the matter. Although maybe it got a bit too technical, I’ve been (rightly) accused of that before
This is not 100% a direct answer to your questions, but it does explain why transports might have an impact on sound quality (this was written in context of some debates about why DenonLink was a good thing vs just HDMI LPCM):
It seems there is a bit of confusion caused by the very different natures of two types of audio data streams sent from BluRay players to AVP’s.
I’ll try and give my attempt at explaining the differences and what the impacts are in the context of our Denon gear.
First, some terminology:
Isochronous – something that occurs on equal time intervals, as applied to audio, it means audio data packets, such as PCM samples from a CD occur one every 44,100/sec and contain 16 bits.
Asynchronous – something that occurs at varying intervals but with a defined sequence. An example is the FTP transfer of a ZIP file between two computers. The TCP-based transfer is an asynchronous operation. The timing of the arrival of the packets does not affect the integrity of the file.
In audio, most data was isochronous and timing was critical, thus why everyone is jittery about jitter (sorry couldn’t help myself
). When a CD player output its PCM datastream over SPDIF, it had to rely on its own clock to send out the samples, this clock may or may not have been aligned with the receiving units D/A clocks, or gaps would be introduced, and the resulting slight timing variations would result in slightly different waveforms than intended by the original PCM encoding.
With the introduction of DolbyDigital, we began to see the arrival of ‘packetized’ and compressed (whether lossy or lossless doesn’t matter for now, so don’t get too hung up on that aspect) formats that combined multiple audio channels along with structured data about the packet contents (such as: is it 2.0, 3.0, 5.1, is the Dialog normalized or not, etc.). These structured packets could be transmitted asynchronously, as timing was not critical (although clearly, there is a maximum allowable time between packets or buffers run dry).
So while PCM is sensitive to mili and / or pico-second errors, a packetized stream can survive hundreds of milliseconds delay between packets.
The processor that decodes the packetized formats first buffers multiple packets in a FIFO buffer and then the processor unwraps the packets, processes the metadata and uncompresses the PCM data packets into another set of FIFO buffers. It then pulls data from the output FIFO buffers, synch’s them to the video (if part of a video dataset) and clocks them to the processors master PCM Digital clock and sends them on their way to the D/A converters.
So, for PCM sourced data, such as a multichannel PCM track on a BluRay disc, the isochronous nature of the data stream means timing of delivery is critical to accurate reproduction. And while most PCM survives the HDMI transmission just fine, there is opportunity for error and drift if clocks are not synched. Ergo, the introduction of DL4.
Prior to this, all the other audio formats (SACD,DVD-A,CD) were susceptible to jitter errors unless transported over synched transports such as DL3 or Meridian Digital Link.
For all packetized formats (Dolby TruHD, DTS-MA, etc.), they can be transmitted asynchronously with no loss in resulting accuracy. This is called ‘bitstreaming’ the codec from player to AVP.
We’ve been ‘bitstreaming’ DolbyDigital from our DVD players to our processors for a decade, and now with the new HD codecs on BluRay and new AVP’s like the AVP-A1, we can now bitstream these as well and obtain the benefits
Note that since the player sends the bsitreams to the AVP over HDMI, it is actually clocked pretty tightly, but it’s not clock synched (except in a DL4 player/AVP pairing). However, since its asynchronous data, it doesn’t matter to resulting audio waveform accuracy once decoded.
Hope this helps clear up the matter. Although maybe it got a bit too technical, I’ve been (rightly) accused of that before
Last edited:
amey01
Well-known member
Gordon Gray
Well-known member
Hi CCH,
If you get the opportunity, skip the theory and let your ears tell you if a transport matters or does not.
I personally find the theoretical to be interesting but ultimately non determining.
My CDP does various iterations on the digits and has, I believe, a good quality transport. It also reads, stores, processes, and then plays back the digital info.
My sense is that it's a combination of accurate reading and a very good processing engine.
GG
PS: Yes Jonathon, you never cease to amaze me.
If you get the opportunity, skip the theory and let your ears tell you if a transport matters or does not.
I personally find the theoretical to be interesting but ultimately non determining.
My CDP does various iterations on the digits and has, I believe, a good quality transport. It also reads, stores, processes, and then plays back the digital info.
My sense is that it's a combination of accurate reading and a very good processing engine.
GG
PS: Yes Jonathon, you never cease to amaze me.
Last edited:
There are many factors that contribute to the sound of a digital device, and as in any chain, it's the weakest link that determines how good it will sound. Of course, an old software "GIGO" (garbage in, garbage out) principle applies quite nicely here.
So if we follow the signal path we have:
- transport - for optical devices, obviously very dependent on the capability to reflect the laser ray accurately. Anything preventing a perfect capture of reflected ray will cause trouble (vibration, dust particles, unclean or greasy surface, scars, .....), the drives that do it in real time (unlike computer CD/DVD-ROMs) will not retry but interpolate missing samples. In real time playback there is no time for re-reads. In this respect hard disk is a superior media to any removable disc/drive combination.
- clocks and jitter - an extremely important factor as stated previously. There are several methods to influence that - e.g. replacing a master clock - but there is obviously more to it (digital circuitry on the clock path).
- DACs - another story. Many theories and discussions on this thematics. So far for pure Red Book CD playback I'm totally convinced of monolithic R-2R DACs. YMMV.
- analog stage - quite obvious. Most of the devices out there have operational amplifiers on outputs, many of them really bad sounding ones.
- last but not least: the quality of power supplies within the device in all the above stated segments. Neglected very often, this is a decisive factor. I could tell stories about how the same clocks, analog and DAC circuitries sound differently on different power supplies.
- synergy of all the above - summing it all up and taking the right circuitry, power supplies and right components for each task.
So if we follow the signal path we have:
- transport - for optical devices, obviously very dependent on the capability to reflect the laser ray accurately. Anything preventing a perfect capture of reflected ray will cause trouble (vibration, dust particles, unclean or greasy surface, scars, .....), the drives that do it in real time (unlike computer CD/DVD-ROMs) will not retry but interpolate missing samples. In real time playback there is no time for re-reads. In this respect hard disk is a superior media to any removable disc/drive combination.
- clocks and jitter - an extremely important factor as stated previously. There are several methods to influence that - e.g. replacing a master clock - but there is obviously more to it (digital circuitry on the clock path).
- DACs - another story. Many theories and discussions on this thematics. So far for pure Red Book CD playback I'm totally convinced of monolithic R-2R DACs. YMMV.
- analog stage - quite obvious. Most of the devices out there have operational amplifiers on outputs, many of them really bad sounding ones.
- last but not least: the quality of power supplies within the device in all the above stated segments. Neglected very often, this is a decisive factor. I could tell stories about how the same clocks, analog and DAC circuitries sound differently on different power supplies.
- synergy of all the above - summing it all up and taking the right circuitry, power supplies and right components for each task.
Last edited:
Spike
Well-known member
Maybe this will help...
Found this link from AA and I thought it has lots of reference information which will help with answering the original question.
The big question of TRANSPORT
Spike
Found this link from AA and I thought it has lots of reference information which will help with answering the original question.
The big question of TRANSPORT
Spike
Satch
Well-known member
Great post but jeeze, now my head hurts!
I'm running the Oppo DV-980H through Benchmark DAC-1 usb and it sounds great, although a little cold and glassy compared to my vinyl rig. I was reading about a battery powered DAC by Red Wine Audio that uses NOS chips to get a more warm, analog sound. Anybody have any ideas on this?
Still haven't figured out how hook up the ReadyNAS NV+ to the SB III. Sorry Sleepysurf, I'm hopeless. Plug and play, NOT!
Satch
I'm running the Oppo DV-980H through Benchmark DAC-1 usb and it sounds great, although a little cold and glassy compared to my vinyl rig. I was reading about a battery powered DAC by Red Wine Audio that uses NOS chips to get a more warm, analog sound. Anybody have any ideas on this?
Still haven't figured out how hook up the ReadyNAS NV+ to the SB III. Sorry Sleepysurf, I'm hopeless. Plug and play, NOT!
Satch
