DACs with internal master clocks: less importance of transport?

Al M. · Feb 19, 2014

asiufy said:
Not a valid comparison. A PC can take 10 minutes to open that Excel file from the CD Rom, trying and re-trying until it's successful.
Playing a CD, in real-time, the player cannot do that, so it gives up after a while, and "fills in" for the data that couldn't be read.
This is why some ripping software is better than the others (on the same hardware), as they keep trying and trying, while most will just do a cursory pass, and "fill in" when not successful.
Also, that's why disc transports that are really "memory players" (like the MSB or the PS Audio) have the edge here, as they operate like a PC reading a CD Rom, with multiple tries until success, since they're not operating in real-time.

alexandre

The question is if bit errors really are an issue, even with a transport reading in real time.

Robert Harley says on this subject:

Much of the current speculation as to why this [that the music from server sounds better than from transport] should be the case focuses on the fact that the Exact Audio importing software used in Sooloos and many other hard-drive-based systems can read sections of the disc multiple times if data errors are detected. The implication is that random bit errors affect sonic qualities such as soundstage depth and the reproduction of timbre.

I disagree. CD?s error-correction system can completely correct burst errors of up to 4000 successive bits. My experience performing bit- for-bit comparisons between source data and replicated CDs when I worked as a CD mastering engineer suggests that bit errors are virtually nonexistent. If CDs were rife with errors, computer software couldn?t reliably be delivered on CD (CD-ROM does, however, have an extra layer of error detection and correction but is invoked only when discs have been mishandled and become damaged).

Let?s perform a thought experiment. Suppose that uncorrected bit errors are common in CD playback. What are the sonic consequences of those errors? If a 16-bit word?s least significant bit (LSB) were changed from a zero to a one (or from a one to a zero), an amplitude error would be introduced that is one part in 65,536. (The number of amplitude steps in a quantization word is 2n, where n is the number of bits in the word; 216 is 65,536.) You would never hear an amplitude error that small in a single sample. But let?s say the bit error occurred in the word?s most significant bit (MSB). The value of the MSB is the value of the other 15 bits combined plus one (32,769). The MSB represents just over half the amplitude of a full- scale signal. Changing the MSB from a zero to a one, or from a one to a zero, would cause the signal level to suddenly increase or decrease by half the full-scale amplitude, producing a loud click at every error. Do you hear clicks when playing CDs?

Note also that bit errors would cause momentary jumps in signal amplitude, but would not affect factors such as soundstage depth or instrumental timbre. Bitstreams read from different media (CD, CD-R, hard disk) can sound different from one another, but not because of data errors. The most likely explanation is that hard drives deliver a bitstream with greater timing precision (lower jitter). If the bits are the same, and the sound is different, the only thing left is jitter.

microstrip · Feb 19, 2014

Al M. said:
The question is if bit errors really are an issue, even with a transport reading in real time.

Robert Harley says on this subject:

Much of the current speculation as to why this [that the music from server sounds better than from transport] should be the case focuses on the fact that the Exact Audio importing software used in Sooloos and many other hard-drive-based systems can read sections of the disc multiple times if data errors are detected. The implication is that random bit errors affect sonic qualities such as soundstage depth and the reproduction of timbre.

I disagree. CD?s error-correction system can completely correct burst errors of up to 4000 successive bits. My experience performing bit- for-bit comparisons between source data and replicated CDs when I worked as a CD mastering engineer suggests that bit errors are virtually nonexistent. If CDs were rife with errors, computer software couldn?t reliably be delivered on CD (CD-ROM does, however, have an extra layer of error detection and correction but is invoked only when discs have been mishandled and become damaged).

Let?s perform a thought experiment. Suppose that uncorrected bit errors are common in CD playback. What are the sonic consequences of those errors? If a 16-bit word?s least significant bit (LSB) were changed from a zero to a one (or from a one to a zero), an amplitude error would be introduced that is one part in 65,536. (The number of amplitude steps in a quantization word is 2n, where n is the number of bits in the word; 216 is 65,536.) You would never hear an amplitude error that small in a single sample. But let?s say the bit error occurred in the word?s most significant bit (MSB). The value of the MSB is the value of the other 15 bits combined plus one (32,769). The MSB represents just over half the amplitude of a full- scale signal. Changing the MSB from a zero to a one, or from a one to a zero, would cause the signal level to suddenly increase or decrease by half the full-scale amplitude, producing a loud click at every error. Do you hear clicks when playing CDs?

