Given my setup - dCS Rossini DAC + dCS Rossini Master Clock - a transport with a word clock input makes the most sense.
I have some reservations about I2S: In the most common implementation, all it does is send the clock on a separate line. This is a waste of time given the SPDIF spec already has a transition at double the clock cycle (a 1 is a transition in between, a 0 is no transition in between). So there is no extra info in the clock line. There is another, less common I2S implementation where the clock comes back from the DAC to clock the transport. This makes more sense to me - and this is the Pro-ject implementation.
I think some people misunderstand what about jitter is audible. It is not the noise of the MHz level clock recovery but the lower frequency drift of the clock itself. This is why a master clock that has very low drift is very useful. For example, if you had a clock that gets ahead of a perfect clock, then behind, then ahead again, with a frequency of 200 Hz, every frequency F will get sidebands at F-200Hz and F+200Hz. This is why I think the dampening mods are useful - the clock inside the player gets less microphonic feedback and thus probably lower audible frequency drift.
It would be great if Michael Lavorgna would compare my moded CXC with the unmodded one he’s evaluating.
One of the nice things about the CXC is the simplicity of design and quality of parts. The CD drive is a Sanyo, the same one used in all other CD machines in the Cambridge line, the Hegel Mohican, and possibly other high end CD transport/players.
The power supply is a robust 40W linear supply with rectification and filtration right on the S3 servo board. This board has double-stage linear regulation: first to 8V then to 3.3V. It is also minimally stuffed: the DAC section used in some of the Cambridge CD players is not even stuffed with components:
In this pic you have the linear voltage regulators at the bottom (attached to the heat sink), then going up on the right is the CD mechanism power driver (powers the motors in the mechanism, including the CD tray), and above it the CD reading/decoding/servo which reads the TOC, does the control of the mechanism, error corrects, and produces the SPDIF signal. The empty section on the left is the DAC section used in (some of) the CD players. No DAC here. Clean and minimal.
@Phil_Wright thanks so much for the second hand NUC inspiration! I managed to pick up a fanless 7th gen i5 and got it up and running with ROCK yesterday. It wasn’t possible to do a meaningful A/B but it definitely feels much more relaxed and flowing. The MacBook seemed a bit etched in comparison. Haven’t compared to the usb stick and cd yet. I expect there to be a difference, but I think the gap has closed a significant amount. The difference has really got me wondering what the very top end stuff like Taiko Audio can bring to the mix, not that I am ever likely to be a customer!
Suppose you had a dcs Bartok (that has built in Qobuz streaming).
Would you suppose that adding a Nucleus to the flow, adding Roon, would improve, deteriorate or not change the sound quality over streaming Qobuz through the Bartok without the Nucleus?
It is an extra step. It also introduces additional traffic to your network in the form of an alternative protocol (RAAT). Roon makes no claims about sound quality. I would try it with an existing PC or Mac and see if it suits you before going all in with a Nucleus.
I have not tried Qobuz or TIDAL on Mosaic vs via Roon+RAAT. However, I perceive a slight sound quality improvement when playing either files from USB or UPnP-served files directly on Mosaic. So if I had to guess, I would say it might sound slightly better. But the difference is not worth the massive loss in convenience, IMHO.
I have a Bartok running Roon through a Nucleus. I don’t have Qoboz but use Tidal regularly. I can’t hear any difference between Roon and direct from the Dcs mosaic app.
