Of course, that may just be some problem with two different execution paths in JRiver, rather than being due to some intrinsic difference between the two formats. Have to devise another experiment to settle that.
Roon decodes all formats to LPCM before sending it on so your never getting flac or wav at all via Roon to your device it gets the pure lossless PCM data , canāt see what difference this would make at all.
welll, as I said in my post, I experimented a lot with WAV and FLAC following 2 pathsā¦ 1) ripping a CD in both formats, as said, same player, same machine, same softā¦ played both of them in my highly tunned Roon system and differences were evidentā¦ 2) and much more interesting, took a good sounding FLAC decoded it into WAV using a program that runs the algorithm that converts WAV to FLAC to reverse the processā¦ and yes, played in JRiver and in Roon, the resulting WAV sounded clerly betterā¦ so there you are, try it yourselfā¦
Sorry, I misunderstood. I thought you were only playing this with JRiver.
As for trying it myself, well, I usually only try these things if I can see some reason why it should be so, which in this case I canāt, soā¦
It would help me understand the assertions youāre making if you clarified the following:
-
Are you asserting that the transformation from WAV ā FLAC followed by the transformation from FLAC ā WAV ā PCM results in a change in the bitstream such that the rendering device sees something other than exactly the same bits that would have been seen if WAV were played directly?
-
Are you asserting that the process of converting FLAC ā WAV itself has some side effect on electronics such that having the CPU doing the computational work makes the noise coming out of the device sound different?
I ask this because these are very different.
In the case of the first, that should be simply provable or dis-provable by using tools to roundtrip the data and then compare. I donāt know about other folks here but I certainly did those tests many years ago which first switching from storing WAV to FLAC. This was literally 20 years ago for me and the tests were conclusive.
In the case of the second, as @CrystalGipsy points out, transformations in Roon happen at the core, not on the playback device. I donāt see how playback electronics could be impacted.
I might be missing something.
none of thatā¦ Iām saying that if instead of forcing the playback unit to process, IN REAL TIME,
TWO tasks (decode and convert to analog), you give it only 1 task (convert to analog), the simpler process is much more likely to hurt timing lessā¦ and we all know what digital sound is about " time & silence" (actually two sides of the same coinā¦
Thats what Roon does it sends native LPCM which is what DAC need to do a D2A conversion. There is no conversion on the device with Roon its done before hand so no extra processing on device
yetā¦ somewhare the FLAC must be decodedā¦ and if the file is not preloaded, pre decoded, somewhere, then the decoding task is passed to streamer (which is bad) or to the DAC (which id worst)ā¦
Canāt we put this topic to bed?
ā¦if you look around the Internet at the various audiophile forums, you hear from all kinds of folks how uncompressed formats like WAV and AIFF āsound betterā than the lossless compressed formats like FLACā¦
So he put it to the test:
And this is from ten years ago!
He maybe suggesting FLAC has to be uncompressed first, then decoded, whereas WAV/AIFF requires no decompression, so one less step, dunno
Yes, but the FLAC decompression happens far, far away from the endpoint when using RAAT. The endpoint has no idea about this and there is no known mechanism how it could be influenced by it.
Does it matter if a WAV was once a FLAC and was decoded back to WAV a month ago on a computer in a data center 5,000 km away?
(Now Iām concerned that someone will say yes)
There was a guy a few years ago writing in one of the more extreme audiophool magazines that said the operating system of the computer that made the original rip (Windows, Mac, Linux, etc.) had an impact on the ultimate sound quality. He said this was true, even for WAV/PCM files from different ripping machines, that were determined after the fact to be bit perfect copies of each other and played on many other different machines. Of course, given the magazineās audience, arguments regarding the impossibility of this having any impact fell on deaf ears (pun intended).
I once read that replacing the artwork with black jpg sounds better than the original or white. There is no end to the madness
On going thread on Naims forum how itās claimed Melco rips sound better, some claiming a linear psu makes a difference itās hilarious.
I poked my nose into the Naim forum again just a few days ago after my long absence, and I found that thread right away.
Yep the place is just full of nonsense these days I hardly post anything, itās all switches and Ethernet bs.
Frenchrooster and the others got their wish, I guess, to be left alone
that is not what I am talking aboutā¦
How can that be the case? You wrote:
FLAC is decoded on the Core. LPCM is sent, over the network assuming your core is connected via ethernet and not USB or HDMI, to your streamer.
Multiple people are telling you that the decoding task is not āpassed to streamerā or DAC. Itās done upstream. So itās not clear what your concern is.
[Thereās some irony here. I believe some of us think RAAT might be better off if the data stream between core and endpoint actually was compressed. I wonder the extent to which assertions like the ones being made here about decompression impacting sound quality come into play in internal Roon conversations about RAAT evolution. I donāt mean that theyāre sitting around saying āIf we decompressed on the client, sound quality would tank.ā I mean that they might be sitting around saying āWeād have a hard time messaging this change even though WiFi, including mobile device, connection would be a lot more reliable.ā If I were them, Iād just sneak it into places like FiiOās recent Roon Ready implementation and bet that nobody would notice ]