MQA is Vaporware

[Cebolla]

.

.

.

 

 

 

LSB MQA DRM watermark:

 

[Cebolla]

5 hours ago, FredericV said:

In a nutshell, if an MQA output stream is only 16 bits (MQA CD, 16 bit MQA, truncated 24 bit to 16 bit files), origami is NOT possible, as the crypto DRM part to do the unfold is not being stored, as it is normally the bottom 8 bits of a 24 bit MQA file.

This is what I already figured out by doing my experiments, and now Bob confirms this.

Note that 24 bit MQA does not mean actual 24 bit audio data, as it allocates several bits to do origami, and it also has a bit with a metadata stream stored, so MQA licensed products can recognize it's MQA.

 

With just the LSB being used for MQA encoding (cannot contain hi-res - just used to set the blue light, plus gets the MQA renderer to upsample as necessary up to the bogus indicated original sample rate & apply the indicated MQA filter), the implication is that MQA-CD is actually 15 bits (44.1kHz only), rather than the 13 bits sometimes mentioned.

[Cebolla]

6 hours ago, lucretius said:

 

According to the patent diagram, the 0-24kHz is mapped to the 13 MSB bits .  The next 3 bits are then used to trigger the blue light and selection of the MQA filter, etc.*  That would make MQA-CD 13 bits -- not just 13 bits but 13 bit playback with a leaky filter.  [For 24 bit MQA, HF -- 24-48kHz -- seems to be packed into the 4 LSB bits (bit 21 to bit 24).]

 

*Further, more than 1 bit is needed to indicate authentication, filter selection and, possibly, sample rate.  Also, note that the 8 LSB bits in a 24 bit MQA file are not involved in the MQA authentication process -- the file will still authenticate when those bits are dropped.

 

That doesn't appear to happen in practice:

 

 

Having said that there does appear to be scope in the actual MQA decoder to allow just 8 bits PCM (0-24kHz), so far worse than mentioned in the patent!

 

[Cebolla]

11 hours ago, lucretius said:

 

Sure, like mansr said, any specific numbers mentioned in the patents may just be examples.  However, 3 or 4 bits do not become 1, etc.  And we know from tests, that the 8 LSB bits in a 24 bit MQA file are not involved in the MQA authentication process. And, in the case of 16bit MQA, there's no way one bit alone is used to indicate authentication, filter selection and sample rate  -- so, I doubt that mansr seen files with 15 bits of PCM and 1 bit MQA.  Note that mansr's last statement (re 14-bits) contradicts what he said about 15 bit PCM/1 bit MQA files.

 

Odd that given the many of those tests & the conclusions were made by mansr himself, you doubt his observation in tests of never having seen an MQA-CD file with more than 1 bit for MQA authentication and further, prefer to believe that this contradicts his observation in tests of never having seen an MQA file with more than 2 bits for MQA authentication.

[Cebolla]

1 hour ago, lucretius said:

 

Are you saying that this is a possibility or that the MQA decoder actually works this way?

 

Goodness, please go back & actually read about some of those 'tests', eg:

 

[Cebolla]

For goodness sake, actually read the whole test mentioned in the posts that followed that post! 

 

Just some of the phrases to out for:

"the control stream has a packed structure" - so very much capable of containing original sample rate, MQA filter selection, etc; 

"Corrupting the control bit (counting from 0, bit 8)" - singular, not the 3 control bits!;

"contrary to corrupting the bit just above it (counting from 0, bit 9)" - obviously referring to adjoining 0-24kHz PCM bit;

"when I corrupt the control bit" - ditto singular.

 

[Cebolla]

53 minutes ago, lucretius said:

 

It is unclear to me what you are saying.  Mansr's 14-bit comment appears to contradict his 15-bit comment.  Nonetheless, I believe his testing specifically involved identifying non-music bits.  So where he could only identify 1 bit of the 16, he concluded the other 15 bits where PCM music bits?  In any case, within these 16 bits there must be coded the authentication, filter selection, and sample rate.  Can 1 bit accommodate this?  

 

1 bit can certainly accommodate that, plus I cannot see any contradiction & share @danadam's thoughts:

 

 

[Cebolla]

1 hour ago, lucretius said:

I wasn't sure whether "control stream" (as opposed to the "control bit 9") was referring just to bit 9 (counting LSB from 0). 

 

No idea where you got that from. Also, just look a few posts above, in the same test conversation, where mansr clearly mentions that bit 9 is "just above the MQA control stream":

