Matrix Audio X-SABRE Pro MQA: Best Audio DAC in the World?

[milosz]

Measurements are beyond reproach.

Still, I'd like to see some blind A/B/X listening tests with this super-duper DAC and a "merely good" one like a Topping D50s - is there an audible difference between the $2000 DAC and the $250 DAC??? Enquiring minds want to know!

 

[BillG]

Measurements are beyond reproach.

Still, I'd like to see some blind A/B/X listening tests with this super-duper DAC and a "merely good" one like a Topping D50s - is there an audible difference between the $2000 DAC and the $250 DAC??? Enquiring minds want to know!

Once they reach transparency, unlikely...

 

[Julf]

I'm not sure at all there is an audible difference between a uncompressed Hi-res file and MQA, whatever the system. Some people claim to be able to distinguish WAV over FLAC, while I don't believe it's possible. Best thing in that case would be proper blind test. Very easy to operate in my opinion: some just has to create a playlist with Roon. Same song encoded FLAC, WAV (16 and/or 24b) and then from Tidal/MQA, played screen off. Of course the person tested must to ignore the playlist order.

Better use the double-blind ABX plugin for foobar2000 - but the real problem is making sure the source material is exactly the same. No way to do that unless you have access to the MQA encoder.

 

[VintageFlanker]

Better use the double-blind ABX plugin for foobar2000 - but the real problem is making sure the source material is exactly the same. No way to do that unless you have access to the MQA encoder.

That why I mentioned Roon instead of Foobar: Tidal/MQA support.

 

[Julf]

That why I mentioned Roon instead of Foobar: Tidal/MQA support.

Not sure how that helps with ensuring the source material is exactly the same.

 

[tensor9]

Not sure how that helps with ensuring the source material is exactly the same.

You can turn off the final MQA unfold in Rune. MQA is not really "mastered" differently, it only uses information about some specifics of the DAC it's being fed to to optimize its compression and other such things.

 

[Julf]

You can turn off the final MQA unfold in Rune.

It still goes through the MQA-controlled magic - you have no idea what manipulation happens.

MQA is not really "mastered" differently, it only uses information about some specifics of the DAC it's being fed to to optimize its compression and other such things.

If you believe the MQA marketing stuff, yes. I am a big believer in "trust but verify".

 

[tensor9]

It still goes through the MQA-controlled magic - you have no idea what manipulation happens.



If you believe the MQA marketing stuff, yes. I am a big believer in "trust but verify".

That is true, even with unfolding turned off the file is manipulated.

Though you can't be 100% sure it's the exact same source, it'd be best just to compare the MQA file to the uncompressed flac (the Qobuz version would be a good first try). Though often the full unfolded MQA tracks are a "higher" bitrate (so they say) than the uncompressed flacs.

 

[Julf]

That is true, even with unfolding turned off the file is manipulated.

Though you can't be 100% sure it's the exact same source, it'd be best just to compare the MQA file to the uncompressed flac (the Qobuz version would be a good first try). Though often the full unfolded MQA tracks are a "higher" bitrate (so they say) than the uncompressed flacs.

Indeed - "so they say", not that a higher bitrate necessarily correlates with audio quality.

 

[Bamyasi]

This small Dutch recording company 2L has compiled a set of classical tracks each available for downloading for free in several different formats, including Redbook (CD), up to 24bit/352.8kHz Hi-Res PCM, several MQA variants (including CD-quality PCM encoded with MQA) and several DSD variants up to DSD256:

HiRes Download - test bench

I have downloaded the files and now struggling to make my DietPi (Linux) Allo USBridge network streamer to pass through native MQA files and play them back on the attached Matrix X-Sabre Pro MQA. So far, no matter what I've tried nothing works. MQA files are in fact regular FLAC format files, so they would play as FLAC at 24bit/44.1kHz and the DAC would never attempt to MQA-decode them. Interestingly enough, DSD files when played back same way are properly recognized and played in native DSD mode by the DAC (they sound beautifully, by the way), so I am inclined to think this is a Linux issue. Linux developers does not seem to be interested in supporting MQA at all, so technical information is hard to find.

 

[Julf]

MQA files are in fact regular FLAC format files, so they would play as FLAC at 24bit/44.1kHz and the DAC would never attempt to MQA-decode them. Interestingly enough, DSD files when played back same way are properly recognized and played in native DSD mode by the DAC (they sound beautifully, by the way), so I am inclined to think this is a Linux issue. Linux developers does not seem to be interested in supporting MQA at all, so technical information is hard to find.

Unlikely to be a Linux issue. As you write, MQA files are regular FLAC files. Linux doesn't care about them. It sends the bits to the DAC, and it is the DAC that has to make sense of the MQA stuff.

 

