Using Mutec 3.1+ USB reclocker with the nDAC to improve Tidal SQ

Posted by: MartinCA on 31 December 2015

To save people reading through this whole long post – this is it in a nutshell…

Problem: Some feeds into the nDAC (specifically Tidal, but any music from a PC, Sonos, or Airport Express) don’t sound as good as others (specifically Unitiserve, USB stick).

Hypothesis: nDAC reclocking is not sufficient to fully clear jitter and noise

Solution tried: Mutec 3.1 USB reclocker to pre-clean input to nDAC.

Outcome:           It worked. Very Well!  I'm very happy.

 

This is the long version…

Background

I love Naim DAC. When it came out, for me it was a game-changer – much better sounding than my CD player and able to play music from lots of different sources.  But I soon came to the conclusion that, despite its ability to reclock, not all sources were equal – the same music (WAV rips) played on my directly connected Unitiserve or from a USB stick sounded better than music fed in from an Airport Express or from a PC which could sound a little flat.

It wasn’t particularly an issue (because I just used the Unitiserve) until I started using Tidal. That was a year or so ago, and before Naim announced Tidal support in their streaming products, so I tried a Sonos as a bridge, which worked well, but the SQ wasn’t quite up with the Unitiserve.  On this forum Simon-In-Suffolk suggested trying a reclocker and Aleg recommended a Mutec 3.1+.

https://forums.naimaudio.com/to...60#45633863823643260

I had a feeling that Naim would bring out Tidal support for its streamers which would solve the problem, but I kind of felt that I’d end up paying several thousand pounds for an admittedly excellent streamer, but I’d be paying twice over for the DAC part, whereas a Mutec costing around £600 would solve the problem in my set up for much less money. The Mutec had very good reviews. It’s essentially a recording studio piece of kit, which for my purposes would take a SPDIF input stream via toslink, BNC or coax, and reclocks it out very accurately and cleanly. 

So I put in an order for a Mutec 3.1+ USB, opting to wait for the release of the USB version (which adds a USB input capability, which I felt would give me more flexibility). It arrived a month or so ago, coinciding with nDAC firmware update.

Sound Quality

The combination put a huge smile on my face. The sound I am getting is much better - more ‘metal’ on brass instruments, more 'edge' on guitar strings - basically more clarity and detail, more realism in what was already a good set-up (nDAC, TP-XPS, 252/SC-DR, 250DR, PMC 20-22).  It really does sound equally good to me now whatever the source.

But because the Naim upgrade went in at the same time, I’ve spent a bit of time over Christmas trying to define what difference the Mutec is making.

I’ve tried combinations through the Mutec vs direct to the nDAC of:

Sources: Tidal, Synolgy NAS, Unitiserve;

Players: Media Monkey (PC), Sonos, Unitiserve, Tidal (PC);  

Connections: Inputs - QED Performance USB, Cables-to-go BNC, QED Performance Optical Toslink; Outputs – Naim DC1 BNC-BNC

To be quite honest there was no ‘bad’ here – it all sounds good, with or without the Mutec. Also, I can’t really hear very much difference between many of the combinations.  Poor recordings, I think, make more of a difference at this level.

Despite this one overriding conclusion I can come to is that in all cases it sounds better through the Mutec.   With the Mutec in the chain I felt there was more clarity, better separation between the strands of music, more detail, more naturalness, more edge (metallic notes on brass and guitar strings) more percussiveness.  It’s easier to hear at the top end (despite my hearing being none too good up there), but whilst I find it harder to define the lower end improvement, I feel it is there as well: trying to put words to this - it feels as if there is both more precision and more space, more reverberation.  Overall, more drive and life.  Also much more satisfying to listen to over long periods of time.

Sources: I cannot tell the difference between where the music has come from – Tidal, US, or Synolgy.

Players: I cannot tell the difference between different players (although MediaMonkey does sometime ‘stick’ and repeat the same 15 seconds or so of music over and over).

Connections: I started out thinking that the quality of the input cables into the Mutec wouldn’t make much difference, although the very helpful people at Mutec said that their beta testers thought they did, and they agreed with them. And in fact my impression was that the QED USB cable sounded better than the printer cable I started off with, and indeed I also thought that the optical input gave the best results of all.  But I can’t be as definite about this – the differences were hard to hear.

