MQA technical analysis

[FredericV]

Just analyzed 2L-053_04_stereo-DXD.flac and it's MQA counterpart.

Dark purple is what MQA keeps after full unfold, light purple is the original file.

Some reviewers still believe MQA encodes information above 24/96 ..... they are clearly misinformed and spreading these false claims. Like spreading fake news.

[FredericV]

My overlay was not 100% correct in the gimp, here's the correct one now.

It shows the energy in the ultrasonics has mostly gone.
 

[FredericV]

I'm having a bad gimp overlay day. My previous overlays don't combine well.

So here are the two.

DXD:



Second unfold:


 

Second unfold creates content that was not even in the original.

[FredericV]

7 minutes ago, Shadders said:

Hi,

With regards to the delivery of the sound of the studio - this is impossible, as the studio uses lossless encoding, MQA is lossy with distortion (aliasing) - certainly not studio sound.

Indeed almost impossible and not for the typical audiophile MQA is trying to lure into their DRM ecosystem. Here's an approximation with monitors which are also in grammy award winning studio's, the difference between nearfield and farfield is quite dramatic:

 

I did all our shootouts related to claims about studio formats in nearfield. All mistakes in MQA were revealed very easily.

[FredericV]

26 minutes ago, jabbr said:

Yes, and I am saying that the appropriate place to apply this correction is at upsampling. One can apply upsampling, correction(s), digital crossovers etc at one point.  That would be real end-to-end.

That's what I do. Upsample to a very high resolution my DAC still supports (24/352.8) and run one simple parametric equi filter on the outcome to kill the room mode which in my case is 33 Hz being boosted with almost 10dB by the room. So this correction is done in the digital domain before sending the PCM to the Metrum DAC.

This is a good test track that will hit your room modes easily:
 

So to make this 33 Hz problem go away, I could put a lot of bass traps in the room, or just one line of sox filter recipes.

All measurement systems that I used show the exact problem: Velodyne's Digital Drive measurement system, REW, Anthem ARC, Dirac Live: 33 Hz is a big problem in my room. This is why for a a long time I could get away with the very small Marten Duke 2 monitors, which were rolling off somewhere below 40 Hz, but the room mode compensated for it.

With the Kryptons which go all the way down to 22 Hz, I can't get away with it, and not being allowed to correct this room mode, a right which MQA takes away: no thanks.

I use Amphion Krypton 3 on a Vitus SS-025 power amp connected to Metrum's flagship Adagio DAC:

 

 

[FredericV]

I had some fun with band splitting and compressing ultrasonics of an AIX based recording, which has actual ultrasonic content.
 

So I did a little experiment to see if we can flac compress the ultrasonics of a 24/96 recording in the space available in the bottom 8 LSB bits of a 24/48 file.
 

24/96 WAV file, source file size is 160M

First thing is to only keep the ultrasonics, and then normalize them (the gain factor could be stored in the metadata stream - MQA also has gain parameters encoded). While the stock highpass filter of sox is not very steep, and there is audible treble + ultrasonics in the new file, for this experiment it will probably suffice. Further fine tuning: please peer review So it contains a little bit too much data but we will fix this later.

#sox "03 - Leaning Post.wav" ultrasonics-24b-normalized.wav highpass 24000 norm

 

Then we create 8 and 16 bit dithered versions of the normalized ultrasonics:

 

#sox ultrasonics-24b-normalized.wav -b 8 ultrasonics-8b-normalized.wav
#sox ultrasonics-24b-normalized.wav -b 16 ultrasonics-16b-normalized.wav

 

Now check the bit depth of these new files:

 

# file ultrasonics-16b-normalized.wav
ultrasonics-16b-normalized.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 96000 Hz
# file ultrasonics-8b-normalized.wav

ultrasonics-8b-normalized.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, stereo 96000 Hz

The 16 bit ultrasonics sound very good, no audible noise.
The 8 bit ultrasonics sound like crap because of the added noise - but we will devise a way to kill it later.
 

The requirement is then, that the 24/48 WAV file which is half the size of the 24/96 WAV file, has 1/3 allocated for the hi-res part, so this is 1/6 of the original file size. So can the highres part of this file fit in 26.67 megabyte?
 

Let's compress the ultrasonics with flac (as we have 1/6 of the original channel for the hi-res part, we will need to compress it anyway as it will otherwise never fit):

8 bits dithered ultrasonics compress very well with flac --best:
ultrasonics-8b-normalized.wav: wrote 9970824 bytes, ratio=0.187

16 bits dithered ultrasonics take almost 3.75x the size of 8 bits ultrasonics
ultrasonics-16b-normalized.wav: wrote 37279220 bytes, ratio=0.350

Are 8 bits of dithered ultrasonics with a gain factor enough? Probably yes

So from this little experiment, it's obvious MQA can't do 16 bits of lossless encoded ultrasonic resolution in it's 1/6 hi-res channel (based on the source being 24/96), but 8 bits ultrasonics are clearly possible, and something in between is probably also possible - but does MQA actually dynamically allocate the bit depth for the hi-res part, or is it fixed at 8 bits resolution + gain factor ?
 

# du -h -s --si "03 - Leaning Post.wav" ultrasonics-16b-normalized.flac ultrasonics-8b-normalized.flac
160M    03 - Leaning Post.wav
38M     ultrasonics-16b-normalized.flac
10M     ultrasonics-8b-normalized.flac

The 24/48 distribution file will be a 80M file, as it contains exactly half of the samples of the 24/96 original. So 1/3 of this file will be used for ultrasonics.

The main problem is that ultrasonics-8b-normalized.flac contains a lot of broadband noise also contaminating the baseband, because of the dithering to 8 bits. Can we kill the noise, so the noise only remains for the content region, so the treble + ultrasonics?

The first thing I did was change the bit depth of ultrasonics-8b-normalized.flac to 16 bits:
sox ultrasonics-8b-normalized.flac -b 16 ultrasonics-unfolded-to-16bit.wav

Then in audacity, I loaded both ultrasonics-16b-normalized.flac and ultrasonics-unfolded-to-16bit.wav and for the second one, applied a 16 Khz 24dB/octave highpass to kill the noise. You can still see that the bottom track has slightly more noise, and this sounds like high frequency hiss on max volume.

But except for some hiss, both 8 bit vs 16 bit hi-res parts sound identical at max volume on my system.

Note that because we first normalized the hi-res part, we should now attenuate it, so the total hiss of this part of the spectrum is also much lower, and this spectrum has to be mixed with the baseband signal, probably completely masking the added noise to the ultrasonics by MQA.

Probably with enough sox & flac one liners, we can replicate the basic folding/unfolding principle with open source tools

Based on this research, allocating 26.67mbyte when 10 mbyte would suffice looks like a big waste of bandwidth by MQA. Off course this distribution file goes through flac compression, and the hi-res part is first scrambled with pseudo random noise for those without an MQA decoder (which also kills the efficiency of the flac encoder), but still it confirms MQA is not so elegant in terms of compression compared to flac entropy optimization techniques.
 

Please note: except for the 24/96 source files, all content in this post (C) Frederic Vanden Poel. Non-exclusive license to AS and it's members is given for sake of peer review.