First of all, a couple of corrections to minor inaccuracies in your post. First, both zero's and one's are represented within transitions (there are always transitions around the actual data). So a solid run of zero's (or one's) are not represented by a DC voltage. Jitter is caused by an inaccuracy in the generating clock, in the transport, among other things. If it is tied in any way to the amount of electricity and/or heat, etc. It can also be caused by a sufficiently corrupt digital signal (reflections, etc., cause inability to detect transitions accurately). The only way to fix this is to have extremely accurate and insensitive clock chips in both transport and DAC, have some sort of word clock control over data "collection" on the transport (not getting enough, faster; too much, slow down; etc.). I know of only several ways of doing this: the Wadia system; both DAC and transport have word-clock on them, and master them to one that is extremely accurate, either internally to one or the other, or externally; or "hack" a connection from the DAC back to the transport. I found a web page on this last one once, have it bookmarked at work, will try to remember to look it up on Monday.
CD Transport to DAC Timing/Jitter
I am not clear on the source of excessive jitter that can occur between a CD transport and DAC. As I understand it the transport internal oscillator acts as the master system clock. The DAC in turn runs on recovered clock derived from the incoming transport signal. If this is true then the only thing that should cause timing jitter is long strings of consecutive zeros which would adversely affect the DAC clock recovery circuitry. I would think that this would be prevented by scrambling the data or by some zero substitution algorithm similar to what is used in the telecommunications world. Any ideas/comments on this issue?