09-Jan-2016, 06:45
Hi, sleach. The phrase "They are telling us" is exactly the part that is the marketing. Can't blame you for falling for it, as these "claims" are repeated on almost every review site. Notice, however, that these things are said only by the reviewers, and not claimed by Meridian at all. In fact, the patents for the technology are completely open. The one you might want to read is WO2013061062 and WO2013186561. The latter explains the main idea of MQA, but the former is important to understand one of the ways how it's done. There is nothing lossless about making the stream playable on legacy PCM players, and nothing lossless about adding watermarks to the stream either.
So what happens to your audio stream is this: take any input stream with quality higher than 44/16, for this example, using a 192/24 stream (you'll see that tech is same for any input stream).
Now let's get the 3 features: playback on legacy devices + watermarking(+DRM) + lossy fallback, step by step:
To get the lossy "regular PCM" playback on legacy 44/16 devices, you need to supply a 44/16 PCM stream.
To do that you will need to resample your original stream into 44/16, while applying some sort of a dither. Read details of this and other tricks in the first patent, but basically you dither the least-important 3 bits of the 16bit 44/16 stream, using a data stream as dither. In this data stream you insert the watermark as well as a compressed (lossy) difference between the original 192/24 signal and the 44/16 signal that "legacy PCM equipment" would play. So you get a 44/16 stream which includes a data stream of less than 16KByte/sec (3bit*44khz=132kbit/sec) to decode lossily the original 192/24 signal. Now difference between original 192/24 stream and this high-quality lossy stream is again compressed into a separate data stream, hopefully fitting into 8bits added to 44/16 stream, so extra 44KByte/sec data bandwidth. (8bits*44Khz=352Kbit/sec=44KByte/sec)
Results:
Using the 44/16 stream on a legacy 44/16 device, you get playback _almost_ like the original signal resampled to 44/16. (almost because it's dithered with some data stream and not a standard dither, but if the data stream is compressed enough, it should be almost indistinguishable).
Using the 44/16 stream on an MQA-understanding device, you get a lossy version of your original signal. So you get 192/24 if you had 192/24 before, but compressed and decompressed lossily. It's lossy because it tries to compress difference between the original 192/24 stream and the 44/16 stream inside just <16KByte/sec data stream(3bits*44khz=132Kbit/sec). On lots of content with little data in higher frequencies it will be enough, but please not that it's still lossy compression.
Using a bigger 44/24 (or higher) MQA stream, you losslessly get your original 192/24 stream, by first playing the 44/16, then applying the lossy 16KByte/sec data stream correction to get it to a lossy 192/24, and then applying the 44KByte/sec data stream correction to fix the errors left and get to lossless quality.
In the end, you compress the 192/24 stream into, say, 44/24, getting legacy-playable 44/16 along the way. But because you need to keep the 44/16 stream legacy-playable, you lose a lot of bandwidth that could be compressed.
This is why at least in theory, FLAC/ALAC (which can compress everything) can get much better lossless compression.
The examples given by MQA were that for 48/24 stream, it compresses into 44/16's 1.4Mbit stream. Well, FLAC can fit 96/32 input into a ~3Mbit stream today, so there's nothing magical in that.
What MQA also provides, and which may be more important and a reason NOT to support it by public, is DRM. As both correction ("touchup") streams are just data streams, they can easily be encoded by some secret key, (akin to current HDCP signals over HDMI) which will make it impossible to make open-source/homebrew hardware or software to decode licensed MQA files, at least until the secret key is extracted from one of the licensed players. Or maybe the DRM scheme is even more involved, in which case, even more reason to forget about MQA.
TLRD: MQA gives differently-dithered but legacy-playable 44/16 PCM stream with embedded ~10KByte/sec data stream for DRM/watermark and lossy full-signal playback, and extra ~40KByte/sec or bigger data stream to fix lossy full-signal to lossless quality. Because of this approach it cannot compete on lossless compression with standard formats which do not need to keep uncompressed PCM streams or embed watermark/DRM data.
So what happens to your audio stream is this: take any input stream with quality higher than 44/16, for this example, using a 192/24 stream (you'll see that tech is same for any input stream).
Now let's get the 3 features: playback on legacy devices + watermarking(+DRM) + lossy fallback, step by step:
To get the lossy "regular PCM" playback on legacy 44/16 devices, you need to supply a 44/16 PCM stream.
To do that you will need to resample your original stream into 44/16, while applying some sort of a dither. Read details of this and other tricks in the first patent, but basically you dither the least-important 3 bits of the 16bit 44/16 stream, using a data stream as dither. In this data stream you insert the watermark as well as a compressed (lossy) difference between the original 192/24 signal and the 44/16 signal that "legacy PCM equipment" would play. So you get a 44/16 stream which includes a data stream of less than 16KByte/sec (3bit*44khz=132kbit/sec) to decode lossily the original 192/24 signal. Now difference between original 192/24 stream and this high-quality lossy stream is again compressed into a separate data stream, hopefully fitting into 8bits added to 44/16 stream, so extra 44KByte/sec data bandwidth. (8bits*44Khz=352Kbit/sec=44KByte/sec)
Results:
Using the 44/16 stream on a legacy 44/16 device, you get playback _almost_ like the original signal resampled to 44/16. (almost because it's dithered with some data stream and not a standard dither, but if the data stream is compressed enough, it should be almost indistinguishable).
Using the 44/16 stream on an MQA-understanding device, you get a lossy version of your original signal. So you get 192/24 if you had 192/24 before, but compressed and decompressed lossily. It's lossy because it tries to compress difference between the original 192/24 stream and the 44/16 stream inside just <16KByte/sec data stream(3bits*44khz=132Kbit/sec). On lots of content with little data in higher frequencies it will be enough, but please not that it's still lossy compression.
Using a bigger 44/24 (or higher) MQA stream, you losslessly get your original 192/24 stream, by first playing the 44/16, then applying the lossy 16KByte/sec data stream correction to get it to a lossy 192/24, and then applying the 44KByte/sec data stream correction to fix the errors left and get to lossless quality.
In the end, you compress the 192/24 stream into, say, 44/24, getting legacy-playable 44/16 along the way. But because you need to keep the 44/16 stream legacy-playable, you lose a lot of bandwidth that could be compressed.
This is why at least in theory, FLAC/ALAC (which can compress everything) can get much better lossless compression.
The examples given by MQA were that for 48/24 stream, it compresses into 44/16's 1.4Mbit stream. Well, FLAC can fit 96/32 input into a ~3Mbit stream today, so there's nothing magical in that.
What MQA also provides, and which may be more important and a reason NOT to support it by public, is DRM. As both correction ("touchup") streams are just data streams, they can easily be encoded by some secret key, (akin to current HDCP signals over HDMI) which will make it impossible to make open-source/homebrew hardware or software to decode licensed MQA files, at least until the secret key is extracted from one of the licensed players. Or maybe the DRM scheme is even more involved, in which case, even more reason to forget about MQA.
TLRD: MQA gives differently-dithered but legacy-playable 44/16 PCM stream with embedded ~10KByte/sec data stream for DRM/watermark and lossy full-signal playback, and extra ~40KByte/sec or bigger data stream to fix lossy full-signal to lossless quality. Because of this approach it cannot compete on lossless compression with standard formats which do not need to keep uncompressed PCM streams or embed watermark/DRM data.