Note also that bit errors would cause momentary jumps in signal amplitude, but would not affect factors such as soundstage depth or instrumental timbre. Bitstreams read from different media (CD, CD-R, hard disk) can sound different from one another, but not because of data errors. The most likely explanation is that hard drives deliver a bitstream with greater timing precision (lower jitter). If the bits are the same, and the sound is different, the only thing left is jitter.

IMHO this childish thought experiment is misleading as it ignores the intricate levels of the CIRC error correction in CD readout. I would expect better from RH

. But yes, bit errors are virtually non existent - I am a believer sing long because in the 80's I connected digital counters to the C1 and C2 error pins of the SAA7210 Philips chip (I hope I am remembering the proper reference) . At that time a CD disk having more than an allowed number of C1 and C2 errors would be immediately returned for exchange!

microstrip · Feb 19, 2014

Al M. said:
Microstrip, I did provide the link to the full text of the letter. Here it is again:

http://www.computeraudiophile.com/f10-music-servers/clocks-and-alpha-digital-analogue-converter-997/

Yes, IMHO, just an ambiguous marketing text.

Al M. · Feb 19, 2014

microstrip said:
IMHO this childish thought experiment is misleading as it ignores the intricate levels of the CIRC error correction in CD readout.

Can you please elaborate? I thought RH means read-out after error correction.

microstrip · Feb 19, 2014

Al M. said:
Can you please elaborate? I thought RH means read-out after error correction.

The errors in readout will not result in this situation depicted of an error in the MSB and a loud click - much before this situation they will result in interpolation, that is not clearly audible but can result in soundstage depth or instrumental timbre losses. It is why I check my CD transports with the Pierre Verany test CDs when I suspect that the transport is loosing quality - usually time to replace or align the laser. Remember the old days when all reviews of CD players tested for the ability to correct errors? When it was wrongly assumed that the larger the fault gap that could be played the better sounding should be the player?

Al M. · Feb 19, 2014

microstrip said:
The errors in readout will not result in this situation depicted of an error in the MSB and a loud click - much before this situation they will result in interpolation,

How so?

Don Hills · Feb 19, 2014

Al M. said:
Microstrip, I did provide the link to the full text of the letter. Here it is again:

http://www.computeraudiophile.com/f10-music-servers/clocks-and-alpha-digital-analogue-converter-997/

The full text confirms the following:

The Model Two has a word clock output so that source devices can be slaved to it if they have a word clock input.

The Alpha does not. It recovers its clock from the incoming data stream. Done carefully (galvanic isolation, good PLL design, sufficient buffering etc), this can be adequately resistant to input jitter.

microstrip · Feb 19, 2014

Al M. said:
How so?

When the error system detects uncorrectable errors it creates approximate guesses to avoid the step discontinuity clicks - we can find a much more detailed explanation in the Error Section of the Linn CD Ripping Terminology document:

http://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminology#Error_Correction

Al M. · Feb 19, 2014

Don Hills said:
The full text confirms the following:

The Model Two has a word clock output so that source devices can be slaved to it if they have a word clock input.

The Alpha does not. It recovers its clock from the incoming data stream. Done carefully (galvanic isolation, good PLL design, sufficient buffering etc), this can be adequately resistant to input jitter.

Thanks, Don. How, on a technical level, can the clock be recovered from the incoming data stream? If this can be done correctly, then differences in jitter output between diverse transports should matter less indeed, I would think.

Alrainbow · Feb 19, 2014

May I ask what does MSB do from the UMT plus to a MSB dac ?

Al

Al M. · Feb 19, 2014

microstrip said:
When the error system detects uncorrectable errors it creates approximate guesses to avoid the step discontinuity clicks - we can find a much more detailed explanation in the Error Section of the Linn CD Ripping Terminology document:

http://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminology#Error_Correction

Thanks, Microstrip.

DonH50 · Feb 19, 2014

Al M. said:
Thanks, Don. How, on a technical level, can the clock be recovered from the incoming data stream? If this can be done correctly, then differences in jitter output between diverse transports should matter less indeed, I would think.

CDR (clock and data recovery) circuits based on phase-locked loops (and their cousins, delay-locked loops) have been around for ages. The ones I work with for SAS/SATA/PCIe keep your computers running while working with signals many orders of magnitude higher in ferquency and with much lower jitter than required by audio circuits.

Al M. · Feb 20, 2014

DonH50 said:
CDR (clock and data recovery) circuits based on phase-locked loops (and their cousins, delay-locked loops) have been around for ages. The ones I work with for SAS/SATA/PCIe keep your computers running while working with signals many orders of magnitude higher in ferquency and with much lower jitter than required by audio circuits.

