Native DSD - First Impressions

[firedog]

25 minutes ago, BrianLS said:

DAC is not working as hard receiving the DoP data and re-assembling the DSD stream.

This is a false myth. There is no DSD stream to "reassemble" with DoP. It's exactly the same DSD as native DSD. The PCM shell is just that,  a shell that "tricks" the USB input into accepting the stream. The shell is shed at the USB input of the DAC. Internally the DAC does exactly the same thing with either type of DSD signal. 

[firedog]

11 hours ago, BrianLS said:

So it's not just a myth, but a false myth?  Ok.
This is such a silly thing to argue about given that the point of the post was to talk about what I heard with the new Aurender update.
We don't even disagree for the most part.  Do you just object that I say 'protocol' and you say 'shell'?
DoP is a system for stuffing PCM frames with DSD data.  I think we can agree on this.  The DAC, including everything that is on the receiving end of the USB cable, must recover the DSD data from the PCM frames before processing it as DSD data.  I would guess that we even agree on this.  Amazing what we agree on, isn't it?  No 'false myths' so far.
Perhaps where we disagree is on the impact this extraction could have on the ultimate sound quality.  I guess if your point is that "I can't possibly hear the difference" or something, the conversation is over since we're now just speculating about each other's systems and ears.  All I can say is that I can hear the difference without any difficulty, as can everyone who has heard me demo the new Aurender feature.  The update makes me happy.  I'm glad iFi supports this mode.  Does this mean that the iFi will replace my Vivaldi for all future listening sessions?  Not at all.  Does it allow me to listen to my DSD256 tracks that the Vivaldi doesn't support?  You bet.
Take care - Brian.

I understand that your main point was talking about what you heard with the Aurender. I don't comment on what other people hear-I accept they hear what they claim, becuase even if the sound is based on expectation bias, that's what they are hearing. That's a general comment, not directed at you. 

But you framed your conclusion as being a result of native DSD as opposed to DoP and explained why. Your explanation, as stated originally, is based on a misundertanding of what DoP is, as it doesn't require "reassembly" of the DSD. If you didn't mean that, fine.

But it's an oft repeated (false) myth among audiophiles that DOP somehow isn't native DSD-it is. "Native" DSD originally meant DSD not converted to PCM for playback. Both what you call native and DoP fit this definition.

Manufacturers and marketers have promoted a misunderstanding, tied to redefining "native" as "not DoP" in order to create an incorrect idea that implies that DoP DSD streams are somehow altered and that the processing of them in a DAC is somehow fundamentally different from those used to process what they call "native" DSD. It's not. DoP doesn't add a "processing burden" to the DAC. They just want to make is seem that way in order to claim/imply an illusory SQ advantage for their DACs.

 

Related question: are you familiar with uncompressed (distinct from 0 level compression) flac? It a PCM file in a flac shell.  It's essentially the same size as the equivalent wav file - both are uncompressed. It's the same data. A wav file is a PCM file in a wav shell. Do you think the two  sound different because the flac shell requires "processing" that the "wav" shell doesn't? The same thing is true o the two types of DSD you are talking about. 

 

[firedog]

1 hour ago, matthias said:

 

DoP places a burden of additional 50% on the CPU in comparison to "native" DSD. Surely it is DSD but the CPU has more work to do anyway. For DSD256 for example you need PCM768 as carrier for DoP. I am sure @BrianLS is right in hearing differences in favour of "native" DSD.

 

Matt

Not on my system it doesn't. I just ran DSD 64, 128, and 256 - each in both native and DoP. Same track for each rate of DSD.

Virtually no difference in CPU load reported.