MQA technical analysis

[mansr]

As we know, the Bluesound software contains an MQA decoder. All the MQA code resides in a shared library, libbluos_ssc.so, which is called by various other parts of the playback software. There are three main parts to the library: decode, render, and preserve.

 

Decode

The decode portion accepts audio data and outputs decoded data at twice the sample rate of the input. It also provides feedback regarding the MQA status of the data being processed: none, MQA (green), or MQA Studio (blue). Non-MQA input is also upsampled to double rate. I speculate that this corresponds to the MQA Core decoding done by the Tidal player.

 

Render

The render stage takes the output of the decode stage and upsamples it further. Gain can also be applied here. Again, non-MQA input is accepted.

 

Preserve

This function appears to transfer some MQA signal encoded in the LSB from one audio stream to another. The Bluesound player uses it together with software volume and tone controls between the decode and render stages.

 

Having deduced the programming interface of the library, I wrote some simple test programs to process audio files and save the output. Attached below is a snippet from the output of running the decoder on the 2L-048 sample (recorded at 96 kHz). I'd be thankful if someone who has an MQA DAC could play it and report whether the indicator LED comes on.

2L-048-mqadec.zip

[mansr]

What happens if you just use the default ALSA plugin setup and store the output?

 

It's not all done with ALSA plugins. That was my mistake.

 

No blue light on Meridian DAC with this file.

 

Does it light up when using the Tidal software decoder?

[mansr]

Well, it lights up with Tidal player, but Tidal application detects the DAC and forces the hardware decoding. So the driver is indicating 48k sampling rate when playing MQA track... Regardless if the pass-through setting is enabled or disabled in the Tidal application.

 

No way to force software decoding in Tidal?

 

Would you be able to capture a short sample of Tidal passthrough and software decode of the same track? It would be most helpful if you, or someone else, could.

[mansr]

Here's spectrogram of digital capture of the Tidal software decoded 2L-048 test track.

 

Could you share that capture, please?

[mansr]

Could you share that capture, please?

 

With the exception of two short bursts in the first 0.2 seconds, my decoded file matches Miska's capture bit for bit. I guess that's some kind of success.

[mansr]

Well, it lights up with Tidal player, but Tidal application detects the DAC and forces the hardware decoding. So the driver is indicating 48k sampling rate when playing MQA track... Regardless if the pass-through setting is enabled or disabled in the Tidal application.

 

If you play the captured software-decoded file, does the Explorer indicate MQA? Is it supposed to do this?

[mansr]

You mean the one in first post ? Blue light doesn't lit up with that one on my Explorer. If I capture something from Tidal and play it in Foobar mqa indicator does lit up

 

You mean capture an MQA pass-through from Tidal? I'd expect that to work.

[mansr]

Since I'm now confident the decoder is working correctly, here's a spectrum plot of 2L-048:

 

Here we can see that the decoding process removes the characteristic hump and restores some of the high-frequency content. In this plot, the graphs start diverging noticeably around 30 kHz, the decoded MQA having somewhat higher noise level.

 

Spectrogram of the aligned difference:

 

The larger differences correlate with the louder portions of the audio.

 

This is the difference spectrum of the loud portion from 190 to 250 seconds:

 

Same thing with linear frequency scale:

 

Difference spectrum of the silence at the end:

 

And again with linear frequency scale:

[mansr]

So, does the blusound decoder include a renderer? Will it unfold a 24/48 file to 24/192? Since you have detected an activation bitsteam in the least significant bits, that implies that it is used to switch the renderer on and perhaps apply a specific filter profile. That last stage is of import to those of us with the PWM dacs that currently do not support blusound, since Roon can do the first unfold decode but not the final render with appropriately selected filter.

 

It includes what appears to be a renderer. There obviously isn't any reference available to compare the output against.

[mansr]

