MQA technical analysis

[mm67]

That makes sense to explain that one situation, but the rest all follow a logical pattern. Regardless, the hardware MQA is not 'downsampling' in the Nielsen case (not that upsampling is the correct term either for what MQA is doing, or at least purporting to do), rather the software is decoding/unfolding/whatever to 88.2 while the the DACs are not.

For the Nielsen MQA album, the software decoder (both Tidal's and BlueSound's which could be the same) and hardware decoders (from both the Meridian and Mytec DAC) are interpreting the metadata differently. One is wrong. I've now checked 20 different tracks (from different albums), none do what the Nielsen tracks do. Considering the 'noise' that started this whole discussion, maybe the difference is due to error handling between the software/hardware decoders? Maybe the hardware decoders fault out if presented with faulty data while the software decoder forges ahead filling in the gaps where errors occur?

 

You mean albums that play at 44.1 or 48 kHz ? With a quick 5 minute search starting from the end of Masters albums list I found these :

tidal.com/album/68594179

tidal.com/album/68725744

tidal.com/album/68581195

tidal.com/album/68620380

tidal.com/album/68732153

tidal.com/album/68639594

tidal.com/album/68640671

tidal.com/album/68723724

tidal.com/album/68639546

tidal.com/album/68724758

 

I only browsed through couple of pages so not rare at all

[Miska]

But it could be also a firmware bug in the Meridian DAC that it leaves rendering phase active if the sampling rate is not changed between tracks. I'll check if that's the case...

 

OK, it is a firmware bug in the Meridian DAC firmware. Played exactly same non-MQA track twice, bit-perfect. Only difference being that between the two playbacks I played MQA version of the track. It seems to leave the noisy MQA rendering process active for the subsequent non-MQA track playbacks. So do not trust much on the listening impressions or such with this DAC when comparing MQA and non-MQA tracks, results depend on which order you play the tracks. LED indications are correct, but the real behavior is not.

 

For both cases, the DAC's leaky upsampling filter is the same. Remember the source is 96 kHz non-MQA track which by definition doesn't have any content above 48 kHz frequency.

 

Before playing any MQA tracks:

 

After playing an MQA track:

 

Exactly same track, exactly same bits going to the DAC in both cases.

 

Oh the fun of doing this research work, debugging Meridian's firmware as we go.

[Miska]

Madonnas Like a virgin album also seem a bit odd, Explorer2 leds indicate 172.4 or 192 kHz playback but according to this it was recorded in 16/44.1 or 16/48 format. I thought the name Tidal Masters was referring to offering original masters

 

Yes, I have some other similar ones too, where analysis clearly shows brickwall filter at 22.05 kHz. It certainly isn't proving that the content is authentic hires or anything.

 

And then there are albums like Pink Floyd's Endless River where tracks are mix of content recorded at 44.1/48 kHz sampling rate many years earlier mixed with instruments played later and recorded in 96 kHz sampling rate. This is also clearly visible from the analysis. I wonder how the MQA's ADC analysis and correction works for those...

[bogi]

So do not trust much on the listening impressions or such with this DAC when comparing MQA and non-MQA tracks, results depend on which order you play the tracks.

I am curious if they knew about the bug.

That bug cannot be called minor or unimportant.

[smartin]

You mean albums that play at 44.1 or 48 kHz ? With a quick 5 minute search starting from the end of Masters albums list I found these :

tidal.com/album/68594179

tidal.com/album/68725744

tidal.com/album/68581195

tidal.com/album/68620380

tidal.com/album/68732153

tidal.com/album/68639594

tidal.com/album/68640671

tidal.com/album/68723724

tidal.com/album/68639546

tidal.com/album/68724758

 

I only browsed through couple of pages so not rare at all

 

I had not checked similar recordings, but yes, those all do have the same behavior. Tidal's software decoder/renderer plays them at 88.2/96 while the Brooklyn in passthrough (with blue light) plays them at the original bitrate. So either the software decoder or the DACs are handling these files incorrectly.

[abrxx]

OK, it is a firmware bug in the Meridian DAC firmware. Played exactly same non-MQA track twice, bit-perfect. Only difference being that between the two playbacks I played MQA version of the track. It seems to leave the noisy MQA rendering process active for the subsequent non-MQA track playbacks. So do not trust much on the listening impressions or such with this DAC when comparing MQA and non-MQA tracks, results depend on which order you play the tracks. LED indications are correct, but the real behavior is not.

 