Which, given that bits 0 to 7 are the eight LSB 24kHz-48kHz 'folded' bits, just leaves the single bit 8 as the "control stream" mentioned by mansr, ie, the exact same single "control bit (counting from 0, bit 8)" mentioned later in the test conversation by @FredericV. 

 

 

 

1 hour ago, lucretius said:

And where does filter selection and sample rate fit in?

 

What not convinced by the potential vast capacity implied by stream (as in "control stream") and packed structure (not to mention @Don Hills's & @PeterSt's posts above), eh? 🙂

 

How about this mansr post on the first page of that test thread?

"The displayed rate is whatever the control stream says. That's the orig_rate value in the mqascan output."

 

[Cebolla]

42 minutes ago, bogi said:

And in the next post mansr writes:
The displayed rate is whatever the control stream says.
So that's the source of misleading information discussed yesterday.
That seems to be result of stripping 8 lower bits form 24bit MQA content. The control stream is not affected by this stripping so it will show for example 88.2 with 16bit content. Nobody at Tidal or MQA cares ...

 

That Roon example is showing Authentication MQA 44.1kHz, which is the MQA control stream's actual original sample rate value - so that original sample rate isn't what Roon's MQA Core Decoder is actually upsampling to, ie, 88.2kHz!

[Cebolla]

2 hours ago, R1200CL said:

I’m still chasing this 16 bit MQA decoding or upsampling or whatever is happening. (In Roon decoding signal path). 

 

3 hours ago, R1200CL said:

Edit

Now I’m confused. 
@mansr You wrote this back in 2017 in comments:

”That's not necessarily a bug. The MQA core decoder has a setting controlling whether to upsample 1x (44/48k) content to 2x (88/96k). Enabling this means the caller always receives 2x rate back from the decoder, which might simplify the setup a bit.

 

I believe xxHighEnd's MQA Core decoder doesn't upsample both 16 bit & 24 bit MQA files if the MQA original sample rate is less 88.2kHz - perhaps @PeterSt can confirm/comment?

[Cebolla]

1 hour ago, GUTB said:

I'll look around for another MQA album to compare.

 

No need to look too hard for some tracks - 2L has kindly provided some free downloads of 24 bit MQA 'original resolution', 16 bit MQA-CD and normal original CD (as well as some standard hi-res PCM & DSD) files that you can compare with the source they were actually produced from (mostly DXD):

2L High Resolution Music .:. free TEST BENCH

[Cebolla]

3 hours ago, Abtr said:

IIRC it was discussed and confirmed about a year ago in this thread that Qobuz was streaming a couple of MQA albums without indicating this or even being aware of it.. I'm not prepared to buy an MQA enabled DAC just to check if albums and tracks from Qobuz are genuine redbook files and not (undecoded) MQA. 
 

 

That discussion was specifically about the 2L label having provided MQA-CD content to Qobuz for 16-bit streaming, without having previously notified them about it. Qobuz did provide an official statement on the matter, saying that they would ask for the required extra metadata in order to be able to identify the MQA-CDs and provide an indication for their users:

 

[Cebolla]

9 hours ago, lucretius said:

 

When Roon's MQA Core Decoder is engaged (Settings->Audio->Device Setup->MQA Capabilities = "No MQA Support" or "Renderer Only"), 24/88.2 (in the case of 16 bit MQA) is output to the DAC, i.e. the DAC sees 24/88.2 (not 16/44.1).

 

Let's assume your MQA DAC is setup in Roon as a "Renderer Only" and you are playing a 16 bit MQA file.  The DAC will display the source (pre-MQA) sample rate*, not the actual sample rate input to the DAC.  Therefore, when the pre-MQA sample rate is 44.1k (i.e. MQA 44.1k), then the DAC will display 44.1k.  Likewise, if the pre-MQA sample rate is 352.8k (i.e. MQA 352.8k), then the DAC will display 352.8k.

 

*This is hard-coded in the MQA control stream.

 

Makes perfect sense for those that have bought into MQA, that the MQA DAC use the MQA control stream's ORIGINALSAMPLERATE identifier (or the DAC's max sample rate if the ORIGINALSAMPLERATE is too high) to display sample rate, rather than the actual sample rate of the PCM signal being input to the DAC that's normally used.

[Cebolla]

20 hours ago, GUTB said:

How many of you guys tested DXD vs MQA? I noticed that 2L has those in their sample page so I gave them a listen. DXD vs MQA vs MQA-CD

 

20 hours ago, GUTB said:

