MQA General Discussion

Audio Gear Talk MQA
301

One general comment, however.
There is a lot of commentary, some like Jussi’s backed by analysis, some disputing the value of the goals, some just venting.

What I find missing is thoughts on the time smear issue.
To me, that could be the potentially most interesting effect. In my experience, technologies that improve time alignment have been among the most valuable. Stuart’s discussion indicates that the requirement for timing precision goes beyond what we can achieve by sample rate increase within reasonable bounds, and that equipment like ADCs, DACs, crossovers and speaker enclosures introduce timing errors that can be compensated for. He has done things in this area previously, as have others (Wilson, Thiel, Ayre, Light Harmonic), to great benefit. And it is interesting that this nvestigation has lead Stuart to revert his long-held position that we 96k is all we need. If his analysis is correct, and if his technique is effective, that would be significant.

And I see nobody discussing the theory, nobody doing or planning measurements, nobody listening for this effect. Granted, we have little info on the theory and few samples to measure or listen to. But it seems to me that thus would be a worthwhile area of discourse.

Without that, MQA is only a compression technique with some problems spelled out by Jussi, myself and others.

Can we do listening comparisons and measurements for this effect? E.g. with the 2L Arnesen Magnificat, which is available in PCM from 44/16 to 352/24, and in DSD64 and DSD128, and in a white-glove MQA treatment?

I don’t know how to measure that effect, and my listening has not been conclusive. Can somebody else do better?

This would be interesting. The fact that MQA folds info in as noise is well-known, that noise is audible of it is not, this is not a very interesting discussion because we wouldn’t bother if there were not an interesting benefit.

302

I agree this is in principle a good mechanism to “guarantee” that the contents has not been processed/transcoded/compressed further. However, this is no guarantee of good sound.

For example, if Rihanna is going to release ANTI in MQA format, well, when the blue light comes all I’m guaranteed to get is the horrible sounding, compressed sound the producer decided to impart to this recording.

MQA will not be policing the use of MQA for high-quality-sound, all they intend to guarantee is it is the same as the studio.

303

Regarding data origami: Why can’t TIDAL only have a FLAC file at, say 192/18 or similar, and transcode on the fly to the resolution and (current) bandwidth of your device? This satisfies two important claims TIDAL has made regarding MQA:
1- Only one file on the servers
2- That file works with every device regardless of supported bandwidth/resolution

In fact it is worse with MQA it seems to me since you’d be always streaming the bloated 44/24 file regardless of what the source can take.

304

I don’t think they ever claimed that they can turn ■■■■ into gold. All they are promising is that it is exactly what the artist(s) wanted you to hear, not what someone in the chain decided to do to it. It’s like what Roon does with Signal Path, but MQA can do it without the cooperation of anyone else.

305

Understood. Marginal in my opinion but a plus. As Jussi said, in reality $20k gets you the ability to sign whatever you want. So unless MQA is going to police this, it is a bit of an empty claim.

306

At least I have commented on the topic several times earlier. Mathematically, as long as the system’s bandwidth is enough to accommodate all frequency components of the source, there is no timing smear. For example for all the 2L material I’ve checked, 176.4 kHz sampling rate is enough for that. It preserves everything there is to preserve from the original DXD master.

As a result of MQA’s limiting of source’s high frequency content to about 30 kHz, even if it doesn’t introduce ringing, it will make the original transients slower and lose detail due to this bandwidth limitation. I have argued that it’s choice of using the entire 20 - 40 kHz band as filter transition band in order to avoid ringing, causes transient slow down and loss of detail due to that choice (because harmonics above 20 kHz are attenuated so much or removed completely). So those 2L recordings lose about 25 kHz worth of transient and defailt. This is just a design choice.

Other than that, it is clearly apodizing filter.

I don’t think there’s any change on that, since the MQA files created from DXD master seem to use 88.2 kHz sampling rate.

I know how to make some more detailed analysis, from the analog DAC output, so all the possible DAC profiling is taken into account. But since some of the analysis requires manual work using Octave it is time consuming and has to wait.

307