For both cases, the DAC's leaky upsampling filter is the same. Remember the source is 96 kHz non-MQA track which by definition doesn't have any content above 48 kHz frequency.

 

Before playing any MQA tracks:

[ATTACH=CONFIG]32598[/ATTACH]

 

After playing an MQA track:

[ATTACH=CONFIG]32599[/ATTACH]

 

Exactly same track, exactly same bits going to the DAC in both cases.

 

Oh the fun of doing this research work, debugging Meridian's firmware as we go.

 

This should be reported to Meridian...

[mansr]

I had not checked similar recordings, but yes, those all do have the same behavior. Tidal's software decoder/renderer plays them at 88.2/96 while the Brooklyn in passthrough (with blue light) plays them at the original bitrate. So either the software decoder or the DACs are handling these files incorrectly.

No, the Brooklyn displays original rate. It is barely even meaningful to talk of what it plays at since everything is upsampled to several MHz eventually.

[abrxx]

No, the Brooklyn displays original rate. It is barely even meaningful to talk of what it plays at since everything is upsampled to several MHz eventually.

 

I had thought about this but the second stage upsampling that DACs do is normally pretty basic, zero-padding I thought? I have to admit I know very little about this. But hence the popularity of HQPlayer.

[mansr]

I had thought about this but the second stage upsampling that DACs do is normally pretty basic, zero-padding I thought? I have to admit I know very little about this. But hence the popularity of HQPlayer.

Most basic DAC chips do band-limited interpolation (usually cascaded doubling) up to 352.8 kHz followed by an 8x zero-order hold (repeating samples) to a final rate of 5.6 MHz, which forms the input to the sigma-delta modulator. High-end chips such as ESS are considerably more sophisticated. Audiophile DAC boxes often upsample the input to whatever the chip accepts in a separate DSP using their own filter designs. Either way, while upsampling is always inherent in the conversion process (except on NOS DACs), they indicators reflect the rate of the external input. If MQA decoding is viewed as part of the D/A conversion process, just as regular upsampling is, it makes sense to indicate the original sample rate. Alternatively, consider playing a 320 kbps mp3. You'd still display 44.1 kHz if that is the sample rate of the encoded audio. MQA could sensibly be regarded the same way.

[smartin]

No, the Brooklyn displays original rate. It is barely even meaningful to talk of what it plays at since everything is upsampled to several MHz eventually.

 

I'm not sure what you're saying here. It displays the format of the stream that is given to the DAC, I understand that is not what the output is, and my wording was imprecise.

 

In the case of MQA, if MQA decoding is enabled, it does that then passes to the DAC. If disabled, it goes directly to the DAC. So in the Nielsen case, with passthrough and MQA enabled, it is getting the un-decoded MQA file from Tidal, doing the MQA thing, then giving the DAC 24/44.1. If passthough, and the Brooklyn's MQA decode are disabled, Tidal does a software MQA decode and passes 24/88.2 to the DAC. In the case of the Coltrane track, the original rate is 24/48, Tidal will pass 24/96 if passthrough is disabled and the Brooklyn's MQA decode is disabled (and the Brooklyn will display 24/96), if passthrough is enabled the undecoded 24/48 file is passed by Tidal to the brooklyn where then hardware decoder converts it to 24/192 which is passed to the DAC, and is displayed. If pasthough is enabled, but the Brooklyn's MQA decoder is disabled, the undecoded 24/48 file is passed to the DAC, and that's what the display shows.

 

The point I have been making is the software decoder is turning the 24/44.1 into 24/88.2 while the hardware decoder is not. That isn't right....

 

Am I missing what you are trying to say here?

 

EDIT: Clarified a few details

[Miska]

he point I have been making is the software decoder is turning the 24/44.1 into 24/88.2 while the hardware decoder is not. That isn't right....

 

I think it shouldn't be doing it... But maybe the decoder always outputs 2x rate, regardless of input. But the hardware decoder knows from the stream metadata that it originated from 44.1 and displays that in the DAC display while still in reality putting out 88.2.

[mansr]

I think it shouldn't be doing it... But maybe the decoder always outputs 2x rate, regardless of input. But the hardware decoder knows from the stream metadata that it originated from 44.1 and displays that in the DAC display while still in reality putting out 88.2.

 