Going back to the MQA-CD version (44/16) I was able to validate that yes, there was a definite loss of overall resolution, more akin to what I'd consider 96kHz -- a little bit more open, a little bit more air between instruments compared to CD.

 

So from this experience I don't know if pursuing MQA-CD is worth while if higher resolution versions are available for download. It's still up there with SACD as being the best available physical music format.

 

Instead of making some general CD comparison comment from past experiences, why didn't you actually test listening to the original CD versions, which are also available for download on the 2L test bench webpage (and therefore carefully produced by 2L from the same DXD masters for direct comparison between the different formats), vs the MQA-CD versions?

[Cebolla]

On 1/5/2021 at 6:47 AM, lucretius said:

It's more than a flag.  There is an actual check of bits - bit checksum.  However, as I have posted before:

Only the 0-22.05/24 kHz frequency range encoded in the first 13-15 most significant bits is authenticated. The 8 least significant bits (of a 24 bit file), which also include the encoding for the 22.05/24 - 44.1/48 kHz frequency range, do not affect authentication and thus can be altered and the "blue light" will remain on. Bob Stuart has already admitted this.  Further, @FredericVhas tested and confirmed this:

 

 

 

27 minutes ago, lucretius said:

I suspected this was the case with respect to transmission between Tidal and end user.  OTOH, what I was saying is that MQA authentication provides assurance that Tidal doesn't alter the files or streams before leaving their control, although I cannot think of a reason why Tidal would do this.

 

So much for the assurance, then!

[Cebolla]

9 hours ago, JoshM said:

Are there any MQA CDs out there that also exist in a Redbook version so that this can be compared?

 

Yes - there are some free individual track downloads that you can compare (as well as 'standard' hi-res MQA & other formats/resolutions), available from 2L's hi-res test bench:

http://www.2l.no/hires/index.html

.

..

.

[Cebolla]

3 hours ago, The Computer Audiophile said:

John Bonham too

 

MQA's the ghost in the DAC machine.

[Cebolla]

Separate parallel streams, so with the same playlist - one sourced from MQA material; the other from non-MQA, Really?

 

Unlikely. It'll be far easier to source both streams from the same MQA material and just run a bit depth reducing downsampling (where necessary) hi-res MQA mangler to produce the 16bit/44.1kHz 'non-MQA'  stream - similar to what TIDAL already does on its HiFi quality connection (as opposed to its Masters quality connection). Don't be surprised if some MQA-CD tracks start 'appearing' on the 'non-MQA' stream. 

[Cebolla]

12 hours ago, Currawong said:

 

I'll be happy if they stream 24/96.  I understand that it's a difficult situation for Bill to keep RP running, given that he relies on donations. That means getting RP more well known. Doing so through a manufacturer makes sense. Sadly that has to involve MQA.

 

From the other parts of Bill's post you quoted it's also clear that RP are not sourcing the MQA stream from MQA material and are instead using an MQA encoder to produce the MQA stream from scratch:

Quote

No. We’re not using any MQA masters.

Here’s how it works currently: we assemble blocks of programming as 16/44.1 FLAC files. Those are then encoded into MQA. The folding/unfolding is something that happens when MQA encodes higher resolution input files into 16/44.1 output files. That whole part of their encoding isn’t utilized by our MQA stream at this time.

Here’s how it will work in the future: we assemble blocks of programming as 24/96 FLAC files, from uncompressed (non-MQA) masters of the highest available bitrate — 24/192, 24/96, 24/48, or 16/44.1 — that are then encoded, with folding, into a 16/44.1 MQA bitstream. They will also be available as uncompressed 24/96. 

 

Interestingly, it appears that it's going to be an MQA-CD 16bit/44.1kHz only stream, even when produced from the planned 24bit/96kHz hi-res source.

[Cebolla]

52 minutes ago, Cebolla said:

Interestingly, it appears that it's going to be an MQA-CD 16bit/44.1kHz only stream, even when produced from the planned 24bit/96kHz hi-res source.

 

Bill's corrected that to a 24/48 hi-res MQA stream produced from the 24/96 hi-res source, in response to the query.

[Cebolla]

Crikey, hope you're not suggesting that the Q should be in Union Jack colours - I'm just about to tuck into my tea here!  

[Cebolla]

On 4/2/2021 at 1:09 AM, Currawong said:

 

I'll be happy if they stream 24/96.  I understand that it's a difficult situation for Bill to keep RP running, given that he relies on donations. That means getting RP more well known. Doing so through a manufacturer makes sense. Sadly that has to involve MQA.

 

