Thx @danny We shall be patient then!
Sorry about the MQA rehash above, somehow saw that post and I have developed a habit (nervous tick?) to respond to anything MQA.
I shall crawl back in my cave now…
Original topic for this thread was “Will Roon support MQA first-unfold”?
Answer : Yes.
Additionally, it’ll be done at no extra charge.
Hasn’t this thread run its course?
7 Likes
It will be interesting to compare quality across an MQA DAC versus the Roon unfold…
+1
Could we close all MQA related threads until it is announced? At present, Roon has nothing to do with MQA except as a pass-through. That should be the only allowed discussion.
I still fail to understand why we need Roon to do the first unfold…
As Roon already passes through MQA for the MQA-compatible DAC to unfold, why do we even need Roon to do the first MQA unfold? We’ll need a MQA-capable DAC anyway, with or without Roon doing the first unfold.
What am I missing here?
I have two MQA-compatible DACs currently, and both of them display MQA mark / logo when playing Tidal MQA via Roon
Why stifle expression? People say we can just ignore MQA. That most certainly applies to threads discussing it.
Good discussion. Why shut it down. You want “question-answer-close thread” everywhere? That is not a community. Just don’t enter the thread if you’re not interested! Many are interested.
1 Like
Plus there are other topics to talk about that have nothing to do with first-unfold in Roon, like:
1- MQA tagging / filtering of albums in Roon
2- Using such tags, disable DSP in Roon when MQA file is playing
3- Whether files are not MQA-decoding when reaching a full-decoding DAC
4- Sound comparisons between MQA and non-MQA versions with a full-decoding DAC
Not so, see the diagram below, the famous ‘triangle’…if there’s any information in the ultrasonic range, it will be buried in the noise floor. Assuming we take 48k multiple sampling:
In area ‘A’ (0-24k), ~15 bit sampled at 48k (Shannon-Nyquist sampling)
In area ‘B’ (24k-48k) and ‘C’ (48k-96k) ~7 bit sampled at 48kHz (Non Shannon-Nyquist sampling).
‘A’ +’B’ equals to 96kHz sampling (first unfold) plus the ‘C’ equal to 192kHz sampling (second unfold).
In a scenario where there’s no ‘B’ and ‘C’ then the upper 7 bit can combine with ‘A’ (15 bit) and this gives the claimed ‘24 bit’. At this instance MQA is behaving like a ‘lossless’ when compared to a PCM 24 bit/48kHz FLAC.
The effect of doing Non Shannon-Nyquist sampling as I mentioned earlier on, this will give rise to aliasing components but this is minimised, not eliminated due to the fact there’s very little information in ‘B’ and ‘C’.
Sounds like four new threads should be started. 
1 Like
C region is in fact up-sampling, no? Thus no “real” info in the first place, thus nothing “restored”?
1 Like
No sorry, there is no real information after the first unfold (which gets you to 96KHz sampling rate). The remainder information is “guessed” by an upsampling filter.
Think about what the renderer like the Dragonfly is doing: It receives a first-unfolded 96KHz signal and all it does is upsample it to 384KHz (that’s the output rate of it’s ESS DAC) using an MQA-specified upsampling filter. The MQA update in the DF only touched the controller, not the DAC.
There’s a ‘7 bit sampling at 48kHz’ spans in the region from ‘B’ and ‘C’ using Non Shannon-Nyquist sampling. if there are very small amount of information, it can still be captured. So ‘C’ is not actually ‘up-sampling’ as I thought was in the beginning.
Like I said, think about what the Dragonfly is doing - there’s nothing other than guessampling past 96KHz sample rate / 48KHz audio freq.
MQA uses Non Shannon Nyquist sampling in from ‘B’ to ‘C’, technically it is not up-sampling. The graph stops at 96k bandwidth, so I assumed anything thing above 192k sampling may be just ‘up-sampling’ example, 384k
Ok, one more time… The ESS DAC is getting a 96KHz stream and is doing NOTHING it didn’t do before MQA existed. All that is happening is a particular min phase filter is used to upsample.
BTW, Audioquest’s Gordon Rankin confirmed the ESS DAC is untouched in the update, and that all that happens is the filters are selected.
The ‘96kHz streams’ contains some information in both ‘B’ (96k) and ‘C’ (192k). If the dragonfly DAC chip can only accept 96k, then only ‘A’+’B’ will be able to produce, ‘C’ will only come about if the DAC is capable of doing 192k. I think we need to understand what is Non Shannon-Nyquist sampling is all about.
So a " Non Shannon-Nyquist sampling" is claimed (based on that diagram? which I assume is from MQA themselves?) which in plain terms is a lossy algorithmic encoding (i.e. what AAC, MP3, etc. does) no?
It was some time ago I read the white paper published by MQA and they did mention about Non Shannon-Nyquist sampling.
Yes, Non Shannon-Nyquist cannot fully recover all the available information. Another artifact is it give rise to aliasing components.
Guys, distinguish between encoding and rendering. Both/all of you are correct. Encoding is non Shannon sampling; rendering is upsampling.
AJ