Ok, I have done some digging on Wikipedia, and phase-locked loops lead me to the "clock recovery" page,

http://en.wikipedia.org/wiki/Clock_recovery

where it states:

Some digital data streams, especially high-speed serial data streams (such as the raw stream of data from the magnetic head of a disk drive) are sent without an accompanying clock signal. The receiver generates a clock from an approximate frequency reference, and then phase-aligns to the transitions in the data stream with a phase-locked loop (PLL). This process is commonly known as clock and data recovery (CDR).

[...]

In order for this scheme to work, a data stream must transition frequently enough to correct for any drift in the PLL's oscillator. The limit for how long a clock recovery unit can operate without a transition is known as its maximum consecutive identical digits (CID) specification. To ensure frequent transitions, some sort of encoding is used; 8B/10B encoding is very common, while Manchester encoding serves the same purpose in old revisions of 802.3 local area networks.

A scheme related to 8B/10B encoding (used in DAT and DCC recorders) is found in Redbook CD with Eight-to-fourteen modulation (EFM),

http://en.wikipedia.org/wiki/Eight-to-Fourteen_Modulation

So I suppose the clock can be recovered in CD playback from the EFM scheme. Is that correct?

asiufy · Feb 20, 2014

Alrainbow said:
May I ask what does MSB do from the UMT plus to a MSB dac ?

Al

