

So I go for minimum number of conversions. So his approach is to ensure that minimal losses occur.
#Bitperfect native software
BitPerfect is also the company that has provided the software NativeDSD uses to convert. The tracks on this sampler have been selected by Richard Murison of BitPerfect a firm based in Montreal, Canada. You cannot improve the quality of the original, you can only decrease it. Adagio is a DSD Sampler that features 12 tracks from the extensive Channel Classics catalog of DSD recordings available at Native DSD Music. He is of the view that any component or processing has the potential of losing quality. I try to follow the “minimal loss concept” that I have picked up from Hansruedi Neukomm (the father of the CDA126S).

Maybe he can weigh in with some of his experiences. To me, is the golden ear on this subject. Adding the mysterious DSD sample rate conversion to the up sampling possibilities in dCS equipment provides almost infinite possibilities (even more for the poor Vivaldi owners). Regarding what sounds best, I am afraid there is no simple answer. Whether the math behind changed or whether this is just cosmetics, I don’t know. Interestingly the Roon signal path used to explicitly show a DSD to PCM conversion and a subsequent re-modulation. I suspect there is a demodulation and remodulation somewhere, as no-one wants to be explicit about how they do it. I have asked the question about converting DSD sample rates on several forums, but never got a real answer. I have no idea how exactly nativeDSD convert the sample rate of DSD, but for sure the process is not lossless and involves demodulation and remodulation. I buy the DSD256 because I like to have the “Original” (with all caveats attached) and other DACs that I use can do DSD512 (the Neukomm and Chord Hugo 2). The DXD I usually produce myself using DSDMaster. You can get an additional sample rate for a “few Dollars more”. Having said that, I usually purchase both DSD256 and DSD128 files at nativeDSD. A short summary of the conundrum can be found here. Others such as Andreas Koch may disagree. Does it matter? Merging claim that DXD is transparent to DSD and that it does not. So a “Recorded in DSD256” file may have spent part of its birth process as DXD.

For example Merging’s Pyramix platform converts DSD to DXD for processing and re-modulates to DSD at the very end. It does not mean the audio has not been processed on its way to the final audio file.
#Bitperfect native drivers
Contrary to popular "audiophile" claims, there are NO benefits from using ASIO as far as music playback quality is concerned, while bugs in ASIO drivers may severely degrade the performance.You I like to purchase music in format most closely to the original. It is highly recommended to use the default output modes instead of ASIO. "Please note that this component is meant for systems where ASIO is the only available output method. Slightly off-topic, but also related to all this: For the MusicBee users that put effort in getting ASIO to work or believe it is superior to wasapi, here a quote from the developer of foobar2000 who created an ASIO component himself: It may be interesting from a technical standpoint, but putting effort (or money) in DSD in my opinion serves no practical purpose and won't do anything to improve on sound quality. To me that confirms my belief that there is no added value in DSD compared to the existing lossless formats. You will need to add several 3rd party components for asio, dsf, something called asio proxy, or whatever to be able to play them. (often regarded as some golden standard for no-nonsense audiophiles) Getting curious about the limitations of my DAC or perhaps MusicBee, I thought to see how well foobar2000 handled my testing files. But the concept is cool and I hope someday becomes fully functional. And I just realized Realtek HD came with Asio drivers a week ago, which while working fine with MusicBee have no discernible advantage over Wasapi-Exclusive other than the ability to play DOP/DSD. For now I'm back to my old friend Wasapi-Exclusive, as I have no DSF in my collection, nor do I own a DAC (yet). Why the original poster didn't get involved in the testing I don't know, but any others who can do so, PLEASE DO. It is also not dependent on special USB drivers to handle DSD. The wrapper is then discarded at the DAC and the raw DSD reassembled, resulting in bit-perfect DSD exactly as if the "stream raw DSD data" option was used. Most who are following this already know what DOP is but for "them what's doesn't" it is a stream transport method that encapsulates raw DSD into a PCM wrapper.

While a single case, at least it can be passed on to the users that using DOP with DSD64 and DSD128 CAN WORK. Steven will have some hard data to pass along to the bassdsd.dll developer, which is probably the key to this. Many thanks hiccup for some fully documented testing of this, what a breath of fresh air.
