Jump to content
Rt66indierock

MQA is Vaporware

Rate this topic

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.


Current:  JRiver 24 on Win 10 PC (AMD Ryzen 5 2600 with 32 GB RAM) or Daphile on an I5-2500K with 16 GB RAM

DAC - TEAC UD-501 DAC 

Pre-amp - Audio Research SP-16

Amplification - Kenwood L-07M Monoblocks

Speakers: Wharfedale Linton Heritage

Cables: MIT speaker cables and DiMarzio Interconnects

Share this post


Link to post
Share on other sites
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.


perception = controlled hallucination, hallucination = uncontrolled perception

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.  :)

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...