hi @Dustin_Symanski , may I ask how best to connect a CD transport to the DD? I have an option to get a CD transport that can digitally output through either AES or RCA. The transport can also upsample to 24/176 before sending to the Cascade. 1) From technical standpoint for home use, does AES or RCA differ? 2) Also, is it better to send native 16/44 or upsampled one to Cascade to read? Cascade doesn’t upsample and neither does it provide a feature to do so. Is there a technical advantage from Cascade end to receive an upsampled file? Or is this a case of whichever sounds best to the listener?
I have found that with my Cascade that when there is both a Red Book stream and a upsampled stream ( you can often find both on Qubuz or Tidal, where the “HiRes” version is an upsample of the Red Book version) the Red Book version almost always sounds better. I haven’t a case where the upsampled version sounds better.
I have a number of audiophile friends who often come over to listen and they also find the Red Book version better than the upscaled version.
So now I always prefer to get the resolution that the original recording was done at, if the is possible.
Hi Dan, thanks. Your experience with streaming matches mine, even though I read there are differing views out there. Still, I have not tried playing red book vs upsampled one from a Cd transport and hence my query.
Regarding connecting the CD Transport via AES or RCA - normally AES sounds better. We use an AES input module in the DD for the transport.
My experience is in line with what Dan said about the upsampling as well. Have had several transports with upsampling options, but with a good DAC the native rate is almost always preferred.
Having said that there may be some specifics about the transport you’re using, so no harm in trying which works better for you.
Dustin would be able to explain in more specific technical terms.
For a standard CD transport AES, with word clock feedback, to make the digital stream synchronous to the DACs clock, would be the best. AES balanced usually has a higher noise margin (better signal integrity due to the higher voltages used) and better noise rejection due to the balanced signaling. With AES be sure to use an AES digital cable, not a balanced audio cable, the connectors are the same but the cabling is not. The second best would be S/PDIF with clock feedback. Clock feedback has more effect than AES vs S/PDIF. Third would be AES, no clock feedback. Fourth would be S/PDIF, no clock feedback. Fifth would be TOSLINK. From a noisy source, TV, Computer, etc…, the TOSLINK connection would be the first choice, because the noise coupled on the AES or S/PDIF connection hurts sound quality the most. The optical connection cuts the electrical noise coupling out completely.
As far as upsampling, I would stay away from it. I have yet to see any implementation that is better than nothing. This includes upsampling done in computers, chips or transports. Some people like certain up-sampler implementations that add some “ flavor” they are after. Thats fine if you love it, just know its flavor you are chasing, not quality. Absolute quality is always hurt by upsampling. I say “always”, but that does not have to be true, perfect upsampling could exist. I have just never witnessed it in the 25 years I have been designing DACs. Early on, some of my designs included upsampler chips, their clear shortcomings are what drove me to develop my own digital filtering in DSPs. Since then there have been no significant advances in upsampling chips, I have evaluated many. Software on PCs that does upsampling has become common, and some of it is better than chip upsampler implementations, but most is considerably worse. All software that I have evaluated has significant quantities of naive mistakes in the processing that keeps the quality from med to low with none having high quality. Therefore it is always best to find the original recorded format for any file and use that (if possible).
Just one example of a common naive mistake made by upsampling software would be the incorrect use of floating point math to implement the filter part of the upsampling algorithm. High quality upsamplers use a digital filter type called a FIR (Finite Impulse Response) filter. This algorithm multiplies each audio sample by a filter coefficient and then accumulates (adds) all of the results together. There are hundreds to tens of thousands of these accumulate operations per output sample. The coefficients have the property that they first increase in size then decrease in size. Floating point numbers have a portion dedicated to the actual value and a portion indicating where the “decimal point” is located. As the first half of the filter is calculated the accumulated value drastically increases in value, swiftly moving the decimal place to the right, then during the second half of the filter calculation the very small accumulated values don’t accumulate properly (each have significant rounding errors) because the values are too small to affect the already large floating point result. This means that the second half of the filter has huge total rounding errors in the calculation. The proper way to calculate a digital filter with floating point numbers is to calculate it from both ends separately and then add the two final results together, which I have not seen in any upsampling software. Or alternatively (the best possible way) have a “huge” fixed point accumulator ( without a “decimal point”) that does no rounding at all during processing and scale the result at the end of processing. Which I have never seen in any software either. In my digital filtering, in SHARC DSPs, this takes the form of two 80bit accumulate registers (160bits total) used for the accumulate function then one “rounding” of the complete result at the end of computation. This results in only one rounding error per sample instead of hundreds to thousands of rounding errors per output sample.
one follow-up question, may I know if the clock signal from CD transport to DD will be reclocked if there’s no word clock connection between the transport and DD? I just purchased Aqua La Diva M2 CD transport and although it has a word clock BNC, it’s an “output” so I don’t think it’s possible to connect it to MSB AES input which also has a BNC word clock“output”. That said, the clock in the transport is managed by FPGA instead of the optical module itself and Aqua states it’s very precise and I don’t know if it will be better if it’s being reclocked again in the DD/DAC.
The word clock output on a transport is useless, you always want the DAC to be the master clock source. Low jitter is very important at the point of conversion (the DAC itself) and is less important the farther from that point you get. So you want the DAC to have the ultra low jitter clock in it and everything else to be slaved to that. It’s not much of a problem however to deal with a nonsynchronous transport, the Digital Director will automatically reclock the data. It stores the data in memory and plays it back synchronous to the DAC. Because the incoming data from the transport will not be synchronous to the DACs clock a bit of extra electrical noise is generated, which has a very small but nonzero effect on performance.
