MQA technical analysis

[Miska]

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.

 

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

 

No blue light on Meridian DAC with this file.

[Miska]

Does it light up when using the Tidal software decoder?

 

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.

[Miska]

Here's spectrogram of digital capture of the Tidal software decoded 2L-048 test track. I tried to use same spectrogram parameters you used before.

 

 

Here's spectrogram of the difference to the original, palette switched to highcolor which I mostly use to make the difference better visible.

 

 

Looking at the background noise from the spectrums, there's about 6 dB increase in background noise in MQA version, thus a 6 dB drop in the SNR.

[Miska]

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

 

No it doesn't, it plays it just as it would play any other 96k file. I don't think there is supposed to be any difference...

 

I'll make some analog recordings today in different ways...

[Miska]

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:

 

MQA file decoded by the DAC:

 

For comparison, here is self-noise of the ADC with cable just disconnected:

[Miska]

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

 

[ATTACH=CONFIG]32543[/ATTACH]

 

So it largely matches. The average doesn't show noise increase at the bands where there is also music content, minimum spectrum would probably show that thing better.

 

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...

 

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.

[Miska]

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?

 

Well, because it is above Nyquist frequency of the track, it is technically impossible.

 

Let's say you have two tracks in 96/24 format, tracks A and B. Now in this case outputs from the DAC for these tracks differ in frequencies above 48 kHz. And the behavior matches behavior what @mansr presented for the rendering phase.

 

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...

[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...

[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.

[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...

[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.

[Miska]

1) Apply deblur DSP. This is a different algorithm depending on the sample rate of the track and possibly the embedded ADC signatures within the track. The ADC does not need to be known -- Bob has said on record their software is pretty good at finding evidence of what type of ADC was used. So batch processing does not mean that ADC compensation has not been applied.

 

What do they do in following quite typical cases?

1) Master has never seen an ADC, like music created with software synthesizers, or just partially ADC like soft synths + vocal track. Typical for modern pop music.

2) Master is mixed from different ADC's running at different sampling rates (Pink Floyd - Endless River being an example)

 

6) Apply final reconstruction filter / deblur filter

 

Why apply multiple deblur filters in the chain?

 

7) Analog output stage

 

Wrong, now you are ruling out what makes 50% of the DAC's performance - the delta-sigma modulator. Between digital filter and digital-to-analog conversion stage there's typically delta-sigma modulator. MQA doesn't touch this part at all...

 

And even the MQA upsampling ratio is pathetically low. I'm running at least 256x upsampling filters and for half of the cases 512x. MQA deals with tiny numbers like 2x or 4x.

[Miska]

But sill I don't understand that 'Optional intermediate processing'. If that DSP touches all 24bits then it will change also the MQA metadata and the resulting PCM stream will no more be 'authenticated' as MQA in DAC. Did I miss something?

 

Maybe the "MQA decode" is the Render part which is like upsampling plus some noise shaping that adds the noise. Exactly the part that the bug in firmware now leaves enabled when switching to non-MQA track. Maybe there's supposed to be some side-channel for control data between part 1 and part 2 (in case the processing in the middle changes the embedded metadata).

 

Edit: Reading the Bob's answer this assumption about the side channel is correct. Both part 1 and part 2 are supposed to be in the same box, so there are various different ways to transfer data between the two without involving the audio data. Like just passing parameters to functions or at most using something like I2C or SPI bus.

[Miska]

Isn't the shortness of the filters rather the point. This is all part of the blur/ no more than 10m of air idea?

 

Hmmh, what 10m? For that number I get 25 cm.

[Miska]

May be there is especial initialization of the DAC is need?

 

It is USB Audio Class 2 compliant device.

 

Such behaviour of DAC with any playback software (in bit perfect mode, of course)?

 

I'm just using "aplay" on Linux. Doesn't get much simpler than that.

 

Possibly it is damaged DAC.

 

Yes, in a sense of buggy firmware. It is anyway latest available one, I checked right before doing the tests.

[Miska]

It's graph time again. 2L-111 is a 352.8 kHz master with remarkably low high-frequency noise. Here's the spectrum of the original and the MQA reconstruction (decode + render):

 

[ATTACH=CONFIG]32642[/ATTACH]

 

Nicely shows how they cut on high frequencies above 30 kHz (more like 25 kHz in this case) and then add bunch of artefacts in the higher ultrasonic range...

[Miska]

do we care about 30 kHz and up freqs.?

 

I do, that's what the hires is about. You shouldn't remove anything that is captured during recording and you should record everything the instruments generate. To fully reproduce instrument's sound, you cannot remove anything from it. That's why I have speakers and headphones that go to 50+ kHz and amplifiers that can cleanly reproduce 100+ kHz flat.

 

