I think I will stick with what I have then, sounds great to me.Just going by what that guy from a few days ago said,made me curious about converting everything to DSD.
I’ve heard you mention this many times but I not sure what you mean here or why it would affect the sound quality of one upnp server to another. Can you try to explain in as simpler form as possible please?
Hi @anon91915252 i can try, and with the new NP800 based streamers it’s not relevant as I can hear no difference.
However on the early streamers, on a home network, the data transfer of audio data typically was transferred in bursts until the receiver network (TCP) buffer was full, as opposed to a more regulated flow. In these bursts there is a flow of frames. I found when this flow of frames was more regulated, ie the time between each frame more consistent, I found I preferred the rendered audio from the streamer (NDX feeding a DAC)
Where the frame timing was more varied or inconsistent, I found the rendered audio least pleasing (note I deliberately didn’t use the term SQ)
The best performing UPnP server in this regard, and therefore the most pleasing to ‘listen’ to for me was a basic ReadyDLNA implementation running on a NetgearRN212. Interestingly although it could transcode FLAC to wav, I preferred is FLAC as opposed to transcoded wav on other UPnP servers such as dedicated servers, PCs etc.
At the time I shared this observation with Naim when grey were developing the new streamers, and I was advised that the front end was now very different and should be less noticeable if at all… and indeed that was the case for me when they launched.
Thanks for taking the time to explain. Still trying to understand how that would affect the sound though, does one method potentially generate more electrical noise in a system then. Is this flow determined by the end device then or the software serving it up or a combination of both?
Yes, exactly that. It’s typically noise in the ground plane or voltage lines, or even through EM radiation, although the PCBs are mostly layered and shielded to mitigate this. If you are one of the people that hear sonic changes with firmware changes in Naim products, it’s a similar thing. The actual DSP filter algorithms have not changed it appears since the days of the Naim DAC, however the sequencing, timing execution of the code and processing architecture has and causes a different noise profile depending on the timing of fetching data from memory or writing to a bus and depending on the product. This noise profile when interacting with the DAC/transport clock and analogue circuitry creates a sonic foot print.
In fact Naim had got to know this noise interaction so well for their latest products they could almost get the code execution noise to act as a crude tone control… though apparently, so I was informed, it was not 100% reliable and caught them out sometimes.
I am also an immature student. I will forever more use that quote. .
Thanks again.
I am at college, and immature as far as some aspects of HiFi go.
If a file is native DSD, which dBpoweramp will let you rip too, the processing power used in minimal, but then a whole CD can take up to 5Gb.
If a file is FLAC and Roon converts it to DSD I have found that my NUC CPU is throttled, sometimes over 100% usage, this effects the sound quality to my ears.
The question is do I upgrade my SSD storage device ot the NUC? Something to think about over my summer holidays.
DSD can be interesting if the entire recording and mastering as well as replay chain is DSD… or DSD based, which is quite rare. Much if not most music production has used PCM since the 80s.
Converting PCM to DSD (or vica versa) is a lossy compromised process… I really wouldn’t if high quality is what you are after.
Yes I know Naim do this in their streamers, it’s not ideal, but Naim can optimise the process for their DSP filtering and DAC technology to minimise any artefacts.
My ears tell me something very different, I listen with my ears. If PCM recordings sound worse if converted to DSD, why is/was DSD used for the SACD format?
You are probably noticing the effects of your DAC and it’s filter or even room interaction. But transcoding in a lossy way is never usually recommended.
So sure your setup may benefit from transcoding, but best not assume it’s a general case… but of course no harm in experimenting with transcoding. You can also experiment listening to the performance of your DAC of sending oversampled PCM, that can sound different to.
Yes I use my ears and active listening as well, as well as active listening and why I have come to the conclusion DSD is best with delta sigma DACs… and a full DSD chain.
Though I do have one DAC that sounds quite sweet with DSD… but the sweet spot I find only really works for me on certain DSD masters… which in practice is not many.
My DAC is based around the now discontinued Khandas Toneboard 1, it sounds great playing PCM, but my preference is for DSD.
Upsampling PCM to a rate that is not a multiple of the original recording brings “sillibance” into the equation, at least that was my experience.
How do you do upsampling? There are various hardware and software ways of doing it.
Roon, if a CD rip is upsampled to 176.4Mhz the sound is clean, upsampled to 192Mhz I found sibilance, I think that is why Roon has a upsample rate of ‘Max PCM rate (power of 2)’
I personally would not use any Roon DSP (specially upsampling), it is usually pointless, I would leave the stream lossless as it is.
If you seriously consider upsampling, HQPlayer is probably the best option currently, especially DSD upsampling.
Nice analysis, @Suedkiez ! Another thing I do in these cases is load both tracks in Audacity and subtract one from the other. If you end up with complete silence, the tracks were identical.
True, that would have been easier It was the first time I did this, so I liked learning what flac -a can do, and about the different encoding schemes. I also attempted to try and take the mystery out of it. Nevertheless it’s a bit embarrassing that the simpler solution didn’t occur to me
The other thing to try is using the metaflac command to output the MD5 digest of the (decoded) audio data:
metaflac --show-md5sum *.flac
This is like your sha256sum check in step #8, but in one hit… so it only shows the same digest if the audio is identical (i.e. even down to any silence samples at the start / end of a track).
Steve.
That is, of course, until someone comes up with two different FLAC files, with the same MD5 checksum (which is probably doable but the margin of this message is too narrow to contain my proof for it).
md5 collisions are theoretically possible but still practically impossible unless specifically crafted by reasonably determined actors. Not very likely. But hence my use of sha256
And I love your Fermat reference