MQA is Vaporware

[lucretius]

13 minutes ago, crenca said:

 

It is an encoding (audio codec), and yes it is a compression scheme - even if it is one obscured in a black box proprietary software.  Also, for practical purposes MQA is a "file format", again one that is black boxed and has a freemium PCM aspect.

 

 

Not really relevant - it is a black boxed compression scheme that does not compress very much at all

 

 

 

Incorrect.  MQA has aspects (it's already compressed, etc.) that makes it different from standard PCM.  See the tech post I referenced above.

 

I am familiar with that.  Please don't confuse "folding" or "origami" with actual file compression.  The compression scheme used in producing the flac file will not discriminate between the MQA track and the non-MQA track.

 

 

[lucretius]

3 minutes ago, crenca said:

 

Well, yes it will actually - if you move beyond a "bits are bits and any bit will fit into FLAC (or your compression scheme of choice)" mentality.  Sticking an already largely compressed file, or any other file that is not very compressible, into a compression scheme like FLAC is...good for what, exactly?  What's the point?  Compatibility, familiarity? 

 

The thing is the MQA track is not compressed in that way before producing a flac file. Think of MQA as bit swapping.

 

[lucretius]

5 minutes ago, crenca said:

 

What way?

 

In the way that takes a file from 50,830 KB to say 25,415 KB. Think of MQA encoding as simple bit swapping. The MQA process determines how to fill the bits of the 24/48 file.  File compression is done later and is agnostic to MQA.

[lucretius]

27 minutes ago, crenca said:

 

Why would we think of MQA like that?  MQA is not as compressible as the equivalent PCM.

 

Evidence?

 

Actually, I have some evidence.  I recorded a track from Tidal (Dreams by Fleetwood Mac from the Rumours album) and saved it to a flac file with the recommended level 5 compression.  I made sure it was exactly the same duration (by cutting the beginning or ending silence) as noted both on Tidal and the 24/96 file I own of that track. Then I converted the 24/96 track to 24/48 with the recommended level 5 compression. Here is what I got:

 

52.3 MB for the MQA file

52.0 MB for the non-MQA file

 

That's pretty close.  However, for the MQA file the compression was done by Sound Forge, while for the non-MQA file the compression was done by dbPoweramp. Maybe that accounts for the .3 MB difference? Plus, when I cut the MQA file to size, I may have been off a half second.  Then again, the MQA file may be from a different master.

 

[lucretius]

2 minutes ago, crenca said:

 

On this very thread.  This fact about MQA was documented very early...

 

?

[lucretius]

3 hours ago, crenca said:

 

This was a decoded file right?  

 

"No". The MQA file was bit perfect. Still turns on the blue light. Actually, a DAC does not alter the MQA stream when "decoding" -- all that happens is that certain actions are triggered when discovering the MQA bit pattern. Only the software decoder (built into the Tidal player for example) alters the file.

 

As an aside, I find the blue light useful in determining whether the (MQA) stream received and saved to computer is bit perfect and not mangled by Windows, players/recorders/DAWs, or drivers. 

[lucretius]

50 minutes ago, firedog said:

Are you telling me you have a journal listing every person you talk to everyday, and what you talked about?

 

Sounds like a covert operative.

[lucretius]

5 hours ago, Em2016 said:

 

While I would prefer MQA go away, if we are talking about the 1st unfold only, some have forgotten about Archimago's comments/analysis...

 

"Objectively with the songs I examined, the software decoder works well to reconstruct what looks like the equivalent 24/96 download."

 

and

 

"Bottom line: TIDAL/MQA streaming does sound like the equivalent 24/96 downloads based on what I have heard and the test results"

 

https://archimago.blogspot.hk/2017/01/comparison-tidal-mqa-music-high.html

 

This applies to the 1st unfold only (up to 96kHz)… he’s done plenty of analysis on the stuff after the 1st unfold, which doesn’t need repeating of course.

 

One of the problems in doing such analysis is that much of the hi-res content out there is fake hi-res.

[lucretius]

30 minutes ago, crenca said:

 

How did you capture the stream?  Rerun your experiment capturing the same track using Tidal set to "normal" audio quality, capture the audio, and FLAC it.  What is the size of this file?

 

Now that I think about it, the stream was captured before going to the DAC, using Virtual Audio Cable from the player software into Sound Forge. (Nonetheless, what I said about the DAC is still correct.)  Therefore, no need to capture the track "using Tidal set to normal", which would show nothing relevant in any case (and difficult to know what trash Tidal was sending).

[lucretius]

1 minute ago, Dr Tone said:

 

 

 

 

The problem here is that Miska took pre-existing MQA flac files.  Therefore, how did he know what level of compression, if any, had been used?

 

 

 

[lucretius]

2 minutes ago, Dr Tone said:

 

Well it would be silly of MQA the bandwidth saviour to not use the highest FLAC compression but you never know, they have been known to be be all fluff and mirrors before.

 

Actually, it looks like Miska got the files from the 2L site, not MQA. (I think they actually avoid compression.)

[lucretius]

10 minutes 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.

 

You can look at the storage size of existing material. That is to say, you can re-convert the MQA file to a flac file and choose the level of compression. Then it can be compared to existing hi-res files appropriately processed (converted to same sample/bit rate and same level of compression).  And to get some level of assurance that both tracks originated from the same master, you can look at loudness peaks and dynamic range.

[lucretius]

11 minutes ago, crenca said:

 

Nope, that's not the problem.  The problem is that you are not taking "pre-existing MQA flac files", your taking decoded MQA files.  Miska is right, you are wrong...

 

They were not decoded -- they had not been sent to the DAC yet. I captured the raw stream as sent from Tidal.

[lucretius]

10 minutes ago, crenca said:

 

Nope, that's not the problem.  The problem is that you are not taking "pre-existing MQA flac files", your taking decoded MQA files.  Miska is right, you are wrong...

 

But how did Miska know what level of compression had been applied to the pre-existing MQA flac files?

[lucretius]

2 minutes ago, Miska said:

For comparisons, I don't use Tidal to compare, I use material sold as MQA downloads by 2L annd by highresaudio.com. Both also offer the non-MQA version as well.

 

Of course I can capture raw streams from Tidal as well as the decoded ones. But without matching non-MQA version it is quite pointless.

 

 

Thanks Miska.  Do you know if the MQA downloads by 2L are compressed and to what level?

[lucretius]

1 minute ago, crenca said:

 

Because he understands what MQA is.  In other words, he understands it is not about a "level" of compression, by which you mean a specific implementation of FLAC, but about another kind of "compression" altogether...

 

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.

[lucretius]

5 minutes ago, crenca said:

 

Are you sure?  How?  

 

Here is what I think you did (I could be wrong).  You did not capture the "raw stream as sent from Tidal", rather you captured the stream after it had been decoded by the player software (in this case the Tidal desktop app?) but before it was sent to your DAC...

 

LOL!  I can do this with software that cannot decode MQA. Nonetheless, the final test is playback.  If the blue light comes on, I know the file that was captured is bit perfect.

 

 

[lucretius]

15 minutes ago, ralphfcooke said:

uh... no! It has been shown that it is possible to modify the MQA data stream and still get the blue light to come on.

 

So? That would take some purposeful effort.  Do you really think that the software I was using is doing that?

[lucretius]

Just now, Miska said:

Oh, and let's not forget how fucked up the output spectrum ends up being after MQA decoding+rendering step with extremely leaky filters with correlated images galore.

 

 

I agree.

[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.  

[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.

[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.

[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?

 

 

[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).

[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?