It is contradictory to talk about deblurring while simultaneously having low-pass filter that cuts on high frequencies, because that will precisely cause slowing down of the transient edges. Faster the transient, more high frequency components it will have.

There's life above 20 kilohertz! A survey of musical instrument spectra to 102.4 kHz

 

Now if MQA removes both LSB bits and cuts on high frequencies, it is removing pretty much all "hires" out of "hires". So it just becomes expensive way to create mangled "lores".

[Miska]

The ultrasound harmonics may cause audible noise by intermodulations.

 

Of course, need ultrasound filter.

 

What should be removed are the digital image frequencies and modulator noise, but those are at frequencies way over 150 kHz spreading to MHz range. What shouldn't be removed is real audio content below 150 kHz or so.

 

What MQA doesn't help at all, are those things above 150 kHz. Instead it generates digital images/aliasing under 150 kHz.

[Miska]

Do you don't agree that 30 and 33 kHz harmonics can cause 3 kHz (33 - 30) harmonic in audible spectrum by intermodulations?

 

Yes, but only in shitty electronics not worth having. I'm much more concerned about for example 330 + 333 kHz or 1030 + 1033 kHz image harmonics.

 

For example when the digital filter outputs 352.8 kHz rate followed by zero-order-hold. When you play 1 kHz tone, the DAC will output both 351.8 and 353.8 kHz tones and thus intermodulation product of 2 kHz. And this is directly correlated with the input signal. This is further emphasized by the fact that at 350 kHz range the THD of analog sections will be higher, and thus also harmonic distortion products of these frequencies will cause also intermodulation products.

 

With music, the level of 1 kHz tones is also generally much higher than 30 and 33 kHz harmonics.

[Miska]

Digital pre-fitration can help even for «shitty electronics»

 

Although it can never substitute good analog reconstruction filters. But removing any content that originates from instruments is clear no-no. That's why I really don't like MQA's idea of starting leaky cut-off roll-off at 30 kHz while still leaking like hell at the Nyquist frequency.

 

ADC and reproduction must capture and reproduce everything from microphones like this:

http://www.sanken-mic.com/en/product/product.cfm/3.1000400

 

I'm heard not once about harmonics in 30 … 40 kHz range with significant level. Probably it is artefacts of studio apparatus.

 

Referring to my earlier link and other test I've been doing myself with percussive instruments, there's plenty of stuff going beyond that. For example violin creates wide harmonic spectra, as well as glockenspiel which I've been testing with.

 

For accurate reproduction, every harmonic instrument creates needs to be recorded and reproduced.

[Miska]

We don’t know exactly where is edge of accurate reproduction. Spectrum is infinite. So band should be infinite too, theoretically.

 

It is where the harmonics are not measurable anymore from the noise floor.

 

For example for the 2L recordings, harmonics reach to about 56 kHz, that's why I concluded that 60 kHz bandwidth is enough for those. But if you extend it to ~90 kHz of 192 kHz sampling rate or ~80 kHz of 176.4 kHz sampling rate you at least have enough margin.

 

As a result, having the filter fc above the highest harmonic means that the filter doesn't have time domain implications on the signal either...

[Miska]

MQA-

Objectively with the songs I examined, the software decoder works well to reconstruct what looks like the equivalent 24/96 download.

 

Archimago's Musings: COMPARISON: TIDAL / MQA stream & high-resolution downloads; impressions & thoughts...

 

Funny that the differences to original are higher with MQA and the file is bigger, than you would get with standard hires FLAC TPDF-dithered to 18-bit (-108 dB)... So completely no reason what so ever to use MQA, standard FLAC would give better quality and smaller file.

 

His tests gave good picture though that higher the amount of high frequency content, more there's difference to the original. But none of the tested samples really used frequencies above 22.05 kHz much. But there are tracks that actually have a lot of stuff there too. I've spent quite a bit of money to find such in MQA format.

[Miska]

By render you mean the part of code that is adjusting the final signal to match the dac?

 

If this is just a digital analysis, one part that is missing is how the particular dac chip is handling an input that in digital form may look like this. Maybe the dac compensation process is to tailor the digital signal so the output on the analog side matches what came in on the analog side of this end to end "studio quality" process that is being claimed. To really know, an analog measurement of a MQA dac needs to be made to see resulting waveform rather than just what digital was being fed to it. Maybe at the end this particular dac distorts that waveform and it ends up looking like the pcm representation.

 

Did you post a digital representation of the post unfolding without the render portion? Maybe it is a closer match to the pcm equivalent.

 

My recordings from analog output of a Meridian DAC with hardware decoding pretty closely match to what has been shown here for digital domain analysis...