- Joined
- Oct 25, 2019
- Messages
- 11,126
- Likes
- 14,798
And sometimes presents as 24/44.1MQA presents itself as PCM 24/48, so one bitrate.
And sometimes presents as 24/44.1MQA presents itself as PCM 24/48, so one bitrate.
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.
Roon is doing the MQA decoding in software ?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
Plenty of software can do the first unfold. I believe the second has to be hardware (if there is anything there)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.
Yes, Roon can do the first unfold. https://help.roonlabs.com/portal/en/kb/articles/roon-x-mqaRoon is doing the MQA decoding in software ?
I thought they licensed it only for hardware devices.
I'm interested in how exactly the MQA development is implemented in devices with "normal" DAC chips (without MQA).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.
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)?I'm interested in how exactly the MQA development is implemented in devices with "normal" DAC chips
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.
The workflow is clear, but I'm actually interested in the physical implementation in the device.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)?
Well, as ever , it depends.... but from the horses mouth
http://bobtalks.co.uk/blog/science-mqa/mqa-playback/#
I had read Bob Stuart's blog post before the thread opened, but unfortunately there are no answers to my questions in it.
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.
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 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".
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.Here is an example implementation, per the second "MQA" row of my pic here:
There is no chip from mqaAs 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.
Maybe their definition of "pure hardware solution" is different from yours.But contrary to what Bob Stuart writes about pure hardware solutions, they don't seem to exist in reality.
correct. It’s a proprietary format. They will not give away information that could help others reverse engineer it.