Set-Up and Using

The Mutec is a neat little box - half width and not too deep.  In black with mostly green lights it fits in well with the Naim kit, although there are quite a few lights!

I wasn’t sure how easy it would be to set up. The instructions were reasonably detailed and accurate – but because it has a lot of functionality it isn’t 100% clear that I was setting it up right.  But in fact it worked straight away on the optical and BNC inputs without any problems.  I did have problems getting it to work over USB – I think because of the cable, but it may have been just one of those things with PC set-ups.  Mutec pointed me in the right direction (they were great) and I got it working with a printer USB A/B cable, and then I changed it for a QED cable, and since then it’s been fine. 

I formed the impression that the SQ improved as the Mutec warmed up, though I can’t be certain that wasn’t a placebo effect – I checked with Mutec whether it was OK to just leave it on, and they said that would be better for the oscillator anyway.

Switching between inputs involves pressing a recessed switch through a cycle until you get the right one – that could be a bit easier, but it isn’t too much of a chore really.

HD Music

The Mutec will output up to 24/192.   To change the bit rate being output, you have to change the setting in the driver, in the PC control panel – which might be a pain if you want to switch back and forth between different rates (there might be an easier way, but I've not registered that yet).  On the other hand, it seamlessly reclocks whatever you feed in to whatever you want out.  So you can up-sample 16/44 to 16/176 for example, or 24/192 if you want.  Whether it is better to do that or let the nDAC work with the native resolution I haven’t worked out yet.  I seem to remember someone saying somewhere that the nDAC works best with a particular sample rate but I couldn’t find the reference from a quick look at the forum.

Again – to be honest, I’m not yet hearing the difference between the HD music and US ripped CDs – but I need more time to experiment and listen on that - I've concentrated on 16/44 music.

Conclusion

I’m really pleased with the Mutec. I wanted it to bring music coming from the PC up to the UnitiServe standard, and it not only does this but also improves the US SQ too.  I find it much easier to get lost in the music - the system is now what I always wanted it to be.

Posted on: 01 January 2016 by MartinCA

Anyone else using a Mutec - or indeed any other reclockers with the nDAC?  What are your experiences?

Posted on: 01 January 2016 by nbpf
MartinCA posted:

Anyone else using a Mutec - or indeed any other reclockers with the nDAC?  What are your experiences?

My understanding is that a Naim DAC can only process incoming streams of data without associated time information that conform to the S/PDIF protocol.

Time information is reconstructed inside the DAC which thus acts as a reclocker (or perhaps just as a clocker) and as a digital to analog converter.

The Naim DAC is known to be fairly sensitive to the quality of the incoming data stream. Thus, I can imagine that a reclocker upsteam the DAC could have a positive impact on its sound quality. On the other hand, I would expect such an impact to be limited if the incoming data stream comes from a decent USB to S/PDIF converter.

I have considered testing the new Mutec MC-3+USB as a USB to S/PDIF converter (not as a reclocker between a USB to S/PDIF converter and the DAC because I want to keep my chain as simple as possible) but I have decided to wait until it becomes clear(er) whether Naim is going to upgrade its server range or not. 

 

Posted on: 01 January 2016 by MartinCA

I think SPDIF always combines the clock and the data - the clock is encoded as a sort of binary metranome alternating 0 and 1 like a tick-tock, then the audio bit stream overlays that so that a '1' changes the clock value on a 'tick', and a '0' leaving it unchanged.  What the nDac does, I believe, is strip away the clock data having worked out what bit rate is being used, buffer the reconstructed audio stream, and feed this into the DAC chips using it's own clock.

My technical understanding is not good enough to explain why this doesn't completely clean up a bit stream, but people like Simon-in-Suffolk have said it is to do with cross-talk - I assume that means that the better the input, the less work the nDac does and the less cross-talk there is.

I agree with what you are saying in your third para though.  On keeping the chain as simple as possible - I also agree with that sentiment.  But there's an interesting article about the positive effects of using serially connected reclockers in fromt of a DAC.  Cost and space (and inability to hear the difference in many cases) would make this prohibitive for most of us, but it implies that it is worth having a reclocker in the mix.

Posted on: 01 January 2016 by nbpf
MartinCA posted:

I think SPDIF always combines the clock and the data - the clock is encoded as a sort of binary metranome alternating 0 and 1 like a tick-tock, then the audio bit stream overlays that so that a '1' changes the clock value on a 'tick', and a '0' leaving it unchanged.  What the nDac does, I believe, is strip away the clock data having worked out what bit rate is being used, buffer the reconstructed audio stream, and feed this into the DAC chips using it's own clock.

My technical understanding is not good enough to explain why this doesn't completely clean up a bit stream, but people like Simon-in-Suffolk have said it is to do with cross-talk - I assume that means that the better the input, the less work the nDac does and the less cross-talk there is.

I agree with what you are saying in your third para though.  On keeping the chain as simple as possible - I also agree with that sentiment.  But there's an interesting article about the positive effects of using serially connected reclockers in fromt of a DAC.  Cost and space (and inability to hear the difference in many cases) would make this prohibitive for most of us, but it implies that it is worth having a reclocker in the mix.



I might be wrong of course, but my understanding was that S/PDIF, in contrast to I2S or TCP/IP, can be affected by jitter exactly because of the missing time information. Of course, all connections can be affected by RFI, but this is a different issue.

I came across the article you mention and, in fact, I have been considering testing the mutec or the Hydra Z myself, see https://forums.naimaudio.com/to...-for-naim-dac?page=1

The main reason why at this point I am reluctant investing time and money into further improving my source is that I think that the current approaches towards streaming from LAN resources are essentially doomed.

There is a very obvious way for making the conversion of digital audio contents perfectly source agnostic: just transfer all the files to be played to a dac internal memory and start conversion to analog after the data transfer has completed.

This approach would make all sorts of converters, reclockers, streaming bridges together with their PSU completely useless. And very much contribute to reduce both aesthetic and electric pollution in our living rooms. Thus, it is likely not going to be supported by any mainstream company!

Still, this does not mean that we have to pile-up arrays of converters, mutecs, melcos, etc. in front of our humble DACs!

If I want the best sound quality achievable with my Naim DAC, I just send the data to be played to a USB stick (instead of sending them to the M2Tech) and plug the stick into the DAC.

This is certainly sub-optimal but, in my view, much better that building monstruous chains of devices just to get a little bit nearer to what could be easily achieved with a simple script, some local memory and a decent wireless network.

Posted on: 06 January 2016 by MartinCA

Hi again

Actually I thought that the Unitiserve gave slightly better sound than the USB stick, though both were good.

I do see the benefit of one box (to rule them all) which does the streaming and DAC work.  If I was starting from scratch I might well have gone for an NDS or NDX, but since I already have a media PC, Unitiserve, Sonis, and nDAC, for me it is a question of how to maximise the potential of all that.

In discussion on this forum people seem to claim that the best source for the nDac is the NDS - separating the streaming from the DAC circuitry with separate power supplies minimises both jitter and cross-talk, but whatever the reason that is what their ears are telling them.

I hadn't really thought about it in this way, but I guess my hypothesis is that the Mutec (fed by a Sonos or a PC or or a Unitserve) is doing what the NDS would do - in fact, with a more accurate clock, it might even be better. 

My own ears are telling me that it is an improvement on the Unitiserve, as well as other sources, so it can't be far off, and for the price of £600 that seems like a bargain!

 

Posted on: 19 July 2016 by SteveH

I notice that Andrew Everard has just reviewed the Mutec on his website and mentions he is getting good results with a nDAC

Posted on: 20 July 2016 by likesmusic

Using s/pdif to transfer musical data to a DAC is just totally silly. The correct playback clock rate is a given, it is known absolutely, it is in the metadata of the file. Why add a clock signal that can never be perfectly extracted to the data and make the DAC try and follow it? Just silly. Whether such a DAC uses PLL or ASRC or whatever to try and smooth out the extracted clock it can never do it perfectly. Far better to say "Here is some data, please replay it at 44.1kHz". You can do that with USB (although in stupidly small packets), or much better using ethernet in nice big chunks. Reclocking is an attempt to fix a problem that should never exist.  The humble Logitech Touch takes nice big chunks of data across a wired or wireless network then uses one of two fixed frequency clocks to clock that data out of memory at a precisely known clock rate. And Logitech, or SlimDevices as they then were, were doing that years ago. 

Where s/pdif does make sense is in a live or real-time context where you cannot afford the latency of buffering. But for music sitting on a hard drive? Silly.

Posted on: 20 July 2016 by Andrew Everard
SteveH posted:

I notice that Andrew Everard has just reviewed the Mutec on his website and mentions he is getting good results with a nDAC

Indeed, and also good results with MacMini -> Mutec -> Digital 1 input on the NDS. Think I still prefer the sound of the NDS direct from the NAS over the MacMini -> Mutec -> nDAC route, but it's a fairly close-run thing – and of course Mac/Mutec/DAC saves something like £10k!

Posted on: 20 July 2016 by MartinCA
SteveH posted:

I notice that Andrew Everard has just reviewed the Mutec on his website and mentions he is getting good results with a nDAC

Thanks for pointing that out.  Good review! 

I've had mine in system for 8 months now, and I am very happy with it - it has transformed my computer as a source to my nDac, and I am very happy listening to Tidal or downloads played through the computer to the Mutec.  I also run my Unitiserve through the Mutec in preference to running it direct to the nDac, and I think it is still marginally better than computer sourced music, though I suspect I wouldn't do well in a blind back to back test.

The NDS/555 combination still seems to be to top choice by all accounts, but following what Andrew says below, I am just very happy to be in the same league at a fraction of the price!

Posted on: 20 July 2016 by MartinCA
likesmusic posted:

Using s/pdif to transfer musical data to a DAC is just totally silly. The correct playback clock rate is a given, it is known absolutely, it is in the metadata of the file. Why add a clock signal that can never be perfectly extracted to the data and make the DAC try and follow it? Just silly. Whether such a DAC uses PLL or ASRC or whatever to try and smooth out the extracted clock it can never do it perfectly. Far better to say "Here is some data, please replay it at 44.1kHz". You can do that with USB (although in stupidly small packets), or much better using ethernet in nice big chunks. Reclocking is an attempt to fix a problem that should never exist.  The humble Logitech Touch takes nice big chunks of data across a wired or wireless network then uses one of two fixed frequency clocks to clock that data out of memory at a precisely known clock rate. And Logitech, or SlimDevices as they then were, were doing that years ago. 

Where s/pdif does make sense is in a live or real-time context where you cannot afford the latency of buffering. But for music sitting on a hard drive? Silly.

Well - yes - I sympathise with the point.  NDX / NDS route is probably preferable, but expensive when you already have an nDac.

However, a lot of devices just spit out s/pdif (my Sky box and BluRay player for example).  Meanwhile the nDac on its own only takes s/pdif.   So we're kind of stuck with it.  The Mutec makes the best of things, and incidentally improves a USB connection despite outputting via s/pdif.  

Posted on: 20 July 2016 by Aleg
MartinCA posted:

... switch back and forth between different rates (there might be an easier way, but I've not registered that yet).  ...

 

There's no need for that of course.

 

Set mode (1st column) to re-clk + intern (1st + 3rd light)

Set reference (2nd column) to S/P-DIF BNC (bottom light)

 

this way it will reclock using the internal clock and use the incoming SPDIF as reference for the clock rate.

Manual pg 19.

Posted on: 24 July 2016 by MartinCA

Ah - I should have been clearer.  I am feeding the Mutec from the PC via the USB connection, which is a PCM feed.  Using this, I have to use the Mutec driver settings on the PC to set the bit rate that is being output.  The Mutec takes that in and reclocks it at the same rate.  So if I want to match the rate to the original file, I potentially have to make the change in the driver - it won't happen automatically.

But you are right if you are feeding the Mutec from an SPD/IF input.  My Unitiserve is connected on S/P-DIF OP - and the Mutec automatically outputs at a rate to match the input.

Perhaps I'll try the optical S/P-DIF output from the PC rather than the USB connection and switch the Unitiserve over to BNC - though that rather defeats the point of having the USB variant of the Mutec!

 

 

Posted on: 29 July 2016 by Andrew Everard

Latest firmware – v1.10 – is now available for download from Mutec. Have been using it for a while, and it definitely improves the already remarkable performance of the device, giving a cleaner sound, better detail resolution and more punch in the bass.