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

[FredericV]

Today I had some fun writing a perl script, which manipulates an MQA file in such way, that I have even more serious questions about the MQA blue light.

Somewhere I read that MQA files could still be decoded if you truncate the 24 bit MQA distribution files to 16 bit, before sending it to the decoder.

So we actually tried it. Had to write some Perl code to make it work, as truncating with SOX did not work well and seems to round the value.

So this one liner does NOT work:
 

sox -V -D  input.wav -b 16 output.wav

I used @mansr's mqascan tool to verify my truncation script was correct.

So we now have a situation where:

1. Nothing new: 24 bit MQA distribution files, sent bitperfect to Mytek Brooklyn, work as expected:

If we play the 24/44.1 MQA files from 2L.no, MQA will unfold them to 24/88.2 and then upsample them to 24/352.8 in the renderer.



mqascan shows the details of the input file:

# mqascan -1 2L-050_01_stereo_DXD_WAV.mqa.flac
00000000: [5] datasync
          magic                     36: 0x11319207d
          stream_pos_flag            1: 0
          pad                        1: 1
          orig_rate                  5: 0x03 [352.8 kHz]
          src_rate                   5: 0x00 [44.1 kHz]
          render_filter              5: 8
          unknown                    5: 0x08
          unknown                    1: 0
          pad                        2: 0
          mqa_level                  8: 0x90
          items                      7: 2
          size                       8: 0x14
          size                       8: 0x0b
          type                       8: 0x00
          type                       8: 0x01
          [type 0]
          unknown                    2: 2
          unknown                    4: 0
          unknown                    7: 15
          unknown                    7: 127
          [type 1]
          unknown                   11: 0x314
          checksum                   4: 0xf

So the customer looking at his DAC display believes this is 24 bit 352.8 Khz, while the actual resolution is something like 17 bits and 88.2 Khz, upsampled with minimum phase and one cycle of postringing to the original resolution. It's misleading, but this is how MQA displays it.

 

2. MQA distribution files, sent bitperfect to Mytek Brooklyn, but with lower 8 bits blanked:

This is where it gets interesting:

 

We actually blanked the 8 LSB bits in an MQA file, so we have 16 actual bits per sample in a 24 bit file. So for each sample, 8 bits are zero/nada/rien. Mytek is smart enough to detect this zero padding, so it correctly claims it's only 16 bits.

This also happens with non-MQA files. This is why I still keep the Mytek: it's a good tool to see what's going over the USB, and what is the actual resolution of non-MQA. I can compare the ALSA stats with what the Brooklyn sees in the data.

The mqascan tool shows MQA is in the truncated file:
 

# mqascan -1 output.wav
00000000: [5] datasync
          magic                     36: 0x11319207d
          stream_pos_flag            1: 0
          pad                        1: 1
          orig_rate                  5: 0x03 [352.8 kHz]
          src_rate                   5: 0x00 [44.1 kHz]
          render_filter              5: 8
          unknown                    5: 0x08
          unknown                    1: 0
          pad                        2: 0
          mqa_level                  8: 0x90
          items                      7: 2
          size                       8: 0x14
          size                       8: 0x0b
          type                       8: 0x00
          type                       8: 0x01
          [type 0]
          unknown                    2: 2
          unknown                    4: 0
          unknown                    7: 15
          unknown                    7: 127
          [type 1]
          unknown                   11: 0x314
          checksum                   4: 0xf

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.




How did we do this test?

1. take an MQA file from 2L.no:

2L-050_01_stereo_DXD_WAV.mqa.flac

http://www.2l.no/hires/index.html

2. decode the flac to input.wav

flac -d 2L-050_01_stereo_DXD_WAV.mqa.flac -o input.wav