Just want to mention that this is a great level of technical discussion, @AndersVinberg. Kudos. What hardware are you using in your listening tests?

308

Main system is Meridian 818v3 + DSP8000SE, their latest and greatest. I can drive it over network, which still is limited to 96k, or over USB which supports 192. Both support DSD64, but convert it to PCM because the speakers have digital domain crossovers and other DSP and you can’t to that with DSD. Both modes support MQA.

Headphones (Audeze LCD-3) have two modes: analog out from the 818 to a Bryston, or USB to a LHL Geek Pulse Xfi. I am waiting for the SonicOrbiter to drive the Geek in another room.

Headphones have the potential to be a clearer comparison, eliminating room effects. But I love the openness of the speakers.

One note: some commenters at the Meridian forum say that the MQA benefits are not apparent until you listen at realistic levels, and realistic at home is quite loud. (I once brought a sound level app to a Ron Carter gig in a club, and matching that level at home brings my wife running…)

309

They are… that’s the entire point. A certificate repository is required, or else the whole thing is moot. It’s like doing SSL without the CAs – every person would have to grab every record label’s certs, instead of just trusting some authority(ies).

310

I thought I’d jump in here and comment on this, as a long-time audio guy with (for what it’s worth) a physics PhD. Jussi is clearly a smart guy and knows more than I do about digital audio. But it seems to me–please correct me if I’m wrong–that he’s getting the bit about time smear wrong. Certainly it’s true, as we all know, that there’s a [edit] direct relationship between frequency extension and time resolution. However, loss of technical resolution is not the only way time smear can occur. You can encode a recording from the 1920s in XSD and the transients still will not be sharp. That’s because they weren’t recorded that way. More relevant to the current discussion, you can have an excellent recording preserved in whatever form on a studio master, then send it through several layers of low-pass filtering during the process of producing the distribution version. That distribution version can be in any form you want up to the highest technical resolution/largest file size, but you’re not going to get that resolution back.

Now here’s where things get a little fuzzy to me, but the argument seems to go something like this: 1. MQA is good enough to preserve the needed time resolution, and 2. MQA can preserve much more of the time resolution of the master not because of its file’s technical resolution but because–well, I’m not sure. Something to do with knowing what ADCs were used, and the techniques used to generate the distribution file.

To sum up: If I’m right, it’s not the format’s innate time resolution that makes MQA what it is; that is merely as good as it needs to be. MQA works (if it works) because it fixes or avoids time smear that’s present in most other digital files, at least those intended for distribution.

So, am I off-base?

Thanks,

Jim

311

I think that’s the claim.
The analysis is similar to photography: not just that the number of pixels does not denote image resolution, lenses and shooting technique may downgrade resolution; but also in that we can correct for lens faults if we know them. And also in the concept of hierarchical resolution.

But apparently there is a deeper part to it, the “well, I’m not sure” part. Wish we knew more.

I think I understand (a) correcting for ADC characteristics which is the analg of lens correction, (b) once you have done that to create something with the time precision of a 192 or 352 file the origami technique reduces the size of that. But © Stuart talks about getting time smear way below what the sample rate would imply and we know nothing about that.

312

Ok so all top of the Meridian line. Very nice.

313

Do you mean MQA will maintain a certificate store and be able to revoke licensees? How would they do that? Playing an MQA file will require periodic recertification?

I hadn’t heard of this at all, I’d be interested in the detail, but frankly if periodic recertification is required I cannot see this working for anything but streaming.

314

I think you got this wrong… Happy to be further corrected… :smile:

MQA claims the following:

1- Undo (some of the) damage done by the ADC process - and I’m sure it does (so do other methodologies that Jussi has discussed). MQA goes further in this in that it will tailor the mechanism to undo this damage to specific ADC’s and recording chains if they are known (through some profiling of this chain).

2- Data origami to purportedly reduce bandwidth requirements (also the subject of Jussi’s comments)

3- Decodes with knowledge of the specific DAC used and a profile that allows it to circumvent the possible issues that DAC might have so that the final result is as close to the original as possible - a reasonable endeavor except that in the current scheme this precludes any post-processing such as room corrections

