MQA technical analysis

[Jay-dub]

On second thought, I'm not sure that what I just described would work. A hacker could get around it by analyzing a collection of authentic MQA files, calculating the checksums occurring therein, and creating a database of checksums associated to known authentication codes. The unauthorized encoding software would then take an audio stream, modify it (hopefully with minimally audible degradation) until it matches one of the known checksums, and then use the associated code to create an apparently authentic MQA stream from it.

[mansr]

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.

 

 

That actually makes sense. It probably means the light comes on when the MQA signal is first identified, then turned off again when the checksum doesn't match. There are 22 of what appears to be signature packets in the 30-second file at relatively constant intervals (i.e. somewhat less than once per second). From what I can tell, the decoder is operating all along regardless of what the checksums say. I guess it's time to write some more sophisticated tools to manipulate the MQA data stream.

[mansr]

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?

 

I don't have an MQA DAC, so I hadn't checked how the indicator actually behaved. Running the modified file through the decoder, the actual signal processing parts happen the way they're supposed to. It's just the indicator light that doesn't turn on if the checksum doesn't match.

 

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?

 

Something like that seems to be going on.

 

On second thought, I'm not sure that what I just described would work. A hacker could get around it by analyzing a collection of authentic MQA files, calculating the checksums occurring therein, and creating a database of checksums associated to known authentication codes. The unauthorized encoding software would then take an audio stream, modify it (hopefully with minimally audible degradation) until it matches one of the known checksums, and then use the associated code to create an apparently authentic MQA stream from it.

 

What you describe is called creating a hash collision, and it's something cryptographers have already thought of. With a strong 256-bit hash as used in MQA, you'd potentially need to test 2^256 different combinations before finding a collision, and that would take longer than the lifetime of the universe.

[bcwang]

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.

 

So you are looking at actual source code for an MQA full decoder or just looking at output streams from it?

 

It seems if there was a specific upsampler tailored to work with the triangular sampling, the first unfold data would have to be tailored so this specific upsampling would recreate the frequencies precisely as originally encoded. However, this data if not upsampled would not sound right when played back as is. Thus when not doing a full decode to a specific dac which will upsample after the first unfold, the first unfold creates a different bitstream compatible with all DACs.

 

When I'm talking about sound information above 48khz, I'm not just talking about mirror image aliasing. From some of the graphs archimago blog shows, it matches the original hires content pretty closely up to 60khz.

 

Also it's said the render mode increases noise, so if that's not coming from the upsampling, there is also more going on here. The graphs you show are good but are only digital domain. You would want to correlate it with the actual analog output of an MQA dac to see nothing else is happening that you are not accounting for.

[mansr]

So you are looking at actual source code for an MQA full decoder or just looking at output streams from it?

 

I obviously don't have the source code, but I have a disassembler.

 

It seems if there was a specific upsampler tailored to work with the triangular sampling, the first unfold data would have to be tailored so this specific upsampling would recreate the frequencies precisely as originally encoded. However, this data if not upsampled would not sound right when played back as is. Thus when not doing a full decode to a specific dac which will upsample after the first unfold, the first unfold creates a different bitstream compatible with all DACs.

 

The output of the first unfold, as you call it, is always the same.

 

When I'm talking about sound information above 48khz, I'm not just talking about mirror image aliasing. From some of the graphs archimago blog shows, it matches the original hires content pretty closely up to 60khz.

 

It matches quite well up to 48 kHz, all from the first decoding stage. The renderer lacks the ability to add anything but images.

 

Also it's said the render mode increases noise, so if that's not coming from the upsampling, there is also more going on here. The graphs you show are good but are only digital domain. You would want to correlate it with the actual analog output of an MQA dac to see nothing else is happening that you are not accounting for.

 

The renderer first upsamples, then dithers the result to 16 bits with noise shaping. This is what causes the rising noise above 50 kHz or so.

[manisiutkin]

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

Is NGDecoder the decompressor for this? NightinGale decoder, doesn't that sound nice...

[mansr]

Is NGDecoder the decompressor for this?

 

Yes, at least in part.

[Miska]

1. Hardware decoded files show signal information above 48khz which the software decoded files don't.

 

Where? So far what I've looked at for example 2L content compared to the original 352.8 kHz DXD and proper 192k down conversion of those, the MQA content rolls of early (starting at about 30 kHz) compared to the original or 192k versions where content reaches up to about 60 kHz.

 

