Nucleus + any advantage with internal storage?

I’m waiting for my Nucleus + to pick up next week

I have aprox 2TB of audio on an external drive plus a another external drive for the backup.

Is there any advantage in adding a hard disc to put inside the Nucleus, or will plugging in one of the external drive achieve the same results?

Other than being neater nothing I can think off

An internal SSD inside the Nucleus will be quieter than using an external (non-SSD) drive connected via USB. A spinning disk is never completely silent.
Plus, an internal SSD will provide slightly quicker access to your music files, compared to using an external drive.
IMO an internal SSD inside the Nucleus is the ideal way to go.

My extrernal SSD is whisper quiet and fast enough for music files. Also easier to copy files to as I can move it to where I rip from.

1 Like

If I was getting a Nucleus+ I’d get the internal SSD (4TB) for aesthetic reasons. The Nucleus is a nice looking machine, and I would suppose it would be kept in a visible part of your stereo rig. Having an external drive hanging off the machine would look clumsy.
Not saying this is a good reason to do it, but performance-wise it would be close to a wash.

I agree :grinning:

It shouldn’t be any harder to copy files to an internal driven the Nucleus than to an external drive. The Nucleus will appear on your network and you should be able to see the internal drive showing on the computer you use to rip discs provided both the Nucleus and the computer are connected to the same network. It’s just a matter of copying files from the computer you do the ripping on to the drive in the Nucleus over the network connection so there’s no need to move the Nucleus to where you do the ripping. In fact, depending on the software you use to do your ripping you may even be able to rip directly to an internal drive on the Nucleus if you wish.

No good if ripping on a laptop thats on wifi. Also find the smb connection to ROCK is pretty slow speed wise more so over wifi. For me Its way quicker to connect the drive to my pc and copy them then plug it back in.

I found a slight improvement in SQ with an EVO 960 SSD compared to an external HDD plugged into the Nucleus. I have no problems copying files over the network.

I considered this when choosing Nucleus or Innuos.

With Innuos, and internally installed drive will cache in one of the cores of the processor. With external USB storage, it is effectively played direct from he drive. For that reason, I saw no point in SSD as read speed is not an issue and nor is noise, and went for a normal 4TB hard drive, not SSD. It will be interesting to know how Nucleus handles hard drive data, internal and external.

Innuos describe it better:

In-Memory Playback
The new Zen MK3 has 8GB RAM with 4GB dedicated memory. Music is loaded directly to memory for playback so that it doesn’t engage the hard drive, improving sound quality.

I think Nucleus does this with internal drives.

Roon does not play music from memory.

brianBrian LuczkiewiczRoon Labs: CTO

Jul '16

Memory play feature are, in principle, about separating playback and loading activity to prevent the loading activity from influencing local audio playback hardware via analog domain interference.

The way to accomplish a truly comprehensive memory play feature is to pre-load the entire playlist before the listening session starts, and then lock it against modifications for the duration of the listening session. This would guarantee that loading/playback never happen at the same time.

The reality is–the popular players all fall short of this, because it’s not acceptable to make the user wait for minutes for the music to start, to limit the length of a listening session, nor to prevent the user from reordering the play queue while they listen. All of the popular implementations we’re aware of are performing loading activity during playback under some circumstances They’ve just done things to shuffle the loading activity around in different ways (for better or worse). These features have always felt a bit misleading/dishonest as a result.

As you’ve noticed in your analysis–Roon opts for steady, consistent loading activity by keeping a fixed-sized memory buffer full on an an ongoing basis. Some other software opts for a more bursty approach, racing to fill a buffer each time the track advances. We prefer the steady way because bursts of high level activity are more likely to result in audible defects (especially the worst kind of audible defect: spinning up a fan) than steady, low-grade activity.

Another important thing to keep in mind: Roon is a multi-zone, multi-control-point media server with a library management system that is many times heavier than the lightweight players that typically implement memory play. It’s really a very different kind of system–so the best way to build, optimize, and configure it is not necessarily going to be the same.

As a media server, Roon performs background work–periodic syncing with our metadata servers and with TIDAL. Audio analysis. Filesystem watching. Metadata identification. And so on. As a multi-zone, multi-user product, someone anywhere in your household could kick off file loading activity at any time because they want to browse the library or kick off playback in a second zone. Unlike with a simple, single-zone music player, it is often impractical to reason about about file loading activity during playback in a system like Roon.

We don’t want to force a compromise between feature-set and sound quality–which is why we built RAAT, why we are continually working with hardware companies to get it implemented in a turnkey way (18 Roon Ready products have been certified in the past 6 months), and why we released Roon Bridge–so users could access RAAT without paying big $$ to a hi-fi manufacturer.

RAAT gives you the tools to isolate the media server from the listening environment, which basically moots the goals of “memory play”. Neither analog domain interference nor fan noise are much of a concern if the media server is in a closet far from the listening room.

See this article for a high-level overview of Roon’s architecture
See this article for an overview of how we believe you can get the best SQ from Roon
See this article for some background on why Roon is based around a powerful Core and how we use it

I’m open to discussion regarding memory play, particularly if someone can explain:

  • Exactly how a memory play feature should work in a media server like Roon, both in terms of user experience changes, if any, and in terms of what is going on under the hood, when/how buffering takes place, etc.
  • What promises a memory play feature in Roon should make–as I explained above, most other memory play features do not completely separate playback and loading activity. If we simply copy other players, neither would ours.

We are hesitant to make a dishonest feature, and are committed to being open and honest about how our system works to a greater extent than is typical in this space–so whatever commitments we make must be defensible.

You can only use memory playback with Roon on Inuous using the development version of SqueezeLite. Roon bridge does not support memory playback nor does Roon full stop. As posted above. There is a long ongoing thread about it.

Cant say I noticed any difference in SQ when I switched from USB HDD to the same Samsung SSD in a usb3 enclosure. I can’t see the connection making any difference to this but who knows in this cray hobby.