MQA disappointing

Audio Gear Talk MQA
2798

ACK! A stupid algebra mistake below. Corrected now.

  • There’s no free lunch. If the objective is to minimize bandwidth, then (on information-theoretic grounds) you’ll do better applying compression to the whole signal, rather than treating the high frequency part of the bandsplit separately.
  • While I agree that the information content of the high frequency part of the bandsplit is lower, that’s not nearly enough. Here’s an experiment you can do to see that’s the case. All of these manipulations are trivially accomplished in ffmpeg or your favourite tool.
    1. Take a 24/96 source file. Let’s call it “2496.wav”.
    2. Downsample it to 24/48. Let’s call the result “2448.wav”
    3. Reduce the bit-depth of both files to 16 bits. Call the resulting files “1696.wav” and “1648.wav”.
    4. Now FLAC compress both of the reduced bit-depth files. Let’s call the resulting files “1696.flac” and “1648.flac”.
    5. size(1648.wav)-size(1648.flac) is how much you can save by compressing the low-frequency part of the bandsplit. size(1696.wav)-size(1696.flac) is how much you can save by compressing the whole thing.
    6. So the difference:
      size(1696.wav)-size(1696.flac)-size(1648.wav)+size(1648.flac)
      is an overestimate of how much you can save by just compressing the high-frequency part of the bandsplit. In other words, size(1696.flac)-size(1648.flac) is an underestimate of how much space you require to store the losslessly-compressed high-frequency part of the bandsplit.
    7. How much space do you have available? That’s
      size(2448.wav)-size(1648.wav)
      assuming (incorrectly) that we can devote all of the LSBs to this task.
    8. So now we just need to compare
      size(1696.flac)-size(1648.flac)
      with
      size(2448.wav)-size(1648.wav)
      to see whether the space required exceeds the space available.
    9. In other words, compute
      size(1696.flac)-size(1648.flac)-size(2448.wav)+size(1648.wav)
      If that number is negative, you win. If it’s positive, I win.

I await the results of your experiment.

You can’t both laud the “scientific” claims for MQA and deride independent efforts to test those claims as “trolling”. Sorry, but that’s not how science works.

In any case, there’s an experiment for you to do, to test one of these claims. If you are really committed to the scientific methods, you’ll post the results here.

Edit: Oh, and don’t cheat, by starting with a 24/96 file that was up-sampled from a 24/48 or, even worse, 16/44.1 source. Start with something with some actual ultrasonic content.

Edit 2: And, just so that you can’t complain that testing your claims scientfically is “too much work”, here’s a shellscript to automate the creation of the files listed above:

#!/bin/sh
ffmpeg -i "$1" -acodec pcm_s24le -ar 96000 2496.wav
ffmpeg -i "$1" -acodec pcm_s24le -ar 48000 2448.wav
ffmpeg -i "$1" -acodec pcm_s16le -ar 96000 1696.wav
ffmpeg -i "$1" -acodec pcm_s16le -ar 48000 1648.wav
ffmpeg -i 2496.wav -acodec flac -bits_per_raw_sample 24 -ar 96000 2496.flac
ffmpeg -i 1696.wav -acodec flac -bits_per_raw_sample 16 -ar 96000 1696.flac
ffmpeg -i 2448.wav -acodec flac -bits_per_raw_sample 24 -ar 48000 2448.flac
ffmpeg -i 1648.wav -acodec flac -bits_per_raw_sample 16 -ar 48000 1648.flac
ls -l

Just call it on any 24/96 file in any format (FLAC, ALAC, WAV, …).

1 Like