MSB uses a proprietary connection, that carries signal (up to 32/768 and 2xDSD) as well as clock data over the same cable.
Even though the link is proprietary, the data is carried over regular CAT-6 Ethernet cable.
With this connection, the DAC can slave the transport, with a single cable (instead of the myriad of cables required for a solution like dCS').

microstrip,

Thanks for the link. It's been my (empirical) experience that drive quality (to a lesser extent), and software quality matter when ripping CDs. That I can only attribute to this interpolation that some hardware/software combination do, and that noticeably degrade the sound.
You can see for yourself, just plug in the cheapest MSB transport, that uses a $30 PC CD-ROM drive, and compare it to the fancy Esoteric transport. Depending on the disc, the MSB will sound quite a bit better, because it reads ahead, and avoids all the interpolation that the Esoteric is doing.
Here's the blurb from MSB' site

It accomplishes this task in a manner quite different than other CD transports and players. Using an optical ROM reader , the data is read from the disc in bit-perfect condition. Instead of smoothing over any read errors as other transports do, the MSB transport reads the disc again and again until the file is read perfectly, much the way a computer reads a data disc. The stored musical information is then played back to your DAC with perfect timing and extremely low jitter using our proprietary clocking technology and the MSB Network

alexandre

Alrainbow · Feb 20, 2014

Thanks great response.
I have added on the signature dual transport
For the UMT and as promised it does make the transport
Even better. The only sadness in this the oppo
Cannot support 128 DSD over network
And I must use USB or down sample
Files before using. The other confusing item is it's a reg cat 6.
Not 6a or shieled. And there are so many threads with people buying hi end
Data cables. It makes me wonder is it reall needed at all.
Al

microstrip · Feb 20, 2014

asiufy said:
MSB uses a proprietary connection, that carries signal (up to 32/768 and 2xDSD) as well as clock data over the same cable.
Even though the link is proprietary, the data is carried over regular CAT-6 Ethernet cable.
With this connection, the DAC can slave the transport, with a single cable (instead of the myriad of cables required for a solution like dCS').

microstrip,

Thanks for the link. It's been my (empirical) experience that drive quality (to a lesser extent), and software quality matter when ripping CDs. That I can only attribute to this interpolation that some hardware/software combination do, and that noticeably degrade the sound.
You can see for yourself, just plug in the cheapest MSB transport, that uses a $30 PC CD-ROM drive, and compare it to the fancy Esoteric transport. Depending on the disc, the MSB will sound quite a bit better, because it reads ahead, and avoids all the interpolation that the Esoteric is doing.
Here's the blurb from MSB' site

It accomplishes this task in a manner quite different than other CD transports and players. Using an optical ROM reader , the data is read from the disc in bit-perfect condition. Instead of smoothing over any read errors as other transports do, the MSB transport reads the disc again and again until the file is read perfectly, much the way a computer reads a data disc. The stored musical information is then played back to your DAC with perfect timing and extremely low jitter using our proprietary clocking technology and the MSB Network

alexandre

Thanks Alexandre,

Long ago I found that even using cheap Philips CD readers the number of errors needing interpolation was minimal and would have no effect in sound quality. As readers can now read much faster that replay speed, many CD transports implement this technique of multiple reads to avoid interpolation errors.

As there are large variations in sound quality due to the CD transport feeding the DAC people seek for logical and easily understandable reasons to explain them - but it was shown long ago that bit content is not the real reason. Noise in the digital signal and jitter are some of the remaining possible reasons, as well as injection of noise in the power lines. But some skeptical people do not like them.

asiufy · Feb 20, 2014

microstrip said:
Thanks Alexandre,

Long ago I found that even using cheap Philips CD readers the number of errors needing interpolation was minimal and would have no effect in sound quality. As readers can now read much faster that replay speed, many CD transports implement this technique of multiple reads to avoid interpolation errors.

As there are large variations in sound quality due to the CD transport feeding the DAC people seek for logical and easily understandable reasons to explain them - but it was shown long ago that bit content is not the real reason. Noise in the digital signal and jitter are some of the remaining possible reasons, as well as injection of noise in the power lines. But some skeptical people do not like them.

Curious then: which CD players do you know that can read ahead, "much faster than replay speed"? I don't know many, but if you do, let me know! AFAIK, most of them are still doing the real-time thing...

alexandre

microstrip · Feb 20, 2014

asiufy said:
Curious then: which CD players do you know that can read ahead, "much faster than replay speed"? I don't know many, but if you do, let me know! AFAIK, most of them are still doing the real-time thing...

alexandre

As far as I remember some Meridian, Mark Levinson and the PS Audio do it. I will have to look for the specific models. We can expect it from transports that use ROM drives, as they are able to read up to x56 the normal speed. I got this From a Meridiam post in Audiogon : Take Meridian as an example, they use CD-rom drives, often with multiple read passes, and buffer the data through RAM, before using a separate low jitter clock to pass the data through the DACS. The key words for a search could be "multiple read".

DonH50 · Feb 20, 2014

The clock is recovered from the data stream for any CD as there is no separate clock signal. Buffering by reading the data and then clocking out using a different, low-jitter clock keeps the DAC clean. For streaming signals, there needs to be some way to keep clock alignment, or eventually a tiny difference in transmission and reception clocks you will overrun the buffer (unless you have an infinite buffer). Serial data standards such as SAS include such provisions; AFAIK the CD standard does not. (I do not know about S/PDIF, have not looked at it for a while.)

Yes, the data must be "busy" to prevent the PLL (clock) from drifting off-frequency, and digital encoding schemes are used to enforce "busy-ness". PLL = phase-locked loop, and it needs transitions (edges) to know what it is tracking and to stay locked. If the signal sits unmoving for a long period, there is no edge provided for the PLL to lock to, and frequency drifts. Eventually an edge will come along and resynch the PLL, so long as it has not drifted so far away that it can no longer capture the right frequency. In practice this does not happen because the data is kept transitioning by the encoding.

A simple example would be when an extra bit is added so a "1" becomes "01", "11", "10", "00" on successive samples. Figuring out it is really a string of 1's depends upon the encoding/decoding algorithm, a process I usually refer to as "magic".

The jitter problem that is usually stated is when the transport's clock is not clean, or is corrupted by noise and distortion, and is used directly as the clock for the DAC. The DAC generally has no way of knowing if the clock is varying so clock jitter goes straight to the output. The audibility is always in question; it takes a fair amount of jitter to be audible in the audio range, though of course its bandwidth and spectral characteristics also matter.

I cannot remember who made it, but years ago I heard a CD player that first pulled the data off into a memory then began playback. After endless outcry from those who did not like waiting minutes for it to start playing, the designers were apparently made aware of dual-port memory and released a new version that started playing after a short period to load a few seconds worth of data so the music could play on whilst the rest of the disc was being read. It was still a bit distracting as the rapidly-spinning CD transport could still be heard if you were near the player until it pulled all the data off.

Al M. · Feb 20, 2014

Thanks, Don!

DACs with internal master clocks: less importance of transport?

VIP/Donor

VIP/Donor

VIP/Donor

VIP/Donor

VIP/Donor

VIP/Donor

Well-Known Member

VIP/Donor

VIP/Donor

Well-Known Member

VIP/Donor

Member Sponsor & WBF Technical Expert

VIP/Donor

Industry Expert/VIP Donor

Well-Known Member

VIP/Donor

Industry Expert/VIP Donor

VIP/Donor

Member Sponsor & WBF Technical Expert

VIP/Donor

Similar threads