Looks like you/we are going to be happy:

https://radioparadise.com/community/forum/post/3901944

Quote

When we're ready to launch a hi-res stream, it will be available as straight FLAC as well as MQA. 

Due to the nature of how we deliver our audio, it will never be a mix of different sample rates & bit depths. Everything needs to be standardized to the same rate, probably 24/96. Even if the only master we have is 16/44.1 it will be upsampled to 24/96 and will read out as such on your DAC. 

Because we mix songs together into a continuous flow, there is absolutely no way around that. 

 

[Cebolla]

9 hours ago, GoldenOne said:

As well as the versions streamed from tidal on the "hifi tier" (which as it turns out are the same file but without mqa flagging) 

 

MQA-CD file tracks should be provided unscathed on the TIDAL HiFi quality (16bit/44.1kHz only) connection as they are already distributed at 16bit/44.1kHz,, but the hi-res MQA ones (which in your 88.2kHz case are distributed at 24bit/44.1kHz) should be corrupted as they're provided mangled to 16bit/44.1kHz.

[Cebolla]

13 hours ago, FredericV said:

The MQA-CD sausage machine for internet radio?

So they have 24/96 flac broadcast files crafted from various PCM sources (including 16/44.1 source files upsampled back to 24/96), which they MQA sausage into 16/44.1 distribution files- which can never unfold back to 24/96 ....

So in case the source file was 16/44.1

1. resample to 24/96 as their MQA encoder starts with 24/96 files
2. downsample / folding to 16/44.1 by the MQA encoder - but without the hi-res part (e.g. the source files was 24/96 or 24/192) as MQA CD does not have an actual hi-res part
3. upsample to whatever the MQA metadata says ?

-> how can 16/44.1 MQA CD become 24/96 ? MQA x2 rate = distribution file sample rate x2, so 88.2 kHz and not 96 kHz

 

Ah - been there, done that!

 

Unfortunately you've picked up a bit of misinformation.

 

The 16-bit/44.1kHz resolution mentioned for proposed hi-res MQA Radio Paradise streams derived from the 24-bit/96kHz source files was an error. It was actually corrected to the expected 24-bit/48kHz in a later post on the same RP thread, after I questioned it:

https://radioparadise.com/community/forum/post/3901729

[Cebolla]

On 4/13/2021 at 1:46 PM, GoldenOne said:

That's what I thought too. And it certainly used to be the case. 

 

Unfortunately now though it seems that the 16/44 file is just the MQA file but without the client unfolding it. 

 

Its bitperfect to the 'masters' version and this was the case for any other track I've tried. 

Ive actually stopped my subscription because of this 

 

I pay tidal for lossless. If they no longer offer that for any track marked master, I don't want tidal. 

 

 

Ill double check with some other files that I know were definitely from 48/96khz masters as I can't imagine those would be the same

 

I think we are at cross purposes here. Just to be clear - on a TIDAL HiFi quality connection, ie, not a TIDAL Masters quality connection:

- selecting lossless CD resolution (16bit/44.1kHz) non-MQA tracks for streaming (unfortunately TIDAL are currently actively getting rid of those in favour of lossy MQA-CD ones, so not many left to select), TIDAL's online server provides those unscathed;

 

- selecting lossy MQA-CD (ie, MQA encoded to be distributed with a resolution of 16bit/44.1kHz.) tracks for streaming, TIDAL's online server provides those unscathed;

 

- selecting lossy hi-res MQA (ie, MQA encoded to be distributed with a resolution of either 24bit/44.1kHz or 24bit/48kHz) tracks for streaming, TIDAL's online server provides a corrupted bit depth reduced CD-res version of those tracks.

 

 

So the purpose of the TIDAL HiFi quality connection is not for providing lossless CD resolution non-MQA sourced tracks in place of any lossy MQA tracks that may have been selected, though TIDAL definitely don't make this clear. 

 

As far as I'm aware this has always been the case and is not something that's come about through a recent change as you appear to imply. Certainly I've read posts mentioning evidence of this going back at least 3 years, eg:

https://forum.xda-developers.com/t/app-5-0-v3-5-0-1-bubbleupnp-upnp-dlna-chromecast-control-point-and-renderer.1118891/page-649#post-74757085

 

 

Your observation of client software (Roon, presumably) not decoding to the MQA Core signal aka 'first unfold' (assuming any corruption permits this) or even flagging any of the MQA tracks coming through on the TIDAL HiFi quality connection only adds to the confusion.