This is as much as I’ve learned from reading the tea leaves

315

I am not privy to the details of their keystore, but at a point in the past I was told about a keystore. They may have eliminated that along with the DRM stuff, as there were talks to do that.

This is what frustrates me about MQA the most… we are like 12 year olds talking about sex. We don’t have a clue.

1 Like
316

Haha… Trudat… I think I knew a thing or two when I was 12…:slight_smile:

317

But as long as the decoder is implemented inside a DAC, how would you know who’s certificate it has been signed with? As long as it is valid. If I had my own certificate, I could encode all CD rips I have and people playing it on their DAC would just see that yes, it is indicated as MQA. There’s no GUI to indicate signer entity.

I’m assuming that for example if Tidal runs all their content through MQA it would be signed by Tidal.

If I use encoding house, the process is automated and I just send something there to be encoded and signed with my cert and then it comes back.

In addition, certificate system without revocation system is pretty much moot. That’s why X.509 (used for TLS/SSL) has CRLs and servers the web browser queries when you go to some TLS/SSL protected site to check that the certificate is still valid and has not been revoked.

This all could be done just fine the way I proposed in FLAC metadata. But it doesn’t work in a DAC that doesn’t have internet access and in many cases doesn’t have a GUI either.

And as it goes with many record companies, they don’t necessarily even know what was used on the production chain. It could have been originally recorded as DSD and then converted to 96/24 PCM at mastering stage. Or like the last Pink Floyd album, the final product is mixed from old content recorded at 48/24 and new content recorded at 96/24. And this is not unusual thing to happen in first place. So I don’t know what would be the value of signing it with someone’s key.

318

Hmm, seems over-complicated.

I just thought that MQA would provide to their licensees a certificate that they have signed, and then the hardware or software decoder would verify that cert. And presumably the cert could say “this is legitimate MQA and decode it” or optionally, “this is authenticated MQA” and turn on the green light or other UI indication of authentication. Or if they don’t want to do technical license enforcement (the dreaded DRM which they don’t talk about) but only contractual, the first condition would be omitted, the DAC could decode it in any case but only light up the “authenticated” UI with the validated cert.

I have no knowledge of what they do, that’s just how I would do it.

Btw, in something I read by MQA there was reference to an HSM, which is a Hardware Security Module that can hold a certificate or other secret in a way that cannot be extracted, and can do processing like signing or encrypting the content. It is similar to the TPM, the Trusted Platform Module, that comes in professional laptops, except an HSM has more processing capacity.

319

I don’t think so, I’ve been working on the topic for very long time already.

If the transients are not sharp, they won’t contain the high frequency components either. But also the opposite is true, if you remove the high frequency components you also remove sharpness of the transient. This is what bothers me with the MQA content I’ve been checking through. The original master contains 20+ kHz more of high frequency components than the MQA encoded content, specifically in the transients. Which means that the transient has lost lot of it’s detail and sharpness.

In the case of tracks I’ve been talking about and used for testing, have been recorded using state of the art microphones, microphone preamps and ADCs running at 352.8/24 and contain true high frequency detail close to 60 kHz bandwidth. After MQA encoding, frequency resolution is cut to half and dynamic range is cut to quarter of the original. It doesn’t sound like an improvement to me.

This can and has been fixed for long time using apodizing filters when playing back (in player or in DAC). It doesn’t require reducing resolution of the source file so drastically!

Another aspect as I stated, is that if your recording gear doesn’t bandwidth limit the source signal, there’s no time smear either. Time smear is result of bandwidth limitation, most notable with steep brickwall filters of RedBook. However, if you encode all the content of source as in my previous example - 192 kHz sampling rate is enough to encode all the input’s 60 kHz bandwidth - there’s no time smear and nothing to fix.

Even better, if you use DSD you automatically remove lot of problems from the equation.

320

I think that’s precisely what happens. But the hole is that they don’t know and cannot control what kind of content the licensee encodes with it, or if licensee has some relation to the content itself.

But DAC doesn’t indicate who signed it or whether the signature is still valid.