Still listening through the JVC 1010TN?
How does the Sony CDP compare to streaming via the JVC K2/DAC??
Classic Sony CD players
- Thread starter Tigerjones
- Start date
Still listening through the JVC 1010TN?
How does the Sony CDP compare to streaming via the JVC K2/DAC??
flatpopely
Prog Rock/Moderator
Hi Dan.
The 1010 isn't going anywhere and the recent arm change reminds me how good the phono stage is!
The K2 in the JVC made me listen to CD again after using it to take the SPDIF out of my ARCAM 70.3. Via analogue line outs the ARCAM was very hard and bleached sounding, the K2 made it sound great. I was hard presssed to say if I preferred CD or streaming (Tidal), both sounded good.
The 338 line out sounds better than it's SPDIF out into the JVC. Now CD is consistently better than streaming. Sometime Tidal does amaze, 'Croz' being a case in point.
I'd now say CD and LP sound as good as each other and I can happily listen to both without thinking I'm missing something. Streaming less so but in isolation it's bloody good and I listen to it loads for when I don't possess the original; I don't feel I'm missing stuff.
I'm in a good place, I enjoy music regardless of format!
Mike P
Trade: Pickwell Audio
Congratulations! Which model?
Mike P
Trade: Pickwell Audio
Beast!
Gentleman.
Can someone explain why it is that an 'integrated' CDP can perform better than a seperate DAC / CD transport or even streaming? I know there are manynreasons for either side being better than the other, but something that I've only recently been made aware of is the data transfer language.
The DDDAC builders on the Wam have managed to get a significant improvement in sound qualty by going to R2R, which needed the DAC to be directly connected to a Raspberry Pi. I believe that the vast majority of older high end CDPs always used this method and it is surperior to the USB delta-sigma system?
slightly confused.
Edit, I meant I2S not R2R
Can someone explain why it is that an 'integrated' CDP can perform better than a seperate DAC / CD transport or even streaming? I know there are manynreasons for either side being better than the other, but something that I've only recently been made aware of is the data transfer language.
The DDDAC builders on the Wam have managed to get a significant improvement in sound qualty by going to R2R, which needed the DAC to be directly connected to a Raspberry Pi. I believe that the vast majority of older high end CDPs always used this method and it is surperior to the USB delta-sigma system?
slightly confused.
Edit, I meant I2S not R2R
Julf
Facts are our friends
I assume that you are talking about the interconnection standard when you write "data transfer language"? R2R is a DAC architecture, and has as such, nothing to do with the interconnection protocol - in the case of the RPi I assume they are using I2S.
PigletsDad
My intelligence test came back negative.
Delta sigma is another DAC architecture (like R2R), and nothing to do with the method of connection.
Julf
Facts are our friends
Mike P
Trade: Pickwell Audio
Hi Dan,
Others here will be able to give you a more comprehensive answer but as I understand it the basic answer you are looking for is all to do with clocking and jitter.
In the scenario of a separate transport and DAC the transport acts as the master clock. The DAC unit receives digital information which has both the musical information in it and also a clock signal. This clock signal must be recovered at the DAC and it prone to added jitter.
In an integrated CD player both the transport and DAC are synchronized by a single master clock and this approach is less susceptible to jitter.
There are ways around the problem though, some examples being the Linn Karik/Numerik combination the Cambridge Audio Discmagic/Isomagic combination and *I think* also the Sony DAS R1 CDP R1 combination.
Others here will be able to give you a more comprehensive answer but as I understand it the basic answer you are looking for is all to do with clocking and jitter.
In the scenario of a separate transport and DAC the transport acts as the master clock. The DAC unit receives digital information which has both the musical information in it and also a clock signal. This clock signal must be recovered at the DAC and it prone to added jitter.
In an integrated CD player both the transport and DAC are synchronized by a single master clock and this approach is less susceptible to jitter.
There are ways around the problem though, some examples being the Linn Karik/Numerik combination the Cambridge Audio Discmagic/Isomagic combination and *I think* also the Sony DAS R1 CDP R1 combination.
And would that be the reason why a decent CDP could better a DAC / streamer?
Julf
Facts are our friends
See Mike's answer about clock structure. But there are a lot of factors at play.
Some CDP's transfer data from the CD to the internal DAC or output close to real time. If there is a read error, the CDP has to "fake it". This is of course not an issue with a streamer that buffers the data stream. Many modern CDP's actually read data like a computer/streamer would - by reading in advance, and re-reading if there are problems.
But to re-answer your original question - no, the differences in sound quality (and while some people think dedicated CDPs sound better, I would disagree) don't depend on the "data transfer language" as such.
MichaelC
pfm Member
Installed, well jerry rigged rather, far from ideal set up for the time being.
From cold, first impressions, well well well, its rather SUPERB.
flatpopely
Prog Rock/Moderator
I had a moment like that with CDP 338esd.....
CD as good as vinyl no way........yes way!!!
martin clark
pinko bodger
One other to add, probably the earliest really-complete approach to ideal - DPA/ Deltec's 'Deltran' interface: (fs*128=5.66Mhz clock link, and optically isolated) - once you'd switched-on their CD transports and a matching dac (the prefered connection was toslink, as the designer Rob Watts still prefers to this day) - the transport could be entirely slaved via a buffer to the local clock in the dac: which is really the ideal, comparable to isochronous async USB transfer today*. And obviated *the* problem of toslink, which was the mux' of clock and data via a too-slow interface. The dac's local clock link dictates the general rate of transfer, the toslink data incoming stream is only used for data - not also clock recovery to drive the dac.
I've a few Deltec dacs+ and a deltran-capable transport here - still works very well indeed.
*
When you see how the DAVE/ Hugo inc TT and Mojo work - it's the same, really, except cheap( therefore large) ram FIFO has made made what the transport device sends, when... even less critical.
ETA: the Karik-Numerik is a bit horrible in comparison - the dac sends a DC control voltage (via BNC!!) back to the transport to 'pull' the transport VCXO clock instead. Potentially that's a good way to get gallumphing amounts of hysteresis/ jitter in the loop. Now I've had a play with the things and like them/ the resulting sound and much seen on the 'scope; never had the time to go in & study what the practical/measurable effect was in detail, to be fair.
PigletsDad
My intelligence test came back negative.
This could be OK if there is a high quality clock in the DAC, and this is just used to lock the transport clock to a master in the DAC, to stop data buffers over-filling or running dry.
martin clark
pinko bodger
Actually I think that's what was done, it would make more sense - long time since I played with one.