MQA is Vaporware

[esldude]

It is possible encryption and decryption could have been used to supply the data needed for subtractive dither.  It isn't the only solution.  Of course it appears from what others have found that subtractive dither was just a ruse, and isn't part of MQA.  Like deblurring, sparse sampling, end to end provenance the artist signs off on, and correction of deficiencies in the original recording ADC retroactively.   Subtractive dither can go on that list. 

[Lee Scoggins]

7 hours ago, new_media said:

 

If I purchased an MQA-encoded album and wanted to listen to it on anything other than an officially licensed MQA device, it would be worse than redbook quality.

 

I don't care if that's DRM by your definition, it is by mine, and I would buy a CD over MQA encoded files every single time.

 

That’s a very restrictive view of DRM and would exclude a wide variety of innovative formats including SACD and DVD-Audio.  And MQA is not worse than CD quality.

[opus101]

3 minutes ago, Lee Scoggins said:

 And MQA is not worse than CD quality.

 

As its fewer bits-worth when not decoded, on what basis are you making this claim? Some support for this (to me outrageous) claim would be appreciated.

[botrytis]

5 hours ago, Norton said:

 

I was  quoting from the Sonore sub-forum on this site, not the claims of MQA. I presume that if the Ultra Rendu delivers 24/96 on first unfold (subject presumably to 96kHz MQA source  file)  then other initial software decoders do the same. For example,  XX High End clearly shows 24/96 input too.  Am I wrong?

 

We can't. Since the MQA encoding threw away bits to do the 'folding' process. This is the problem.  Also, how do we know the original file was 96/24? We only have MQA's word that the master file was 96/24. At least with FLAC, ALAC, or APE you can test your files to know if they come from an actual 96/24 master, you cannot with MQA.

[new_media]

2 hours ago, Lee Scoggins said:

 

That’s a very restrictive view of DRM and would exclude a wide variety of innovative formats including SACD and DVD-Audio.  And MQA is not worse than CD quality.

SACD and DVD-Audio have DRM.

Undecoded MQA is worse than CD quality.

[FredericV]

1 hour ago, botrytis said:

 

We can't. Since the MQA encoding threw away bits to do the 'folding' process. This is the problem.  Also, how do we know the original file was 96/24? We only have MQA's word that the master file was 96/24. At least with FLAC, ALAC, or APE you can test your files to know if they come from an actual 96/24 master, you cannot with MQA.

MQA encoders set comments in the flac file, example:
 

Quote

  comments: 22
    comment[0]: ALBUM=DIVERTIMENTI
    comment[1]: ARTIST=TrondheimSolistene
    comment[2]: CATALOG=2L-050
    comment[3]: COMPOSER=Benjamin Britten
    comment[4]: DATE=2008-06-03
    comment[5]: DESCRIPTION=Following on from the award winning recording of MOZART's violin concertos with Marianne Thorsen, TrondheimSolistene team up once again with the recording company 2L for their new production. This album features a selection of some of the finest and most technically challenging repertoire for string orchestra, and includes repertoire by Benjamin Britten, the Polish composer Grazyna Bacewicz, the Norwegian composer Terje Bjørklund as well as Bela Bartok's seminal work for string orchestra the Divertimento. DIVERTIMENTI is the first music-only recording to be made available commercially in the ground breaking format of Blu-ray. A true world premiere!<br><br>The divertimento as a musical genre dates back to the nineteenth century. Divertimenti were composed for various social occasions and were intended to be light, uncomplicated and cheerful. Such pieces were often scored for small string ensemble. Over the years this effortless, elegant form has appeared in many different musical styles and, to a large extent, set the standard for the virtuosic chamber music we know today. A number of the most prominent composers of our age have engaged with this most fascinating musical style and have contributed to its further refinement as a chamber-symphonic showpiece. <br><br><strong>5.1 SURROUND + STEREO</strong> produced in DXD (Digital eXtreme Definition 352kHz/24bit) by Lindberg Lyd, Norway
    comment[6]: DISCNUMBER=1
    comment[7]: DISCTOTAL=1
    comment[8]: ENCODER=MQAEncode v1.1, 2.1.0+0 (01450a4), DF77A107-A71F-4e57-A322-872C6D0E99C8, Apr 20 2016 17:08:42
    comment[9]: GENRE=Art Music > Classical > Classical
    comment[10]: GRID=A10314Q0000034188A
    comment[11]: ICPN=7041888512820
    comment[12]: ISRC=NOMPP0802010
    comment[13]: LABEL=2L
    comment[14]: ORIGINALSAMPLERATE=352800
    comment[15]: PERFORMER=Trondheimsolistene
    comment[16]: PERFORMER=Øyvind Gimse
    comment[17]: PERFORMER=Geir Inge Lotsberg
    comment[18]: TITLE=BRITTEN Simple Symphony, Op 4: I. Boisterous Bourree
    comment[19]: TOTALTRACKS=11
    comment[20]: TRACKNUMBER=1
    comment[21]: TRACKTOTAL=11

