MQA is Vaporware

[lucretius]

14 minutes ago, Miska said:

Why would I care? They claim to save bandwidth, and whatever bandwidth they end up using is what matters.

 

I agree in principle.  I just wanted to make sure we were comparing apples to apples.  

[crenca]

20 minutes ago, lucretius said:

 

What are you talking about? When you produce a flac file (MQA or otherwise), you choose compression or no compression and if the former, the level of compression.

 

Your stuck in a narrow understanding of "compression" (see Miska's two posts above), that's what I am talking about.  

 

You claim your software is not decoding.  It is completely MQA unaware, or you have turned decoding off?  Your results don't add up.  You claim to be FLAC compressing MQA to the nearly exact same size as the equivalent 24/96 file, something that does not make sense.  So I am looking for where you made an error.  I suspect you are not capturing what you are thinking/asserting what you are capturing.

 

Perhaps however that the track you are using is fake High Res and that is throwing your results off...

[mansr]

Using three samples arbitrarily picked from the 2L collection, I recompressed the MQA version using FLAC level 8. This reduced the size somewhat compared to the files as supplied by 2L. I then converted their original version to 44.1 kHz 24-bit using SoX and compressed this at FLAC level 8. Finally, I converted the original to 88.2 kHz 18-bit, also compressed at FLAC level 8. These are the resulting file sizes:

        MQA       24/44.1   18/88.2
2L-053  37862623  36853248  36461170
2L-106  49633139  47950023  42431452
2L-111  14497235  13809502  11675747

Note that the MQA file is the largest in all cases. Even Bob Stuart admits that MQA only preserves up to 17 bits or so of precision, so comparing this to a plain 18/88.2 FLAC is perfectly reasonable. No matter how you look at this, MQA loses.

[lucretius]

19 minutes ago, Miska said:

You can easily run their MQA files through "flac -d" and then do "flac --best" after that and see if it gets better. But I'm pretty sure that what ever you do, 88.2/16 or 96/16 plain "flac --best" encoded version is smaller than the equivalent MQA one.

 

It may well be that the plain version is smaller that the equivalent MQA one.  I tested only one MQA track against its HDtracks counterpart and the file sizes turned out very close.  Maybe that was a fluke.

[crenca]

9 minutes ago, lucretius said:

 

I agree in principle.  I just wanted to make sure we were comparing apples to apples.  

 

Then take the capture/decoding question out of it.  Download MQA and equivalent PCM files from 2L or some other source and FLAC it..

[lucretius]

Just now, crenca said:

 

Then take the capture/decoding question out of it.  Download MQA and equivalent PCM files from 2L or some other source and FLAC it..

 

No need. See Mansr's post above.

[kumakuma]

1 hour ago, Sonicularity said:

When you don't intend to ever provide the means for anyone that does not sign an NDA to be able to convert a file to MQA, claims of saving 80% on storage size can be made on a blog with comment features disabled.

 

Perhaps comments were disabled to make the blog smaller.

[new_media]

54 minutes ago, kumakuma said:

 

Perhaps comments were disabled to make the blog smaller.

 

The comments are folded into the least significant bits of the blog posts, but you need proprietary hardware to read them.

[Paul R]

3 hours ago, Miska said:

But mathematically, MQA is losing on FLAC compression because the encoded/encrypted stream portion of the stream ends up being looking like white noise which is uncompressible by lossless compression algorithms. So from that perspective you get better results when FLAC can actually see the full proper original spectrum plain, as it expects.

1

 

Just trivia I suppose, but I thought it looked more like image data, still irritatingly hard to compress.  Though - isn't the stored data stashed away in the high spectrum already compressed? 

 

-Paul 

 

[Miska]

14 minutes ago, Paul R said:

Just trivia I suppose, but I thought it looked more like image data, still irritatingly hard to compress.  Though - isn't the stored data stashed away in the high spectrum already compressed? 

 

Since FLAC is not lossy, there's no throwing away. While MQA folding process making the 1x "base band" look exceptionally noisy for FLAC encoder. So from compression perspective, FLAC encoder is seeing MQA  as 44.1/24 or 48/24 content with exceptional amounts of random noise. More randomness you have, less compressible it is.

 

If MQA would do it correctly, they would first compress and then encrypt/fold, but then it wouldn't be anymore playable at all without a decoder. So what they do is trade off bandwidth to allow "unlicensed no-decoder" devices to play the very noisy version of base-band. So instead of saving bandwidth they actually consume more to enable their two-tier model.

 

Overall, with MQA you get best results by just software-unfolding it to 88.2/96k and then using normal oversampling filters (be it DAC, software or whatever else) instead of theirs to produce final output rate.

 

[Les Habitants]

18 hours ago, Paul R said:

Also, what possible purpose could I have for lying? It's unimaginable.  I just like to talk to people. -PR

 

Wow so you really did roam the streets of Cheyenne, interviewing hundreds of audiophiles, all of whom were giddy over the MQA sound quality on their Tidal HiFi tier subscription?

Tas de merde...

[The Computer Audiophile]

17 minutes ago, Les Habitants said:

 

Wow so you really did roam the streets of Cheyenne, interviewing hundreds of audiophiles, all of whom were giddy over the MQA sound quality on their Tidal HiFi tier subscription?

Tas de merde...

Here is your one and only warning. Next time you’re gone.

 

Treating people this way isn’t allowed here. 

 

[mansr]

I thought he was referring to TAS.

[miguelito]

On 5/3/2019 at 9:55 AM, mansr said:

The fact that they are increasing the bitrate also suggests that bandwidth isn't an issue. What was the point of MQA again?

The point was to make money for Bob Stuart. The fact that his initials are BS is just so right.

[Paul R]

57 minutes ago, Les Habitants said:

 

Wow so you really did roam the streets of Cheyenne, interviewing hundreds of audiophiles, all of whom were giddy over the MQA sound quality on their Tidal HiFi tier subscription?

Tas de merde...

 

Well, no. I never said I roamed the dang streets. To begin with, Cheyenne doesn't have that many streets - but what it does have is thriving if small audiophile community, and I can say the ones I met were welcoming, friendly, and really thirst for information about everything audiophile. The few systems I heard were really well put together, most better than mine.

 

 Where did you get that from?  And I was specific to say over a much larger area and tagged it as possibly non-representative or just a regional thing. It may have sounded to you like I was trying to make out like an expert, but I wasn't. If so, I apologize for that. 

 

On the other paw my french is a tas rusty, but - 

 

Votre mère sait-elle ce que vous dites en public? 

[lucretius]

5 hours ago, crenca said:

You claim your software is not decoding.  It is completely MQA unaware, or you have turned decoding off?  Your results don't add up.  You claim to be FLAC compressing MQA to the nearly exact same size as the equivalent 24/96 file, something that does not make sense.  So I am looking for where you made an error.  I suspect you are not capturing what you are thinking/asserting what you are capturing.

 

Perhaps however that the track you are using is fake High Res and that is throwing your results off...

 

First, the software is not decoding -- the resulting file is bit perfect. Duh?  Second, the 24/96 file was re-sampled to 24/48 with the same level of compression. Could well be the 24/96 file (HDtracks) is fake hi-res -- there are so many of them.

 

I do note that the files Mansr tested were all MQA'd from DXD (24/352.8). I'm wondering if it makes a difference if the source file was only 24/96?

 

 

[crenca]

2 minutes ago, lucretius said:

I do note that the files Mansr tested were all MQA'd from DXD (24/352.8). I'm wondering if it makes a difference if the source file was only 24/96?

 

 

What software are you using to stream (I assume a Tidal desktop app of one sort or another - not a third party MQA aware app like Roon, etc.), and what software are you using to capture?  There must be some reason for your results which swim upstream to both theory and empirical results of others.

 

Also, since MQA is only capable of encoding actual data up to 24/96 (everything after that is upsampling), it should not make a difference at all...

 

 

[lucretius]

20 minutes ago, crenca said:

 

What software are you using to stream (I assume a Tidal desktop app of one sort or another - not a third party MQA aware app like Roon, etc.), and what software are you using to capture?  There must be some reason for your results which swim upstream to both theory and empirical results of others.

 

Also, since MQA is only capable of encoding actual data up to 24/96 (everything after that is upsampling), it should not make a difference at all...

 

 

 

I am using Roon as the initial player (since it streams Tidal). See settings:

 

 

Note that the MQA Capabilities setting is "Decoder and Renderer"; that turns off software decoding as it is expecting the DAC to do it. In any case, if the software was decoding the MQA stream, I definitely would not get a resulting file that is bit perfect (confirmed by playing this file and getting the blue light, etc.)

 

As I said on previous posts, the recording software is Sound Forge. (I could not get Audacity to work with the WASAPI driver and with the MME driver it was not bit perfect.)

 

In reference to Mansr's files, etc, it could be that the MQA process is encoding more noise into the resulting MQA file when the source file is of a higher bit rate (i.e. 24/352.8 as in the case of the 2L files).

[mansr]

7 minutes ago, lucretius said:

In reference to Mansr's files, etc, it could be that the MQA process is encoding more noise into the resulting MQA file when the source file is of a higher bit rate (i.e. 24/352.8 as in the case of the 2L files).

No, MQA doesn't work like that. The encoder downsamples higher rates to 88.2/96 kHz. The high half of the remaining spectrum is compressed and placed in the low 8 bits of each sample with scrambling that makes it look like noise. After the MQA metadata is added in the 9th bit along with some additional dither, the FLAC encoder sees about 14 bits of music data and 10 bits of noise regardless of the source sample rate.

[lucretius]

5 minutes ago, mansr said:

No, MQA doesn't work like that. The encoder downsamples higher rates to 88.2/96 kHz. The high half of the remaining spectrum is compressed and placed in the low 8 bits of each sample with scrambling that makes it look like noise. After the MQA metadata is added in the 9th bit along with some additional dither, the FLAC encoder sees about 14 bits of music data and 10 bits of noise regardless of the source sample rate.

 

Now we're down to only 14 bits of music data.  I thought there were at least 17 bits of music data.

 

You say that "the high half of the remaining spectrum is compressed and placed in the low 8 bits". Does it matter how much is in that high half?

[mansr]

10 minutes ago, lucretius said:

Now we're down to only 14 bits of music data.  I thought there were at least 17 bits of music data.

Some resolution is restored by the decoding process, but 17 bits is probably a bit (or two) generous. That figure comes from Bob Stuart, after all.

 

10 minutes ago, lucretius said:

You say that "the high half of the remaining spectrum is compressed and placed in the low 8 bits". Does it matter how much is in that high half?

The accuracy of the encoding depends on the content, but it still appears as incompressible noise due to the scrambling. Without scrambling, the packet structure could show up as spurious low-level tones.

[crenca]

56 minutes ago, lucretius said:

 

I am using Roon as the initial player (since it streams Tidal). See settings:

 

 

Note that the MQA Capabilities setting is "Decoder and Renderer"; that turns off software decoding as it is expecting the DAC to do it. In any case, if the software was decoding the MQA stream, I definitely would not get a resulting file that is bit perfect (confirmed by playing this file and getting the blue light, etc.)

 

As I said on previous posts, the recording software is Sound Forge. (I could not get Audacity to work with the WASAPI driver and with the MME driver it was not bit perfect.)

 

In reference to Mansr's files, etc, it could be that the MQA process is encoding more noise into the resulting MQA file when the source file is of a higher bit rate (i.e. 24/352.8 as in the case of the 2L files).

 

 

I have a Schiit Gungnir MB (obviously no MQA support whats so ever) and in Roon 'Device Setup' I have it set to "no MQA capability".  I pay a Tidal MQA track (in this case something from Charles Lloyd's "Vanished Gardens"), and Roon indicates (in the Signal Path) it is "Authenticating" to 96kbs and I get the tell tell sound of the USB relays clicking on the Gumby to confirm that indeed, it is receiving a 24/96 PCM stream.

 

I change over to "Decoder and Renderer" in 'Device Setup'.  First, I play a 16/44 file to reset DAC (hearing the relays click), and then I play same MQA track and...wait for it...Roon authenticated MQA and I hear the DAC click to accept the 24/96 stream!

 

Roon has blown your experiment by not behaving as you expected - you captured a decoded MQA file...

[Ralf11]

1 hour ago, Paul R said:

 

Well, no. I never said I roamed the dang streets. To begin with, Cheyenne doesn't have that many streets - but what it does have is thriving if small audiophile community, and I can say the ones I met were welcoming, friendly, and really thirst for information about everything audiophile. The few systems I heard were really well put together, most better than mine.

...

 

Many, many members are still curious about the hundreds of people you talked to and your journal entries about their HiFi Habits, not to mention your career as a mathematician, or graduate background in that area.

[lucretius]

36 minutes ago, crenca said:

 

 

I have a Schiit Gungnir MB (obviously no MQA support whats so ever) and in Roon 'Device Setup' I have it set to "no MQA capability".  I pay a Tidal MQA track (in this case something from Charles Lloyd's "Vanished Gardens"), and Roon indicates (in the Signal Path) it is "Authenticating" to 96kbs and I get the tell tell sound of the USB relays clicking on the Gumby to confirm that indeed, it is receiving a 24/96 PCM stream.

 

I change over to "Decoder and Renderer" in 'Device Setup'.  First, I play a 16/44 file to reset DAC (hearing the relays click), and then I play same MQA track and...wait for it...Roon authenticated MQA and I hear the DAC click to accept the 24/96 stream!

 

Roon has blown your experiment by not behaving as you expected - you captured a decoded MQA file...

 

1.  The thing is, I can check for this, since I have an MQA DAC.  If Roon does the first unfold, I will not get a blue light on the DAC.  For example, if set to "no MQA capability", there will be no light.  And if I set Roon for "renderer only", then the DAC will have a magenta (not blue) dot.

 

2.  We can go on and on but this is irrelevant.  The fact is that I can capture an MQA stream bit perfect.  If software had mangled the stream, this would not be the case.

[mansr]

1 minute ago, lucretius said:

1.  The thing is, I can check for the since I have an MQA DAC.  If Roon does the first unfold, I will not get a blue light on the DAC.  For example, if set to "no MQA capability", there will be no light.  And if I set Roon for "renderer only", then the DAC will have a magenta (not blue) dot.

 

2.  We can go on and on but this is irrelevant.  The fact is that I can capture an MQA stream bit perfect.  If software had mangled the stream, this would not be the case.

Why don't you share a short sample? Then someone could verify that your capture process is working properly.