advertisement


MQA beginning to see the light?

MQA is not lossless.
The FLAC and WavPack experiments we have done are bit perfect to 20kHz to the 16 bit level and 20 bit almost up to 10kHz.
Resolution goes down towards 48kHz just like MQA does

I did think that MQA was lossless upto 20khz in 24 bit, and lossy above 20khz.

I'm conscious that MQA has been previously criticized for not being lossless across the full frequency range. Suggesting another format that can't achieve 24 bit (regardless of the benefits of 24bit over 20bit) is going to be a HARD sell to elements of the audio fraternity.
 
One point about bitfreezing, packing, or scaling down the resolution is that it can be targetted to simply reduce the redundant over-use of the lsb for noise. From my tests simply doing this tends to roughly halve the size of a flac file and need not lose any real signal. So is essentially lossless. And simple freezing can be played as per normal for flac or wave lpcm.

This could be used quite separately from applying emphasis before freezing/packing/etc. That can again about halve the size by sacrificing resolution for HF - similar in result to MQA. It then need correction on replay, but this can already be done with existing software.

So these approachs offer a choice. The users can decide how to trade off a reduction in file size (stream rate) against any decision to lose HF resolution.
 
I did think that MQA was lossless upto 20khz in 24 bit, and lossy above 20khz.
.

My understanding was that the MQA argument was to use the least significant bits of 48k/24 to give the HF 'hints'. i.e. The LF info would then be less than 24bit resolution.

So in Information Theory terms this isn't really much different to bitfreezing, etc. Just a matter of the recipy being used. In both cases it will be likely that most of the lowest bits will be noise in the first place. *If* this is the case and only the 'below noise' bits are affected MQA and the alternatives we are discussing could both be said to be 'lossless'. Above that, any changes by any system risk causing loss of details.

However the difficulty here with MQA is that by *using* these lsb for 'other purposes' rather than freezing them, the risk arises that this *non*-noise pattern will affect what is sometimes produced when replayed as if it were LPCM by non-MQA devices. Bitfreeing or reducing the resolution need not expose users to this risk. MQA *adds* some patterns which replace the lsb of noise. Bitfreezing or resolution reduction *remove* the excess noise and don't replace it with any other variations which would add to LPCM replay.

Information Theory generally shows us that there are many ways to skin a cat. Just a question of devising and choosing the one that suits best in a given case.

BTW I should perhaps declare an unusual POV on the above. I spend time in former employment working on hiding and uncovering patterns hidden by noise. This wasn't for audio, but the same IT basics apply.
 
I did think that MQA was lossless upto 20khz in 24 bit, and lossy above 20khz.

I'm conscious that MQA has been previously criticized for not being lossless across the full frequency range. Suggesting another format that can't achieve 24 bit (regardless of the benefits of 24bit over 20bit) is going to be a HARD sell to elements of the audio fraternity.
I don't think MQA is "lossless" to 24 bit below 20khz -see
http://archimago.blogspot.co.uk/2016/02/measurements-impressions-meridian.html?m=1

I can't really see how it could be since it uses those lower 8 bits. I'm not even sure it's lossless to 16 bits.
 
My understanding was that the MQA argument was to use the least significant bits of 48k/24 to give the HF 'hints'. i.e. The LF info would then be less than 24bit resolution.

So in Information Theory terms this isn't really much different to bitfreezing, etc. Just a matter of the recipy being used. In both cases it will be likely that most of the lowest bits will be noise in the first place. *If* this is the case and only the 'below noise' bits are affected MQA and the alternatives we are discussing could both be said to be 'lossless'. Above that, any changes by any system risk causing loss of details.

.
I understand what you mean by lossless here Jim, but it's difficult to avoid a sense of the absurd about all of this because frankly the likelihood is slim that anyone can here any difference between 16/44, 24/96 and whatever MQA is on the same master. It seems 2L got round this by using different masters. There is an air of unreality about discussing what is and isn't lossless to 24/96, or indeed to DXD. Does increasing the noise level slightly over the noise floor of the recording relevant? Does the length of ringing around 48khz matter?
 
Just bought Stereophile. My understanding is that in a 44.1/24, MQA replaces approximately 8 lsbs with an encoding of the data covering 22k to 44k. This is scrambled to resemble noise and might be compressed or even lossy compressed. This means the <22k part is bit transparent to only around 16 bit.
 
Just bought Stereophile. My understanding is that in a 44.1/24, MQA replaces approximately 8 lsbs with an encoding of the data covering 22k to 44k. This is scrambled to resemble noise and might be compressed or even lossy compressed. This means the <22k part is bit transparent to only around 16 bit.

The idea that the lsbs can be lossy compressed is curious. I'd assume that would lose being able to recover the 'hinting'.

However the implication is that a fair comparison would be to freeze the ls *8* bits of 96k/24 material and simply leave in the HF. I'd be inclined to ensure this was done with noise shaping, though. So to test it I'd need to modify the programs I've written to add in a simple noise shaping. I guess a simple first order carryover would do given that the rate remains 96k (unlike MQA cutting it to 48k).
 
