<perhaps a favored libation while reading, due to length>
This was one of the reasons that caused (in my use case) to veer away from the Nucleus. Really wanted to go down the path of a Nucleus, but when you read the next paragraph - it starts to become obvious why the Nucleus just wasn’t an option.
Source storage is on a rather large NAS (ZFS RAIDZ3 for data integrity and data survival with a replica). However wanted a mechanism to periodically replicate music (and playlists) from the NAS to the Nucleus so that it would have everything local for playback. Then changes to files on the NAS would [periodically] replicate over. Unfortunately (and understand why), the Nucleus server option only supports a limited number of interactions for music source and having the music locally for playback means that there wouldn’t be a dependency - it would perform “as originally intended”. Solution (in this use case) was a supported NUC with 32GB of RAM (more than needed but assured headroom) with enterprise grade storage (over-provisioned) via an M.2 NVMe (OS/database) and a SATA SSD (local music files and m3u8 playlist storage only), inside a fan less case (with massive heat sinks). Then using rsync so that the NUC replicates (logical “pull only”) from the NAS every couple of hours - adding and removing files on the NUC’s local storage drive, to remain in sync.
Admittedly, a bit different from your issue/situation however having to ‘convert’ everything would be a monumental task. Well over 90% of the files are fully tagged in Apple’s ALAC m4a format while the balance are fully tagged mp3 files (tagging in both cases is done via MusicBrainz Picard, includes embedding album artwork - re-ripping from CD is still not complete, hence the mp3s). While flac continues to garner some excellent support, it’s still not as widely supported as m4a. Such as being able to play/use natively in the Apple ecosystem or use “as is” in in-vehicle storage for audio (not via phone). For more portable uses, connecting a dongle-based DAC to iPhone. Said differently, whatever works across your use cases is the route you should go - there’s no single answer, only the “right” answer in your context. Once you get started on that path it will be a LOT of work, but in the end it will pay dividends with how you continue to enjoy your collection.
The guidance of being [at minimum] album centric is sage. Tend to use a
[A-Z]<Artist><Album>\ hierarchy, with each track being something along the lines of:
artist-album-cd#-track#-name
cd# only if the album is more than one disc. Have a “cover.jpg” in each album directory along with that same file as a “Folder.jpg” file for completeness. This also helps to ensure that whatever player is used (Roon/Apple Music/Audirvana/…) has the best chance of being able to readily read/update it’s local database without issue. That structure seems to have worked particularly well across a wide array of playback options. Roon definitely has ZERO issues with it, even with a collection into the many 10s of thousands - likely folks with far larger collections (size, quantity and/or both). Still haven’t exceeded the storage capacity of a 1TB iPhone - yet. Hoping that a 2TB model will arrive before 1TB is insufficient.
Once you start playing with Roon, it can become quite addictive. The two primary aspects seem to be simplicity for ambient/non-critical listening (Bluesound and similar where everything can be controlled from the Roon app, with a “once and done” optimizing for sound quality) and getting drawn into the additional information that Roon populates around artists and albums. (Having gotten lost a few times, for hours listening to music and perusing information…)
One side thought about “conversion” from one format to another - this can actually degrade the resultant audio (historically this was certainly case, not sure if things have been able to overcome this). Premise is that whatever format you standardize on - just rip from source to that format to avoid potential degradation that may be incurred as a result “conversion”. Furthermore, every storage medium is subject to bit-rot. eg: over time, at a very low level you will have bits that change 1->0 or 0->1. Generally, this won’t be noticeable until there’s a sufficient number of these in a localized part of the storage media. This is where ZFS comes in. For brevity/simplification, ZFS will correct bit-rot so that you don’t end up with degradation over time. (rsync’s hashing algorithm likely wouldn’t catch such low level deviations until they’re more significant in which case the local media [on the Roon server] may also start exhibiting more visible signs of wear, etc. or the fact that rsync reveals constant re-write due to change on the Roon as an early indicator of an issue).
As far as issues - keeping the OS up to date (weekly at minimum), sometimes have run into an error where Roon barks about a database issue (it says to restore the database) but a reboot clears this. Appears to happen randomly, every couple of days to every couple of weeks. Probably something related to a minor change in a dependency and either a subsequent Roon update or OS/App update resolves the issue? Other is the more recent constant “metadata improver paused” - this used to work quite well but something changed. It demands some deeper inspection, as last time this was looked at - seem to recall that Roon was attempting to circumvent the locally configured DNS servers (that have proper security mechanisms) and go direct to open resolvers on the Internet (a security “no-no”), which is blocked - may be part of the issue.
