I had the opposite experience when I compared the Matrix’s I2S and AES/EBU outputs into the DS Sr. – OneConvey HDMI vs. BJC AES/EBU. (I have since upgraded the I2S connection to a red-clad Wireworld Starlight 7 HDMI.)
Initially, I had the two cables running out of the Matrix simultaneously when I did shootout. They were pretty close when both leads were connected to the DS Sr., but when I ran them one at a time – which is the best way to go, or so I have read – the I2S connection beat the AES/EBU connection fairly handily.
Wireworld Gold Starlight 7 AES/EBU vs. Silver Starlight 7 HDMI here. I am preferring the former although I am certain I would be happy with either. The bottom seems better the the AES/EBU cable.
(I was able to purchase the Gold Starlight 7 AES/EBU used from the Cable Company for $250)
I2S between the DMP and the DAC is as close to jitter free as you can get while AES/EBU and Coax do have jitter signatures. Some people do prefer the sound even so. I do not.
I’m not sure this is a supportable assertion. Ted has stated on a few occasions that the DS inputs are essentially equal in terms of their jitter rejection, but that I2S over HDMI has a possible noise advantage over some of the others due to its high level of shielding and grounding.
Maybe I2S is the best performing connection between the DMP and DS, but I would be surprised if the reason why had anything to do with jitter.
The key word in your observation is jitter rejection! I2S does not combine the data and clocks into a single stream so it is jitter free. The input on the DS has the same jitter immunity but the source carried over I2S does not induce jitter to be rejected. No jitter is superior to and immunity to low jitter.
Sorry but that’s just not a correct view of how these things work. In a conventional digital audio receiver circuit I2S does have an advantage over the bi-phase-mark encoded AES-EBU, S/P-DIF and TOSlink connections which partly is due to it having explicit clock signals, yes, but the DS is not a conventional device.
Jitter is a variation in timing. There is no such thing as zero jitter, even I2S clock signals have some degree of jitter in them. It’s just that deriving a clock from the data (as per AES etc) results in greater jitter in that clock signal than would be in the I2S explicit clock from the transport.
But none of that matters in the DS because it doesn’t use any incoming clock – explicitly or derived – as the source of its own timing.
Very interesting for sure. Now please explain why the DMP connected via I2S sounds so much better than the PWT or the DMP connected with either AES EBU or SPDIF Coax if jitter is not taken into consideration. The DS is not the only DAC that is designed to ignore the incoming clock signals either.
Given that the system does not have significant ground-loop noise, the coax interface will outperform the Toslink, If you use a decent coax cable that is. The Optical conversions add jitter. If the system has a lot of ground-loop noise, the Toslink will be better simply because it breaks the ground loop.
I2S is the native interface to most D/A chips. Because there is no need to encode the clock and data into a single signal, this makes it superior technically to S/PDIF coax. Termination and handling of the transmission-lines of I2S is non-trivial however and many of the early implementations were not very good. I2S consists of 4 signal lines: MCLK, SDATA, L/RCLK and SCLK (aka BITCLK). The HDMI connector used with the differential version of I2S was chosen by PSAudio and adopted by Wyred 4 Sound and Empirical Audio, who also uses RJ-45. I2S has been used in single ended version with DIN and RJ-45 connectors for about 10 years. The earliest was Audio Alchemy. Differential version has 8 signal lines and ground. Single ended has 4 signal lines and 4 return lines (grounds).
If you remove changes in bits (bit perfect) and changes in the timing of bits (jitter) as effectors of SQ, what remains are differences in noise (EMI, RFI, ground loops, etc.) -this would include the noise generated in processing a given connection modality within the DAC, hence Toslink is not impervious as sometimes argued.
Please explain to me how the level’s of jitter you are talking about make a difference in the DS when the DS adds 6ns P-P of jitter to all incoming signals. It was explained how the cables make the difference - mostly thru their solidity of grounding and their shielding of the signals from noise and shielding of the rest of your system from the noise in the cables. It is certainly the case that other DACs reject some of the incoming jitter, but there are few DACs that add jitter and simply ignore the timing of the edges of the signal - no PLLs, no FLLs, no reconstruction of the incoming clocks at all (and for that matter no ASRC). Those are the fundamental ways that jitter affects DACs none of which apply to the DS.
You are the guru If you can’t explain it how could I. Maybe the fact that the separation of the clocks and the balanced connections are responsible for the difference than I hear. All I know is that in my system there is no reason to use any other connection between the DMP and the DSD than I2S.
The point that people have been trying to make is that with the DS the separation of the clocks is completely immaterial - the clocks aren’t used in the DS and the DS only looks at the steady state values of the data. All digital inputs (whether I2S or AES, etc.) are sampled at 169.344MHz - then pattern matching is performed to see what the data is. The master clock for I2S isn’t hooked up at all and the I2S bit clock is just part of the pattern matching, no edges are ever looked at nor timed.
We’re not denying that you hear what you hear, we are just saying that your technical descriptions of what is happening are not correct in this circumstance.
The other reason for using the HDMI connection is so you can decode SACD’s Something that is not possible over any other input. I am glad you clarified how the DS handles the inputs. I have only been repeating what Paul had told us about I2S since they first developed the connection for use between their DAC and the PWT.
If the icon is not displayed than it will playback properly! The question is does the transport you use handle deemphasis internally so that when you play a disk using preemphasis you will not get a 10db boost in the highs.
I can tell you it is not. I have a few that are not on there like Lionel Richie ‘Can’t Slow Down’ Men at Work to name a couple. I see one listed that does not have PE and does not sound excessively bright.
I don’t think the list of CDs with PE is complete. I have two Bruno Walter CDs that are on the list and I have always been troubled by the strident upper string quality when playing my rips of them. I had no idea this might be a PE issue. I have been able to process the files with the SoX uitility to apply de-emphasis and they do sound much better. But I have other CDs from the same period (early 80’s) that I strongly suspect of being similarly affected - including the other two CDs of Walter’s Brahms symphony cycle. I have not yet succeeded in finding a way of determining whether a CD does or doesn’t have PE applied. Playing the CDs on a Sony DVD player using the coax input to my DSD Snr doesn’t bring up any PE icon on Huron or Redcloud. I’ve tried selecting the option in dBpoweramp to include PE tags but found no way of displaying them to confirm they are there in the flac files.