MQA technical analysis

[mansr]

Yes. However, you use absolute values. At spectrum analyzer level dB are showed.

 

Me seems, need begin from other end.

 

Need calculate rounding error energy and distribute it across band.

 

As result you get tone with amplitude lower 0 dB (0 dB minus energy of rounding error).

 

The rounding error energy distributed by full band.

 

Wider band - lower energy per Hz.

 

The calculation is reversible. It doesn't really matter if you work in amplitude or power as long as to stick to one.

 

However, analizer use FFT. So need distribute noise by [FFT length]/2 points, not per Hz.

 

With an FFT you get frequency bins covering a fixed range each. The output is typically normalised to get values that are not dependent on the transform size.

 

Can we now please get back to MQA and away from elementary calculus?

[mansr]

At spectrum we view power in each point (bin?) of FFT. More points, lesser energy in each one, because sum of quantization errors for all points is constant.

 

Lesser energy for each point - lesser noise floor.

 

Example:

 

Let suggest, total energy spectrum: 100 = 90 (signal) - 10 (errors)

 

Signal take 1 point. 10 (errors) distributed by rest points.

 

If rest 255 point: energy per point is 10/255.

 

If rest points is 1023: energy per point is 10/1023.

 

Etc.

 

It in the each point we will see lesser noise for more FFT length.

 

That's why the output is usually scaled according to the FFT length.

[mansr]

Yes, scaled. But I wrote about spectrum energy distribution. It is relative. Signal (90% energy) anyway take 1 point and 10% energy (errors) distributed by rest points.

 

Only if the signal falls exactly in the centre of one of the bins. This is one reason windowing is used.

[mansr]

If it (we talk about pure sine only) fall between two points it distributed between these points and noise distributed between rest again.

 

Of course, if we have too low point number (16 as example) there more noise will mixed with the sine in its points.

 

I'd like, check the above mentioned source and decoded signals in an other analyzer, that show more traditional results.

 

I try check my results different ways for decreasing of error probaility.

 

What do you consider "traditional" results?

[mansr]

For 15 bit (truncated 16 bit) sine I expect -90 ... -110 dB (accounting accumulation, overlapping, FFT len (2048 ... 4096) and dithering).

 

The total noise power should be somewhere in that range, yes. Not the power per Hz.

[mansr]

I told about average level of noise floor that we can observe at spectrum plot.

Well, your numbers don't add up. Mine do.

[mansr]

Good video on MQA

 

Please stop posting links to marketing material. This thread is for actual technical aspects of MQA.

[mansr]

Level of random noise is directly dependent on length of the FFT (as well as the other parameters). More frequency bins you have, lower the level of random noise is per bin. Level is constant, you just choose how many bins you distribute it to.

Exactly, and that's why you typically normalise the values so outputs of FFTs of different lengths can be readily compared.

[mansr]

I see a few advertising links being offered on this thread...

 

Permit me to offer a non-advertising link for those interested in some objective analysis:

COMPARISON: Hardware-Decoded MQA (using Mytek Brooklyn DAC)

 

Nice measurements. Everything I've seen suggests that the first stage decoding is identical on all devices, software or hardware. Certainly the Tidal decoder output is bit-identical to that of Bluesound one. The lowest bit of this output contains instructions for the "renderer" on how to upsample further. This includes the original sample rate and which of 16 predefined filters to use (I've only seen a few of them chosen in actual MQA files). These filters generally have a fairly slow descent towards a notch at 88.2 kHz which explains the difference you noted between software-only and full decoding. The "rendering" actually removes some of high-frequency content reconstructed by the decoder. Some graphs here: http://www.computeraudiophile.com/showthread.php?p=627196

 

