MQA, where is decoding done, what is required?

[Jimbob54]

MQA presents itself as PCM 24/48, so one bitrate.

And sometimes presents as 24/44.1

 

[Vincentponcet]

But when decoded its either 44. 1, 48, 88.2, 96, 192 etc. That's the numbers the end user is being conditioned to care about. That, and the coloured lights.

I was talking about tidal different bitrates, MQA being used for the highest bitrate.
So they are not using the same file.
The output of decoded MQA is 24/96 or 24/88.2, the 192 or 176 are just upsampling.

Just to add another data point to the discussion, here’s Roon doing the first unfold and sending a 96 kHz file to my RME. The display on the DAC confirms it’s receiving a 96 kHz file.

View attachment 102264

Roon is doing the MQA decoding in software ?
I thought they licensed it only for hardware devices.

 

[Jimbob54]

I was talking about tidal different bitrates, MQA being used for the highest bitrate.
So they are not using the same file.
The output of decoded MQA is 24/96 or 24/88.2, the 192 or 176 are just upsampling.


Roon is doing the MQA decoding in software ?
I thought they licensed it only for hardware devices.

Plenty of software can do the first unfold. I believe the second has to be hardware (if there is anything there)

I'm pretty sure most of it is smoke, mirrors and a hefty dose of marketing. But Bob and co would tell you that second unfold is where the real magic happens. Others would say its padding a few more zeroes. But it makes the lights change colour.

 

[Zensō]

Roon is doing the MQA decoding in software ?
I thought they licensed it only for hardware devices.

Yes, Roon can do the first unfold. https://help.roonlabs.com/portal/en/kb/articles/roon-x-mqa

 

[Roland68]

Sorry OP. I thought your question had previously been answered.

You want to know if your Pioneer does the full unfold of MQA or just the first unfold. What information can you give us about the file it's playing when it's playing MQA? One way you can tell if it's only doing the first unfold or the full unfolding is the sample rate information. If you have an MQA file that is 96khz or higher then it will need to do the full unfolding to play at that rate. If it's only doing the first unfolding you will be limited to 44khz or 48khz.

Do you have a way to see what sample rate your device is playing at?

Use @danadam link to download an MQA file and load it onto your player and see what it plays.

I'm interested in how exactly the MQA development is implemented in devices with "normal" DAC chips (without MQA).

But ash on my head, I hadn't played a file with MQA on my Pioneer XDP-30R.
David Elias' MQA files are actually played on the Pioneer Player with the MQA logo (incl. Blue dot ;o) and 352.8 kHz.
That now raises even more questions for me, since the implementation of MQA on this player only took place with a firmware update.

 

[Raindog123]

I'm interested in how exactly the MQA development is implemented in devices with "normal" DAC chips

Are you looking for a high-level workflow (that is fairly straightforward) or “how exactly” implementation (that most definitely varies from one brand to another)?

 

[andymok]

I’m more interested to know how MQA is done in the first place

coz it isn’t done inside any DAW, even pyramix. So it must be done outside of the box, after mastering

if we know how it’s done, we’ll know how it’s “undone”

 

[Beershaun]

I'm interested in how exactly the MQA development is implemented in devices with "normal" DAC chips (without MQA).

But ash on my head, I hadn't played a file with MQA on my Pioneer XDP-30R.
David Elias' MQA files are actually played on the Pioneer Player with the MQA logo (incl. Blue dot ;o) and 352.8 kHz.
That now raises even more questions for me, since the implementation of MQA on this player only took place with a firmware update.

Glad to hear it works for you on your DAP. That's great news.

 

[Roland68]

Are you looking for a high-level workflow (that is fairly straightforward) or “how exactly” implementation (that most definitely varies from one brand to another)?

The workflow is clear, but I'm actually interested in the physical implementation in the device.
Apparently there is no chip from MQA (as was previously the case with PMD for HDCD).

Apparently, each device is individually guided through implementation and development by an MQA engineer.
So my question is also not to answer because there are probably several ways of implementing MQA, depending on the device design, chip used, circuit design, etc.

Unfortunately, that also explains the whole nebulous "behavior" around MQA.

 

[Beershaun]

@Roland68 then I’d refer you back to @Jimbob54 original post linking to the MQA blog and Bob Stuart’s write up on how it does what it does.

Well, as ever , it depends.... but from the horses mouth

http://bobtalks.co.uk/blog/science-mqa/mqa-playback/#

 

[Beershaun]

BTW I am listening to the Metallica Black album (or self titled) streaming to my rpi Moode player from Tidal as a 44.1khz sample rate file and it sounds fantastic! The kick drum action from Lars is amazing. I have no idea whether it’s getting the MQA file or regular flac file and I don’t care. It just sounds so damn good.

 

[Chrispy]

Besides the gobs of unctuous marketing from mqa/bob, wtf is unfolding actually/technically?

 

[Roland68]

@Roland68 then I’d refer you back to @Jimbob54 original post linking to the MQA blog and Bob Stuart’s write up on how it does what it does.

I had read Bob Stuart's blog post before the thread opened, but unfortunately there are no answers to my questions in it.
He only writes very superficially about how it could be implemented and about the advantages and disadvantages of the different options, nothing is written about the technical implementation.

I am now assuming that MQA does not want to disseminate this information.

 

[Beershaun]

I had read Bob Stuart's blog post before the thread opened, but unfortunately there are no answers to my questions in it.
He only writes very superficially about how it could be implemented and about the advantages and disadvantages of the different options, nothing is written about the technical implementation.

I am now assuming that MQA does not want to disseminate this information.