[Ranath]

Hello! I am interested in buying this dac and would like to ask a question. In the specs on the matrix site it says that it supports usb audio PCM 16-24Bit, so it does not support 32 bit pcm via usb audio?

 

[Julf]

Hello! I am interested in buying this dac and would like to ask a question. In the specs on the matrix site it says that it supports usb audio PCM 16-24Bit, so it does not support 32 bit pcm via usb audio?

What would be the point? No domestic audio DAC does more than 21 effective bits.

 

[Bamyasi]

Unlikely to be a Linux issue. As you write, MQA files are regular FLAC files. Linux doesn't care about them. It sends the bits to the DAC, and it is the DAC that has to make sense of the MQA stuff.

Unfortunately, this is all not that easy, even though I thought the same before starting my foray into MQA playback testing. Linux audio subsystem is a convoluted mess, second to only Windows one by complexity and lack of documentation. For one, you need kernel support in the form of a proper ALSA drivers to get anything other than plain PCM to work flawlessly. Then comes ALSA configuration which needs to be traced all the way down to ensure audio stream is bit perfect down to the soundcard and not destroyed on its way by software digital mixer or routing. I am actually surprised the DSD files played back without a hitch, this gives me some hope but it looks like Linux MQA playback is unlikely to happen without some help from the ALSA kernel driver developers.

Not that I am too frustrated by this failure. I have started this project out of curiosity only and have no vested interest in MQA standard personally. I just like to learn how things work (or not).

 

[Bamyasi]

Hello! I am interested in buying this dac and would like to ask a question. In the specs on the matrix site it says that it supports usb audio PCM 16-24Bit, so it does not support 32 bit pcm via usb audio?

The specs are correct, 24-bit is the upper limit. Do you own any 32-bit files to play? I do not think such files exist outside studio environment.

 

[Julf]

The specs are correct, 24-bit is the upper limit. Do you own any 32-bit files to play? I do not think such files exist outside studio environment.

And even if they do exist, they tend to be 32-bit floating point that only has 24 bit accuracy anyway.

 

[dc655321]

And even if they do exist, they tend to be 32-bit floating point that only has 24 bit accuracy anyway.

FYI - signed 32-bit PCM (S32_LE) is supported by newer USB DACs. At least the two I own both support S32_LE.
I tend to think of it as more of a transport/consumption format than something one might usefully find from a production source.
In ALSA, this is really only 24-bit anyway, as the representation is 0xABCDEF00 (only the 3 MSB carry info).

An older USB DAC I have only supports up to S24_3LE (formatted as 0xABCDEF, only 3 bytes/sample).
Contrast that with S24_LE (formatted as 0x00ABCDEF, transmitted as 4 bytes/sample).

 

[Julf]

FYI - signed 32-bit PCM (S32_LE) is supported by newer USB DACs. At least the two I own both support S32_LE.

Sure. But 32-bit files, if they are produced at all, tend to be floating point.

I tend to think of it as more of a transport/consumption format than something one might usefully find from a production source.

But why would you need a transportation/consumption format that has more bits than the source material?

 

[dc655321]

Sure. But 32-bit files, if they are produced at all, tend to be floating point.

Not at all. It's a simple matter to tell my DAC to eat 32-bit integer data. IIRC, the Sabre DAC operate at 32-bit natively anyway.

But why would you need a transportation/consumption format that has more bits than the source material?

Speculating: could be beneficial for the transport layer (driver works natively at deeper bit depth), or for the DAC to operate at its native word size. Dunno...
Could be of some benefit for DAC volume control.

But if such a format is absolutely useless, as you suggest, why offer it as option?

The only thing I can think of for certain is that increasing bit depth may be a way to avoid having to dither samples (say, if the samples have gone through some DSP operations, even soft-volume changes).

 

[Julf]

Not at all. It's a simple matter to tell my DAC to eat 32-bit integer data. IIRC, the Sabre DAC operate at 32-bit natively anyway.

Sure. I am talking about files, as in source data, not DACs.

Speculating: could be beneficial for the transport layer (driver works natively at deeper bit depth), or for the DAC to operate at its native word size. Dunno...
Could be of some benefit for DAC volume control.

Could be beneficial for processing and volume control, yes, but no need for either input data, transport path, or DAC to be more than 24 bits.

But if such a format is absolutely useless, as you suggest, why offer it as option?

Because one of the most popular marketing mantras is "bigger numbers must be better".

The only thing I can think of for certain is that increasing bit depth may be a way to avoid having to dither samples (say, if the samples have gone through some DSP operations, even soft-volume changes).

But in that situation, the dithering is in any case not harmful in any way - and has to happen at some point anyway.