UnitiCore - Does what it says on the box ..... or not !

Even if the Core was working as it was advertised to do, ripping a CD collection using device-specific, propritary formats would not be a good idea in my view.

Rip your collection to .flac files using an established software (see http://www.thewelltemperedcomp...om/Intro/Ripping.htm) running on a general purpose computer under the OS of your choice. Edit the rips metadata with a software you feel comfortable with and check your work running MinimServer on the same computer that you use to rip and to edit the matadata.

Once you are happy with your work and with the way you can browse your collection in a control point, import your collection into the Core.

I too have had similar problems and hope Naim sort this mess out. I guess my main complaint is the lack of transparency from NAim or much in the way of comment. I complained of cds not ripping with the last tracks not completed......no idea what Naim are doing about this.

we need to know what is being worked on and a timeline for a fix?

nbpf posted:

Even if the Core was working as it was advertised to do, ripping a CD collection using device-specific, propritary formats would not be a good idea in my view.

Rip your collection to .flac files using an established software (see http://www.thewelltemperedcomp...om/Intro/Ripping.htm) running on a general purpose computer under the OS of your choice. Edit the rips metadata with a software you feel comfortable with and check your work running MinimServer on the same computer that you use to rip and to edit the matadata.

Once you are happy with your work and with the way you can browse your collection in a control point, import your collection into the Core.

Isn't that the OP's point The Core is supposed to do all of that, should you not be able to pop a CD in have it ripped an data stored hassle free? Isn't that what it is supposed be a one stop one shop ripping device, ' Your mucic collection re imagined" and all that.

not sure how big the market will be for the core,  most who want streaming would have ripped large collections by now, and if you are ripping a few at a time then its easy to do by other means ,   the all in one units look the solution for most customers and will surely be a great sell for naim

I agree it works great in playing music, we just need the bugs fixed.....please

nbpf posted:

Even if the Core was working as it was advertised to do, ripping a CD collection using device-specific, propritary formats would not be a good idea in my view.

Rip your collection to .flac files using an established software (see http://www.thewelltemperedcomp...om/Intro/Ripping.htm) running on a general purpose computer under the OS of your choice. Edit the rips metadata with a software you feel comfortable with and check your work running MinimServer on the same computer that you use to rip and to edit the matadata.

Once you are happy with your work and with the way you can browse your collection in a control point, import your collection into the Core.

Avoiding all that gobbledygook is exactly why i bought the UnitiCore !

Naim are still saying early April for metadata editing on the Core.  And I have found ripping is better since the firmware upgrade, although the metadata is no better.  But they will be very interested in details of specific CDs that don't rip with good data on the Core. You should drop Phil Harris a line at Naim about that as he may not read this thread.  Phil.harris@naimaudio.com

best

David

Thanks David, i have just sent Phil the following...

I have just ripped the CD that took 50 minutes on my core using a portable LG CD drive on my laptop into WindowsMP as a WAV and it took 5 minutes. The final track that took over 40 minutes on the core was a bit slower but completed in 50 seconds.

Maurice Andre - EMI 7243 5 73374 2 7  .   Disc 2 ,  which is printed as EMI 7243 5 73376 2 5   ( in case anyone on here has it )

I also included the details of a couple of CDs that show no data but are fine in the portable CD drive on my laptop.

Doyen     DOY CD236 , DOY CD199

I bought it as a Simple Quality solution to my CD library. However, while it is certainly the latter, it is definately not the former.

Whilst it wasnt my intention to get all techy, I have just signed up to the beta program to try and help.

Hopefully, soon it will achieve the standard normally assiociated with the NAIM name ....

Gazza posted:

I too have had similar problems and hope Naim sort this mess out. I guess my main complaint is the lack of transparency from NAim or much in the way of comment. I complained of cds not ripping with the last tracks not completed......no idea what Naim are doing about this.

we need to know what is being worked on and a timeline for a fix?

Hi Gazza,

If you are having issues with one or more discs not ripping completely then can I get you to do three things please?

1) Pull a copy of the album from the Music folder on your Core (complete with the Artist folder and Album folder) and ZIP it so it's a single archive that can be easily transferred to us via WeTransfer / DropBox / OneDrive etc.

2) If you have a Windows PC then grab a copy of IMGBurn and create an image of the disc itself as a .cue / .bin file and ZIP those files into a single archive that can be easily transferred to us via WeTransfer / DropBox / OneDrive etc.

3) Contact me directly at phil.harris@naimaudio.com and we'll get those files over to us and we can look into what is going on.

