At this point I think MQA is an interesting curiosity, with some clever “technology”, which may or may not actually do anything useful, and not a lot of point. I’ve been playing with it, on and off, since it first becomes available, and my experiences haven’t changed much over that time.
It has been fairly heavily technically torn-down.
Evaluating MQA is harder than it should be because the demonstrations that have been conducted haven’t been done with back-to-back versions of non-MQA content from identical masters. Nor is there very much available material which permits you do this for yourself. Even on TIDAL, where you might have MQA and non-MQA versions of an album side-by-side - there isn’t enough information available to determine if they’re from an identical master (and only differ based on their encoding) or if they’re from different masters entirely.
One place you can start for this, if you want to try and do a direct comparison from common masters, is to look at the few files that 2L have in their test library.
Over many comparisons, using both MQA and non-MQA DACs of various flavors, my personal experiences with MQA can be summed up relatively succinctly:
-
In the vasty majority of cases I prefer the normal PCM versions of music to the MQA versions.
-
In those cases where I have preferred the MQA version, it has almost invariably been down to it being a different master (typically with less aggressive dynamic range compression) and not anything about MQA-itself that is responsible. I have found cases of this where ALL replay was done on a standard PCM (non-MQA) DAC and the only thing that differed was the source file.
-
For most, but not all, MQA encoded tracks, they tend to sound better via an MQA-capable chain.
-
MQA content tends to sound superficially more impressive in a quick/casual listening session - with the most apparent change being more readily discernible detail. However, this is also what happens when you do some level of dynamic range compression to music, as well. And since MQA “eats” the bottom three bits of each 16-bit sample, there would have to be something of that nature in effect for more dynamic pieces (most modern pop/rock doesn’t use anything like 13-bits of dynamic range).
And note that I’m not necessarily talking about high-resolution PCM versions of music here, either. In fact most of the comparisons have been to Redbook 16/44.1 content. High-resolution music has tenuous “advantages” at best, and even more so in most replay chains.
I think there would be a lot less (but not “no”) resistance to the format, on principal, if it were demonstrated in the most common A/B audition format that is genuinely ASSUMED as a minimum requirement (and a properly blind A/B would be even better). That never happens, though, and it’s made harder to do for yourself than is reasonable.
For me personally, I don’t care if a DAC supports MQA or not. It isn’t a factor in my buying choices. I’ll listen to it on DACs that support it if I am reviewing them, but it’s not a personal requirement, or even desire, that my DACs are MQA-enabled.
At a recent audio event (well, earlier this year at least), I saw quite a depressing demo. I’ll keep the names out of it, since it was mostly 6-figure gear anyway, but it was an MQA demonstration. The manufacturer’s rep played a few excerpts of tracks with MQA processing disabled. Turned-on MQA processing. And replayed the same tracks.
There was much safe nodding, scratching of beards, and exclamations of delight in response to this second round of listening. The usual “it’s a night and day difference” nonsense was being heavily touted. People were really excited.
Except for me — as I was sat close enough to the DAC in question to see that the MQA function had NOT engaged when the rep had thought he’d turned it on. So what was playing was the very same tracks, in the very same fashion. Not that they sounded any different anyway, but it does go to show just how strong the effects of expectation bias can be (one reason why I try to do comparisons in reviews as blindly as possible).