Format Conversion / RAAT

It was to my understanding that RAAT ( bit perfect) = PCM transport.
Meaning that if I play a non PCM file like MP3 or FLAC ( level 5) ( ignoring DSD playback ) Roon would always convert it into uncompressed PCM before sending it out to the endpoint.

If I ask Roon to up convert the file the up conversion will be done in PCM
Meaning that a non native PCM file ( example MP3) will be converted into PCM prior to the upsampling.
I always thought that this was how Roon handled things but… I’m starting to doubt myself.

Do I need to reset my brain ?

1 Like

MP3 is MP3, RAAT will deliver it unmolested through your network

Thanks Chris,
If I ask Roon to upconvert a MP3 file from 44.1 to 88.2 will that proces take place while leaving the file compressed ? What does my endpoint see after the upsampling ? MP3 or PCM ?
Do you know ?

You cannot recover lost data from MP3. The process discards up to 90% of the musical information in a way they assume you won’t notice.
If you up sample the files, they may sound better (My Meridian system upsamples all 44.1 /48 KHz signals and apodises) but you cannot regain lost information.

Hi Chris,

While you are correct if for MP3 this makes any sense. I’m not looking a how it would sound but get a better understanding what is happening in Roon under the hood, a look inside the Roon engine.
MP3 is just used as an example.

If I play an MP3 file, it shows as such in my signal chain

Thanks Chris,

If I play MP3 I see

and when I upsample that same file to 88.2 KHz

However I can’t see if it is still MP3 or converted in PCM

Decoding MP3 does indeed produce a PCM stream.

You are mixing music file formats - mp3, flac - with audio transport formats.
Allthe usual file formats are transported in PCM - wav, aiff, DXD, flac, mp3, …
DCF music format is transported in DSD.
Upsampling and DSP are done on the audio transport (frequency, bitrate, …)


I’m going to repeat what @anon90297517 said and expand on it a bit.

@Hans_Bogaert is actually confusing Audio Container vs. Audio Format.

Container - How you store music. Generally this includes the metadata, image, etc. plus the audio (or in the case of something like WAV just the audio on disk).
Audio Format - The Encoded analog audio into a digital format.

Both the Container and the Format are clearly defined independently. Remembering that the container itself is the audio + other stuff. And the format is just the audio.

At the point of D/A conversion you, basically, have 2 options of format: PCM and DSD. One is a multi-bit format and one is a single bit format. All audio formats are a way to get back to PCM or DSD or are directly the PCM or DSD.

All lossy “compressed” CODECs compress PCM into a smaller storage format. This is MP3 in your example. The MP3 encode compresses (by throwing things away it thinks are not important from the analog waveform) the PCM and stores the result. The MP3 starts with a PCM data stream (usually 16/44.1). The MP3 uncompress and decode operation expands the compressed data back to PCM (16/44.1) but the analog waveform does not match the encoded waveform. It’s an “approximation” of the original (because of the stuff that got thrown away). So, MP3 is a container of metadata + the compressed audio waiting to be decoded back to 16/44.1 PCM.

When Roon encounters a MP3 file it first decodes it to 16/44.1 PCM and then hands that bitstream to the transport; in your case RAAT. EDiT: See nice correction by @BrianW below with a link to why Roon will decode at a bit-depth of 24 bits. Thanks for that!

It’s 16/44.1 PCM and it’s “bit-perfect” across the stream (because RAAT is bit-perfect transport) but it’s “bit-perfect” from the decoded PCM and that is absolutely not bit-perfect to the original PCM which was used to encode the mp3.

This is not the case for something like Cast or Airplay. Both Cast and Airplay re-encode the PCM to 16/44.1 specifically for the stream / transport. In that case the streaming protocol itself is said to not be bit-perfect (the PCM that arrives at the DAC can be different than the decode of the file).

So few things based on your signal path:
Roon shows you the bitrate of the MP3. The bitrate of the MP3 impacts the amount of data that gets stored and influences how close the “approximation” will be to the original PCM. Higher bitrate, less thrown away, closer approximation. This is why 384k MP3s sound much better than 128k.

You can upsample just fine, it’s upsampling the decoded PCM from the MP3. The 16/44.1 (or 24/44.1 it looks like in your case)

And, to directly answer your question, PCM by definition is not “compressed”. It’s very simply a string of 1’s and 0’s representing a bit depth and sample rate. Whatever RAAT does it maintains the PCM data stream across the network so that data stream is unharmed when handed to the DAC (via SPDIF, USB, etc.). When using RAAT, Roon will always take the original container, extract the PCM (ignore DSD for now), and send it as is across the network. So, no, it’s not being “converted” it’s being decoded. That’s the DEC part of Code / Decode in CODEC. Once you have the PCM you can upsample to whatever bit depth and resolution you want. What’s actually occurring to add those additional bits and sample resolution is a bit (pun unintended) beyond the scope… and… maybe another time.


Just one minor quibble - Roon will endeavour to decode to 24 bits, see here

1 Like

Sounds like a great Saturday topic. ;D

To explain it simply. Any DAC regardless of what it is can only handle pcm or dsd data. Therefore all systems somewhere in the chain need to decode to these formats. Roon does it upfront for compatbility reasons not all devices support certain containers so converting to native pcm gets around this and it’s in the native format the DAC needs so less work for the playback device to do other than pass on the stream to the DAC.

Thanks everyone for stepping in and sharing your knowledge !
This line below expresses that what I thought was correct.

“When Roon encounters a MP3 file it first decodes it to 16/44.1 PCM and then hands that bitstream to the transport; in your case RAAT.”

I convert convert that into :
My DAC doesn’t receive the MP3 encoded track because MP3 decoding was done inside ROON.
a PCM stream is transmitted to my DAC using RAAT
MP3 can be replaced by any other codec ( like FLAC, AAC, etc)

is that a good summary ?

Good, yes you’ve summarized it well.

I’ll get super geeky here and say that this may or may not be accurate. RAAT isn’t “open source” and nothing is published about the encode / decode. Therefore we don’t know exactly what RAAT is transporting, what bits are hitting the wire, from source to destination (it could be the raw PCM, it could be DSD, it could be the PCM encoded as wizardry and fireballs). All we know, and all we care about as users, is that the PCM bitstream used to encode for transport via RAAT is the same PCM bitstream that comes out and is fed to the DAC at the destination. We know this is happening because there are a few DACs that allow you to test for “bit perfect” by playing specific test files and those DACs pass the test when tested.

1 Like

Well, not to throw in super side edge cases, but, in terms of Squeezebox playback, you CAN set Roon to send the unprocessed FLAC and not PCM. :wink:

ok , let me go to root cause for dropping my question on the forum.

is anyone familiar with the Linn Climax DS DAC ?
I don’t have one but a friend of mine does. He recently became member of the Roon family and his DAC shows on the display FLAC when playing FLAC, WAV when playing WAV and MP3 when playing MP3. (using Roon) And therefore convinced that Roon doesn’t do any decoding.
To me that sounds strange for I always thought RAAT was based on PCM as transport ?

It would be better if you started with the exact case because:

Linn, like my Squeezebox example, is another edge case.

oeps, sorry about that.
I thought that Roon was a generic protocol.

I have learned from all your feedback and it help me to understand Roon better !

Are they? Or does Roon simply use a protocol other than R.A.A.T. to stream to them?