Best

Phil

Red Kite posted:

Thanks David, i have just sent Phil the following...

I have just ripped the CD that took 50 minutes on my core using a portable LG CD drive on my laptop into WindowsMP as a WAV and it took 5 minutes. The final track that took over 40 minutes on the core was a bit slower but completed in 50 seconds.

Maurice Andre - EMI 7243 5 73374 2 7  .   Disc 2 ,  which is printed as EMI 7243 5 73376 2 5   ( in case anyone on here has it )

I also included the details of a couple of CDs that show no data but are fine in the portable CD drive on my laptop.

Doyen     DOY CD236 , DOY CD199

I bought it as a Simple Quality solution to my CD library. However, while it is certainly the latter, it is definately not the former.

Whilst it wasnt my intention to get all techy, I have just signed up to the beta program to try and help.

Hopefully, soon it will achieve the standard normally assiociated with the NAIM name ....

...and I've just replied to you too.

Thanks

Phil

Hi Phil, I passed the disc info weeks ago to someone in the support team. I am not a computer expert and I bought the uniti core so I did not have to mess about doing as you suggested. I know many on the forum enjoy the fiddling around with computers, I do not. I bought the core to rip and then play the music, nothing else. Happy to ship the cds if needed.

Red Kite posted:

Description.... "Uniti Core is the ultimate fuss-free, no-compromise solution to ripping, storing, cataloguing and playing your entire music collection."

I have had dozens of Naim units over the years and didnt consider changing until recently but it looked as though it would be an easy upgrade for a streaming novice like me, replacing my CDS3 with a UnitiCore and NDS. Well, i have spent more hours on the internet and forums in the last few days than i can remember in a long while.

Basically it is not very good at doing what it is supposed to.

I have ripped a couple of hundred CDs so far. Many dont have the album cover art. Some of them then tell me its a completely different album along with listing all the wrong tracks. However i can then say its not this one, it then presents me with a massive list of others which it isnt ! On a few of the correct albums the odd tracks are just a few random letters. Others come up as the date for the album and track01 etc for the tracks. I have a very small number of CDs that it wouldnt rip, i noticed it was always the last track that was failing so i left it and finally after 50 minutes it finished one of them but i have given up on the others. Has anyone else had this problem, is the CD drive capable of reading all the way to the outer edge of all CDs ?

Apparently i cant edit the infomation..... I see that there will be some sort of update for tags. Will it correct all the errors or will i have to re-rip the affected CDs ? If so, is it worth carrying on until its sorted. And dont get me started about the high output from the NDS with my 252 volume control moving about 15 degrees before its deafening........

i have the unitserve and tried the core, and had the same problems. Sometimes i just restarted the nds and unitserve, then finally all my tracks appeared finally. Sometimes i need to clean more the cd to rip, with 90 degree alcohol. But sometimes it did not work.

As for covert albums or albums dispatched in several tracks, it is a common thing with unitserve and the core. You will have to wait april until to have the possibility to change the metadata ( on unitserve it is the desktop client).  With the melco the same problems, but even worse...

Bob the Builder posted:

nbpf posted:

Even if the Core was working as it was advertised to do, ripping a CD collection using device-specific, propritary formats would not be a good idea in my view.