After upsampling, the renderer truncates the signal to 16-20 bits (16 in all files I've checked) using shaped dither. The rising level you noted above 60 kHz is this dither noise.

 

Good job on the examination of the underlying code, everyone. Perhaps I missed it in this thread, but I am curious about the filter being used by the MQA decoder. Was there an updated sine sweep looking at the aliasing/nonlinear distortions?

 

The decoder uses a variety of filters for different purposes, not all of which I have figured out yet. The renderer uses filters as discussed around the post linked above.

[mansr]

Not related to the signal processing, but to the format itself.

 

MQA seems sensitive to ID3 tag contents. I took an MQA wav file, and converted it to flac in two flavours: one with ReplayGain writing to the ID3 tag, one without.

 

The Explorer2 refuses to recognise the ReplayGained track as MQA, even though the actual signal in the file nulls perfectly with the original MQA wav.

The Explorer2 is fine with the non-RGed track.

 

Your player probably applied the gain thus destroying the MQA information. The DAC never sees the file headers (including metadata tags), so that alone can't make any difference.

[mansr]

Can someone with an MQA DAC please play this file and report whether the indicator comes on and, if so, which colour.

mqatest.zip

[mansr]

No MQA indicators and no sound

 

It was supposed to be silent. The purpose was to see if it actually detected the audio bits being tampered with while leaving the control bitstream alone. Apparently it does. Which DAC did you use?

[mansr]

Hmm. A non-advertising link. That's kind of a play on words because you are making money through advertising on your site, and driving more traffic to your site through your posts on CA is clearly in your financial interest.

 

His post is informative and on-topic for this thread. It is not an advertisement for MQA, unlike those other links that were posted recently. Who cares if he makes a few cents off the traffic he gets from here?

[mansr]

I think it's a bit comical that you guys don't trust the commercial interests of one entity, but do trust the commercial interests of another that supports your point of view.

 

The ads I see on his site are served by Google and Amazon. I don't think they care whatsoever what he writes. This is very different from ads on, say, Audiostream where the advertisers have a direct relationship with the publication.

[mansr]

No indicators and also silent using Bluesound Node 2. It shows 24/48 sample rate in the tech info.

 

Thanks for testing. I just wanted to confirm that the "authentication" really does verify the content of the file rather than just looking for the MQA control bitstream.

[mansr]

I disagree. Whatever you write about, Google will scrape the text and display ads that will garner the most clicks. Publishers frequently tailor their articles to discuss the topics that produce the best click through rates on the displayed ads. For example, if you talk about mesothelioma, you will make a lot of money. Lawyers will pay $50 per click to Google, who then cuts a percentage to the publisher.

 

I really don't think Google or Amazon are going to put pressure on random bloggers to write more favourably about things advertised through their networks. Looking at the post linked above, these are the ads I see:

 

- A book about DSP room correction at Amazon

- Amazon links for the products and music mentioned in the text

- Some sort of currency and/or commodity trading site

- Travelodge hotels

- Vinyl records from Amazon

- A Kindle reader from Amazon

- A "master class" on film scoring

 

Those are either completely random or triggered by a single keyword in the text. If you think that is in any way comparable to the highly paid ads placed by high-end audio companies on the usual "review" sites, you are out of your mind.

[mansr]

Think bigger. Google doesn't put pressure, the advertising income can put pressure on people. If you write about music, then you'll see Adsense ads for people selling music. One only has to look at the Adsense stats to see which ads are paying him the most, and tailor his content to talk more about the stuff that brings in more income.

 

The Amazon link for, say, the RME Fireface appears regardless of what is said about it in the text. In fact, you often see these content-related ads pop up in the most ironic of situations, i.e. right next to a scathing criticism of whatever the ad is for.

[mansr]

We've all seen the characteristic noise hump in undecoded MQA files. Apparently, this is the result of shaped dither applied during the encoding. The first two steps of the decoding process entail removing part of this noise. This is possible since the pseudo-random sequence used to generate it is known. Here's a graph of the decoder in action:

 

[mansr]

Which situation has no effect whatever, I'm sure, on a desire to drive traffic by developing a reputation for publishing said scathing criticisms. (Eyebrows raised.)

 

The point is that to Amazon and Google your opinion doesn't matter. They'll find an ad to show no matter what you write. When you deal directly with the advertisers, they have a lot more leverage in that they can simply stop running ads on your site if they don't like your writing. If you rely on them for your pay cheque, you just might be tempted to keep them happy.

 

While obviously any income-generating site has an incentive to stay popular, pandering to advertisers isn't necessarily going to help with that. Clickbait and sensationalism works quite well, but those don't imply any particular bias.

 

Trying to place Archimago in the same basket as Audiostream et al just because he has a few syndicated ads on his blog is pathetic.

[mansr]

Is essentially all of this taking place in the last one/two/few LSBs?

Of the 15-bit input, yes. I'm not sure what the maximum possible adjustment is, but clearly it doesn't reach very high.

[mansr]

MQA impress has been mentioned a bit too much here and there. But software decoder also contains references to MQB (like MQB mark, MQB audio type, MQB sync packet). So, what the devil's mark is MQB?

 

MQB is the information stream embedded in the output from the "core" decoder, i.e. the input to the renderer.

[mansr]

And meaning of MQB data for the renderer? Besides flushing blue/green lights on output device:) Isn't that why you've started speaking about DRM schemes in MQA?

 

There are a few things covered:

- Resampling filter to use (16 choices)

- Bit depth to dither output at (16-20)

- Noise shaping filter for the dithering

- Original sample rate

- Amount of digital gain to apply

- Whether the audio bits are scrambled

- Some sort of metadata

- A handful of bits I don't know what they mean

 

There is no authentication information here, and apparently the Mytek DAC lights up red when sent such a stream.

[mansr]

What is steps? What is measurement scheme?

 

These steps inside decoder? In this case, how you access it?

 

I used a debugger to extract the audio samples partway through the decoding process.

[mansr]

There is constant reference by Miska or Mansr to the rendering stage of MQA to be just upsampling. Can you explain this as this doesn't fit with what MQA claims.

 

1. Hardware decoded files show signal information above 48khz which the software decoded files don't. If it was simply upsampling 96khz I would expect a sharp cutoff at 48khz and nothing above. So his doesn't sound like upsampling

 

2. MQA claims hierarchical unfolding, where 96khz and above sound is encoded and buried in the noise floor of between 48-96khz band. Then that whole band is encoded and buried in the noise floor below 20khz. If you simply claim it's upsampling then that means you think MQA is lying about how their tech works?

 

The low 8 bits of a 24-bit MQA file contain a compressed representation of the 24-48 kHz frequency content. The decoder combines this with the base band information in the high 15 bits to recreate a 96 kHz stream. This part works more or less the way they say it does.

 

So I'm not sure where this claim that rendering is simply upsampling with a specific digital filter comes from.

 

The claim comes from looking at the actual code that does it. It's a perfectly standard polyphase interpolation filter. Nothing more. The filters they use have horrible amounts of aliasing/imaging, which is why the output includes frequencies above 48 kHz.

[mansr]

By this information, I can suppose, that 16 bit of MQA contains unmodified content in 0 ... [sample rate encoded signal /2].

 

At Archimago's difference pictures we seen that difference (between encoded and supposed original) present in audible range.

 

I'm wondered, it is error of measurement or MQA have real difference between coded and decoded signal in audible range (except highest frequencies, where noise is slightly risen)?

There are some differences beyond the dither noise. I don't know where they come from, perhaps aliasing in the downsampling during encoding. MQA seems to really like aliasing.