Yes that link indeed seems accurately mentioning:
- full decoding: first unfold (device is including license 50 euro by MQA corp) + rendering
- rendering for final unfold: rendering ONLY (no license for first unfold; this means that files will play for example 48khz 24 bit, but without the lossy MQA part added. I.m.h.o. sounds quite good anyway because the 24 bit holds most important lossless data).
About incorrect data on the MQA site, I was referring to their page:
Playback Devices | Unlock Studio-Quality Sound of MQA | MQA,
where it says “MQA-enabled Digital Audio Converters provide full decoding for the highest possible sound quality”.
It should say: DAC’s that can either:
- render previously unfolded MQA;
- or otherwise immediately unfold (decode) and render MQA.
Or better even split the category. At least on their generic device introduction page they should avoid the terminology “fully decode” in order to prevent any confusion. Because in the detailed device pages they use this term full decoding only for devices that have the “first unfold” license. This way it is appropriately distinguishing from “rendering only” devices.
Don’t you think?
The vagueness happens probably because of marketing reasons: no manufacturer wants to name their device: “MQA rendering ONLY”, as it seems like you are buying a not so great product.
Now you see some manufacters start to talk about:
last unfold, or 4x MQA/ 16 MQA (SMSL e.g.). While the MQA docs talk about “expand” once, twice or third time. Expand once is equal to first unfold. The “full decoding” devices can do a complete first, twice and third unfold. Then “renderer only” devices: most can do twice and third, but it seems some smaller devices can do only twice. I think this is what SMSL calls “4x MQA”.
I think it would have been better if MQA had prescribed conventional naming with clear definitions. And some examples of expected applications with an explanation. Like “some low powered smaller devices can still have a good level of sound using MQA twice unfold. The higher powered gear. Desktop DAC should be fully decoding only.” And say more about the fact that even without any MQA decoding it still sounds awesome, so people will be less hesitant to start using MQA enabled services like Tidal. It doesn’t hurt and you are not locked into MQA once you start using this service.
P.s. I
In fact with greater bandwidth now other hi-res (non-MQA) services (like Qobuz and Highresaudio) will also gain more market volume.
Then you also have this new UAT (and LDAC) bluetooth bandwidth, so you could stream high-res from your UAT/LDAC enabled phone or devices like Hiby. Hiby devices seem able to transport over UAT/LDAC Bluetooth with their own Hiby link (while using the Tidal app for first unfold) to Hiby link enabled DAC’s. What is not clear to me is if you still need the proprietary “connect” (Tidal connect e.g.) or is this obsolote in case of UAT?
Has anyone experience with these Hiby devices linked to Hiby link (over UAT) enabled gear (like SMSL US-9 or M500 e.g.)?
Another question: is this transport jitter free? Does it keep the MQA data untouched for full unfold or does it send first unfolded to an MQA renderer? Or does the Hiby device fully unfold and then send lossy data over UAT?
Otherwise the Tidal app on mobile devices in Master mode can do a first unfold to an external “rendering only” USB/Lightning (for Android/Apple) connected DAC (for desktop models through USB B and for newer models A) for further full unfold. However it may introduce some jitter and/or noise problems depending on your mobile device outlet and DAC USB input quality? It is unclear to me if there is “jitter issues” when the first unfold is done on another device than the final unfold renderer. I could not find anything in the MQA documentation on this. I suspect there can be an issue.
If you want to send the music wirelessly by Volumio to a Raspberry or Odroid and connect the USB DAC to this device you will have wireless bitperfect MQA, is my understanding. (See also here:
MQA with authenticated DAC and RPi - MyVolumio / MyVolumio Help and Support - Volumio.) as long as you use a full decoder DAC (not just a MQA renderer). The first unfold is in this case done by the last device in the chain: the USB DAC. Next to convenience I understand this has also benefits of transport control (jitter free).
But then again: I wonder even when the transport is not controlled in the way an MQA full decode (and/or Roon) does for example, how much jitter will even possibly show up with UAT/LDAC? Bluetooth is not lossless, but because there is minimal compression needed and hardly bandwidth restrictions it may be comparable to full MQA for sound quality anyway (if it is not already because of some MQA transport control does actually apply on UAT?).
Roon (which I am using too now) includes both hi-res and MQA and has for both the advantage of transport control (RAAT), so jitter is (almost?) absent. It is technically unclear to me whether or not an MQA final unfold has the same transport control as Roon. Anyone here can explain?
I do not see much benefits from Roon anymore if MQA can do this transport control wirelessly (via Volumio Tidal Connect e.g.) or virtually or completely (if transport control existst) absent by UAT (over Hiby link or another direct Bluetooth link) within my own network. I am not considering now the other benefits like their great Roon app layout, radio and seemless integrated access to NAS stored files. I think Roon RAAT covers all transport challenges, but is way too expensive and unfortunately always needs a Core device somewhere in the home netwerk (on your NAS or Raspberry e.g.), which prevents the so much desired mobile benefits “on the road”.
P.s. II: sorry for the long read. I edited to try and make the questions I still have more clear. 