Rip your collection to .flac files using an established software (see http://www.thewelltemperedcomp...om/Intro/Ripping.htm) running on a general purpose computer under the OS of your choice. Edit the rips metadata with a software you feel comfortable with and check your work running MinimServer on the same computer that you use to rip and to edit the matadata.

Once you are happy with your work and with the way you can browse your collection in a control point, import your collection into the Core.

Isn't that the OP's point The Core is supposed to do all of that, should you not be able to pop a CD in have it ripped an data stored hassle free? Isn't that what it is supposed be a one stop one shop ripping device, ' Your mucic collection re imagined" and all that.

I do not know precisely what the Core is supposed to do but I am a little bit skeptical when I hear phrases like "hassle free ripping", let apart the reimagination of one's music collection: what I do imagine is that most Core users would be perfectly fine if their devices would plainly import their data by just preserving existing information and without any form of reimagination. 

However, the point that I was trying to make is that, even if the Core would work properly, it might still be a good idea to do the ripping and metadata editing on a computer and by using open formats and platform independent tools.

I am not arguing that the OP should do so. I know that systems like the Core precisely aim at simplifying the tasks of ripping, editing and maintaining a music library. But I also know that such a simplification does not come for free. For some users, it might in fact be an oversimplification or even a complication. 

It goes without saying that there are no right and wrong choices. The OP will have to make his own.  Since the OP has bought a Core, I assume that he is already aware of the potentially negative consequences of taking the process of ripping and maintaining a music collection in his own hands. The purpose of my original post was to remind him of the potentially negative consequences of adopting device-specific solutions and proprietary formats.

Red Kite posted:

nbpf posted:

Even if the Core was working as it was advertised to do, ripping a CD collection using device-specific, propritary formats would not be a good idea in my view.

Rip your collection to .flac files using an established software (see http://www.thewelltemperedcomp...om/Intro/Ripping.htm) running on a general purpose computer under the OS of your choice. Edit the rips metadata with a software you feel comfortable with and check your work running MinimServer on the same computer that you use to rip and to edit the matadata.

Once you are happy with your work and with the way you can browse your collection in a control point, import your collection into the Core.

Avoiding all that gobbledygook is exactly why i bought the UnitiCore !

I know and I am sure that Naim will readily fix the most severe issues that are currently limiting the Core's usability. With my post, I only wanted to make you aware of the fact that there is no silver bullet solution to the tasks of ripping, editing, maintaining and storing a music library. It is possible that the Core is (or, rather, will be) a perfect fit for you. But it might also turn out that you find it easier to tackle these tasks using a more flexible, device independent approach. Sometimes facing a probelm is much easier than trying to avoid it.

nbpf posted:

I do not know precisely what the Core is supposed to do but I am a little bit skeptical when I hear phrases like "hassle free ripping", let apart the reimagination of one's music collection: what I do imagine is that most Core users would be perfectly fine if their devices would plainly import their data by just preserving existing information and without any form of reimagination. 

However, the point that I was trying to make is that, even if the Core would work properly, it might still be a good idea to do the ripping and metadata editing on a computer and by using open formats and platform independent tools.

I am not arguing that the OP should do so. I know that systems like the Core precisely aim at simplifying the tasks of ripping, editing and maintaining a music library. But I also know that such a simplification does not come for free. For some users, it might in fact be an oversimplification or even a complication. 

It goes without saying that there are no right and wrong choices. The OP will have to make his own.  Since the OP has bought a Core, I assume that he is already aware of the potentially negative consequences of taking the process of ripping and maintaining a music collection in his own hands. The purpose of my original post was to remind him of the potentially negative consequences of adopting device-specific solutions and proprietary formats.

Hi nbpf,

Just a quick point ... we're not using any proprietary formats for the audio data on any of our rippers / servers and so it will always be possible to use those files even if there was a "Day The Earth Stood Still" type invasion of nanites that only ate Naim anodized aluminium and all the Naim Cores were eaten overnight.

Thanks

Phil

Phil Harris posted:

nbpf posted:

I do not know precisely what the Core is supposed to do but I am a little bit skeptical when I hear phrases like "hassle free ripping", let apart the reimagination of one's music collection: what I do imagine is that most Core users would be perfectly fine if their devices would plainly import their data by just preserving existing information and without any form of reimagination. 

However, the point that I was trying to make is that, even if the Core would work properly, it might still be a good idea to do the ripping and metadata editing on a computer and by using open formats and platform independent tools.

I am not arguing that the OP should do so. I know that systems like the Core precisely aim at simplifying the tasks of ripping, editing and maintaining a music library. But I also know that such a simplification does not come for free. For some users, it might in fact be an oversimplification or even a complication. 

It goes without saying that there are no right and wrong choices. The OP will have to make his own.  Since the OP has bought a Core, I assume that he is already aware of the potentially negative consequences of taking the process of ripping and maintaining a music collection in his own hands. The purpose of my original post was to remind him of the potentially negative consequences of adopting device-specific solutions and proprietary formats.

Hi nbpf,

Just a quick point ... we're not using any proprietary formats for the audio data on any of our rippers / servers and so it will always be possible to use those files even if there was a "Day The Earth Stood Still" type invasion of nanites that only ate Naim anodized aluminium and all the Naim Cores were eaten overnight.

Thanks

Phil

Thanks for the clarification Phil. In this case, it should not be a problem for Core users to export their Core rips as .flac files, edit what they need or want to edit and reimport the edited files into the Core, should it? This might be a bit annoying, but it would be a temporarily workaround until Naim has implemented full support for metadata editing. Is there anything wrong with this workflow?

nbpf posted:

Thanks for the clarification Phil. In this case, it should not be a problem for Core users to export their Core rips as .flac files, edit what they need or want to edit and reimport the edited files into the Core, should it? This might be a bit annoying, but it would be a temporarily workaround until Naim has implemented full support for metadata editing. Is there anything wrong with this workflow?

No - the audio file formats are non-proprietary but the databasing is proprietary and as such if you take an album outside of the Naim Core "infrastructure" to edit it then you can't push it back in to where it came from however if you wanted to take a copy of the album ripped as a FLAC, edit it and then put it back into the "Downloads" folder you certainly could do so if you had the wherewithal to do so but that album would no longer be managed by the Core as you have manually edited it.

As I said, the music files are not proprietary so if you did at some point in the future want to take them outside of the Core and use them on another system then you would be able to do so so we don't in any way lock those files into a Naim-only system.

Cheers

Phil

Gazza posted:

Hi Phil, I passed the disc info weeks ago to someone in the support team. I am not a computer expert and I bought the uniti core so I did not have to mess about doing as you suggested. I know many on the forum enjoy the fiddling around with computers, I do not. I bought the core to rip and then play the music, nothing else. Happy to ship the cds if needed.

Hi Gazza,

I would rather not pull the CDs back here if possible (as then there's always a risk of them going AWOL) but if you are happy to send them back to me at the main Naim snail-mail address then I will make sure that they are checked and seen by the software team to see what is going on however it would be really useful to get access to the rips that are on your Core too so that they can be checked through as well... 

If you can identify specific discs that have issues then I could log in remotely if you wish and I could transfer copies of those albums over for us to take a look at...

...but it would be great if you could contact me directly by email so we can arrange this.

Best

Phil

Phil Harris posted:

nbpf posted:

Thanks for the clarification Phil. In this case, it should not be a problem for Core users to export their Core rips as .flac files, edit what they need or want to edit and reimport the edited files into the Core, should it? This might be a bit annoying, but it would be a temporarily workaround until Naim has implemented full support for metadata editing. Is there anything wrong with this workflow?

No - the audio file formats are non-proprietary but the databasing is proprietary and as such if you take an album outside of the Naim Core "infrastructure" to edit it then you can't push it back in to where it came from however if you wanted to take a copy of the album ripped as a FLAC, edit it and then put it back into the "Downloads" folder you certainly could do so if you had the wherewithal to do so but that album would no longer be managed by the Core as you have manually edited it.

As I said, the music files are not proprietary so if you did at some point in the future want to take them outside of the Core and use them on another system then you would be able to do so so we don't in any way lock those files into a Naim-only system.

Cheers

Phil

Why so? The proprietary database is not a problem but what seems to be missing is an interface for importing .FLAC files into the Core's infrastructure and proprietary database.

Without an importFLAC interface, Core users will not be able to put their data under the Core's control, for instance, to take advantage of the Core's upcoming metadata editing capabilities. This suggests that Core's users will have to use two different approaches for editing the metadata of Core rips and for editing the metadata of music they have bought from, say, prestoclassical or hyperion. This makes little sense to me. 

In contrast, a fully symmetric exportFLAC / importFLAC interface would very much improve interoperability, make the "Downloads" folder obsolete and, finally, simplify the internal software architecture of the Core.

nbpf posted:

Why so? The proprietary database is not a problem but what seems to be missing is an interface for importing .FLAC files into the Core's infrastructure and proprietary database.

Without an importFLAC interface, Core users will not be able to put their data under the Core's control, for instance, to take advantage of the Core's upcoming metadata editing capabilities. This suggests that Core's users will have to use two different approaches for editing the metadata of Core rips and for editing the metadata of music they have bought from, say, prestoclassical or hyperion. This makes little sense to me. 

In contrast, a fully symmetric exportFLAC / importFLAC interface would very much improve interoperability, make the "Downloads" folder obsolete and, finally, simplify the internal software architecture of the Core.

Hi nbpf,

There is no intention for the Cores metadata editing facilities to be applicable to third party audio files - if you have "outside" music that wasn't ripped on Core then you simply drop it into the downloads folder and it will be indexed and assimilated into the library.

Anything ripped on the Core can be edited using the editing that will be in the app and anything not ripped on the core is indexed and used with the metadata payload that it carries - this is the same as on the existing servers.

Best

Phil

I think that there are so many users experiencing these problems with metadata that there has to be a recognition that there is a fundamental issue to be resolved.

a worry for me, based on comments above, is that many of the CD's I have imported from a nas drive (that were ripped on the HDX, have now gone into the core data storage with nonsense or blank metadata. Now these were not ripped on the core but we're done on the HDX. Above comments suggest this data may not be editable in the app.

the other question in the original listing asks if updated software will automatically correct these errors, or require re ripping if CD's. I don't believe this has been answered, but am interested as my listing on the core is not at over 8000 albums, imported and maybe around 100 with missing/wrong metadata

Phil Harris posted:

nbpf posted:

Why so? The proprietary database is not a problem but what seems to be missing is an interface for importing .FLAC files into the Core's infrastructure and proprietary database.

Without an importFLAC interface, Core users will not be able to put their data under the Core's control, for instance, to take advantage of the Core's upcoming metadata editing capabilities. This suggests that Core's users will have to use two different approaches for editing the metadata of Core rips and for editing the metadata of music they have bought from, say, prestoclassical or hyperion. This makes little sense to me. 

In contrast, a fully symmetric exportFLAC / importFLAC interface would very much improve interoperability, make the "Downloads" folder obsolete and, finally, simplify the internal software architecture of the Core.

Hi nbpf,

There is no intention for the Cores metadata editing facilities to be applicable to third party audio files - if you have "outside" music that wasn't ripped on Core then you simply drop it into the downloads folder and it will be indexed and assimilated into the library.

Anything ripped on the Core can be edited using the editing that will be in the app and anything not ripped on the core is indexed and used with the metadata payload that it carries - this is the same as on the existing servers.

Best

Phil

Phil, that makes little sense to me. I can imagine that there will be users that prefer editing metadata using the Naim app and others that will prefer doing so using other programs. But I can hardly imagine any user wanting to have to use (let apart learn) two different programs for metadata editing. It seems an unnecessary complication with no obvious advantage for experts and obvious disadvantages for beginners. I might be missing something, of course. Best, nbpf

nbpf posted:

Phil Harris posted:

nbpf posted:

Why so? The proprietary database is not a problem but what seems to be missing is an interface for importing .FLAC files into the Core's infrastructure and proprietary database.

Without an importFLAC interface, Core users will not be able to put their data under the Core's control, for instance, to take advantage of the Core's upcoming metadata editing capabilities. This suggests that Core's users will have to use two different approaches for editing the metadata of Core rips and for editing the metadata of music they have bought from, say, prestoclassical or hyperion. This makes little sense to me. 

In contrast, a fully symmetric exportFLAC / importFLAC interface would very much improve interoperability, make the "Downloads" folder obsolete and, finally, simplify the internal software architecture of the Core.

Hi nbpf,

There is no intention for the Cores metadata editing facilities to be applicable to third party audio files - if you have "outside" music that wasn't ripped on Core then you simply drop it into the downloads folder and it will be indexed and assimilated into the library.

Anything ripped on the Core can be edited using the editing that will be in the app and anything not ripped on the core is indexed and used with the metadata payload that it carries - this is the same as on the existing servers.

Best

Phil

Phil, that makes little sense to me. I can imagine that there will be users that prefer editing metadata using the Naim app and others that will prefer doing so using other programs. But I can hardly imagine any user wanting to have to use (let apart learn) two different programs for metadata editing. It seems an unnecessary complication with no obvious advantage for experts and obvious disadvantages for beginners. I might be missing something, of course. Best, nbpf

Totally agree with nbpf. If core is supposed to be a single mechanism for an user to manage his/her digital music then it should provide single mechanism to manage the metadata for music either ripped by core or imported to core (or copied to downloads). 

Regards,

Sourav

core blimey

I suggest we wait to see what the metadata editing version of the software and firmware actually brings before continuing to pontificate about unknowns. 

For myself this will be the critical step as one who bought a core myself. 

Core as a product stands or falls as an entire package at that point.