Even if the ROCK CD ripper worked perfectly as designed (and that seems to be questionable), the inherent design of the CD ripper is profoundly deficient. Let me count the ways:
The only supported format is FLAC. Really? What happened to .wav?
The default rip path is:
a) ROCK internal SSD
b) Any available USB storage connected to the ROCK
What’s wrong with this? It will pollute your SSD with music files that don’t belong there. It will pollute any attached USB drive (even if it’s NOT your library drive.
The ripping engine is primitive, slow, and the customer gets no control over the defaults.
Three strikes - it’s out so far as I’m concerned. I’d expected better from Roon.
It’s dead for this purpose, what would one need it for?
That seems sensible, why would ROCK not rip to its internal music store? Surely that’s what it’s there for?
But they do
It’s attached to the ROCK as a music store? Why else would it be attached?
I would not say primitive, it does use CD Paranoia. It’s true that this makes it slow, and one can argue that it should automatically be as fast if possible and as accurate when necessary as dbPoweramp is. That would require some UI, but it would be a good addition to ROCK/Nucleus for sure.
On the other hand, it is currently designed to be as automatic as possible, and that is also worth something to some users.
True, but as advertised. dbPoweramp and others exist for those who want more control
This support is meant to be as hands-off as possible. Obviously, you will need to physically load and unload CDs, but not much else in terms of setup or usage.
This support is also meant to be used in conjunction with Roon, and not other software. You will find it lacking if you use it with other software.
Um, I’m not sure I recall exactly, but I think Roon has considered jettisoning the built-in ripper before, because as you point out there are so many good tools out there that cater to different use cases, and there isn’t a compelling reason to keep it internal. But there are users who for some reason really really want it. I think we are a very diverse group with very diverse needs. I will say that posts which say “this non-core, barely supported thing sucks” will elicit people who agree with you in various ways. That is the sound of me agreeing with you. But I took one look and went back to EAC and haven’t been bothered since. Not sure what benefit I would accrue by having my rips within the same software. Ripping is infrequent, batch-oriented, and highly important to get precisely correct. Listening is constant, and errors while not fun are not high cost.
It’s nice for those that want to pop in a cd and get music. This works in the same way as most all the appliance type rippers that came before it.
For anyone who understands much more than that, I believe Roon shouldn’t waste any dev resources on it. There are some really good ripping solutions out there and you should go buy a license and support those efforts.
It’s free and part of a free operating system and does what it needs to for Roon. Yes it’s not perfect but at least they finally fixed it after nearly 2 years being bust.
I suspect WAV is excluded as the metadata support is so much inferior to FLAC.
FLAC when decoded properly (I believe Roon dos this) reconstitutes to a PCM stream identical to the CD source so why would WAV sound better but let’s not start that argument.
The Roon Core decodes the FLAC file, on the core, and sends the exact same PCM data whether it was FLAC or WAV. The DAC has no idea what it was.
Even with the DAC directly attached to the NUC and considering the “noise” bogeyman, the decoding of a FLAC file is done in mere seconds.
But why do you have one, then? The “Internal SSD” in this case is not the primary SSD for the OS and database, it is the secondary internal SSD whose only purpose is storing music files.
Roons ripper doesn’t add any metadata so is moot. It just pulls the cd info and looks it up from Roons sources you get files called track 1, track 2 no artwork no metadata.
With fewer storage reads to boot in all likelihood if we’re going down that route. What’s “louder” disk reads or the “sound” of a decompression algorithm?
I think he means all audio on one (USB) HDD or internal HDD/SDD so its a simple one to one copy for back up.
Its how I do it , every data drive has 2 matching size USB HDD for BU. Then Sync Back Pro just copies by difference no worries about size. If you are backing up incrementally you are probably only copying a small amount at a time
Oh yes - LET’S start that argument! The .wav vs. .flac issue is NOT going away! The “Flaccies” contend that because flac is a lossless format, it contains the same data as an uncompressed wav file. This is true.
The second argument made on behalf of flac is that it allows more file metadata to be included in the file. This is also true.
The third, and most significant argument made in favor of flac is that it takes less storage space (and depending on the compression level, sometimes significantly less space) than an uncompressed wav file. This compression is mostly useful for portable players that have limited storage capacity, but the general argument is also valid.
The wave file enthusiasts among us contend that every argument made in favor of flac highlights some “advantage” that has nothing to do with SOUND QUALITY.
The amount of metadata included in the file does not enhance sound quality.
The flac format has limitations on bit-depth and sampling frequency that the wav format lacks.
If the user is not using their audio files on portable devices, then the “virtue” of space saving evaporates - storage capacity is now really cheap.
And most importantly of all, ALL flac files, by definition, are compressed. This means that DURING playback, the resources of the playback device must be sufficient to not only uncompress and stream the audio signal, but also complete any and all “background” tasks requested of the machine. Does the decompression step affect sound quality? The answer is still debatable, but the burden of proof belongs to the flac advocates - and to date, there is no such incontrovertible proof.
So, ultimately, why take the chance of compromising audio quality to save storage space? Definitely a false economy!
FLAC supports 32 bit samples and at least 192 kHz sampling frequency (dunno if there is a limit). Unless for aliens, this is enough, but in any case it has nothing at all to do with ripping CDs
True, but you are talking about a NUC, which decodes a 40 MB FLAC in like 2 seconds and sends the resulting PCM (which is in every way the precise same as when reading a WAV and extracting the PCM from that) to the Roon endpoint, which is completely uninvolved in this.
Nope. The burden of proof is on those who claim the equivalent of a teapot orbiting the sun beyond Mars. But this does not matter - you make your choice, and you can rip your 16/44.1 CD, upsample it to 64/2048, and store it as punch cards, but this is in no way something that the ROCK ripper needs to take care off.
Yeah. This is precisely the separation of concerns benefit that Roon provides. This is not worth a war of religion to me, so that’s all I have to say, though surely it could be said with more words or repeatedly.
