I think this conversation about naming is over-complicating the subject and getting various elements muddled together.
To me, in order for Marcel's RTZ decoder to work it requires three data components, Left Data, Right Data and Clock, which are collectively referred to as DSD. (Maybe a better road analogy would be to think of a motorway (or freeway, autostrada, etc) as comprising of a left carriageway, right cariageway and a central safety barrier.)
In order to render the DSD to the decoder it is normal to send a data signal to a 'computing device', which processes the data signal to derive the three components of DSD. Passing the derived DSD components to the decoder typically utilises the transport protocol we know as i2s (I guess because it is ubiquitous), but the data is still DSD.
Of course there is more to it than that and I've not covered the data streaming to the 'computing device', nor the the format of the media, any required transcoding, or the format of the original recording.
Anyway, to me, to optimise any measurement process, it seems sensible to remove as many variables and as much processing as possible, ideally playing back DSD files stored and played back locally on the computing device that derives the DSD components, but probably more practically, working with DSD-format source files that don't require any transcoding or transport processing (such as the use of DoP).
From my own perspective, I think of the term 'Raw DSD' in terms of the data stream (as opposed to DoP) and 'Native DSD' as source media that was recorded in a DSD format (though I'm probably guilty of being casual with the use of these terms on occasions).
For what it is worth, I'm gradually accruing a library of Native DSD recordings, mostly DSD256, that playback exceptionally well on Marcel's RTZ and Valve DAC decoders (and Pavel's DSC2).
To me, in order for Marcel's RTZ decoder to work it requires three data components, Left Data, Right Data and Clock, which are collectively referred to as DSD. (Maybe a better road analogy would be to think of a motorway (or freeway, autostrada, etc) as comprising of a left carriageway, right cariageway and a central safety barrier.)
In order to render the DSD to the decoder it is normal to send a data signal to a 'computing device', which processes the data signal to derive the three components of DSD. Passing the derived DSD components to the decoder typically utilises the transport protocol we know as i2s (I guess because it is ubiquitous), but the data is still DSD.
Of course there is more to it than that and I've not covered the data streaming to the 'computing device', nor the the format of the media, any required transcoding, or the format of the original recording.
Anyway, to me, to optimise any measurement process, it seems sensible to remove as many variables and as much processing as possible, ideally playing back DSD files stored and played back locally on the computing device that derives the DSD components, but probably more practically, working with DSD-format source files that don't require any transcoding or transport processing (such as the use of DoP).
From my own perspective, I think of the term 'Raw DSD' in terms of the data stream (as opposed to DoP) and 'Native DSD' as source media that was recorded in a DSD format (though I'm probably guilty of being casual with the use of these terms on occasions).
For what it is worth, I'm gradually accruing a library of Native DSD recordings, mostly DSD256, that playback exceptionally well on Marcel's RTZ and Valve DAC decoders (and Pavel's DSC2).
Last edited:
@nautibuoy , have you noticed the difference between same dsd files played on Valve dac vs. RTZ dac/DSC2?
I have found a big difference between the direct dsd file as in DSC2 and the same file decimated first, the re-modulated, as in Valve dac. I don't have Valve dac, but I used the same algorithm in my FPGA. As Marcel wrote, they sound as if the dsd files come to life.
I have found a big difference between the direct dsd file as in DSC2 and the same file decimated first, the re-modulated, as in Valve dac. I don't have Valve dac, but I used the same algorithm in my FPGA. As Marcel wrote, they sound as if the dsd files come to life.
In any case, nautibuoy uses the raw DSD version of the valve DAC. That's a variant without FPGA board that puts the DSD streams straight on the E88CCs, after some reclocking and level shifting.
Are you sure I wrote that?
Are you sure I wrote that?
I have no experience, as Marcel has said, I use the version of Valve that only takes a DSD input, so no FPGA involved.
Didn't Marcel write a few different modulator algorithms? IIRC, one was chaotic?
Also, could you be a little more clear about the meaning of "come to life?" Is the sound more 3-dimensional? Is there more separation between instruments (kind of like having a deep black level on a video monitor, instead of only gray)? Are amplitude dynamics less compressed?
Yes, a chaotic single-bit sigma-delta modulator and several variants of a quasi-multibit sigma-delta modulator with an embedded pulse width modulator with randomly rotated patterns (like in post #763, https://www.diyaudio.com/community/threads/return-to-zero-shift-register-firdac.379406/post-7403058 ).
Partially yes, I used sigmadelta module as a model and random noise generator modules, on a CycloneIV EP4CE40 FPGA - the most powerful I have. These modules are heavy consumers of resources, so they wouldn't fit (as they are in the original Valve dac project) in a small FPGA as SLX9 or SLX16. I actually did it for SLX16, but I only kept "chaos" and "PWM8" modes and I heavily optimized the verilog modules, but there is no room left for decimation of dsd files.
Now that you asked, I am not so sure if you said that or other user. I am sorry if I was wrong.
Anyway, this is my perception, that it comes to life.
It is hard to explain and I think that "it comes to life" is the best description. Music becomes more vibrant and gains presence.
It would be nice if we could compare SQ of various approaches. BTW we are still doing some listening sessions in the background for Simple DSD Converter FPGA algorithms. We try to provide some very specific observations about what's good and what's maybe not as good. Among other things, we use SACD rips of the same song as one form of official "how it should sound" reference. Also use high quality vinyl versions of original tapes, when available.
I am getting confused here, getting all over the place (again) …
Are we talking about comparisons of a pcm sd modulated one as in a version of ValveDAC or a straight thru rawDSD version that Marcel developed later and Ray used for listening tests?
As I understand it, this Simple DSD converter does pcm->dsd and then goes to suitable DSD DAC. Does it also do some DSD raw -> DSD ‘decimated’ like Thorp was indicating? and it was the sound quality of the latter that he was enquiring with Ray earlier?
Are we talking about comparisons of a pcm sd modulated one as in a version of ValveDAC or a straight thru rawDSD version that Marcel developed later and Ray used for listening tests?
As I understand it, this Simple DSD converter does pcm->dsd and then goes to suitable DSD DAC. Does it also do some DSD raw -> DSD ‘decimated’ like Thorp was indicating? and it was the sound quality of the latter that he was enquiring with Ray earlier?
Algorithms can be done is software or hardware. The first question should probably be, what gives the best sound and how computationally expensive is it?
With that as a limit, finding good value at different cost points would probably be the next question.
One of the reasons for needing to know the best (or close to it) algorithm would hopefully be to help perfect better and better DSD dacs.
With that as a limit, finding good value at different cost points would probably be the next question.
One of the reasons for needing to know the best (or close to it) algorithm would hopefully be to help perfect better and better DSD dacs.
To decimate literally means to divide by 10. In DSP it means to reduce the sample rate, to divide it down.
IIUC, 'DSD decimated' means to downsample DSD to some kind of baseband digital audio. Maybe something like DSD256 down to 16/44 or 24/44 PCM. So long as its all done in the digital domain then the only damage to the original musical information is the result of mathematical calculational approximation (which can be arbitrarily determined given sufficient processing power and sufficient processing time).
So, if we downsample DSD back to some lower sample rate form of the original digital information, the remodulate it back up into DSD at some higher sample rate using some different modulator algorithm, maybe our physical DSD dac will be able to do a better job of converting the underlying musical information from its new particular DSD form back into something better resembling the original analog information.
Does that make sense?
IIUC, 'DSD decimated' means to downsample DSD to some kind of baseband digital audio. Maybe something like DSD256 down to 16/44 or 24/44 PCM. So long as its all done in the digital domain then the only damage to the original musical information is the result of mathematical calculational approximation (which can be arbitrarily determined given sufficient processing power and sufficient processing time).
So, if we downsample DSD back to some lower sample rate form of the original digital information, the remodulate it back up into DSD at some higher sample rate using some different modulator algorithm, maybe our physical DSD dac will be able to do a better job of converting the underlying musical information from its new particular DSD form back into something better resembling the original analog information.
Does that make sense?
Thanks Mark, this is new to me. I thought when you downsample or convert from DSD to PCM there will be loss of quality? The other way round, PCM upsampled and converted to DSD is fine and quality preserved. So, the implication here is it would be better to start with PCM recorded one than a DSD recorded original source and do upsampling/convert to DSD. There is this site selling hires stuff - NativeDSD and they have both PCM and DSD original recordings. I am already sampling their DSD256 recordings - huge files! So, better to get PCM ones and use HQPlayer or this FPGA to convert and will sound better than native DSD recordings?
There certainly can be. Depends on how well it is done. Information is information no matter how it is encoded. Seems to me when converting encoding of information from one form to another in the digital domain, the result is dependent on the algorithm used and the numerical precision/bit-depth of the calculations.
Also IME so far, modulator algorithms and upsampling filter algorithms have a great deal to with final sound coming out of a DSD dac. What happens from there then depends on the rest of the system. IMHO it turns out most systems seem to have have some flaws (perhaps in part because of the way we may typically measure stereo amplifiers one channel at a time; IME it tends to make certain audible problems having to do with imaging get overlooked).
Look forward to the developments. Good to know that the DAC side remains unchanged 
The other reason going for DSD source is that the player side can be hosted on a low power streamer. I just using a fanless core i5 Surface Pro for testing DSD music - doesn’t break a sweat even with DSD512 and sounds great
The other reason going for DSD source is that the player side can be hosted on a low power streamer. I just using a fanless core i5 Surface Pro for testing DSD music - doesn’t break a sweat even with DSD512 and sounds great