If ripping CDs to FLAC > ROON, any need for CD player/transport?


No, I have no CD transport to connect to a DAC. For me a transport is out of the equation and makes no sense independent of sound quality. I just say when comparing, several measures must be taken to make the comparison as much apples/apples as possible.

I think the decision for a transport or not shouldn’t be sound related as there are so many other aspects more important for each one compared to the expected sound difference.


We’re in total agreement. My only transport is connected to my computer for ripping. I moved some years ago to completely computer-based audio.

I do buy CDs on occasion as they often are the best available and I do find a good rip can sound better than streaming from Tidal (probably different masters). I don’t believe comparing a CD or a rip or Tidal is worthwhile unless all other variables are consistent.

I see no need for a spinner other than the aforementioned USB player used for ripping.


I could care less about any difference in sound quality… there won;t be… Why? Because I listen to more music more often having it all on my server. Done.

For ripping, I use EAC… as long as it is bit-for-bit, you win. I ripped… I don;t even know how many CDs… two walls worth. Took literally months. I use WAV, all bit-for-bit and uncompressed. For ripping, my cd drive in my desktop. For playing on the network, I use my Accuphase cd player… where I can send a digital out to my DS or play directly to my integrated… but I don’t bother with it. I almost never turn it on.

BTW, storage gets nothing but cheaper and transport gets nothing but faster. Why compress?

Bruce in Philly


Compression isn’t the only reason to use flac. flac contains a checksum of the music data that’s independent of the metadata. You player will let you know if the music has been corrupted (or you got a bad read/bad network packet…) You can scan your music collection to look for bit-rot (which is more and more likely to happen to each of us as the shear amount of data we have grows.) More often I find problems caused by disk errors caused by power outages, etc. but it’s still good to check your whole collection now and then.


Hi, Ted

How does one scan music for errors?


From the moment i bought the Melco and ripped my cd’s direct with it’s FLAC Uncompressed encoding option (which stores audio uncompressed, for those who want WAVE PCM with better Tagging), spinning cd’s on the PWT has no added value.


Foobar2000 can scan any playlist or library search result (right click/Utilities/Verify Integrity). dBpoweramp can scan a file selection in Windows Explorer or you can use it’s (hairy) batch select and then scan (right click/Convert To/Test Conversion). I’m pretty sure JRiver also supports it and probably any other reasonable player.

When they aren’t scanning flac’s or other formats that have checksums they by default perform a file read looking for read errors.



Thanks, Ted. I was wholly unaware of these featuers even though I regularly use Foobar and dBpoweramp.

I need to pay more attention.


I’m pretty sure the discs I tested for those albums came from that box set (certainly the extra’s, like Birth of the Dead). They are all “fake HDCD.” No HDCD features are enabled so they should sound the same with and without decoding, except the decoded files would be 6dB quieter, which is not exactly desirable. You won’t lose anything if you rip them using the Mac version of dBpoweramp without the HDCD decoder.


Ted, can dBpoweramp also check a whole library with the Accuraterip function, which also works for all other file formats by checksum comparison with their database during ripping?

At first I thought of saving all first file versions (no matter which format) to a backup I wouldn’t touch, as the flac checksum helps to identify errors, but not to get the files back. But together with the constant backup cycle this would mean 3x16TB in my case…too much. If your whole collection is from still available discs at home, it’s another case.

So I decided to pass on that checksum argument for flac and converted all to aif/dsf and took the risk of loosing without recognizing single file consistencies in case. So far I at least didn’t recognize any by sound problems.

I think at the end flac just helps to identify and recognize…all the rest of the problem fixing is the same for all formats, isn’t it?


I know the dbpoweramp product PerfectTUNES can.



Yes dbPoweramp can check Accuraterip with a scan (or when ripping), But that doesn’t help with non-ripped files. CueTools can help heal bad rips or corrupted files ripped from known CDs. I’m always confused by it’s interface, but I’ve used it successfully for CDs that wouldn’t rip with no errors.

I definitely find a file or two with problems now and then, I’ve always been able to get it off one of the backups. I back up my NAS to both a sea of USB 4T drives formatted with ReFS configured with two way mirroring and online with CrashPlan. The selfhealing of ReFS seems to be better than the NAS’s RAID scrub recovery in my system from an empirical point of view.

To me helping to identify corruption is clearly the biggest part of the problem. Also it’s helpful in detecting when some part of my hardware is failing… (Network, disk, ram…) Usually these problems give flac checksum errors sporadically and I’ve not lost any data from them as far as I know. I also keep md5 checksums of all of my .iso files, but that takes forever to check…


Do those wrong checksums result in dropouts?

Well, streaming also has it’s downsides it seems. I guess all this backup/checksum effort possibly is too much to be implemented by Paul into the Octave server as a set it and forget it solution.


Bad checksums simply indicate a problem. The problem may or may not be audible - it could be as simple as a few tens of bits wrong (a sample or two) which usually isn’t audible (but can be) or whole disk blocks wrong which usually is audible.


Yes, that’s about what I expected, thanks.

So I understand that there’s a certain need to make those checks but a solution to fix only if quite sophisticated backup measures are taken.

All this seems to be a practical matter at max. for IT nerds like us but not for the average streaming customer, so I think the recommendation of flac for this reason is in fact also quite limited to this target group.

But at least it’s interesting to know if/how much of a library is slightly corrupted. For my part, I’ll probably ignore it and in case of an occasional nameable audible problem I trust in the options to re-acquire the stuff. I fear, different than your experience, if something’s corrupt it would be so on all of the backups in most cases.

But thanks for the hint rg. crashplan. I’m still seeking for a good online backup solution with proper data privacy policy and a smart encryption option. But this service is US based, so…


HDCD is handled through the LSB (the 16th bit) and as long as you don’t use a lossy compression format (FLAC is lossless) you’ll preserve the HDCD encoding.


So what you’re saying Paul is, HDCD is preserved even without the plugin used? Would be great…I just wonder what’s the plugin for then…I never cared or used it so far.


Yes, HDCD is encoded into the datastream. The plug-in is used to decode HDCD. If you do not use the plug-in, nothing happens and the encoding remains as part of the file.


No, sorry. The bits are preserved but the small change in extra dynamics are not gotten without the plugin. I was just referring to the question of whether HDCD would be preserved with FLAC.

HDCD uses the LSB to attain an extra 6dB of dynamic range. So, you loose the 16th bit and the very small amount of low level information it contains in exchange for greater dynamic range as they toggle that. But, it’s only with the decoder in
play. Without the decoder an HDCD disc has 15 bits of resolution.


I meant the HDCD plugin offered in dBpoweramp for coding while burning…