Well the details of MQA are still very unclear, but my understanding is the same as Miguel above, i.e. MQA software decoding will sound the same as hardware decoding if the software decoder is allowed to render to the studio native rate and your DAC support this rate. And MQA is more about avoiding impact of DAC implementation by upsampling to a high rate (see below how I understand the process from reading the MQA paper and patent applications). Please correct me if I am wrong.
Example how I understand MQA works: 384kHz/24bit studio master encoded into 48kHz/24bit MQA file by downsampling using a track-specific filter-kernel (lossy-folding) to 96kHz/24bits dithered and truncated to 96kHz/16bits (at most) and then compressed into a 48kHz/24bit container (lossless folding). For a software decoder I imagine this will happen:
Played at 48kHz/24bit sounds like 48kHz/16bit “pre-apodized” (i.e. renders incorrectly on a “Nyqvist” DAC, how good it sounds will depend on the difference of the filter in your DAC compared to the “reference dac” used to tune the “sound” and how well your taste is aligned with the “Meridian MQA” sound ideal).
Unfolded to 96kHz/24bits is in reality only 96kHz/16bit again “pre-apodized”.
Upsampled using the embedded interpolation filter to 196kHz/24bits is still only 96kHz/16bits but with a little less impact on the sound from your DAC. This is because the upsampling overrides the filter in your DAC e.g. makes all DACs sound more the “same”.
Upsampled to 384kHz/24bits is still 96kHz/16bits close in sound to the “master sound” in the studio (but not necessarily close to the “real” master tape).
It does (in a DAC which is fed the appropriate metadata from the MQA decoder). That’s what Bob Stuart meant when he talked about “joining up the [recording] ADC and [your playback] DAC modulators”.
Hmmm… Methinks there’s a lot of speculation here. For one I have heard so much unsubstantiated claims from Mr Stuart to take all of this with a grain of salt.
Agreed, we are all speculating and salt is appropriate.
The statement by Bob referenced by Joel suggests that MQA can optimise for particular ADC/DAC combinations, but it is also possible, as suggested by Oliver, that this may not happen in every implementation.
It would be great if anyone at CES could clarify this.
Yes I also agree that it is too much speculation (sorry ) and too little actual information.
But I think the papper on MQA that Joel was kind enough to reference in the other thread gives some information but it does not support the marketing talk from Mr Stuart.
I would realy want to hear what HQ-Player Jussi has to say about this. Some aspects of MQA sounds like a simplified version of HQ-Player i.e. “simple” enough to run on a smartphone, e.g. very few taps in the reconstruction filter and that this will create a lot of artifacts (e.g. alaising) but that these artifacts are not a problem! Seems that it would be much better from a sound quality perspective to have a “real” high-res file and use HQ-Player if you have a “real” computer.
Edit: Just to clarify, the alaising in 0-48 kHz is due to that there is also a small filter-kernel in the down-sampling step as I understand it.
In one of the HQ Player threads (I’ll edit it in when I find it) @jussi_laako set out what he’d need to know in order to meaningfully comment about MQA.
Edit: This was the comment by Jussi. The other person who will give us the straight dope is @brian because he will be implementing Roon’s MQA solution. I suspect he is also waiting on further technical detail.
MQA (like HQPlayer, and most things in this space) is proprietary. If we implement software decoding, it will be accomplished by integrating an SDK that has hidden implementation details. We don’t expect to have access to in-depth knowledge about MQA (or HQPlayer’s) DSP. And even if we did, it seems unlikely that MQA (or Jussi) would allow us to act as their spokesperson and disseminate their technical details second-hand.
I’m not that interested in Jussi’s analysis of MQA or Bob’s analysis of HQPlayer. They are both strongly convicted guys operating at a very high level and focusing on different approaches. It is almost certain that they will each perceive many flaws in “the other way”.
I have a lot of respect for both ways of thinking, and I think there are interesting places worth exploring at the end of both optimization paths.
Thanks Anybob, very good comments from Jussi as usual!
I agree Brian, that is why so many people including me is interested in getting software decoding either in Roon or by buying an Auralic. Simply because we don’t want to be forced to buy a new “MQA” dac. But as was pointed out in the other thread that Andrew found, depending on the technical details these details will limit how we can use software decoding.
Example: My DAC works at 2.8 MHz e.g. 44.1 kHz x 64, the dac chip takes 176.4Khz “native”-input. Hence if the input is e.g. 192 kHz the first step is a downsample to 176.4 kHz. Using HQ-Player for this step improves sound a lot.
Accoding to Mr Stuart in the MQA-paper:
"We thus have recipes for downward and upward conversion within a hierarchy of rates such as 44.1, 88.2, 176.4 and 352.8 kHz, however these methods do not provide satisfactory conversion from, for example, 96 kHz to 88.2 kHz. "
Rather if you want to render at another rate the paper suggests going back to the original master and doing a new MQA encoding. This is obviously not possible for a consumer hence the only hope is that software rendering to the highest rate can be used. This implies that for me perhaps the only “good” solution is Roon software decoding to 384 kHz and then use HQ-player to downsample to 176.4 kHz. But maybe even this method will not give me “full” sound quality.
so i guess that answers the question of hardware vs software decoding.
I am interested to hear more on this.
From the press release quoted in the original link:
AURALIC LIMITED, are pleased to be the first developer of a complete line of high-resolution audio streamers to offer fully implemented capability for two of the industry’s significant new technologies: MQA® decoding and RoonReady® integration.
big difference between the word fully and complete line to 1 product (Mini) qualify for half of the statement and being delayed on the other half. Not sure how a company can say something at the beginning of the week and it change at the end on an item the should have been well known beforehand.
Makes me wonder if it is because of “copy-protection” of the high-res content, “IPR”-protection of the encoding kernel or if you actually need a “MQA”-dac for some hard to understand reason.
Starting to feel very anti-MQA. But I might be extra “negative” as I have 100s SACDs that I cannot stream from Roon, hence never play as I only stream from Roon/JRiver.
Things I think make a lot of sense:
1- MQA beautification of the signal by correcting recording/ADC issues - especially with less than optimal implementations of such
2- Folding lossy compression to stream efficiently the “audible” parts of high res audio content
I also think that the “end to end” concept is interesting for lower priced DACs. I find it very hard to believe that if you have decoded an MQA file into 24/192 say, then this last stage optimization would make a difference for a high end DAC (say > $10k).
No, I don’t agree and I think this is one of the mayor head-aches with MQA. Independent of how good a DAC is that dac will assume that the samples in the 24/192 stream represents Nyquist-sampling and pick a suitable reconstruction filter. But infact if you don’t have the decryption key of the MQA file you have no idea what the samples represent. Hence how much you lose from rendering the 24/192 compared to 24/384 is a design choice of MQA and is “secret”.
My assumption is that a high res file encoded with MQA will decode into a very similar high res file - save for the beautification filters. So I am not sure what the foundation of your assumptions are.
My assumption (or maybe fear?) is from AES 9178 “A Hierarchical Approach to Archiving and Distribution”.
From said paper by Mr Stuart:
“The authors have had some success with this process using a triangular kernel, but for much commercial source material something closer to a B-spline of order 4 or 5 has been found preferable.”
This means that the samle points will then represent the information content captured by these filter-kernels and hence not contain the amplitude of a bandwidth limited signal in a point as by Nyquist-sampling.
Again from said paper:
"Using such filters, we have been able to take a 192-kHz sampled signal, resample to 96 kHz for more economical transmission to a listener, then resample again to 192 kHz in order to optimally feed a D/A converter in the listener’s decoder. "
Saw this link on Computer Audiophile to a statement released by Auralic.
It is unfortunately that MQA has decided to pull back the integration on ARIES/ARIES LE during CES as they have decided to make it an ‘end to end’ technology which means it will always requests a MQA certificated DAC to work.
ARIES ARIES LE, will be able to playback or stream music contains MQA format but will not listed MQA certificated device, to benefit from MQA, you will need a MQA certificated DAC and this is the only way.
From this statement, and followup comments on the page, i gather that it appear software decoding is possible but Meridan has decided to require the hardware aspect. Disappointing to say the least.
Feel for Auralic on this too. They deserved scorn for the how they handled the mini release but i don’t see anything wrong with their actions here.
) and too little actual information.