ORIGINALSAMPLERATE=352800

This corresponds in case of 2L.no to the DXD format they use to master.

More clues:
https://community.roonlabs.com/t/roon-failing-to-identify-an-mqa-album-as-mqa/16340

 

In case of DXD, MQA unfolds to 24/88.2. Anything higher than 88.2 is their renderer which is upsampling + weird filters to kill post-ringing. So the DAC doing the unfold will show 24/352.8, which is not the actual resolution, but upsampled resolution. DXD's encoded to MQA have something like 17/88.2 of actual resolution at best at the decoder output.

Consumers see 24/352.8 on their DAC's display + MQA logo and think this is DXD. They are being lied to:

[vmartell22]

8 hours ago, semente said:

 

You should take a mindfulness course. Streamed in MQA.

HAHA

 

It is dangerous, but no different that any parent - nothing but pain the faces of the dropoff/pickup line at school!

 

 

v

[Fokus]

10 hours ago, mansr said:

I haven't found them. Well, I've found a whole lot of filters, but I'm not sure how it all fits together.

 

Can you take a 96k MQA file, preferably one with little signal above 24kHz. Then replace the baseband data with white noise or with an impulse, and send this through unfolding.  That should reveal one of the two join filters.

[firedog]

7 hours ago, Lee Scoggins said:

 

That’s a very restrictive view of DRM and would exclude a wide variety of innovative formats including SACD and DVD-Audio.  And MQA is not worse than CD quality.

Yes, and you don't think this is part of the reason both are failures except in an exceedingly small audiophile market?

[mansr]

12 hours ago, Lee Scoggins said:

That’s a very restrictive view of DRM and would exclude a wide variety of innovative formats including SACD and DVD-Audio.

Are you suggesting those formats would sound worse if they didn't have DRM?

[botrytis]

Don't forget, Meridian tried to insert a proprietary file format into DVD-A, unsuccessfully. Just wondering if this is their next bite of the apple?

[Fair Hedon]

1 hour ago, botrytis said:

Don't forget, Meridian tried to insert a proprietary file format into DVD-A, unsuccessfully. Just wondering if this is their next bite of the apple?

Just one of their many business disasters.

[Lee Scoggins]

2 hours ago, mansr said:

Are you suggesting those formats would sound worse if they didn't have DRM?

 

No, I am drawing an analogy to illustrate how restrictive a view of DRM this is.

[tmtomh]

6 minutes ago, Lee Scoggins said:

 

No, I am drawing an analogy to illustrate how restrictive a view of DRM this is.

 

Lee, if I purchase an MQA file of a song that will decode and unfold to 24/192 resolution, can I store and freely copy the full 24/192 data across all my music-storage and playback devices?

[crenca]

7 minutes ago, Lee Scoggins said:

 

No, I am drawing an analogy to illustrate how restrictive a view of DRM this is.

 

What do you mean (if you even know) by "restrictive view of DRM"?  To paraphrase Forest Gump, DRM is what DRM does.  If you look at the definition of Digital Rights Management (look at the wiki for example, and keep in mind neither you, nor I , nor Bob Stuart gets to define what DRM is), you will (or should - it comes down to the meaning of words in a rather simple way) discover that it is you who have a "restrictive" view of what DRM is.  You have erroneously restricted it to a certain kind of strong file copy restriction scheme.  That's ok, it's a common mistake given the history and rank ignorance of all things digital in audiophiledom.  Bob, to his credit played this market perfectly.

 

You would do well to look to the wider digital, software (IT), and legal worlds where DRM actually comes from.

[FredericV]

22 minutes ago, tmtomh said:

 

Lee, if I purchase an MQA file of a song that will decode and unfold to 24/192 resolution, can I store and freely copy the full 24/192 data across all my music-storage and playback devices?

No you can't. There is no "full" 24/192 data. MQA does not contain 24/192 resolution. 24/192 is degraded to something like 17/96 after the first unfold, and then upsampled back to 24/192, fooling the user into believing this is actual 24/192 resolution when he looks at the display on his dac, which is quack.

MQA does not allow the output to be captured easily at this upsampled resolution.
But why would you want to capture fake upsampled highres which what the MQA renderer is all about? It is a waste of diskspace.

DRM = digital restrictions management.

[Samuel T Cogley]

16 hours ago, Lee Scoggins said:

 

That’s a very restrictive view of DRM and would exclude a wide variety of innovative formats including SACD and DVD-Audio.  And MQA is not worse than CD quality.

 

