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

[Ranath]

the dac version without mqa support is the same of the dac of this topic? I mean, same Measurements?

 

[w1000i]

the dac version without mqa support is the same of the dac of this topic? I mean, same Measurements?

I believe it should be the same.

 

[VintageFlanker]

the dac version without mqa support is the same of the dac of this topic? I mean, same Measurements?

We aren't sure about that.
From @MatrixAudio website:

X-SABRE PRO (MQA) used the ES9038PRO advanced 8-channel D/A chip, and its inner DSP unit and analog circuit have the high performance and better user experience. The new generation XMOS XU216 USB asynchronous transfer interface and new AK4118 S/PDIF receiver chip,

Maybe nothing noticeable in measurements, maybe not. But without certitude, We can't say X-Sabre Pro MQA and X-Sabre Pro (non-MQA) measure the same.
Also, not only this is an upgraded product, the MQA was significantly more expensive at launch.

 

[Krunok]

We aren't sure about that.
From @MatrixAudio website:

Maybe nothing noticeable in measurements, maybe not. But without certitude, We can't say X-Sabre Pro MQA and X-Sabre Pro (non-MQA) measure the same.

Those 2 chips work in digital domain ad process the signal before DAC chip so it is reasonable to assume they don't affect the analog signal as DAC chip and analog stage remained the same.

 

[Veri]

We aren't sure about that.
From @MatrixAudio website:

Maybe nothing noticeable in measurements, maybe not. But without certitude, We can't say X-Sabre Pro MQA and X-Sabre Pro (non-MQA) measure the same.
Also, not only this is an upgraded product, the MQA was significantly more expensive at launch.

I believe it should be the same.

This question was mostly answered by Matrix on page 4:
https://www.audiosciencereview.com/...-best-audio-dac-in-the-world.8729/post-220256

-> The measurements would be about the same.

 

[dc655321]

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

Ha, true. Had not considered the "sale-ability" aspect - I would be a terrible marketeer.

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

I would say perhaps not harmful. In a DSP/convolution engine for playback, there is a fixed time-budget to consider. Although, if selecting a variate from a TPDF, adding it to a sample, truncating/rounding, and checking overflow is blowing that time-budget, one is likely doing something wrong elsewhere in processing...

Curious why you say, "... dithering... has to happen at some point anyway"?
My thinking is that lack of dithering is likely inaudible for most music, even at 16 bits, and almost certainly at 24 bits of depth.
Happy to be shown the error(s) of my thinking though...

 

[Julf]

I would say perhaps not harmful. In a DSP/convolution engine for playback, there is a fixed time-budget to consider. Although, if selecting a variate from a TPDF, adding it to a sample, truncating/rounding, and checking overflow is blowing that time-budget, one is likely doing something wrong elsewhere in processing...

Indeed, that will be a very small part of the overall processing, and enough computing capacity should be planned in.

Curious why you say, "... dithering... has to happen at some point anyway"?
My thinking is that lack of dithering is likely inaudible for most music, even at 16 bits, and almost certainly at 24 bits of depth.
Happy to be shown the error(s) of my thinking though...

Yes, formally you don't *have* to have it. It is just how proper truncation is done these days. Of course there are people out there who get away even with leaving out the reconstruction filter...

 

[Yviena]

@amirm when you did the measurement for jitter on usb between async/sync did you also disable the jitter reducer, or did you leave it on.

 

[amirm]

@amirm when you did the measurement for jitter on usb between async/sync did you also disable the jitter reducer, or did you leave it on.

You are asking me a little too late given my poor memory. I am fairly certain I just changed sync/async mode.

 

[Yviena]

You are asking me a little too late given my poor memory. I am fairly certain I just changed sync/async mode.

np thanks for answering, but does this mean that async mode is not bitperfect due to ASRC while sync mode is?

 

[amirm]

np thanks for answering, but does this mean that async mode is not bitperfect due to ASRC while sync mode is?

