Are Naim rips readable using non-Naim streamers?

Thanks.  I suspect I'm probably getting confused by comments about Naim Metadata being difficult to edit.  Can the non-Naim streamers read the metadata generated by Naim rippers?

You can certainly read the WAV files produced by HDX & Unitiserv with other devices so long as you've ripped to a 'share' (shared folder) on an external hard drive.  The Naim devices are not keen on allowing you to see the data stored on their internal drives, however it's freely available on the NAS drive.  The only gocha is that you should avoid changing or adding to the Music Store folder on the external drive using anything other than the Naim device - it confuses the HDX / Unitiserv for a while.  If you absolutely have to add WAV files without using the Naim device to do it, you can use the database rebuild function on the HDX/Unitiserv to reconstruct its cataloge and make it happy again.  But note - this is a No-No in the product manual, perhaps for obvious reasons.

But coming back to your question... Yes. 

So ...

I've got the 24/192 "Meet Me In London" download from Naim and a high res download from Linn records.  If I added thosecto the music store would just the Linn download upset it, or would the Naim download cause problems too?  Sorry for all the questions, but I'm just trying to sort out in my own mind any questions I'll need to ask Cymbiosis about when I go for demo next week.

Dungassin,

It is not the streamer which reads the music library. It is the task of the server software which sends the data to the stream client. It is true that most servers can not read Naim library metadata. I have been searching on this last month, and MediaMonkey turned out to be the only non-Naim server which can read Naim library. However, this is just not a problem, because Naim rips are made by Naim server devices (HDX and UServe) which have their own internal server software. So you will most probably be using these servers to stream to the stream client. It doesn't matter at all which brand this client is, as long as it is UPnP compatible. It does not make any difference if you use the internal storage or elsewhere to store the library.

You can not add a downloaded file to the 'music store' of Naim rips. It is rather called a 'network share', where you store your other music files. Naim servers are very successful in indexing and reading all kinds of downloads from different sources and streaming them to stream clients.

So, what do you actually do?  Do you set up separate folders on your NAS for downloads/rips from sources other than the HDX/Unitiserve?

Exactly. And, your HDX/UServe will be able to read and stream from both of these folders to a client, or just playback these files locally. In fact, especially with HDX, I strongly believe, that you don't need a client device (in the same room). It will playback locally these files with the highest quality (possibly to your nDAC). You don't need a streamer if playback will be in the same room.

Thanks for the help.  For the time being any streaming is likely to be one room only.  I'm considering that option rather than a HD HDX purely because of the no of CDs to be ripped (>2000), so any storage is likely to have to be on an external NAS, of which I already have one.  Any multiroom use is moot ATM, because the other system (my 52/135 active SBLs etc) is in the living room and (alas) rarely used due to SWMBO restrictions.  Not sure she could actually cope with the complexities of learning yet another new device anyway (she still summons me frequently to sort out very minor laptop niggles).  If she let me near the active system more often I would never have bothered upgrading the AV system to its current level.

A little surprised at Naim for opting for a tagging system which can be read by hardly anyone else.  If I do go down the streaming route perhaps I should consider swapping my nDAC for and NDX and do my rips using dBPoweramp which I already own  (purchased to do bitperfect rips to try out the nDAC with USB sticks).

Most likely I'll just finish up buying the XPS or 555PS to go with my DVD5/nDAC for now and live with that for a little while.  Still intend to listen to the HDX and Unitiserve next Tuesday to keep my options open.

Decisions ... decisions ...  

Naim rips are the same as other rips in that the music content is the same.

Any player that can play WAV files can play them. 

You might not see all the metadata and cover art. 

If playback is all in one room then a new Mac Mini with Naim DAC/555PS is as good as anything I've heard. When playing 24 bit recordings it sounds better than any CDP I've heard. Of course, others may have different views. 

If you want to stream then the Pioneer N50 + Naim DAC/555PS may be worth a look, not heard it, but the features and price definitely make it worth an audition. 

dBPowerAmp is probably the best CD ripping software around, shame it only runs on Windows. 

They have no choice.  When they decided to rip exclusively to WAV they made their bed.

Now you get to lay in it.

Tagging WAVs corrupts the files, not that people dont do it anyway.  It is not within WAV specifications.

-patrick

Thanks for the information.  I'm going to discuss options with the dealer during the demo next week.

In addition to the specific difficulty of wav files, which Patrick points out, there seems to be no standard in tagging other formats either. When I tried different servers, I experienced that each has a difficulty sorting out files from different sources. In fact, Naim server was the most successful in sorting out downloads from various sources.

The amginfo.xml file (for discs ripped by a Naim server which have been matched using the Lasso API) is separate from the WAV audio files and is freely readable, provided that an appropriate XSLT style sheet is created to load it natively into a (third-party) media server's database. This allows an appropriately-featured server to cache all of the metadata for a album playlist prior to playback, instead of extracting and buffering the headers at the same time as the audio data is being spooled.

So, I think what the op was asking is how do you do that dave, you have not provided a answer at all or is it just theory.

I think op question was answered already, and Dave was just giving a technical explanation.

... as to why Naim chose not to tag the wav file directly, as Simon says it is possible, but store the metadata on a separate file, if I have not misunderstood him.

It wouldn't be the first time I was wrong.  I did read the specification once.  I thought I read that tagging "broke" the specification, not that it wont "work", i.e. not every system will be able to read the tags or even the files if tagged.

Why doesn't/wouldn't Naim's rippers tag the WAV files themselves if there is NO issue with doing so?

-Patrick

Oh for the ULAC - Universal Lossless Audio Codec that everybody could agree to use. I think I'll put on a record. 

Isn't this the answer from David about why Naim did not chose to tag the wav file directly?

"This allows an appropriately-featured server to cache all of the metadata for a album playlist prior to playback, instead of extracting and buffering the headers at the same time as the audio data is being spooled."

So, I think what the op was asking is how do you do that dave, you have not provided a answer at all or is it just theory.

If you are using a Naim server with a non-Naim streamer–absolutely, it should play, display cover art, etc.–this is a function of the UPnP / DLNA server contained within the Naim server and works similarly regardless of file type or sample rate.

If you are not using a Naim server with the Naim rips (untagged WAV), there are no guarantees as to whether your specific UPnP / DLNA server will present the audio files in an organized, sensible manner–nor is there an established standard for external description of the audio files (iTunes, for example, uses a combination of relational database and per-track XML descriptions).

Embedded artwork and metadata can individually be addressed depending on the constraints of the system–for example, a hi-res album cover might cause some network players with limited memory bandwidth to choke when embedded into the audio file itself. As there is no established standard for extended metadata, on the other hand, this information can be stored outside the audio file (where it may be edited and updated independent of the audio file itself, possibly in real time). The server may then present this to the player in its up-to-date form, if in fact it can read or write the externally-located metadata files (as I responded above, this is server-dependent).

A functional example of this is as follows–a network player may request and queue a specific file which is missing artwork or has incomplete metadata, and (perhaps in an ideal world) the server can substitute or enhance the metadata in the background while the file is playing. Keeping the metadata separate permits this editing in situations where file locking might otherwise prohibit the server itself from re-writing information into the headers of the file while it is being accessed for playback.

This is an area of the UPnP / DLNA specification at the server side which has long required a sensible approach–who knows, maybe in this lifetime?