16 hours ago, opus101 said:

 

As its fewer bits-worth when not decoded, on what basis are you making this claim? Some support for this (to me outrageous) claim would be appreciated.

 

You won't get any technical information to back up that specious claim.  Scoggins is here to parrot MQA marketing and drop names.  Nothing more.

[Tony Lauck]

18 hours ago, Shadders said:

Hi Tony,

This would not be possible - as you have stated, it is a one way hash function, and the data that goes in, is not reversible (in practice), and the hash output is generally a lot smaller than the input data stream.

Regards,

Shadders.

I was discussing the need for the scrambling function needed to whiten the low order bits that represent the folded high frequency information.  Since these bits appear in the code space for the undecoded playback they need to appear to the receiver and listener as uncorrelated with the music.  That way, they will be heard as random noise, rather than distortion.  (It's actually slightly more complicated because changing the low order bits to random values will still be correlated to the music in the form of noise modulation, but these are details of the dithering algorithms and are unrelated to the method of generating the pseudo-randomness.)

 

There is no way to recover the lost bits if they have been repurposed so that they can encode other information. This is true regardless of the specific algorithm used to generate the pseudo-randomness.  This is easily proven by the use of the pigeon-hole principle.   However, if the goal of the system is to make some kind of tradeoff between perceived audio quality and bandwidth uses, the pseudo-randomness does not require the use of an actual encryption algorithm which includes hidden (key) values.  The use of actual  encryption algorithms is necessary to inhibit reverse engineering and to invoke DMCA style legal protection for content, but these relate to the DRM-like aspects of MQA, not the sonic improvement or bandwidth reduction aspects.

 

Note that lossless encoding schemes such as FLAC can not guarantee that they will provide compression for all possible input data.  In fact, for any lossless scheme that compresses some inputs, there must be other inputs that are expanded.  Similarly, if a CODEC takes a fixed input bandwidth and reduces it to a fixed (lower) output rate, there must be some inputs that can not be encoded and then decoded losslessly.  This is another application of the pigeon-hole principle.   So we can be absolutely sure that MQA can not losslessly encode higher resolution input formats at a lower data rate.

[Tony Lauck]

18 hours ago, esldude said:

It is possible encryption and decryption could have been used to supply the data needed for subtractive dither.  It isn't the only solution.  Of course it appears from what others have found that subtractive dither was just a ruse, and isn't part of MQA.  Like deblurring, sparse sampling, end to end provenance the artist signs off on, and correction of deficiencies in the original recording ADC retroactively.   Subtractive dither can go on that list. 

Subtractive dither is more than a ruse, however. Compared to TPDF dither, subtractive dither provides higher audio quality (removing all correlation between signal and dither noise and not just first and second order correlation). In addition compared to TPDF dither it provides an approximate 6 dB gain in S/N ratio or, equivalently, saves approximately one bit.

 

I found that subtractive dither used to convert 96/24 audio to 96/8 audio sounded musical, albeit noisy like an old 4 track 7.5 ips pre-recorded tape.  At 96/12 the noise was similar to that on high quality analog tape.  In this regard, there is a difference between a streaming codec and a recording codec.  That's because a non-repetitive noise pattern (the streaming case) is different from a repetitive nose pattern (the non-streaming case, especially where a brief sound clip is used that is shorter than aural short-term memory).  I did all of this work ten years ago at a time when I could still hear up to 15 kHz.  Since then all of this work is irrelevant, first to me as I now can barely hear 12 kHz, and generally because bits have become vastly cheaper in the past ten years.

[Shadders]

1 hour ago, Tony Lauck said:

Snippet "can be done using cryptographic one-way hash functions which accomplish the same effect with more confidence"

 

I was discussing the need for the scrambling function needed to whiten the low order bits that represent the folded high frequency information.  Since these bits appear in the code space for the undecoded playback they need to appear to the receiver and listener as uncorrelated with the music.  That way, they will be heard as random noise, rather than distortion.  (It's actually slightly more complicated because changing the low order bits to random values will still be correlated to the music in the form of noise modulation, but these are details of the dithering algorithms and are unrelated to the method of generating the pseudo-randomness.)

Hi Tony,

A cryptographic hash function does not scramble. A cryptographic hash function operates on an input data stream (such as a file) and produces a finite output which is the same size whatever the data stream input size is - examples are MD5, SHA etc.

 

With regards to randomness, Sample Rate Converters dither using the Triangle Probability Density Function. Essentially, dither is based on a pseudo random algorithm, but the randomness has a probability density function (specific distribution) which can be triangular, gaussian (white noise) etc (see : https://en.wikipedia.org/wiki/List_of_probability_distributions the section "Continuous distributions"). Weakness in the algorithm (pseudo random) can expose encrypted links etc., to attack.

 

Regards,

Shadders.

[Samuel T Cogley]

57 minutes ago, Shadders said:

Hi Tony,

A cryptographic hash function does not scramble. A cryptographic hash function operates on an input data stream (such as a file) and produces a finite output which is the same size whatever the data stream input size is - examples are MD5, SHA etc.

 

This is not correct in my experience in using these hashes.  For example, an SHA512 hash returns a 512 bit (64 byte) value regardless of the size of the input stream:

 

host $> openssl sha512 01\ Cleveland\ Orchestra\ -\ Symphony\ No.\ 1\ in\ B\ flat\ major\ \(\'Spring\'\)\,\ Op.\ 38\;\ 1.\ Andante\ un\ poco\ maestoso\ -\ Allegro\ molto\ vivace.flac
SHA512(01 Cleveland Orchestra - Symphony No. 1 in B flat major ('Spring'), Op. 38; 1. Andante un poco maestoso - Allegro molto vivace.flac)= 5def2b4e3fc826a005b5bc5795b9e07b7f3007ef229bf5c354cdda4dcaad2593c70a519a13f36ca32f4432699a2f0a0a99e2abf844406f994b04c044f94056aa

host $> ls -l 01\ Cleveland\ Orchestra\ -\ Symphony\ No.\ 1\ in\ B\ flat\ major\ \(\'Spring\'\)\,\ Op.\ 38\;\ 1.\ Andante\ un\ poco\ maestoso\ -\ Allegro\ molto\ vivace.flac
-rwxrwxrwx  1 user  group  53218211 Nov 16 18:31 01 Cleveland Orchestra - Symphony No. 1 in B flat major ('Spring'), Op. 38; 1. Andante un poco maestoso - Allegro molto vivace.flac

Note that the input file is 53MB, and the hash is 64 bytes.

 

What you're describing sounds more like a One TIme Pad.

[Shadders]

3 minutes ago, Samuel T Cogley said:

 

This is not correct in my experience in using these hashes.  For example, an SHA512 hash returns a 512 bit (64 byte) value regardless of the size of the input stream:

 

host $> openssl sha512 01\ Cleveland\ Orchestra\ -\ Symphony\ No.\ 1\ in\ B\ flat\ major\ \(\'Spring\'\)\,\ Op.\ 38\;\ 1.\ Andante\ un\ poco\ maestoso\ -\ Allegro\ molto\ vivace.flac
SHA512(01 Cleveland Orchestra - Symphony No. 1 in B flat major ('Spring'), Op. 38; 1. Andante un poco maestoso - Allegro molto vivace.flac)= 5def2b4e3fc826a005b5bc5795b9e07b7f3007ef229bf5c354cdda4dcaad2593c70a519a13f36ca32f4432699a2f0a0a99e2abf844406f994b04c044f94056aa

host $> ls -l 01\ Cleveland\ Orchestra\ -\ Symphony\ No.\ 1\ in\ B\ flat\ major\ \(\'Spring\'\)\,\ Op.\ 38\;\ 1.\ Andante\ un\ poco\ maestoso\ -\ Allegro\ molto\ vivace.flac
-rwxrwxrwx  1 user  group  53218211 Nov 16 18:31 01 Cleveland Orchestra - Symphony No. 1 in B flat major ('Spring'), Op. 38; 1. Andante un poco maestoso - Allegro molto vivace.flac

Note that the input file is 53MB, and the hash is 64 bytes.

 

What you're describing sounds more like a One TIme Pad.

Hi,

What i have stated is correct - the hash is the same size, whatever the input stream size.We are in fact, in agreement. The size is finite = constant size = same size.

Regards,

Shadders.

[Fair Hedon]

3 hours ago, Samuel T Cogley said:

 

 

You won't get any technical information to back up that specious claim.  Scoggins is here to parrot MQA marketing and drop names.  Nothing more.

If you want some laughs, see his latest posts on his Hoffman thread. Hysterical. he is asking for "logic" based arguments with "evidence".  LOL.

[Samuel T Cogley]

32 minutes ago, Fair Hedon said:

If you want some laughs, see his latest posts on his Hoffman thread. Hysterical. he is asking for "logic" based arguments with "evidence".  LOL.

 

I'm actually surprised Hoffman is letting Scoggins take such a beating over there.  The fact that MQA apologists can find no quarter on audio forums is a hopeful sign.  

[Samuel T Cogley]

43 minutes ago, Shadders said:

Hi,

What i have stated is correct - the hash is the same size, whatever the input stream size.We are in fact, in agreement. The size is finite = constant size = same size.

 

Ok.  For clarity, I would phrase it, "the hash is a constant size, irrespective of input stream size".