MQA technical analysis

[Jud]

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.

 

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

 

 

Sent from my iPhone using Computer Audiophile

[Miska]

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

 

What I've understood, it is not actually shaped dither, but the encoded upper band data that has been noise-shaped to be less audible and then mixed with the actual shaped dither (that is not removed).

 

So how I see the graph is that the difference is the actual useful data taken out.

 

Of course I'm not at all sure if I'm right...

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

[Michael Lavorgna]

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.

 

Please be so kind as to explain how advertisers on AudioStream have "leverage" in terms of our editorial content. To clarify, what I am asking you to explain is exactly how this works, i.e. I am not interested in the intellectual equivalent of the Monty Python "witch" test.

[Jud]

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.

 

Why, exactly? You have just noted sensationalism works well; I'd add to that anything, really, that tends to make someone other than run-of-the-mill. Middle of the road need not apply. So either mythmaker or mythbuster.

 

Publications regarding the high end audio industry tend toward excitement and enthusiasm for the product. If you wish to read payola into that, it's your prerogative, but frankly I doubt any such thing is really necessary to get people who are "into" audio and love to write about products to sound enthusiastic. That space is already well covered.

 

So any individual who wants to drive traffic better look at another market segment, and Archimago has one. I don't think he needs to change what I assume are his natural skeptical tendencies to write what he does, any more than I believe journalists for the magazine sites need to change what I assume are their natural mostly enthusiastic tendencies in order to write what they do. I attribute nefarious motives to neither. A desire to drive traffic? Of course. Who wants to run a business to lose money?

[Jud]

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:

 

[ATTACH=CONFIG]33109[/ATTACH]

 

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

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

[Fokus]

So you cannot apply any DSP of your choice; like replay gain, digital room correction, headphone cross-feed or stuff like that, unless those are specifically approved/blessed by the MQA company.

 

I know. I wrote that years ago, mere days after MQA plans were released.

 

The point is that the machine/player I use for analysis is not supposed to have any processing going on.

When I find the time I will return to it and check if it has RG totally inadvertently enabled.

[manisiutkin]

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?

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

[manisiutkin]

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?

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

[bcwang]

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?

 

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

[abrxx]

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?

 

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

 

This has been explained recently on this forum. I posted links to relevant patents etc. The process to encode audio data above 48 kHz i.e. over 96 kHz sample rate is a very clever undersampling technique using a triangular sampling kernel. To decode this one has to perform a process which involves upsampling along with custom filtering.

[audiventory]

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:

 

[ATTACH=CONFIG]33109[/ATTACH]

 

What is steps? What is measurement scheme?

 

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

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

[audiventory]

The low 8 bits of a 24-bit MQA file contain a compressed representation of the 24-48 kHz frequency content.

 

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)?

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

[Samuel T Cogley]

Why, exactly? You have just noted sensationalism works well; I'd add to that anything, really, that tends to make someone other than run-of-the-mill. Middle of the road need not apply. So either mythmaker or mythbuster.

 

Publications regarding the high end audio industry tend toward excitement and enthusiasm for the product. If you wish to read payola into that, it's your prerogative, but frankly I doubt any such thing is really necessary to get people who are "into" audio and love to write about products to sound enthusiastic. That space is already well covered.

 

So any individual who wants to drive traffic better look at another market segment, and Archimago has one. I don't think he needs to change what I assume are his natural skeptical tendencies to write what he does, any more than I believe journalists for the magazine sites need to change what I assume are their natural mostly enthusiastic tendencies in order to write what they do. I attribute nefarious motives to neither. A desire to drive traffic? Of course. Who wants to run a business to lose money?

 

Apples and oranges. Hobby vs. Day Job. Blogger is a free platform that is free because of the Google ads.

[mansr]

Apples and oranges. Hobby vs. Day Job. Blogger is a free platform that is free because of the Google ads.

Can we drop that topic in this thread? Please.

[Jud]

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.

 

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.

 

 

Not having any technical understanding, I'm wanting to know whether or not the output includes frequencies above 48KHz because that's needed as part of the 96KHz recreated stream. A simple arrow flow chart (A -> B) of the sequence of the filtering and "unfolding" would be helpful to me, I think.

[Jud]

Can we drop that topic in this thread? Please.

 

Yep - Samuel, that's been moved to a dedicated MQA and DRM thread.

[Jay-dub]

As an experiment, I took the MQA version of 2L-048 and zapped the high 15 bits preserving only the sign while leaving the MQA control bitstream in bit 8 and the lower bits intact. The decoder still reports this as "blue-light" MQA and tries it's best to decode it....

It should also be noted that the decoder calculates a checksum over the input samples, and I don't know what effect a mismatch here has.

 

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.

I'm confused by this. According to the earlier post, it appears that you've managed to find a way to replace the audio content in an MQA file and still have it light up the blue-light indicator; according to the later post you haven't. Was the earlier post in error?

 

It seems to me likely that an MQA stream would have something along the lines of a checksum of the audio data, encoded through a public-key encryption (encoding key closely held by MQA, decoding key built in to all client devices). That way, the decoder could use the checksum to verify that the data isn't corrupted (as a condition for turning on the authentication light), but a hacker wouldn't be able to create an unauthorized MQA encoder by reverse-engineering client software. At least, that would definitely be a sensible approach. Have you seen any evidence that the decoder is doing something at all similar to what I've described with the checksum?

[PeterSt]

Originally Posted by mansr

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.

 

The report (of someone else) on this was wrong-ish. The blue light does come on, but only very briefly. Throughout this stream (of IIRC 30 seconds) the decoder keeps on resetting (I counted 24 times). Also IIRC it is a 24/96 originally.

 

I'm confused by this.

 

So very well observed.