I have a wild speculation that a “Big Surprise” to be included with the release of ROCK is a full-resolution software MQA decode.
Hear me out.
From what I can infer, one of the primary reasons MQA likely does not like full software software decoding is to prevent clever users from sending the fully decoded stream to some kind of virtual sound card for saving the PCM studio master file. With only partial decoding, MQA can maintain their assurances to the content owners that end users can “hear” the file at full studio resolution, but never actually possess the decoded studio master data.
Since ROCK is a fully closed OS (unlike running RoonServer on Ubuntu on your NUC), and passes audio data to the endpoint over the fully closed RAAT protocol, Roon can certify to MQA (and thus to the content owners) that users cannot surreptitiously intercept the fully decoded data on its way to the DAC. Just a thought (in no way seeking unauthorized hints)!
P.S. I have precisely zero insider knowledge about this or any other Roon-related information. PLEASE don’t misconstrue this as anything promised, hinted, or implied by the awesome Roon development team.
Sorry to burst your balloon, but the decoded stream could be captured on any Roon endpoint with open source OS and drivers. In particular, the widely used Linux ALSA driver has a flexible plugin architecture that should make it easy to duplicate the PCM stream going to the DAC.
I’m certainly no Linux expert, but RAAT still has the ability to detect the DAC at the end of the chain. For example, the Roon Signal Path sees my IQaudIO DAC+ even though the RPi endpoint uses Linux ALSA. It would be trivial for ROCK to limit software MQA decoding to the first unfold if a Roon Tested DAC is not detected at the end of the path. (Surely the cute line are isn’t purely for show.) That is a key difference with trying to implement a similar MQA certification with software using OpenHome/DLNA/etc protocols. For better or worse (mostly better), we’ve bought into the Roon-controlled ecosystem.
At any rate, arguing angels on the head of a pin quickly becomes counterproductive, and maybe it’s best for the thread to be locked. We’ll all know the answer in a month (or two, or three, or…). Until then, back to the music.
Interesting ! I’ve been thinking of what this surprise could be and I like this one.
The other thing I thought of was ROCK’s OS would allow attaching an external CD drive to the NUC and have built in CD ripping… Vortexbox has had a music server OS and CD ripper for years. Not sure how popular this would be today though.
It would certainly explain the delay, in terms of the additional development for the decoding, permissions on the endpoint on the signal path re. The level of decoding, the proving to MQA & partnership, and the desire to co-ordinate releases with market event over just “a custom Linux distribution and existing Roon Core software”.
This would certainly be an interesting development. It would make full MQA available for the technically capable DIY system builder, re taking a off-the-shelf NUC building it as the server, and then partnering with a RaaT end-point & DAC, which will be broader than the hardware approved program.
Also if the end-point wasn’t a Roon certified DAC would there be the first level of decoding to 24/96?
Simon
Roon certification is not enough for full MQA decode. The DAC has to be known by MQA. And I mean intimately. Which is why some of the more accomplished DAC manufacturers are choosing not to go the way of MQA and having to share their code in the process. If MQA are happy with a less intimate relationship with the hardware then this might be a something that might happen. But nothing that has been said so far by MQA suggests they will relinquish that need to know the end DAC. Plus there is that requirement not to expose anything decoded via SPDIF etc. So ROCK will need to be very secure and work via USB only. If you are bridging, RoonBridge will need to be more secure too. As a result I think the best we can hope for is a partial decode plus into a USB DAC.The plus might be full resolution unfold.
Whilst I know nothing about MQA in ROCK it appears that the MQA people are possibly taking a less rigid view on the decoding. PS Audio are reportedly putting full MQA decoding into the Bridges of their DS DAC’s which is a bit of a surprise as this would be outside of the DAC itself.
James_I
(The truth is out there but not necessarily here)
11
I don’t see full software decode ever – I have a pretty strong feeling that one motivation of MQA is DRM. Sure, it is also a method of delivering what many consider high quality sound, but really, it has to be that some of the interest from the record companies is based on DRM. Yes, I’m jaded…
The speculation is tasty. As I recall, one of the reasons cited for the delay that prevented ROCK from being released at the same time as 1.3 had to do with hardware manufacturer partners. I cannot speak intelligently about MQA’s technical aspects, but it seems like the decoding/unfolding could easily be limited to two “secure” situations: 1) when the DAC is recognized as MQA capable, and 2) when the ROCK device is the Endpoint. Would that address the concerns about intercepting the MQA decoded signal?
For the full end-to-end process, this is certainly true. However, we also know there is a “generic DAC profile” used for already announced cases of the first MQA unfold in software. If the DAC is not intimately known, it is conceivable that the generic profile could be used for the second unfolding step. I don’t care to speculate what percentage of the ideal performance that would leave on the table.
Of course, if one already owns a fully MQA certified DAC, this can be connected to the RoonBridge endpoint (or core) as usual, and software decoding would be unnecessary (unless one desired to apply other DSP like room correction after decoding).
Leaving aside whether this is formally true, software decoding in a fully closed software environment would preserve any DRM-like properties. The end user never “sees” the decoded bits (they cannot be saved), but only hears them decoded on the fly during playback. I agree that MQA would never allow you to transcode MQA to PCM FLAC (or other format), which would permanently unlock the original data.
Don’t forget that ROCK is actually a DIY spinout of RoonOS, which is to be licensed to other OEMs. It is conceivable that some of these OEMs might consider MQA to be quite valuable (even if only from a feature checklist point of view).
Again, from my original post:
Given how quickly speculations about either ROCK or MQA can get out of hand on this forum, perhaps it is most prudent for @moderators to close the topic. Any future Roon features (whether or not dreamt in my philosophy) will arrive in due time, and patience is a virtue.