If it was simply upsampling 96khz I would expect a sharp cutoff at 48khz and nothing above. So his doesn't sound like upsampling

 

MQA filters are specifically extremely non-sharp and "poor", so they leak a lot.

[Miska]

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.

 

What I've been wondering is what happens when MQA encoder is running short in bits to encode the upper band. From what I've seen I get feeling that it may be stealing bits from the lower band...

 

If one could encode 0 dBFS 192/24 white noise and multi-tone, we could know more. But so far the best I have are the synth tracks that actually push stuff out throughout the bandwidth of 96/24 original.

 

For example MP3 encoders look OK with single sine, but go pretty bad at multi-tone and white noise (of course).

[Miska]

When I'm talking about sound information above 48khz, I'm not just talking about mirror image aliasing. From some of the graphs archimago blog shows, it matches the original hires content pretty closely up to 60khz.

 

The resolution is not so great on the spectrograms, but what I see by quick glance is just images leaking through the filter.

[The Computer Audiophile]

MQA filters are specifically extremely non-sharp and "poor", so they leak a lot.

Given that Bob Stuart and Peter Craven have some ability to understand digital filters, can you make a guess as to why (if true) they elected to implement filters that are "poor and leak a lot."

[mansr]

What I've been wondering is what happens when MQA encoder is running short in bits to encode the upper band. From what I've seen I get feeling that it may be stealing bits from the lower band...

 

If one could encode 0 dBFS 192/24 white noise and multi-tone, we could know more. But so far the best I have are the synth tracks that actually push stuff out throughout the bandwidth of 96/24 original.

 

Too bad we don't have an encoder. I'm still working my way through the decoder, but it's slow going. I've rarely seen such convoluted code. It's almost as bad as Adobe Flash (for which I've seen the actual source code).

[mansr]

Given that Bob Stuart and Peter Craven have some ability to understand digital filters, can you make a guess as to why (if true) they elected to implement filters that are "poor and leak a lot."

When anyone can make a good filter, a bad one is your only option to differentiate yourself.

 

That the filters leak a lot is indisputable. I could post the actual coefficients here and now, but you probably wouldn't like that.

[scintilla]

Given that Bob Stuart and Peter Craven have some ability to understand digital filters, can you make a guess as to why (if true) they elected to implement filters that are "poor and leak a lot."

 

My speculation is that because the aliased images are correlated to the audio signal they add to the signal power when noise-shaping. This would be a clever way to add correlated

HF to the decoded signal that wasn't explicitly encoded. It would be a cheat of sorts but that's why I reference that hearing is a stochastic process. What parts of the time-series harmonics do you need for adequate reproduction of impulses?

 

 

Sent from my iPhone using Computer Audiophile

[Jud]

MQA filters are specifically extremely non-sharp and "poor", so they leak a lot.

 

 

 

Are they poorer in this regard than any (meaning all) of Meridian's non-proprietary filters?

[Miska]

Given that Bob Stuart and Peter Craven have some ability to understand digital filters, can you make a guess as to why (if true) they elected to implement filters that are "poor and leak a lot."

 

Because it's the "non-ringing" school of thought, same category as NOS DACs and for example Ayre's "listen" filter. You can check out the Stereophile measurements linked here to see... This is complete opposite of for example Chord which goes to the other extreme. I personally rather stay somewhere in the middle, but for example HQPlayer offers also both extremes as an option. DAC chips have long had options for different schools too, with usually two filter choices.

 

In these measurements, there's a 19.1k tone at 44.1k sampling rate and there shouldn't be much if anything of it left at 25 kHz (blue). A leaky filter is one that leaves strong tone visible at 25k. This is image of the 19.1k tone. Red plot is just white noise at 44.1k sampling rate, thus spanning up to 22.05 kHz, you can see how much of it is leaked above 22.05k frequency as images.

 

Mytek Brooklyn's MQA-filter:

 

Meridian Explorer2:

 

See a striking similarity between the two?

 

Ayre Codex:

 

For comparison, Chord Mojo:

[Miska]

Are they poorer in this regard than any (meaning all) of Meridian's non-proprietary filters?

 

Sorry but I don't understand the question, what do you mean by non-proprietary?

 