How many times do I have to repeat that something in the DAC will always be upsampling? Displaying the original rate is really the only logical choice. If some part of the processing produces a double-rate stream, that's just an implementation detail.

 

Decoding (and encoding) H.264 video involves interpolating the image to 8x resolution (though only a small part at a time). One would still expect video players to report the actual pixel resolution that went into the encoder. The MQA situation is no different.

[smartin]

I think it shouldn't be doing it... But maybe the decoder always outputs 2x rate, regardless of input. But the hardware decoder knows from the stream metadata that it originated from 44.1 and displays that in the DAC display while still in reality putting out 88.2.

 

I asked Mytec directly, they said the display is what the DAC is being fed. The MQA decode happens upstream of that. And that would match with how it displays other MQA files like the Coltrane one I detailed, where what is displayed is exactly what should be happening based on what has been said about the MQA process.

I appreciate both all the responses, and apologize if I'm missing something, this just doesn't make sense to me based on what has been said about MQA. From what I've read the software decoder should never produce a higher bitstream than the hardware decoder, and if it is, something is amiss, and perhaps that explains the noise you discovered (if I understand correctly, the bug in the Meridian DAC explains why the non-MQA FLAC was showing the noise, but not why the MQA file has it).

[smartin]

How many times do I have to repeat that something in the DAC will always be upsampling? Displaying the original rate is really the only logical choice. If some part of the processing produces a double-rate stream, that's just an implementation detail.

 

Decoding (and encoding) H.264 video involves interpolating the image to 8x resolution (though only a small part at a time). One would still expect video players to report the actual pixel resolution that went into the encoder. The MQA situation is no different.

 

The Brooklyn displays what is being fed to the DAC, before the DAC does anything to the file, but after the MQA hardware decoder has done it's magic (or Tidal, or HQPlayer, etc...).

[Miska]

Most basic DAC chips do band-limited interpolation (usually cascaded doubling) up to 352.8 kHz followed by an 8x zero-order hold (repeating samples) to a final rate of 5.6 MHz, which forms the input to the sigma-delta modulator. High-end chips such as ESS are considerably more sophisticated.

 

Pretty much all do the same, but some DAC chips do linear interpolation instead of ZOH (IIRC, Cirrus Logic). Analog Devices, AKM, TI/BB and Wolfson run digital filter to 352.8/384k and then ZOH aka S/H. ESS has two-stage FIR filter, first stage is 64 taps and second stage is 16 taps.

[Miska]

if I understand correctly, the bug in the Meridian DAC explains why the non-MQA FLAC was showing the noise

 

Only after first playing the MQA file.

 

but not why the MQA file has it

 

Because it seems to be part of the MQA rendering stage as shown by mansr's plot of the software render output in post #19. So both the hardware and software seem to be doing same stuff. Why it does that is another question for which I don't have answer...

[bcwang]

Only after first playing the MQA file.

 

 

 

Because it seems to be part of the MQA rendering stage as shown by mansr's plot of the software render output in post #19. So both the hardware and software seem to be doing same stuff. Why it does that is another question for which I don't have answer...

 

Does the dac revert back to normal if you stop and play back the non-MQA file again? Does it require a full signal stop or sample rate change to get out of this buggy mode?

 

This is quite disturbing to learn about.

[abrxx]

What about Amy Duncan / Undercurrents ? I thought that was 44.1 MQA.

 

I double checked: bizarrely the MQA version of the album is not available on Tidal, depsite Amy Duncan being at one point prominently displayed on the MQA website as one of the artists embracing MQA.#

 

Additionally, with my non MQA DAC, "Dog on a Chain" - Emitt Rhodes, plays as 88.2 kHz. User mm67 reports that this is actually a 44.1 MQA track. So this seems to indicate that the software decoder always upsamples. So how does anyone know the actual master sample rate?

 

Isn't the entire point of MQA to deliver the master whatever the sample rate? Upsampling everything to 2x seems contrary to the original MQA gameplan.

 

I wonder if this automatic MQA upsampling is part of the reason they claim MQA sounds better than the original 44.1 kHz file sent to a regular DAC with regular upsampling?

 

Its all a bit confusing.

[smartin]

