If you have a "kick booty" DAC, does the transport


really matter as it is just a "reader" correct. Am I over simplifying it. When you plug your player into an outboard DAC don't it bypass the internal dac and stuff and shoot it to the outboard? Isn't the laser just reading the 1010101 on the disc and shooting the data to the DAC? If this is true can't a Joe just get a whatever player with coax/i.r./esbu out and just invest in a high horsepower DAC?
mtandrews
Svhoang,

It's actually pretty complicated. At every stage in both the transport and the DAC, digital information (conceptually consisting of 1's and 0's) is superimposed (or "rides") on a modulated analog carrier signal. There is no such thing as a "pure" digital signal in electronics - a digital signal is really just an information-processing abstraction.

The process of digital to analog conversion you describe is better thought of as taking a very high frequency modulated analog signal coming in from the transport, extracting the digital information from the analog carrier, processing this information through the necessary filters and producing a reconstruction of the original sound pressure waves (the "analog").

The point is, at every stage in the process, from the pits on the CD throught the transport, the cabling, and all the circuitry out to the output jacks on the DAC, the signals are analog. The digital information rides along on these analog signals as a passenger. Anything that can corrupt an analog signal can affect the digital information it carries.

The idea that there are somehow 0's and 1's flowing around inside a "digital" component is unfortunately a massive oversimplification, one that leads to notions like "bits are bits" and "the quality of the transport doesn't matter because it's not analog".

It's all analog. Everything matters.
Svhoang,
The data is digital from the Transport. You can view that data on a Scope and look at it at a analog standpiont.
Is the complexity due to the nature of how Transports, output stages and cabling is currently implemented for the purposes of digital audio? The notion of bits-are-bits comes, for me, from the notion that in any other application of computers, I take for granted the transfer of a set of binary data from one circuit board to another in bit-perfect fashion. All sorts of things I do every day would not work, or not work nearly as well, if this wasn't the case.

So, my point has always been, if the current transport-output stage-cable is so flawed as to introduce such widely audible differences, why wouldn't we first engineer a basic transport to accomplish in audio what we take for granted elsewhere?

I'm not an EE, so I could easily just be not understanding something. But I collect, route and deliver digital information globally as a profession, and it would just seem that audible mishandling of the data in a three-foot digital audio connection should either 1) be able to leverage the technologies so cheap and prevalent in other digital data applications, or 2) I should be spending huge portions of my day dealing with errors in my data transfer applications, which I don't.
After a lot of tests and money thrown away I can tell you..
the most important part of a digital playback is the Transport...the most expensive also.
Yes it seems logical that a computer HD would read better, try it out and try a "real" good dedicated transport in your system, you wont believe the difference!
Forget about DVD payers with cheap plastic transports and switching power supplies...aargh,

Thank you Gliderguider for that nice explanation, that clears up a lot of things...
Kthomas,

Much (most?) of the problem is that the SPDIF interface doesn't carry timing information, certainly not bit-level timing info. The time base has to be recovered from the signal, and that is inherently problematic on a high frequency link. This is why digital cable quality is so much more important that you'd think it ought to be. It's also why quasi-proprietary interfaces like IIS were developed, and why there is curently so much interest in USB - they pass explicit timing information as well as the data, and so should minimize this particular problem.