Here's same track, recorded at 192k sampling rate from line output of the Explorer2. I tried to get as low noise output from the DAC as possible, using iFi iUSB as a power supply. There's still some amount of USB packet noise (8 kHz intervals) visible.

 

Original 96k file:

[ATTACH=CONFIG]32541[/ATTACH]

 

MQA file decoded by the DAC:

[ATTACH=CONFIG]32539[/ATTACH]

 

Here's the average spectrum of what the Bluesound MQA renderer outputs:

 

[mansr]

I have a feeling that some regular hires files can trigger this rendering mode too. I have one regular hires FLAC that seems to trigger this noise and upsampling filter behavior (without the blue light though). Running that FLAC through upsampling before sending it to the DAC takes out the noise and makes it much quieter, and also removes the 30 kHz filter cut. So it seems like there are hires files that are sort of "encoded-decoded" MQA...

 

Does it have the bit pattern described above? What happens if you dither it to 22 bits or so? That ought to ruin any signatures the decoder is looking for.

 

Seems like the 30 kHz cut-off is more on the rendering phase then. I really fail to see the point in this "rendering" part... The upsampling filter is really slow roll-off, so it leaks a lot of image above Nyquist, visible on tracks that really hit the Nyquist limit.

 

I fail to see the point of any of it.

[mansr]

I have only a rudimentary understanding of the analysis y'all have been doing but this paragraph struck me as odd. Wouldn't this suggest that the noise you are seeing with this MQA decode might be a factor of the track, and not be related to MQA at all. It seems that if you see this behavior with non-MQA content, it would be more likely to be due to some attribute of the track itself (that was carried over into the MQA version) than something inherent to MQA?

 

I took it to mean he's seeing the noise characteristic of the MQA renderer when playing some non-MQA 96 kHz files. No DAC I've ever seen normally generates such noise. Even the built-in upsamplers in the DAC chips are better than that.

[mansr]

By graphs above, looks like MQA work like 24 bit uncompressed format.

 

But MQA lossless or lossy?

 

It is definitely lossy. It's just plain impossible to pack all the high-frequency content into the bandwidth afforded by the format. That's simple information theory.

 

The decoded files are also substantially different from the originals (assuming the 2L MQA samples were created from the masters provided).

 

I read about a probable "frequency-amplitude response correction", but real implementation of encoder/decoder is unknown.

 

It's only a matter of time before we learn how the decoder works.

[mansr]

My impression of the various steps in MQA decoding:

 

"first unfolding" to 88/96:

This is where -actual- file information is used to recover (lossy) information above the 44/48 KHz sample rate. This step is "universal" - ie no tailoring to the output device.

 

"rendering" to a higher bit rate:

This is entirely an upsampling step, very little if any information above 88/96 rate from the original file exists or is being used. The DAC chip's profile now plays a big role as it's really just upsampling at this point rather than reconstructing actual info.

 

Is this a possible interpretation?

 

It's a possible interpretation, sure, but it's not the only one.

 

I wonder how much, if any, the Bluesound decoder is tailored to the Bluesound DAC chain.

 

So far we know that the Bluesound decoder output is bit-identical to that of the Tidal software decoder. No tailoring there.

[mansr]

It was not 100% clear to me, but I guess that the decoding from the Bluesound code is to a max of 96 KHz, correct? The plots all stop at 48KHz so I am guessing this is right.

 

It seems to double the input sample rate no matter what parameters I throw at it. The "render" part can upsample by higher factors.

[mansr]

Is there a render component in the Bluesound software?

If the design is as I detailed above, it would make sense from a design and software distribution standpoint to split the libraries in two components: the first unfold to 88/96 which is common across the board, and a device-specific component which upsamples.

 

There is a single library containing both decode and render parts. The decode runs first, then the output of that is optionally send through the render part.

[mansr]

Can you isolate the primary upsampler's response (magnitude, phase, impulse) for a non-MQA input,

