It could be there is mqa bit depth metadata inside the file that is set to 24bit regardless of the file is originally 16bit or a 16bit file exported as 24bit flac (that pink floyd album was 24/44.1 before). the core decoder upsample it (44.1 to 88.2) and use the bit depth metadata to display as 24bit/88.2.
you can export a 16bit to 24bit and the file size is approximately the same, there is a difference in sound quality - the 24bit is a little smoother. (very subtle).
The core decoder doesn’t do upsampling. It just unfolds, assuming there is high res data.
The size in MB of a 24b file and 16b file are very different. If you’re seeing the same size in MB and you can calculate that the expected sizes (MB or Mbps) for the two data rates match what you’re seeing, then it’s likely that the 16b file is zero-filled to 24.
I think it would be more correct to say that the core decoder decodes to MQA Core, which is 2x the sample rate of the delivered MQA, and it does this for *all* 1x (delivery) rate MQA. I don’t know exactly what is happening in the case of 44.1/16 (and 44.1/24) original sample rate material.
Am I missing something, in my image the version is CD , in the other image it’s clearly says MQA
My account is good for MQA but this example doesn’t have an MQA version
Am I missing the point somewhere?
My 16-bit MQA compact discs do “unfold” beyond redbook.
Hi Joel,
I’m going by Bob Stuart’s new blog write-up on 16 bit files and the overall topic of Provenance and Containers. He says:
When the input is PCM, the output stream will have the same bit-depth as the input unless either a) Origami is used or b) the input is DSD or floating-point; in these cases, the MQA stream output will always be 24 bit. So an original at 44.1 kHz/24b will create a 24b file and 44.1kHz/16b will create a 16b file. However an original of 96kHz/16b) will generate a 48kHz/24b MQA file because Origami was used. [1]
In other words, you get decoding (unfolding) only when there is origami, i.e. when high res data exists and has been packed.
The links for the write-ups are here and appear to be an attempt to clarify these various file types. They are worth reading. If there are still questions on the intermediate steps for a 44.1/16b file before it is sent to a DAC, it might be worth asking MQALtd.
16b MQA compact discs actually are different. They do contain some form of high res material (unlike the redbook albums from Warner that were just released on Tidal, which were always CD masters.) I don’t believe the 16b packing of high res is available anywhere except on actual discs, which I believe are mostly sold in Asia. This is also discussed in Bob Stuart’s write-up. MQA is getting to be a complex subject.
Bob Stuart is referring to MQA encoding, i.e. generating files. Decoding is a different story.
AJ
Also available here in the U.S. from Chesky Records, for example.
Yes, I’ve read these. I found them very useful actually.
Agreed.
Decoding ≠ unfolding, but decoding can involve unfolding.
I’m going by what sounds good to me. Nothing else matters. I recently paid another year for both Tidal and Qobuz. I might drop Qobuz next year because I don’t really need both.
It must be.
I just noticed that after any MQA file in Roon, it’s the original encoded rate.
Under is listed all possible options. I hope.
Under Signal path, all those MQA original encoded numbers, is also showing up with same number under Authentication, which is correct.
(The 16 bit file will not show studio. The 4 others will).
Also illustrated with one example under.
So useful that you agree there is an error in Roon ?
Your point is that there is regional differences. Which seems to be correct.
We’re discussing an error in Roon core decoder that displays something that can’t be correct.
This may be checked by someone if Audirvana have same issue. Or by using a MQA DAC doing all decoding.
If DAC’s doesn’t unfold Tracy Chapman, Pink Floyd, and Donald Fagan, (as examples), I would consider this as a prove that Roon signal path is displaying wrong information. As indicated, both decoded and encoded information is displayed in Roon under the album.
Absolutely not.
Seriously, could you please respond to the question posed?
Is Roon mislabelling in the Signal path when playing back MQA Authenticated content at 44.1/48Khz?
Or is Roon “unpacking/unfolding/expanding/upsampling” this content to 88.2/96Khz, thus breaching the MQA agreement?
Sheesh. That is a false dichotomy. And the second option is a loaded question.
Try a third option.
The answer is obvious, has been plain for everyone to see for years now in the Roon Signal Path, and has been stated several times already. Regardless of bit depth or ORFS, MQA Core Decoder always outputs at 88.2 kHz or 96 kHz. This is part and parcel to MQA. Roon did not design the Core Decoder – MQA did.
So, if you have issue with MQA Core Decoder 2x upsampling on 44.1 kHz and 48 kHz ORFS content, take it up with MQA. Roon is just sticking to its commitment to transparency and pulling back the curtain a bit to reveal the inner workings of an otherwise obfuscated proprietary process.
AJ
Can I have an explanation of what Bob actually is saying here. Is this error he’s talking about, the same error I’m talking about ?
——————————————
More on Provenance
So we see that Provenance is secure because the audio in an MQA file will not decode if it is changed.
But there is one harmless way it can be changed and that is if a 16b MQA stream is extended to 24b by the addition of zeros to the bottom 8 bit s. The zeros contain no information and the MQA decoder will ignore them.
There is no benefit to this word-width extension, but it can happen benignly and automatically if a 16b MQA stream is passed over a 24-bit link such as SPDIF/optical or HDMI. 16-bit MQA goes in, 24 PCM bits come out, but the audio information in the top 16-bits is not changed – and that is all we care about .
Of course, if the MQA starts out as 24b, then there is no useful scenario for altering the word-width in this way (except as provided for compatibility) – see blog about playback and MQA-CD.
It is possible for a 16b FLAC file to be opened (for example to add a seek table) and then saved (in error) as a 24b container. When that happens, the audio is zero-extended, just as described above for SPDIF. Such a file would then indicate to the outside that it is a 24b container and normally, we would expect it to contain 24 bits of significant data. Still, FLAC will detect the zeros and compress down to basically the same size as the 16-bit – as it should because the information content is identical (except for the seek table header).
Streaming 16b MQA
Recently, as we have rolled out many more MQA files sourced from 44.1 kHz 16b masters – where we expect the MQA file to be 16b – this FLAC mishandling occasionally happened while adding seek tables and some listeners have been confused about the bit-depth indication on their players. However, in this case, whether the streamed FLAC is 16b or 24b, the audio is identical – as we know from the MQA indicator.
Because there was a process to tidy up that error, some contents might appear to change between 16b and 24b, but it has no significance.
You can try it yourself take a 16bit flac. Open it in Audacity and Export it as 24bit.
200 posts in, in yet another thread dedicated to figuring out what MQA does and does not… Nothing, whatsoever, is clear about this apparition of a format.Or it’s purpose and need for that matter…
