Truncating MQA files to 16 bits and the blue light still shines

[mansr]

46 minutes ago, FredericV said:

So why does the MQA blue light still shines?

Now my big concern is: it's still saying the resolution is 352.8 Khz and the blue light still shines., but we have just thrown away 1/3 of the MQA input file as we blanked those bits. How in the world can such manipulation and throwing away the first unfold data, still authenticate the file.

This is by design. The MQA identification and authentication data is embedded in bit 8 of a 24-bit PCM stream. Dropping bits 0-7 thus leaves it untouched. The authentication works by computing a Blake2s hash over the top 15 bits (the plain PCM portion) and parts of the control stream in bit 8. This hash is then verified against a cryptographic signature extracted from the control stream. The public key is stored in the decoder. If the signature matches, the blue light goes on. The low 8 bits encoding the high-frequency content are not covered by the authentication.

[mansr]

Just now, miguelito said:

But if I understand the original poster correctly, it not only authenticates but somehow is upsampling to 352KHz... How does that work?

The displayed rate is whatever the control stream says. That's the orig_rate value in the mqascan output. It may or may not be actually upsampled to this rate. If the DAC chip doesn't accept rates that high, something lower will be used. The display tells you what went into the MQA encoder, not what is coming out of the decoder.

 

Just now, miguelito said:

What is the quality of the signal coming out? Would love to see it. Would also love to see the first unfold of this.

Easy enough to find out. Give me a day.

[mansr]

1 minute ago, GUTB said:

The technical basis of MQA rests on two concepts:

 

1. There is very little music information above 50 kHz.

That much I agree with.

 

1 minute ago, GUTB said:

2. High-res sounds good because of time domain performance.

This is patently false.

 

1 minute ago, GUTB said:

In Stuart's and Carver's view, almost all of the music data is present within a sample rate of 96 kHz, and information above that is just noise. MQA seeks to maintain the music data, eliminate the bandwidth dedicated to noise,

All that can be done using standard FLAC.

 

1 minute ago, GUTB said:

while improving time domain performance.

That's bollox.

[mansr]

1 minute ago, GUTB said:

Stuart and Carver made their cases for time domain. Has someone rebutted it?

Show me the maths.

[mansr]

6 minutes ago, rickca said:

Is this your version of show me the money?

We've already seen the money, or lack thereof.

[mansr]

3 minutes ago, FredericV said:

So if the real MQA file, and stripped version with only 16 bits of entropy, both show decoding to 24/352.8, how does the customer know he is not being scammed?

Easy, if the blue light is on, it's a scam.

[mansr]

What happens if you mess with bit 9, just above the MQA control stream?

[mansr]

2 hours ago, GUTB said:

Doesn't the 8 LSB just contain the ultrasonic unfold data?

Yes, so?

[mansr]

1 hour ago, FredericV said:

Setting the 9th bit (starting counting from bit 0) via one of these 2 Perl operators, de-authenticates the file, and mytek says it's 24/44.1:

As expected. The authentication covers only the PCM part of the stream.

 

Here's something else to try. Toggle bit 9 in one sample every few seconds.

[mansr]

2 minutes ago, FredericV said:

It ignores the first corrupt sample, blue light almost immediately shines, but after 3 seconds, the light goes out and stays out. As long as there's a datastream without pauze, it does not recover from the corrupt bit.

Use "mqascan -p4" on the file to check the signature packet interval. Then corrupt the PCM data in only some of the authentication blocks.

 

2 minutes ago, FredericV said:

Curious if we start to flip bits in the MQA control stream ....

The control stream has a packet structure, each having a 4-bit checksum. If this doesn't match, decoding is disabled until the next sync pattern is found. If the checksum matches, any corruption will still fail authentication.

[mansr]

11 hours ago, FredericV said:

Also note that flac can't compress the output of the decoder back to the MQA flac distribution file sizes.

Hardly surprising. A decoded mp3 file compressed with FLAC is also larger than the original mp3.

[mansr]

10 hours ago, Don Hills said:

I am surprised that the MQA decoder doesn't seem to complain when it is fed the invalid compressed data.

If the expected markers aren't there, it is simply ignored. It has to work this way. If some software (player/OS) has mangled the lowest bits for whatever reason, the DAC still must play something.

[mansr]

8 minutes ago, FredericV said:

So except for a licensing scheme, what purpose does the 1e unfold offer?

It undoes some of the dither applied to the PCM part as you can see in this plot of a silent bit in the file. DXD original included for reference.

[mansr]

1 hour ago, FredericV said:

How many MQA cd's are there ? 5...10 ?
How many MQA albums on Tidal are there? A few thousand.

While MQA could probably design a different bit allocation scheme for 16 bit distribution files, they also have stated that truncating 24 bit files to 16 bit also works, so Occam's razor dictates they have just truncated the 24 bit version for MQA CD.

It would not make much sense to do such an engineering effort for a few CD's.

It could be as simple as flipping a setting in the encoder. Or even a setting to have the encoder output both versions at the same time. Until we've had a chance to examine such a CD, we can't know.