The earlier Explorer (non-2) was better in that respect:

[ATTACH=CONFIG]33144[/ATTACH]

 

Or if you look at the original Prime:

[ATTACH=CONFIG]33145[/ATTACH]

(possibly changed later as part of MQA firmware update?)

[Jud]

Sorry but I don't understand the question, what do you mean by non-proprietary?

 

The earlier Explorer (non-2) was better in that respect:

[ATTACH=CONFIG]33144[/ATTACH]

 

Or if you look at the original Prime:

[ATTACH=CONFIG]33145[/ATTACH]

(possibly changed later as part of MQA firmware update?)

 

Sorry, Stuart and Craven's non-MQA filters would have been a better way of putting it - but you answered in any case.

 

 

Miska, your images are showing as non-valid attachments.

[mansr]

My speculation is that because the aliased images are correlated to the audio signal they add to the signal power when noise-shaping.

 

That makes no sense.

[Miska]

Miska, your images are showing as non-valid attachments.

 

Crap, the forum acts up sometimes with images, first shows those and then they silently disappear and become broken...

 

Explorer:

 

Prime:

[The Computer Audiophile]

Crap, the forum acts up sometimes

 

Completely new site software coming soon. Shooting for end of February.

[Archimago]

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.

 

LOL.

 

OMG Chris, I have "commercial interests"? Come on man... The amount of traffic I have on the blog *pales* to the commercial interests on any of the major audiophile blog and sites I've seen. To put it another way, I make a few bucks off Amazon if there's anything I talk about and readers buy, and another few bucks in AdSense. Notice that not all my posts are about audio, some about video as well; stuff that interests me and experiments that other hobbyists might find interesting.

 

Let me be honest as well. I make more money in my day job in one day than 2 years worth of what I'm getting off blog proceeds... I trust this puts into perspective the level of "commercial interest" I have.

 

I'm interested in truth. I'm interested in having audiophiles be educated in such truth as can be proven with evidence. Not every audio lover will care about a lot of this but I do want the material and measurements out there for reference if one days, an audiophile get to thinking about an alternative viewpoint other than the interests of the "mainstream" audiophile Industry-supported media.

 

Go ahead and do the same with your reviews by adding objective data and I will be a happy man because then I can look forward to answers rather than yet more testimony and opinions rather than facts. I would happily retire when that day comes!

[Archimago]

Hi Chris. With due respect, I think you're beating around the bush a little. A better way to say that is that his blog is not his "day job".

 

No kidding! :-)

 

Not to continue this subthread of course... Just had to put in my peace...

 

Carry on.

[audiventory]

In these measurements, there's a 19.1k tone at 44.1k sampling rate and there shouldn't be much if anything of it left at 25 kHz (blue). A leaky filter is one that leaves strong tone visible at 25k. This is image of the 19.1k tone. Red plot is just white noise at 44.1k sampling rate, thus spanning up to 22.05 kHz, you can see how much of it is leaked above 22.05k frequency as images.

 

Input signal is 19.1 kHz pure sine in 44 kHz?

 

It is modelled signal? What is bit depth?

[The Computer Audiophile]

LOL.

 

OMG Chris, I have "commercial interests"? Come on man... The amount of traffic I have on the blog *pales* to the commercial interests on any of the major audiophile blog and sites I've seen. To put it another way, I make a few bucks off Amazon if there's anything I talk about and readers buy, and another few bucks in AdSense. Notice that not all my posts are about audio, some about video as well; stuff that interests me and experiments that other hobbyists might find interesting.

 

Let me be honest as well. I make more money in my day job in one day than 2 years worth of what I'm getting off blog proceeds... I trust this puts into perspective the level of "commercial interest" I have.

 

I'm interested in truth. I'm interested in having audiophiles be educated in such truth as can be proven with evidence. Not every audio lover will care about a lot of this but I do want the material and measurements out there for reference if one days, an audiophile get to thinking about an alternative viewpoint other than the interests of the "mainstream" audiophile Industry-supported media.

 

Go ahead and do the same with your reviews by adding objective data and I will be a happy man because then I can look forward to answers rather than yet more testimony and opinions rather than facts. I would happily retire when that day comes!

 

I would bring on several more writers like Mitch if I could find them. Good writers are incredibly hard to find.