copying data from Uniti Core
Posted by: chrisb56 on 14 December 2018
Can someone let me know how I could copy the data I have burned onto my Uniti Core onto a network drive which I could then access (on a different network) from a Uniti Star, preserving the meta data?
Many thanks in advance!
Mike-B posted:Echolane posted:What am I missing? Please clarify why ripping in WAV format is bad?
Nothing whatsoever is 'BAD' about WAV, its just that the way Naim do it is not to the Microsoft/IBM standard
WAV ripped with a Naim Core, UnitiServe or HDX are ripped in a different way w.r.t. metadata packing to the MS/IBM 'standard'. 'Naim' ripped files cannot be used in a non-Naim machine & must be converted to 'normal' WAV or another format. The only way to do this is use the Naim ripper/server to convert to FLAC, then using a PC/Mac/Laptop the file can be converted back to the MS/IBM WAV format or one of the Apple formats to use with any compatible streamer.
To the best of my knowledge, this is not correct. Naim WAV rips are proper WAV files that can be used in every device that reads WAV files. It is just that they do not contain any metadata. The Core (and the US, HDX, etc.) saves the metadata associated with WAV files in a proprietary, Naim specific database. This would not be a problem by itself if Naim offered an "export to FLAC" functionality on the Core. In absence of such a functionality, users who have ripped their CDs to WAV on the Core have the metadata associated with these rips locked into a proprietary, poorly documented format. I understand that, if one rips to FLAC on the Core, the metadata are embedded into the FLAC rips. Thus, for interoperability and for the sake of avoiding proprietary standards, one should rip to FLAC on the Core. No matter whether one rips to WAV oder to FLAC, the metadata supported by the Core are very rudimentary and quite unsuitable for classical music.
Echolane posted:Rich 1 posted:I'm coming round to the fact that the Core has very limited functionality and compatibility and this needs to be addressed by Naim, otherwise unfortunately I can see it as being a short lived also ran. My wife and I can personally hear a difference to the better when using the Core against my Qnap NAS but we appreciate that others do not. It's a bit like the the debate around Ethernet and other types of digital cable. If your existing systems up to scratch and you can't hear a difference then go for a NAS and you'll have enough money left over for a sizable album collection! Rich
... That matters a lot to me because my bad back doesn’t like sitting at my desktop. Roon’s editing of metadata is done via Windows or Mac, which is a big disadvantage for me. Enough that I will probably keep the Uniti Core around.
To the best of my knowledge Roon ignores the metadata associated with no matter which files. Thus, editing of metadata is pointless if one uses Roon. I might be mistaken, I have never used Roon.
Echolane posted:Mike-B posted:Echolane posted:What am I missing? Please clarify why ripping in WAV format is bad?
Nothing whatsoever is 'BAD' about WAV, its just that the way Naim do it is not to the Microsoft/IBM standard
WAV ripped with a Naim Core, UnitiServe or HDX are ripped in a different way w.r.t. metadata packing to the MS/IBM 'standard'. 'Naim' ripped files cannot be used in a non-Naim machine & must be converted to 'normal' WAV or another format. The only way to do this is use the Naim ripper/server to convert to FLAC, then using a PC/Mac/Laptop the file can be converted back to the MS/IBM WAV format or one of the Apple formats to use with any compatible streamer.
Sadly, that is contrary to what I was told by Naim, who said their WAV was standard WAV. I so hope that doesn’t complicate my move to the Sonic Transporter. I had a brief trial with Roon and it had no problems with my WAV files, at least nothing obvious, so I hope it will be no different when I ask Roon to process from the Sonic Transporter.
If you intend to use Roon, the WAV metadata issue becomes irrelevant, as Roon uses its own metadata, unless you optionally set it to use the tags stored with the files. So in this case, you may be OK with the Core files, but if you ever choose to use then with other servers or hardware in future, the problem may come back to haunt you.
2
ChrisSU posted:Echolane posted:Mike-B posted:Echolane posted:What am I missing? Please clarify why ripping in WAV format is bad?
Nothing whatsoever is 'BAD' about WAV, its just that the way Naim do it is not to the Microsoft/IBM standard
WAV ripped with a Naim Core, UnitiServe or HDX are ripped in a different way w.r.t. metadata packing to the MS/IBM 'standard'. 'Naim' ripped files cannot be used in a non-Naim machine & must be converted to 'normal' WAV or another format. The only way to do this is use the Naim ripper/server to convert to FLAC, then using a PC/Mac/Laptop the file can be converted back to the MS/IBM WAV format or one of the Apple formats to use with any compatible streamer.
Sadly, that is contrary to what I was told by Naim, who said their WAV was standard WAV. I so hope that doesn’t complicate my move to the Sonic Transporter. I had a brief trial with Roon and it had no problems with my WAV files, at least nothing obvious, so I hope it will be no different when I ask Roon to process from the Sonic Transporter.
If you intend to use Roon, the WAV metadata issue becomes irrelevant, as Roon uses its own metadata, unless you optionally set it to use the tags stored with the files. So in this case, you may be OK with the Core files, but if you ever choose to use then with other servers or hardware in future, the problem may come back to haunt you.
At this time, I can’t forsee adding other hardware or servers so hopefully my Naim ripped WAV files won’t become an issue for me.
That said, I apparently fail to fully understand the issue. As I explained in more detail above, a Naim Support person told me in a private email that the WAV Data is not proprietary to Naim and no metadata is attached. How do Naim ripped WAV files differ from the IBM standard? What specifically causes a problem to some servers? Is it the absence of metadata?
Echolane posted:2
ChrisSU posted:Echolane posted:Mike-B posted:Echolane posted:What am I missing? Please clarify why ripping in WAV format is bad?
Nothing whatsoever is 'BAD' about WAV, its just that the way Naim do it is not to the Microsoft/IBM standard
WAV ripped with a Naim Core, UnitiServe or HDX are ripped in a different way w.r.t. metadata packing to the MS/IBM 'standard'. 'Naim' ripped files cannot be used in a non-Naim machine & must be converted to 'normal' WAV or another format. The only way to do this is use the Naim ripper/server to convert to FLAC, then using a PC/Mac/Laptop the file can be converted back to the MS/IBM WAV format or one of the Apple formats to use with any compatible streamer.
Sadly, that is contrary to what I was told by Naim, who said their WAV was standard WAV. I so hope that doesn’t complicate my move to the Sonic Transporter. I had a brief trial with Roon and it had no problems with my WAV files, at least nothing obvious, so I hope it will be no different when I ask Roon to process from the Sonic Transporter.
If you intend to use Roon, the WAV metadata issue becomes irrelevant, as Roon uses its own metadata, unless you optionally set it to use the tags stored with the files. So in this case, you may be OK with the Core files, but if you ever choose to use then with other servers or hardware in future, the problem may come back to haunt you.
At this time, I can’t forsee adding other hardware or servers so hopefully my Naim ripped WAV files won’t become an issue for me.
That said, I apparently fail to fully understand the issue. As I explained in more detail above, a Naim Support person told me in a private email that the WAV Data is not proprietary to Naim and no metadata is attached. How do Naim ripped WAV files differ from the IBM standard? What specifically causes a problem to some servers? Is it the absence of metadata?
The metadata is still there, it’s just stored differently, in a separate folder, and it’s this that makes it unreadable by most non-Naim server/streamers. If you use an all-Naim system, it’s not an issue. If you use Roon, it’s not an issue. If you convert to FLAC on a Naim device, it’s not an issue even if you subsequently use non-Naim servers or players, because the conversion changes the way the metadata is stored back to a conventional way. This only becomes an issue with the Core because unlike its predecessor, it is apparently unable to convert an existing WAV library.
ChrisSU posted:Echolane posted:2
ChrisSU posted:Echolane posted:Mike-B posted:Echolane posted:What am I missing? Please clarify why ripping in WAV format is bad?
Nothing whatsoever is 'BAD' about WAV, its just that the way Naim do it is not to the Microsoft/IBM standard
WAV ripped with a Naim Core, UnitiServe or HDX are ripped in a different way w.r.t. metadata packing to the MS/IBM 'standard'. 'Naim' ripped files cannot be used in a non-Naim machine & must be converted to 'normal' WAV or another format. The only way to do this is use the Naim ripper/server to convert to FLAC, then using a PC/Mac/Laptop the file can be converted back to the MS/IBM WAV format or one of the Apple formats to use with any compatible streamer.
Sadly, that is contrary to what I was told by Naim, who said their WAV was standard WAV. I so hope that doesn’t complicate my move to the Sonic Transporter. I had a brief trial with Roon and it had no problems with my WAV files, at least nothing obvious, so I hope it will be no different when I ask Roon to process from the Sonic Transporter.
If you intend to use Roon, the WAV metadata issue becomes irrelevant, as Roon uses its own metadata, unless you optionally set it to use the tags stored with the files. So in this case, you may be OK with the Core files, but if you ever choose to use then with other servers or hardware in future, the problem may come back to haunt you.
At this time, I can’t forsee adding other hardware or servers so hopefully my Naim ripped WAV files won’t become an issue for me.
That said, I apparently fail to fully understand the issue. As I explained in more detail above, a Naim Support person told me in a private email that the WAV Data is not proprietary to Naim and no metadata is attached. How do Naim ripped WAV files differ from the IBM standard? What specifically causes a problem to some servers? Is it the absence of metadata?
The metadata is still there, it’s just stored differently, in a separate folder, and it’s this that makes it unreadable by most non-Naim server/streamers. If you use an all-Naim system, it’s not an issue. If you use Roon, it’s not an issue. If you convert to FLAC on a Naim device, it’s not an issue even if you subsequently use non-Naim servers or players, because the conversion changes the way the metadata is stored back to a conventional way. This only becomes an issue with the Core because unlike its predecessor, it is apparently unable to convert an existing WAV library.
Providing a conversion to FLAC is not rocket science and Naim could easily implement this functionality on their Core devices as they have done on the UnitiServe. Thus, it is probably fair to say that this is a design choice rather than a technical limitation. Still, until an "export to FLAC" functionality is implemented, Core users should be aware of the fact that ripping to WAV means entering a dead end in terms of portability and interoperability. I would expect serious Naim dealers to make perspective Core owners aware of the implications of ripping to WAV with the Core and of the further limitations of Naim UPnP servers in terms of support for classical music metadata.
nbpf postedTo the best of my knowledge Roon ignores the metadata associated with no matter which files. Thus, editing of metadata is pointless if one uses Roon. I might be mistaken, I have never used Roon.
According to feedback on the Roon forum, there is a flag that can be set prior to Roon converting data (or afterwards) that tells Roon to use your metadata rather than Roon’s. I think that will turn out to be global rather than field by field, which is probably unfortunate considering that Roon has many more fields for metadata than Naim provides. For example, Roon has multiple fields for Artist. It has a separate field for Composer. So perhaps if I set that flag I will miss out on this extra metadata. I hope not. I have extensively edited my metadata for Title and Artist to follow a standard convention, so at least for Title and Artist, I should be in good shape. I will soon find out and I admit to being worried about it. It seems Roon has a bad reputation for classical.
But...having said all that, if Roon cannot read my Naim generated metadata, per this discission, I am completely out of luck in asking it to use my metadata. In that case, I might wind up with no metadata! Oh dear......
Regarding the classical music metadata editing of the Core, it’s not a problem if you want to rip some CDs, know what the albums are and what the individual tracks are. It gets more difficult if you insist on categorising the music according to the time of day it was first performed or the tenor soloist’s baby brother’s first name for example.
And searching on artist, conductor or composer is work in progress by Naim because although you can search, you can’t edit these fields so you are in the hands of the CD publisher, which means the search function is very heavily flawed.
The Core was obviously specified and designed by people with no interest in or knowledge of classical music, to the extent that they even released it initially with no metadata editing capability at all and were surprised at the fuss that ensued, but the difficulty the Core presents most normal classical music listeners is often overdone by some forum members.
My opinion of course.
best
David
David Hendon posted:Regarding the classical music metadata editing of the Core, it’s not a problem if you want to rip some CDs, know what the albums are and what the individual tracks are. It gets more difficult if you insist on categorising the music according to the time of day it was first performed or the tenor soloist’s baby brother’s first name for example.
And searching on artist, conductor or composer is work in progress by Naim because although you can search, you can’t edit these fields so you are in the hands of the CD publisher, which means the search function is very heavily flawed.
The Core was obviously specified and designed by people with no interest in or knowledge of classical music, to the extent that they even released it initially with no metadata editing capability at all and were surprised at the fuss that ensued, but the difficulty the Core presents most normal classical music listeners is often overdone by some forum members.
My opinion of course.
best
David
Luckily, I really don’t care about those missing fields that much. I am mostly happy with the data fields Naim is using. I like Naim’s editing feature which has allowed me to edit my classical and opera music to a standard convention. Any album with a composer is alphabetical and easily found by scrolling. But when I have to search for an artist instead I do get annoyed when the search by Artist fails to retrieve all the albums. Since I have a relatively small library at around 550 albums, it isn’t as awful as it could be to scan albums looking for the ones missing in the search. But it is annoying. If I consider how much the Uniti Core cost it becomes more annoying. Oh well. That is not the issue that is making me want to test the waters at Roon. It is mainly one of economy, that I don’t have to buy another very pricey Naim streamer for my TV audio system so I can stream there too. Instead, all four of my stereo systems are Roon ready, therefore able to stream my music simultaneously.