Are UnitiServe NAS backups NDX Compatible?

Posted by: jamesw on 18 November 2012

Hi All,

 

I have just started setting up and playing with my UnitiServe and NDX (very nice, I must say!). I'm currently lining up a NAS for backups, etc., (separate thread about which to buy) but had a question I'm uncertain about-

 

When I rip to my UnitiServe, which is incredibly easy and hassle free- one of the reasons I bought it, and then backup the UServe to the NAS, when I get one, I'm assuming the NDX will 'understand' the file structure and metadata, album art, etc., created by the UServe, being another Naim product and all? The reason being, a backup is obviously there in case of a UServe HDD failure, in which case the NDX would then be used as a streamer direct from the NAS backup while the UServe would be in for repair - I know this might seem paranoid having just bought it, but I've been around computers long enough to realise that HDD failure is a question of when, not if

 

I only ask because I've had experiences before where things like that which seem obvious, actually arent! If not, how do I backup, or batch re-process, my UServe rips so that the NDX can read them correctly with all metadata, album art, etc, intact? Something like Media Monkey with particular settings?

 

Cheers,

 

James

Posted on: 23 November 2012 by jamesw
Originally Posted by PinkHamster:

You stated that FLAC level 0 was sounding better than FLAC level 5. As I understood you conducted this test in order to test Phil's theory. Your result was that Phil was probably right, and that less processing work on behalf of the streamer would result in better SQ.

 

I say, you may have been influenced in your judgement by the assumtion that the playback of FLAC level 0 would require less processing power than that of FLAC level 5.

 

As a matter of fact the processing requirements for the decoding of different FLAC compression levels do not differ, or only by a very small margin.

 

Your conclusion as to reason of the result of your listening test is therefore not plausible.

I'm sorry, but you are the one being subjectivist. I have clearly stated that I haven't listened to the difference, if there is one, and I'm not claiming to know whether there is a difference either way. You seem to be claiming, not for the first time, that there can be no difference because your interpretation of a particular theory doesn't allow it. I'm not just speaking of one particular post, but your general attitude to this whole thread.

 

For example, in the post above- firstly, it seems you are assuming that the above listening test was flawed and that the person in question was being influenced by an expected outcome. How do you know this? Have you carried out a psychological evaluation to assess how suggestive his personality is? Or, even, do you know how revealing his system is to minute changes? You'd have to do something similar to claim your refutation as an objective fact in some way (even if such things were able to be so accurately assessed, which they're not).

 

Secondly, you seem to also be assuming that because, in your own words, the processing requirements for the decoding of different FLAC compression levels do not differ, or only by a very small margin [italics mine], there cannot be a meaningful difference in SQ due to increased processing requirement raising the PSU noise floor. Is that an assumption, too, or have you actually measured it with the relevant equipment?


The thing is, Phil has already stated that the difference is very small, but nonetheless significant. Now I'm going to make an assumption too- that someone at Naim measured this difference in power requirement and that's how they concluded the former points. I might be wrong, but the difference is, I'm not actually claiming to know different/better since I haven't actually carried out such tests. If you have, please do present the relevant data, and at that stage I'll happily concede that you're speaking factually. At that stage also, a new theory would be required to explain any differences in SQ between the relevant files, if they do indeed exist.

Posted on: 29 November 2012 by totemphile
Originally Posted by Phil Harris:
Originally Posted by totemphile:
Originally Posted by totemphile:
 

Hi Phil,

 

Thanks for posting on here indeed! I have just purchased an AssetNAS and will start ripping my CD collection soon. One question from my side, which format in your experience is second best to WAV from a SQ point of view, would that be AIFF? It's completely lossless as WAV is, as far as I understand, but it also allows for metadata management. I will be using XLD for ripping and am undecided whether to rip to AIFF or FLAC. I am leaning toward AIFF, mainly because it's an uncompressed format but also because it works in iTunes (which I also use). Asset UPnP transcodes on the fly though, so if I get a Naim streamer at some point in the future it could transcode AIFF or FLAC to WAV before serving up the file to the Naim streamer or it could serve up the original AIFF/FLAC version. At the moment I am still using my modefied Sonos ZP90 feeding an nDAC/555PS based set up and although the differences here is negligable, I want to plan ahead long term.

 

Thank you for your thoughts

tp

 

Hi Phil,

 

Any thoughts on the above or are you not at liberty to share your view on this?

 

Many thanks

tp

 

Sorry TP - hadn't seen that posting from you - one of the dangers of trying to handle queries on the forums and why we like people to contact us directly rather than assuming we'll just see everything up on here.

 

I have to say that I'd be quite wary of AIFF as a format after the experiences I've had with it - it is generally really badly supported by most of the NAS based UPnP servers out there (I would assume AssetUPnP is better as it generally is one of the best of the software UPnP servers out there).

 

I think that if I wasn't using WAVs then I'd be using FLACs and getting my UPnP server to transcode before streaming...

 

Phil 

Now, I missed your post...;-)

 

Thanks Phil.

 

Best

tp