and see if it is identical to Fig.6 here Mytek HiFi Brooklyn D/A processor–headphone amplifier Measurements | Stereophile.com and Fig.4 here Meridian Explorer2 D/A headphone amplifier Measurements | Stereophile.com?

 

I don't see what comparing to those graphs would tell. They don't appear related to MQA at all.

[mansr]

The terms imply a delivery method that aims to preserve all information. But MQA has always said that they do not preserve the original input. They apply DSP as part of the recording chain. That DSP is claimed to improve the way the file sounds, by correcting temporal errors. That is their claim. So words such as "lossy" and "lossless" are a little inappropriate ... MQA is always "lossless", but they believe that delivers a better sound. Its lossless in the same way that a crossover is lossless, or DSP room correction.

 

That aside, there are various compression and encoding schemes used by MQA. None are mathematically lossless. Bit depth is always truncated, from a mathematical POV.

 

I know MQA use the word "lossless" (or Bob Stuart has). I believe when pressed he talks about audibly lossless. That's a fair concept, but a lot harder to define and test than mathematical lossless.

 

My understanding is that the frontend processing to "correct" ADC errors is distinct from the delivery format. I see no reason the former couldn't be delivered in a truly lossless container.

[mansr]

In theory, sure. They could do their DSP and then ship at 24/762kHz massive file...some of the publicly stated design goals of MQA are:

 

- compatible with existing consumer non hi-rez gear (ie. max 16/48)

- compatible with 24/48 gear

- compatible with existing entry level hi-rez (24/96) e.g. Dragonfly which limits the USB input rate to 24/96 (but internal DAC can do more)

- compatible with best DACs (i.e. super high sampling rate)

 

I like this approach, its a neat idea. I also live in a world where streaming mp3 is sometimes flaky. I don't want to stream massive files.

 

They could take the processed master and resample it normally to the usual delivery rates.

[mansr]

There is no reason that I can think of why the "de-blurring" process cannot be applied without the "Origami" process. Selling only the filters will be a tough thing but bundling it with lower file size make it attractive for streaming services.

 

Or put another way, sell the "de-blurring" to the likes of Merging (Pyramix) and the recording studios pay. Sell it to the DAC and playback software vendors and everybody pays. Which do you think Mr. Stuart likes better?

[mansr]

What is temporal errors here?

 

Bob waving his hands, mostly.

[mansr]

So are you running two pieces of code, one for the first "unfold" and one for "rendering"? Sorry but I am a bit confused about this.

 

The library contains two functions with names similar to "decode" and "render". I made one test program for each them, storing the output of "decode" in a file. Both functions could of course be called one after the other in a single program, but I wanted to look at the intermediate data anyway.

[mansr]

So that also plays differently from mqa dacs ? http://www.computeraudiophile.com/f8-general-forum/big-mqa-news-really-tidal-and-software-decoding-etc-31151/index8.html#post625315

 

There appears to be an option to decode without upsampling. I just haven't figured out how to trigger it yet. Perhaps the exported library interface doesn't make it possible.

[mansr]

Yes, as expected. I would think the "decode" func is the same across all implementations whereas the "render" function is tailored to each DAC.

 

My questions are:

1- The plots you show - are they after decode or decode+render?

2- What comes out of decode? PCM?

3- Is the sample rate out of render higher than the 2x you get out of decode?

 

Thx.

 

The set of plots for 2L-048 are all after the decode only. There is also one plot (in reply to Miska) showing render output. The renderer can upsample by 2x or 4x, and also pass the data through unaltered. Again, this might be a limitation of the Bluesound library which only exposes a simplified wrapper around the full MQA software.

[mansr]

One thing I don't understand: my DAC shows 44.1 or 48 sample rate when playing certain MQA tracks. At least I think it did. But how can that be if the software decoder always upsamples?

 

Is 2L-120 (Carl Nielsen Piano Music with Christian Eggen) one of them? It was recorded in 44.1 kHz.