FWIW provided a process only removes the 'excess noise bits' it can be said to be lossless. Beyond that any changes may mean *some* loss in terms of theory, and you then may need to get into arguing about how many angels can dance on the head of a pin before you can hear a change in how many are dancing. 8-]

Personally, I think it makes more sense for streaming, etc, to keep the rate high and eat the noise. Avoids the bother of trying to hide the HF under the LF and ensure the eggs can be unscrambled *and* that you didn't mess up ordinary lpcm replay.

The history of the music biz being what it is, once they use it, we'd get examples where they messed up the removal and/or the 'hidden patterns' affect the result when played non-MQA. If you think about it, they may not care about the latter as it might just encourage people to decide "MQA is better" and buy into it without realising what happened.
 
Out of curiosity I just quickly tried using sox to convert the 2L example (Britten Bridge Vars) into a 96k/16 flac. This reduced it to about10 MB from the original 27.275. Applying treble -40 20k 1.0 to shade off the HF got a file size of 8.751 MB. Using 'flac -8' would perhaps get these values a bit smaller. But I guess this reflects that it isn't 'hinting' about the HF but largely preserving it.
 
The idea that the lsbs can be lossy compressed is curious. I'd assume that would lose being able to recover the 'hinting'.
Start with a 88.2/24 file - A
Downsample to 44.1/16 - B
Construct a 44./24 - C, where the first two bytes of each sample are the 44.1/16 data from B - this chunk is the legacy CD quality part
Take the difference between A and B, which will be >22kHz audio and LF noise
Compress this to fit in the "spare" low byte in each sample in B.
There is no point storing this as LPCM as it would confuse flac etc and would be potentially audible, so it has to be scrambled to become noise like. We might as well flac it first or even do a lossy compression. Lossy is even more attractive if we are tying to squeeze the HF residual from a 196k or more file into this spare byte. It's a quart into a pint pot problem.
 
Various problems arise in practice. The one that bothered me is trying to divide and then recombine. It places a serious restriction on the pairs of filters to be used and may mean both 'leak' - which would be bad news if you want to confine the results into two different bands help seperately. Unless you employ something heavy like an FFT split built to give a very sharp crossover indeed.

Given that we've already managed to match the /4 filesize reduction *without* having to band split it seems to me that here the simpler method of not splitting works fine. No real need for the bother of split and glue.
 
Filtering and recombination is the hard part. The most extreme case would be simply taking alternate 88.2/24 samples, truncating to make the lpcm compatible part of 44.1/24 and encoding the rest. This would be easy to implement, but suffer from aliasing.
As time and time again reviewers like aliasing dacs, this is a possible explanation for preference of MQA
Not being able to make a MQA file with test tones stops us ruling this out
 
I've not read up much on this MQA thing yet as at this point it doesn't apply to anything I use, as such please forgive the following question should it appear daft...

If this high-res streaming format takes off will it always require a hardware decoder such as a Meridian Explorer DAC, or could the decoding/decompression take place in say a Tidal or Spotify app running on a Mac/PC which would then output standard high-res PCM to a standard external DAC?
 
or could the decoding/decompression take place in say a Tidal or Spotify app running on a Mac/PC which would then output standard high-res PCM to a standard external DAC?

In part. The best thing so far is the BS Node 2 which after a firmware update days ago partially decodes MQA to dual rate (i.e. from 44.1 or 48 to 88.2 or 96) and outputs that on its SPDIF interface.
 
At present I don't think I could give a definitive answer to your question, Tony. The statements and 'answers' I've read are too ambiguous and before-the-fact. However it seems likely that some companies would be licensed to sell closed-source replay software. The uncertainy being if that would then try to block fully decoded LPCM being sent out of a computer to, say, a non-MQA DAC. And if it did try to control something like that, how successful it might be. As per the 'BS' example, what happens might vary, and possibly sometimes occur because it 'slipped past' those controlling MQA.
 
Filtering and recombination is the hard part. The most extreme case would be simply taking alternate 88.2/24 samples, truncating to make the lpcm compatible part of 44.1/24 and encoding the rest. This would be easy to implement, but suffer from aliasing.
As time and time again reviewers like aliasing dacs, this is a possible explanation for preference of MQA
Not being able to make a MQA file with test tones stops us ruling this out

Yes. One of my concerns wrt this 'split and then recombine' idea is that it can lead t all kinds of problems - particularly when people cluelessly 'mastering' get their hands on it.

Real-world filters have to trade off various competing requirements. So in this case there would be some tendency to add variations in the response around the 'dividing line'. Plus aliasing sprayed into the area of the spectrum. Trying to 'brickwall filter' the division reduces that, but then means a tendency for long filter profiles that will tend to ring.

And what might be optimum for split and combine may well *not* be optimum for those who are left with lpcm and then listen to the LF part alone as if it were LPCM. It is quite likely that what filter is best for one use is *not* best for the other

All this may be fine if you can cover the details in secret sauce. But may mean when people do comparisions and say "Having compared by ear I prefer MQA to the LF-only as LPCM" what they *might* really mean is that "The LF part has been degraded by the process altering it to get an LF part that recombines best with the HF hints."

