Ghost in the Machine: UnitiServe 1.7 sp1 - WAV to FLAC [back to WAV ?]

Sorry I was really unable to follow . . . but as a uServe owner I am interested in your experiences.  Perhaps as you work through this I will be able to glean something

Is there an issue between "ripping to flac" [ripping being defined by me the first time a file is 'pulled off of a cd and onto a hard drive'] and "converting already ripped .wav files to flac?"  It seems that you are discussing the two perhaps interchangeably. 

Hi Bart,

I appreciate the confusion.

I set the ripper to rip to flac. I understand it is 'suposed' to convert the existing library to the FLAC. it did not seem to do that.

I tried manually re-encoding a few album/artists to FLAC and it looks like it was doing it.

Came back later everything was still WAV.

Also tried ripping Peter's 'new' album [set to flac] and it still hasn't arrived in the music store.

Now off to the client. [BTW I design IT systems and infrastructures. So filesharing and windows is far from alien to me.]

Ron

Hi Ron,  yes changing to .flac is supposed to convert the existing library of rips.  I agree that for 'future proofing,' it seems that a flac library could be preferable.  One can always transcode to .wav on the fly with the uServe.

I'm not sure what might be going wrong other than some setting not pointing to your preferred Store on your nas, or the uServe not seeing that store following the upgrade process (maybe due to an ip address change).

From the manual:

file basis with the DTC or n-Serve for OS X applications."

Hi

Was just wondering why is Flac a preferable format over Wav for future proofing? sorry if this is a dumb question but my whole library is in wav, is it worth converting?

I would try a couple of albums and keep the WAV files backed up. The HDX-SSD to my ears sounds thinner and less dynamic playing back FLAC. I haven't tried it through NDS. The whole raison d'etre behind ripping for me is that all the reading, interpolation, error correction, guesswork and reconstruction occurs once at the time of ripping. From then onward it's just streaming. It strikes me as odd that I would want to put another process, even an "easy" one between the file and the stream. Smaller file size equals compressed in some way equals a need to reconstitute. This might account for my slightly fuzzy ear feel during FLAC playback. And then again it might not. Storage is cheap. Why skimp or potentially compromise? 

Harry I think that there are advantages to flac -- the ability to tag (embed metadata) in a very industry-standard, cross-platform way.

I am comfortable addressing the (possible) disadvantage of flac vs. wav by having the uServe transcode to wav before sending on to the NDS. 

For me it is not about storage (I have plenty of hard disc space), but about a database that in its current form is not very useable outside of the Naim server ecosystem.  Actually I have two databases -- my Store (rips made by the uServe) and my Downloads folder (other rips).  The Downloads folder is all .flac (maybe just a few m4a albums), and would be immediately useable by pretty much any other server/player system around, other than one that is iTunes based.  I do not think that the same can be said for what's in my Store.

Yes. tagging WAVs is easy enough but my god, it can be like pulling teeth if (as I have done) you want to read the files in another application such as iTunes. That's a good point which didn't occur to me. But I'm sticking to doing it the hard way for what I think is a sonic benefit in the main system. 

You've just given me an idea about booting up a healthy but unused ReadyNas, copying a TB of WAVs over and FLACKing them. I love this forum.

Good old slogan in the profession is ' if in doubt pull it out' , and yes sometimes easier said than done !  ATB Peter

Harry I was thinking "either, or" and not both.  You've given me a great idea too -- keep the .wav format in my uServe share, but "flac them" on a nas just in case I ever want them that way.  Touche!

We rock!

Uh oh...

Update: After the reboot of the US the albums I queued for re-encoding to FLAC are still FLAC. No evidence of automagic conversion.

Re: DigiFi: I saw the listing searching for DigiFi answers to update issues.  I am a consultant so finding answers is a thing I do.

Re: Bart & Manual: Thanks that is why I was figuring it would have all been FLAC but not a single file had 'transmuted'.

Re: FLAC v. WAV for the RIP to format: Metadata (tagging), robust file integrity (checksums) and universal recognition by every UPnP server and renderer. WAV is checksum free, as such it is prone to file system errors such as weak sectors and copy transfer errors.  With FLAC you can scan your music stores and identify files with errors. With WAV you can hope they don't have errors.

Re: FLAC to WAV on demand transcoding: I hear it, WAV does sound better. Most decent UPnP servers can transcode to WAV. The US does an excellent job at it.

Re: FLAC v WAV sound quality: I am researching this but my initial take is it is the jitter induced by the CPU computation to decode the FLAC to PCM for the DAC to render. Also the CPU will create noise on the DC voltage rails which can bleed noise into other parts of the system contaminating the conversion from file to audio or spdif stream (which is also an awful interface that is prone to jitter). In contrast WAV is just about as close to PCM as you can get so the computation is virtually nil and the problem is reduced to a pure file buffering problem. Also TCPIP unlike spdif is a guarantied delivery system complete with retransmission of lost or corrupt packets, spidif is a joke in this regard.

Re: Relative File size: Today storage is cheap which can lead us to believe lots of copies means we are safe. But backup copies are useless if they are corrupt. FLAC provides us with a degree of certainty that WAV does not. As anyone who has tried to recombine the various folders/drives/flash cards of digital pictures they have into a coherent collection knows, lots of duplicate files are a real buzzkill. We need a smarter answer or we will just get buried under terabytes of duplicate files with no sensible way to figure out which are the good ones or the bad ones or the new ones or the old ones.

Interesting DigiFi might be baking new cookies...

http://apps.microsoft.com/wind...1b-95a6-4d38138e7fba

http://apps.microsoft.com/wind...18-9ca2-1a0bc4ef7ac4

Of course we can hope:

https://www.duedil.com/company...74877/digifi-limited

Where did you get that from?

A bit of a paradigm shift? With all the emphasis Naim has placed on WAV as the optimum file format for best SQ with its streamers and their rippers doing it better, it beats me why anyone would want to rip to FLAC on a US / HDX??!

Now to figure out the optimal way to do this -- let the Naim Server do this? Or otherwise.

I need to figure out just where the Naim server will and will not build a flac library from the wav database.

Never say never. However, I haven't yet lost a WAV file, going back to the late 80s. I would in the first instance be more suspicious of dodgy hardware than a WAV file destroying its substrate.