correct. It’s a proprietary format. They will not give away information that could help others reverse engineer it.

 

[Raindog123]

I'm actually interested in the physical implementation in the device

Here is an example implementation, per the second "MQA" row of my pic here:

1) An MQA stream/file is stripped by host from FLAC container and sent to "DAC device" (not the same as a "DAC chip") as a raw MQA PCM bitstream through DAC’s input interface (eg asynchronous USB).
2) The "GPP component" of the DAC device performs the "first [core] MQA unfold" - that is essentially (a) splitting of each incoming 24-bit sample into two, through (b) some shaping, interpolation and noise dithering, thus (c) doubling the sample rate. All of this is done in non-real-time. The "GPP component" can be a variety of physical devices: a microcontroller, DSP chip, FPGA or a SoC (multifunction system-on-chip, eg, combining a USB interface and DSP functions).
3) The now-2x-sample-rate bitstream gets passed to a "DSP+DAC component" whose job is to (a) further up-sample the bit-stream with one of 16 pre-configurable “MQA interpolation filters" - to provide "MQA-defined" impulse responses and equalize-out non-linearities of this particular DAC device. After that, (b) the stream is send to the "DAC chip" input to generate an analog waveform. The upsampling/filtering step can be physically done in the core-decoder FPGA/DSP or, if supported, in the digital filter section of the DAC chip (ESS chips with MQA rendering support offer it).

Both steps (2) and (3) are an MQA Ltd-licensed implementation. Again, the "first, core unfold" step can be done in a streamer (eg, Roon server or Tidal app) or by a processor inside ”full MQA-capable DAC" device. As it stands today, the final “MQA rendering” step must be performed by a MQA-certified “hardware” (FPGA, DSP or SoC code).

[For the record, I am a RF communications/networking engineer, not a digital audio devices designer. So all my postings here are just _my_ interpretation of what I - like many others - read online and reimagining “how it could be implemented would I do it”. My goal is also to provoke true experts into telling us how its really done through [hopefully] friendly criticism of my insinuations.]

 

[Chrispy]

Here is an example implementation, per the second "MQA" row of my pic here::

1) An MQA stream/file in a FLAC container enters a "DAC device" (not the same as a "DAC chip") through an input interface (eg, asynchronous USB).
2) A "GPP component" of the DAC device identifies the stream as a MQA, removes the container and exposes a raw MQA "PCM" bit-stream.
3) The same "GPP component" performs the "first MQA unfold" - that is essentially (a) splitting each 24-bit sample into two, through (b) some [sample] shaping, interpolation and noise dithering, thus (c) doubling the incoming sample rate. All of this is done in non-real-time. The "GPP component" can be a variety of physical devices: from an actual GPP to an FPGA, to a SOC (eg, combining a USB and GPP functions).
4) The now-unfolded [to the 2x sample rate] bit-stream gets passed to a "DSP/DAC component" whose job is to (a) further up-sample the bit-stream with one out of 16 "pre-configurable MQA convolution filters", whose job is to (a1) provide "MQA-defined" impulse responses and (a2) equalize "channel non-linearities" of this particular DAC device. After that, (b) the stream is send to the "DAC chip" input to generate an analog waveform. The upsampling/filtering step can be done in an FPGA logic (aka "old school") or in an integrated DSP-DAC chip (like newer ESS chips with "MQA support"). In reality, all that is is support for custom digital filters -filter's taps loading and dynamic run-time selection).

Both steps (3) and (4) are governed by the MQA-licensed implementation in "software" and "firmware" respectively. Again, the "first unfold" step (3) can be done in a streamer (eg, Roon server or Tidal app) or by a "full MQA-capable decoding DAC" device (not in just "MQA DAC chip"). As it stands today, the step (4) must be performed by a MQA-certified "hardware" - either a "MQA rendering DAC device" or a "MQA rendering function of a full MQA decoder-DAC".

What a pile of doodoo to unnecessarily wade thru.....

 

[Roland68]

Here is an example implementation, per the second "MQA" row of my pic here:

As I said, I'm interested in what is really used in "hardware" in a device that does not have an MQA capable DAC chip.
So which chip / IC really does the work before the DAC chip.

But contrary to what Bob Stuart writes about pure hardware solutions, they don't seem to exist in reality.
Apparently only ICs with computing power are used in front of the DAC chip, which then take over the unfolding via the appropriate software. That has nothing to do with a real hardware decoder.
So far I have not found a chip from MQA.

 

[Jimbob54]

As I said, I'm interested in what is really used in "hardware" in a device that does not have an MQA capable DAC chip.
So which chip / IC really does the work before the DAC chip.

But contrary to what Bob Stuart writes about pure hardware solutions, they don't seem to exist in reality.
Apparently only ICs with computing power are used in front of the DAC chip, which then take over the unfolding via the appropriate software. That has nothing to do with a real hardware decoder.
So far I have not found a chip from MQA.

There is no chip from mqa
. Licensing.

And there is always going to be software of some sort inside all black boxes. I'm afraid you have probably got all you're going to get from here.

 

[danadam]

But contrary to what Bob Stuart writes about pure hardware solutions, they don't seem to exist in reality.

Maybe their definition of "pure hardware solution" is different from yours.
Maybe it is a perceptually pure hardware solution

 

[ElNino]

correct. It’s a proprietary format. They will not give away information that could help others reverse engineer it.

Fortunately, all of the interesting bits have been reverse-engineered (at least enough to completely understand what's going on behind the scenes, without having to parse Bob Stuart's often misleading, incoherent and sometimes literally incorrect public statements): https://code.videolan.org/mansr/mqa