It's the HDCD problem again. What you get as 'LPCM' has been altered to suit best some *other* form of replay. You then can't compare the fancy version with what would have been a well made plain version because that's *not* what you've been sold.

Given the demands on the split and combine imposed by the result having to be 'high quality' I can easily see the LF part alone ending up being degraded. Indeed, that happening might be seen by some as a useful way to nudge people towards paying for MQA decoding. All covered in secret sauce...

Given all this, keeping the sample rate and not splitting seems far more sensible to me. The tests we've done show you can reduce the filesizes that way in a way the matches MQA, and it avoids the almost-impossible - and conflciting! - demands of the magical split and recombine.
 
I've not read up much on this MQA thing yet as at this point it doesn't apply to anything I use, as such please forgive the following question should it appear daft...

If this high-res streaming format takes off will it always require a hardware decoder such as a Meridian Explorer DAC, or could the decoding/decompression take place in say a Tidal or Spotify app running on a Mac/PC which would then output standard high-res PCM to a standard external DAC?

As Jim's already stated, Bluesound have recently announced their new (android IIRC) based streamer. That will include software decoding of MQA.
That certainly infers that the doors are now open for others to license software decoding, and personally I'm hoping that it will include Roon.

As most of these devices will output via SPDIF, I see no feasible way to control the DAC on the backend, so I'm not quite sure where control concerns are coming from.

One part of MQA to consider however is the logic of it. In theory, I think it's meant to add a filter to cater for the ADC during recording, do it's folding/unfolding, then add another filter to cater for the characteristics of the output DAC. My assumption is that some kit will be able to have plug-in software filters built for external DACs. Clearly, if the MQA decoder is unaware of the DAC (either you've not told it, or no one's built one for the DAC in question), then some of the benefit will be lost. Quite how important that is, we simply don't know right now.
 
And what might be optimum for split and combine may well *not* be optimum for those who are left with lpcm and then listen to the LF part alone as if it were LPCM. It is quite likely that what filter is best for one use is *not* best for the other

All this may be fine if you can cover the details in secret sauce. But may mean when people do comparisions and say "Having compared by ear I prefer MQA to the LF-only as LPCM" what they *might* really mean is that "The LF part has been degraded by the process altering it to get an LF part that recombines best with the HF hints."
Two points here,
The demands of splitting and recombining mean that FIR filters are a likelier bet than IIR types.

The word "hints" is far too mild. Roughly the bottom byte (maybe a little more) of the 3 in a 24k sample have been completely repurposed to carry HF data, scrambled/encrypted to look like noise
 
Agree about the comment re FIR. However that doesn't change the concerns re tradoffs, etc.

One curio of using an entire bit per sample as info prentending to be noise is that this would losslessly compress very badly as well as being easily scrambled and lost. Given that, anyone who just wants 16bit would be better off downloading or streaming 16bit. And those who want 96k would be just as well using the open alternative as using the 2bytes LF 1byte HF 48k MQA. So on that point MQA doesn't have any performance advantages.

The comments about DACs is a reasonable one. But the reality is that makers of DACs or those using computer software can choose the DAC model they want anyway given that the MQA 'ideal' ADC model is known. Even *I* have been able to write some simple demos that let users synth a DIY replay filter shape. This is now fairly easy when people play material though a DAC that can accept higher rates than the material. I had wondered why people aren't already experimenting with this approach. Have I missed it, or haven't people twigged?

I confess I doubt the practicality of an MQA argument that it will fully define the ADC. Partly a problem with "Unknown unknowns" and partly that there may be more than one ADC/process chain involved, more than one microphone type, etc. Somehow I doubt that most real studios would *really* measure this for their entire chains and produce full and accurate details which could usefully be used. I doubt any know if you push this up to the '10 meters of air' level. 8-] That aspect does seem to me a theorists fantasy whichI wonder if real injuneers wouldn't think worth even trying in a working studio. And at lower levels, if all they have to do is correct for mics, old analogue tapes, etc, they can do that anyway when processing the plain LPCM.

BTW Got the email and tarball OK. Thanks. :)

I fear it will take some days to write all this up, though. Hope to start soon.
 
One curio of using an entire bit per sample as info prentending to be noise is that this would losslessly compress very badly as well as being easily scrambled and lost. Given that, anyone who just wants 16bit would be better off downloading or streaming 16bit. And those who want 96k would be just as well using the open alternative as using the 2bytes LF 1byte HF 48k MQA. So on that point MQA doesn't have any performance advantages.
This is why the HF content and LF residue have to be compressed, either losslessly truncated or all out lossy before scrambling. Trying to compress random data achieves nothing, often a bigger file than the raw. Flac will compress the total to about

[(2x50%)+(1x100%)]/3 = 67% of the 44.1/24 wav file size
or 33% of the original 88.2/24

1 byte of MQA data is describing 4 bytes in the original lpcm file, so no way it can be truly lossless. If the master is >88k, the compression must be more drastic
 


advertisement


Back
Top