I double checked: bizarrely the MQA version of the album is not available on Tidal, depsite Amy Duncan being at one point prominently displayed on the MQA website as one of the artists embracing MQA.#

 

Additionally, with my non MQA DAC, "Dog on a Chain" - Emitt Rhodes, plays as 88.2 kHz. User mm67 reports that this is actually a 44.1 MQA track. So this seems to indicate that the software decoder always upsamples. So how does anyone know the actual master sample rate?

 

Isn't the entire point of MQA to deliver the master whatever the sample rate? Upsampling everything to 2x seems contrary to the original MQA gameplan.

 

I wonder if this automatic MQA upsampling is part of the reason they claim MQA sounds better than the original 44.1 kHz file sent to a regular DAC with regular upsampling?

 

Its all a bit confusing.

 

Only the software decoders are doing that. The hardware decoders do not. I suspect there is a bug in the software decoders.

[YashN]

I suspect there is a bug in the software decoders.

Plausible, but how many different software decoders have been evaluated in these tests?

[bcwang]

I double checked: bizarrely the MQA version of the album is not available on Tidal, depsite Amy Duncan being at one point prominently displayed on the MQA website as one of the artists embracing MQA.#

 

 

Even more strange is the MQA version no longer being available for sale in the 7digital store. It still seems available directly from Amy Duncan's website though.

[mocenigo]

Decaf is really bad.

 

Yup, 0xABAD1DEA

 

 

Sent from my iPhone using Computer Audiophile

[bogi]

Yeah, very strange. Using Mytec Brooklyn with passthrough get blue light and 24/44.1. If i disable passthough, it still plays at 24/44.1, but now with a red light (whcih is what happens when Brooklyn is fed software decoded file, it still 'unfolds' fully). However, if I disable MQA decoding on the brooklyn and turn off passthrough, it plays at 24/88.2. That makes no sense...

 

It seems to be a bug in Tidal app, at least looking at info abrxx posted here: http://www.computeraudiophile.com/f11-software/roon-and-mqa-software-decoding-coming-31155/index12.html#post623317

Or the info abrxx posted in not correct.

 

Actually depends on whether you are talking about the first fold, or the others:

 

- the first unfold (if necessary, its not applicable to 44.1/48 masters) is a decompression stage, indeed as you infer, similar to unzipping. But note that unzipping is a lossless recovery of the original file. The first unfold is nearly lossless, but not quite. See the patent for more details, https://www.google.com/patents/WO2013186561A3?cl=en .

 

- additional unfoldings use an entirely different process. These unfoldings are mathematically similar to upsampling. I refer you to the relevant patent (different from above): https://www.google.com/patents/WO2014108677A1 .

 

- deblurring is another process and covered by additional patents/papers:

-- For redbook masters: https://www.google.com/patents/EP3029674A1?cl=en

-- For high rez masters they likely use this approach: AES E-Library » Antialias Filters and System Transient Response at High Sample Rates

 

So look at the 1st unfold (decompression) performed for originally 44.1k (not hires) content. The 1st unfold should add high frequency music content above 21k present in the original hires master, but such content is not present in original 44.1k master. So ... what for content is decompressed, what information is that content based on??

 

We read something about deblurring to correct time smear (ringing) introduced by ADC. Is that deblurring relevant to original 44.1k content? Do all MQA files contain that debluirring info? If a MQA file contains it, how it is processed in the case of 44.1k original recording and in the case of hires recordings?

[Miska]

I wonder if this automatic MQA upsampling is part of the reason they claim MQA sounds better than the original 44.1 kHz file sent to a regular DAC with regular upsampling?

 

Yes, I think so. Now based on the results discussed in this thread. I get the feeling that the "deblur" apodizing upsampling filter is run primarily at playback side and nothing really apart from the folding/encoding is done at the source. This could be in line with how MQA operates in Mytek DAC, because the MQA upsampling filter is probably programmed into the ESS Sabre DAC chip and thus input to the DAC chip is 44.1k, but the upsampling is then performed later inside the DAC chip.

[bogi]

I get the feeling that the "deblur" apodizing upsampling filter is run primarily at playback side and nothing really apart from the folding/encoding is done at the source.

 

Looking for further info if that's true. If that would be the only way how MQA makes that 'deblur', then such type of solution is for years already included in HQPlayer - probably on better quality level and without that MQA propaganda agenda.