Yep, I wonder if that’s part of the neuroscience that Bob mentions in all the interviews - that warm fuzzy feeling you get with the MQA confirmation light.
I don’t mean that in a negative way too - I used to get that warm fuzzy feeling when I’d see the DTS indicator come on with my CD player with DTS 5.1 CD’s. Good times lol.
Yes, it does. Try converting MQA FLAC to WAV, MQA decoding is defeated, you only see 24bit 44.1kHz WAV. If you take the WAV file and convert back to FLAC, you only see 24bit 44.1kHz FLAC. If this process is bit perfect and lossless, than it should retain the necessary information for the decoder to work. My guess is there is some embedded meta data and flags not port over when converting from MQA FLAC to WAV. Anyone can try this simple experiment, let me know what you think.
What certified MQA decoder are you using to test? (Auralic non-licensed MQA decoder does not count.)
If you don’t have certified MQA hardware, you can use Audirvana.
If you don’t believe me, read another user’s test here:
Edit: Lumin players also work, if that’s not obvious. It is possible for incorrectly implemented MQA decoder to fail bit-perfect conversion. In that case, please notify the manufacturer.
The light helps users confirm their playback chain is not accidentally destroying MQA integrity via any digital volume or OS mixer (e.g. Windows).
But any other manipulation of the stream will affect MQA decoding? Such as convolution or PEQ?
That’s why I suggest re-inserting the MQA flag before the stream is sent to the DAC. Is there another way to achieve this? MQA+convolution++ and correct second state decoding in a MQA enabled DAC?
That’s true also, like the indicators we have with the Roon Signal Path.
And that can be an important thing. The Roon Signal Path performs a similar function.
So if we could take the MQA lights and shift them back in the signal path to a point just prior to user DSP in the Roon Signal Path then that might satisfy the user and MQA, but the DAC licensee could be unhappy …
The problem is that at the input of the DAC you can either be authentic (as defined by MQA) or have the DSP you choose, but not both. Personally my appetite for bit perfect authenticity runs out immediately prior to any DSP that I choose to implement. It’s hard for me to understand the mindset of someone who might be upset at the loss of their MQA lights, particularly if they were to appear in the Roon Signal Path but I suspect they exist and that MQA is concerned about them.
My mention of MQA lights in the Roon Signal Path is pure speculation on my part. I have no knowledge as to whether Roon and MQA have discussed that, it just seems logical.
The only official answer I’ve read is from A65 of MQA Q&A in CA forum.
My understanding is that room correction can only happen to MQA Core (after the first unfold), not before any MQA decoding, and not after the MQA rendering, and that room correction DSP needs to be MQA-aware. This way the feed to MQA Renderer is still MQA compliant.
Whether or when we’ll see a product that supports room correction that fits the MQA model, I don’t know.
The loss of MQA light at the DAC would imply (1) loss of folded hi-res musical content (unless it’s already been unfolded by Roon or something else before the DAC) and (2) not engaging the DAC-side de-blurring provided by MQA Full Decoder or Renderer.
J[quote=“MusicEar, post:264, topic:26336”]
Yes, it does. Try converting MQA FLAC to WAV, MQA decoding is defeated, you only see 24bit 44.1kHz WAV. If you take the WAV file and convert back to FLAC, you only see 24bit 44.1kHz FLAC. If this process is bit perfect and lossless, than it should retain the necessary information for the decoder to work. My guess is there is some embedded meta data and flags not port over when converting from MQA FLAC to WAV. Anyone can try this simple experiment, let me know what you think.
[/quote]
Ah good point on the metadata. Prob that. Wav doesn’t really support metadata.
Hi @wklie,
Please see below:
The first two files are actually converted using JRiver from 2L ‘Et Misericordia’ under the album Magnificat. Roon didn’t detect the files as MQA, somehow, I suspect the embedded meta data and flag are missing during the convert from MQA FLAC to WAV or ALAC despite the process is bit-perfect and lossless. These are detected as 24bit 44.1kHz files
When/If Roon adds MQA decoding, let’s retest this again.
Are they recognized as MQA material by your MQA-aware DAC? I Think the MQA designation you see on the last song is purely metadata-related. However, that should be of less interest to the DAC…
What about this:
I’ve to borrow from my colleague a Mytek Brookyn DAC to see if it actually does decode back. I will post back again.
Indeed! I am also looking at the graph in A65 on the CA forum. When you say “…room correction DSP needs to be MQA-aware” that is what I mean when I say “re-inserting the MQA flag”. The point is that if the content is, say, 384kHz only a DAC can decode this. The first ‘unfold’ is limited to 96kHz if I understand this correctly. Roon’s DSP will receive the first unfold at 88.2 or 96kHz and pass this to the renderer with the MQA code after processing .
The initial version of MQA detector used in Build 242 was buggy, and I guess it is not the same thing as the regular MQA decoder.
I am sure that the regular decoder will decode MQA in FLAC / AIFF / WAV / Apple Lossless because I tested all these formats.
I don’t have an MQA DAC, yet. May pass on one altogethr and haven’t tried Audirvana.
So a few months ago MQA unfolding was 87th on the list of priorities for Roon. (I know that’s not really true, but Danny’s wholehearted endorsement of AndersVinberg’s comment above does say something about the state of things.) Hoping it’s at least moved up some on the list, maybe even to single digits?
It’s not that I’m unhappy with recent developments but honestly even a potential increase in sound quality is always going to be near the top of my wish list.
We are still deep in licensing talks with MQA. This has gotten complicated because we are a multizone software streamer with a subscription license and can already stream to a multitude of Roon Ready devices that support MQA already. … and DSP.
No ETA.
I’m an IP/media lawyer, and I’m sure these licensing discussions are very challenging for both sides.
If I were Meridian/MQA right now, at this early stage of MQA adoption, I would want to preserve end-to-end control over the rendering process and there is no way I’d let any decoding process fail to light up those DAC lights. You’re blowing your whole DAC licensing model right there if you let that happen. And I doubt Meridian/MQA would ever give out to a software developer the ability to re-load encrypted flags after any sort of signal processing.
Roon has already developed itself past some of these limitations. DSP is a great example: it appears there has been huge adoption within the Roon user community. DSP will go off when an MQA track comes on, I’m sure, and Roon may be concerned about that. I’ll bet that Meridian is even concerned about MQA rendering into HQPlayer. Crossfade might even violate the MQA license terms, who knows?
I never really thought about it before, but there must be some significant tension between Roon’s desire to include MQA decoded files with the same capabilities as all other tracks and Meridian’s regulated model for MQA usage. Some of these issues may abate as MQA matures or when MQA starts to lose revenue because they don’t allow it.
I don’t envy Roon’s counsel this task.
