Over on the Naim forum the general consensus is to rip to flac uncompressed as this gives the streamer less work to do with a subsequent improvement in sound quality.
Does Roon core do this work before the signal is sent (in my case to squeezebox and airport express) thus allowing compressed flac rips that don’t effect SQ?
SJB
roon does not touch “encode” your files in any way. So if your ripped file is flac it will stay flac, therefore allowing for unaltered SQ (unless I am misreading your question).
But with the current technology and equipment (flac is around for quite some years now), I do not think there will be any audible difference between a compressed flac file or the equivalent file in uncompressed wave. At least I do not hear any difference 
.
Roon sends the decoded PCM or DSD stream to endpoints, thus if you’re in the camp that believes decoding a FLAC file taxes your server and audibly affects ‘SQ’ then you’ve nothing to worry about.
But with the current technology and equipment (flac is around for quite some years now), I do not think there will be any audible difference between a compressed flac file or the equivalent file in uncompressed wave. At least I do not hear any difference
I don’t think @Sloop_John_B is suggesting that FLAC files sound differently than WAV files because the data is different–he is concerned about the impact that the work of decoding a FLAC file might have on sound quality.
For the most part, all of the decoding work happens in the core.
For AirPlay ONLY, we (losslessly) convert to Apple Lossless format before shipping the data to the device. We do this because it is consistent with iTunes behavior, and because our AirPlay implementation would be less reliable than iTunes if we required the (often weak) WiFi chips on those devices to handle 80% more data.
For every other playback mechanism, we send PCM or DSD content directly, so there’s no decoding going on in the endpoint hardware.
Tanks Brian, that’s what I presumed, just wanted to be sure - running out of room on my NAS!
SJB
Just a quick tech note here:
The beauty about the FLAC decoder is that the no matter what the compression ratio is, the decoder does the same amount of work.
The FLAC encoding works (simplified explanation) first by compression of the audio stream using a lossy mechanism, and then comparing the result to the original audio stream. The differences are then compressed (losslessly) and added to the stream.
The decoding works by combining the two.
The encoding process works by finding the best balance between the two. Since this is an iterative process, this is the difference between a small files and larger files of the same stream - in the smaller files the encoder performed more iterations to find the best balance.
So the entire discussion is moot. I would even suggest that larger files make the decoder work harder, since it has to pull more bytes from the stream.
[quote=“Maor_Avni, post:6, topic:8843”]
So the entire discussion is moot. I would even suggest that larger files make the decoder work harder, since it has to pull more bytes from the stream.
[/quote]shhh!!! Audiophools don’t want to hear this kind of dirty talk. The Naim clan and like minded brethren the world over will attack and kill you and your descendants if you persist with this kind of nonsense.
Yep, this “oh noes, my CPU is doing cycles” thing is pure audiophile paranoia.
I wouldn’t mind so much but there are so many people willing to monetise it.
As Joseph Heller might have said;
Just because you’re paranoid…
SJB
{insert analogue effect} of {digital cause}
My treble is noticeably less airy as my CPU hits 30% utilisation.
You lucky bastard, my treble is noticeably less airy when the CPU hits 17.63% utilisation after I’ve sent the kids barefoot to school.
SJB
Sorry about the resurrection.
This thread was referenced at audiophile style where a member was looking for an affirmative only answer to SQ based on FLAC compression levels.
So I learned a few things and wanted to share a quick video on flac encode vs decode times.
I took a 1.17GB wav file and 0 and 8 encoded it with the FLAC command line noted the time it took.
What I learned: Some people are only interested in a subjective echo chamber and true to the developers documentation (which audiophiles lose their literacy skills when asked to read them) the encode/decode is asymmetric. Decode times are identical.
Can you expand upon this. I read this like taking a 100 mile trip makes an engine work harder than a 20 mile trip.
Here’s the wiki.
https://en.wikipedia.org/wiki/FLAC
You can see that decoding times are roughly constant, whatever the compression level used. It can sometimes be the case, depending on the type of music, that a more compressed file is quicker to decode.
FLAC works by trying different compression algorithms, the more time you allow it, the more it tries.
To use your car trip analogy, if you spend more time considering alternative routes it is quite possible you will find a quicker journey.
But this is primarily during encoding. Decoding is the same from what I’ve read in the Dev notes. And it makes sense. You only need to encode once while you will be decoding many.
A better analogy would be a packer working at a warehouse, packing crates according to online orders.
The shippers can pickup a constant number of crates each hour, so there’s no need in packing more crates than that number.
You have two packers. One prefers to pack crates that only have one or two items. The others prefers to pack crates that are filled to the brim.
They each run around the warehouse, picking up the items they need, pack the crate, and repeat, until the hourly quota is met, and then they rest.
Who would work harder?
The warehouse is the computers memory.
The packers are the CPU.
The orders are the flac stream.
The shippers are the audio output device.
Can I be Jeff Bezos? 