3. then run the perl script on it, which I will release on an external site (copyright reasons, I intend to GPL this script, therefore I won't copy the code here)

./mqastripper.pl

which takes input.wav and writes 10 seconds into output.wav

# file input.wav
input.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 24 bit, stereo 44100 Hz
# file output.wav
output.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 24 bit, stereo 44100 Hz

This script can also be used to remove the encrypted non-nyquist data from MQA file, so it compresses better with flac:

input.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
input.wav: wrote 30524205 bytes, ratio=0.635

output.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
output.wav: wrote 608305 bytes, ratio=0.228

So this script actually implements what Jim Lesurf calls bit freezing:

http://www.audiomisc.co.uk/MQA/cool/bitfreezing.html

Script is still slow on my raspberry, but works. We'll open source it so anyone can play with it.
 

 

[asdf1000]

Very interesting. I wonder if the same happens with an MQA file that’s supposed to pack in more information, like this 353kHz MQA album:

 

https://shop.klicktrack.com/2l/411252/

[FredericV]

1 minute ago, Em2016 said:

Very interesting. I wonder if the same happens with an MQA file that’s supposed to pack in more information, like this 353kHz MQA album:

 

https://shop.klicktrack.com/2l/411252/

The files that I used were sourced from 352.8 Khz (not 353Khz which is not a valid sample rate, but I get your point).

[asdf1000]

3 minutes ago, FredericV said:

The files that I used were sourced from 352.8 Khz (not 353Khz which is not a valid sample rate, but I get your point).

 

Eep, apologies for rounding up.

 

[hsmeets]

35 minutes ago, FredericV said:

So why does the MQA blue light still shines?

 

 

Implementation by Mytek: perhaps it does not look at the actual encrypted bitstream but only at some value in the header of the FLAC container which says it is MQA....and turns on the 'blue light'.

 

Stick that header to a non-MQA FLAC file and see what happens......

[asdf1000]

35 minutes ago, FredericV said:

If we play the 24/44.1 MQA files from 2L.no,

 

Here you say it’s a 24/44 MQA file but I linked to an actual 353kHz MQA file/album. I wonder if the same happens, given this file should pack in much more info? 

 

[FredericV]

5 minutes ago, hsmeets said:

 

Implementation by Mytek: perhaps it does not look at the actual encrypted bitstream but only at some value in the header of the FLAC container which says it is MQA....and turns on the 'blue light'.

 

Stick that header to a non-MQA FLAC file and see what happens......

 

Mytek does not know it's a flac of wav. All it sees is PCM. It's a WAV in this test for the 16 bits truncate test.

[FredericV]

5 minutes ago, Em2016 said:

 

Here you say it’s a 24/44 MQA file but I linked to an actual 353kHz MQA file/album. I wonder if the same happens, given this file should pack in much more info? 

 

For 24/88.2, 24/176.4, 24/352.8, .... source files, after encoding the MQA dIstribution files are always 24/44.1

For 48K multiples it's always 24/48

[hsmeets]

Oops, yes it’s a DAC and not a mediastreamer. Well, the MQA signature must then be embedded in more significant bits, so maybe truncate more bits.

[asdf1000]

4 minutes ago, FredericV said:

For 24/88.2, 24/176.4, 24/352.8, .... source files, after encoding the MQA dIstribution files are always 24/44.1

For 48K multiples it's always 24/48

 

Ok, noted.

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

[FredericV]

32 minutes ago, mansr said:

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.

I wonder if MQA CD is just the 24 bits MQA encode truncated to 16 bits. That would only work for masterings in multiples of 44.1K.
Then they can license the 24/44.1 files to Tidal and as also sell as downloads, where the customer has the illusion it's something higher like 176.4K or 352.8K after MQA decoding.
 

[miguelito]

35 minutes ago, mansr said:

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.

But if I understand the original poster correctly, it not only authenticates but somehow is upsampling to 352KHz... How does that work? What is the quality of the signal coming out? Would love to see it. Would also love to see the first unfold of this.

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

[FredericV]

Perl script released under GPLv2:

http://432evo.be/perl/mqastripper.pl
http://432evo.be/perl/mqastripper.txt

I also intend to add a feature where bits 0..7 are replaced by a repeating ASCII string, to see what that does with authentication.        

[NOMBEDES]

This is all very interesting.   But how can all of this manipulation possibly result in better sound?  I don’t care if it is a $50K dCS or a $499. iFI, none of this processing can be good for music — or humans for that matter.

 

I submit that the primary benefit of most digital systems is convenience and, sadly, if you look at other threads on this site, you will see that library management, storage, connectivity and other issues are still major issues.

 

It all makes me wonder if the much maligned, non audiophile, iPod generation has it right, just put your music on a phone and get some ear buds — burn your Stereophile magazines and forget all this digital pain, life is to short.

[esldude]

2 hours ago, NOMBEDES said:

This is all very interesting.   But how can all of this manipulation possibly result in better sound?  I don’t care if it is a $50K dCS or a $499. iFI, none of this processing can be good for music — or humans for that matter.

 

I submit that the primary benefit of most digital systems is convenience and, sadly, if you look at other threads on this site, you will see that library management, storage, connectivity and other issues are still major issues.

 

It all makes me wonder if the much maligned, non audiophile, iPod generation has it right, just put your music on a phone and get some ear buds — burn your Stereophile magazines and forget all this digital pain, life is to short.

This is what is a true shame about High end audio in the modern world.  It leaves one thinking simple is a guarantee of poor quality (30 years ago it was the reverse).  That you need not only superb (and obscenely expensive) gear, but a whole trove of add ons just to get this supposedly great gear to function much at all.  

 

It is not true.  It breeds needless worry for what should be fun hobby.  And it makes this hobby needlessly expensive and complex.  A music lover who appreciates quality sound should get a step off the  bottom rung and ignore the rest of this baloney.  Beyond that you are exactly right.  For everyone else the value proposition is much better to just iphone it and roll on. 

[NOMBEDES]

3 hours ago, esldude said:

This is what is a true shame about High end audio in the modern world.  It leaves one thinking simple is a guarantee of poor quality (30 years ago it was the reverse).  That you need not only superb (and obscenely expensive) gear, but a whole trove of add ons just to get this supposedly great gear to function much at all.  

 

It is not true.  It breeds needless worry for what should be fun hobby.  And it makes this hobby needlessly expensive and complex.  A music lover who appreciates quality sound should get a step off the  bottom rung and ignore the rest of this baloney.  Beyond that you are exactly right.  For everyone else the value proposition is much better to just iphone it and roll on. 

 

 

Post of the day award!!!

[GUTB]

The technical basis of MQA rests on two concepts:

 

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

 

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

 

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, while improving time domain performance.

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

[GUTB]

Just now, mansr said:

That much I agree with.

 

This is patently false.

 

All that can be done using standard FLAC.

 

That's bollox.

 

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

[mansr]

1 minute ago, GUTB said:

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

Show me the maths.

[esldude]

29 minutes ago, GUTB said:

 

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

Maybe we should ask Mr. Craven.

[FredericV]

MQA's time domain is clearly inspired by Ayre's filter:

 

I can do such filters in SOX easily. Not that I prefer them.

[rickca]

1 hour ago, mansr said:

Show me the maths.

Is this your version of show me the money?