Well, nothing is bit perfect inside these DACs as the PCM data is upsampled anyway before conversion to analog. As long as ASRC doesn't show errors of its own in the measurement data, then it is not a concern. That is the case here.

 

[Yviena]

Well, nothing is bit perfect inside these DACs as the PCM data is upsampled anyway before conversion to analog. As long as ASRC doesn't show errors of its own in the measurement data, then it is not a concern. That is the case here.

Hmm, i see i actually thought sync would have better jitter measurements as then the clock used is the CCHD 957 45/50mhz clock which has better specifications, the ASRC clearly does a good job then.

 

[ZXHSean]

Hi amirm! How do you perform the Jitter Noise test? Did you add jitter by APX555 manually or just run a 12kHz FFT averaging? I tried to run 12khz FFT tests and some of them are similar to your results but others goes abnormal after only several averaging. May I know your detailed setup and filter choise for jitter test?

 

[Bamyasi]

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).

I have e-mailed Matrix Audio and Nick from their tech support was able to help me with resolving this issue in no time. I can confirm now that the DAC will play MQA files via MPD under Linux just fine. Make sure you have your audio system configured for bitperfect playback and especially that the software volume control does not get in the way. This last one setting was easy to overlook, as it turned out.

I have then spent several hours listening to 2L tracks in various Hi-Res formats 2L offers on their download page, including MQA of course, and honestly, I was unable to tell much of a difference between them, even in fully sighted comparisons. If anything, I would prefer DSD256 version very slightly, although I am pretty sure I would not be able to spot it in a blinded ABX test. So much for MQA format for me, I've had my curiosity satisfied and do not find any reason to delve into it any further.

 

[amirm]

Hi amirm! How do you perform the Jitter Noise test? Did you add jitter by APX555 manually or just run a 12kHz FFT averaging? I tried to run 12khz FFT tests and some of them are similar to your results but others goes abnormal after only several averaging. May I know your detailed setup and filter choise for jitter test?

Since these signals are sent over USB and the device runs in asynchronous mode, there is no way to "add" jitter to the signal.

The test uses a special signal called J-test that is a square wave at 12 kHz, plus one at 250 Hz that toggles all the bits. To the extent the DAC has data dependency, they bleed into the output of the DAC.

Further, if there is any intrinsic jitter (inside the device), it gets aggravated the higher the signal level. The 12 kHz signal is high enough to create this situation.

Most of the time what we see is not jitter but other spurious tones.

If we are driving the DAC with Coax, then the AP can indeed create jitter. But even for that interface I usually just use the j-test signal.

 

[citraian]

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?

I have the old version (non-MQA) and it accepts 32-bit PCM

 

[JBNY]

I would prefer DSD256 version very slightly, although I am pretty sure I would not be able to spot it in a blinded ABX test. So much for MQA format for me, I've had my curiosity satisfied and do not find any reason to delve into it any further.

But you are missing the main point of MQA, its not that it is supposed to always sound better than other hi res formats. MQA is mostly for hi res streaming over the internet, something that is still difficult for flac 192K, DSD and others. For all local playback, MQA doesn't make much sense to me at least. I am happy with it as an option if for no other reason than they generally have very good mastering on the files they choose.

 

[Labjr]

MQA makes designers alter their DAC design to favor MQA. The reason PS Audio won't include MQA in their non streaming DAC model.

 

[JBNY]

I thought that the design was that only when the MQA circuit was engaged was the DAC geared to produce a sound endorsed by MQA. The main reason, I thought, was to not have the DAC coloring the sound, as so many boutique DAC do.

 

[Labjr]

I thought that the design was that only when the MQA circuit was engaged was the DAC geared to produce a sound endorsed by MQA. The main reason, I thought, was to not have the DAC coloring the sound, as so many boutique DAC do.

Paul McGowan said MQA wanted them to make changes that they weren't willing to make. Why would he care what happens when MQA files are playing? There's also other explanations and interpretations about the requirements of MQA. Either way MQA is telling you how to design your product. When everything sounds identical then there'll be nothing to set one brand apart from another.