Mint 20.3 can't detect C2 errors from a scratched-up music CD, yet native Windows 7 can? (but not Win7 in a VM?)

[NM64]

On my 2013-era custom-built PC running Intel 4th gen and Windows 7, Exact Audio Copy v1.6 is able to detect C2 errors without issue on a scratched-up music CD (actually the PS1 Wipeout XL disc which doubles as a music CD), and it does so without fail on various optical drives on different PCs to the point that it's my go-to disc for testing C2 support.

But in Mint 20.3 Cinnamon on the exact same hardware with the same CD and everything (the only difference being the SSD I booted the OS from), it doesn't seem to be able to read any C2 errors at all. It doesn't matter whether this is via the "sudo readom -c2scan" terminal command, via Exact Audio Copy v1.6 running through WINE 7.0-rc6, or even via Exact Audio Copy v1.6 with my SATA optical drive passed through to VirtualBox running a cloned image of my Win7 partition (the same partition that could find C2 errors when not running in a VM) - it always returns that no C2 errors are found.

I even did a sanity check by trying via a live USB running Linux Mint 20.3 XFCE (not a typo) but, again, no C2 errors were found despite using the same CD in the same optical drive on the same PC.

Now to clarify, this is literally the first time I've ever tried finding C2 errors through Linux Mint, so I have no idea if this is perhaps a long-standing issue or if it's some new development or is just something with my hardware. I'm still quite the Linux beginner (I'm kind of amazed I even figured out how to get "readom" working without a guide simply by following its included "help" and instructions).


I don't know if the following helps at all, but here's a screenshot of the "readom" output from the live XFCE session (it was definitely running as the CD was spun up the entire time that "readom" was processing and it took like 30 minutes or something):

• https://archive.is/Xq5Lk

[smurphos]

Just a hunch but the man pages for readom indicates it should be run with elevated privileges, are you using sudo with it?

[NM64]

I have no idea whether I had originally ran it with sudo or not, so to make sure I just ran it again with sudo but I still got the exact same result of 0 C2 errors found.

I've edited my first post so as to specifically state that it happens with "sudo readom"

[t42]

Despite the OSes mentioned in the subject line the problem is down to the abilities of the irreplaceable Exact Audio Copy and its particular ways to handle disks. From EAC FAQ:

On all CD-ROM media are at least two levels of error correction, called C1 and C2. If both fail, the output is probably not correct anymore. Most drives are not able to report if audio reads failed or not, so each block had to be read twice and be compared to make sure that everything is fine.

[NM64]

Despite the OSes mentioned in the subject line the problem is down to the abilities of the irreplaceable Exact Audio Copy and its particular ways to handle disks.

So if I'm understanding you correctly, there are basically three categories of optical drives:

1. (rare) drives that report C2 errors - this is what the "readom -c2scan" command is designed for
2. drives that don't report C2 errors but EAC is still able to retrieve C2 error information from
3. drives that don't report C2 errors and EAC is not able to retrieve C2 error information from

That still begs the question as to why passing my SATA optical drive directly through to the virtualized Windows 7 results in EAC being unable to retrieve C2 error information (and it's definitely passing it directly to the VM as I accidentally booted up said VM while an initial "sudo readom -c2scan" was running and it immediately become unable to see the drive until I shut down the VM and re-ran readom).

And I know that there's enough translation layers going on in WINE that, for all I know, the C2 information is being stripped out or something.

(I've also edited my first post to clarify that I'm passing my SATA optical drive to the virtualized Win7)

[t42]

You didn't say which drive(s) makes you are using, probably it's important. It seems we agree on that it is impossible to replace EAC and it can't be used outside of its own OS. Readom is a fork of cdrtools but the SCSI transport code was (wrongly?) modified (see why do Linux distributions create bad forks?). Rip Joerg Schilling. Also the readom mailing list link is not active. Comparing to EAC approach

-c2scan
Scans the whole CD or the range specified by the sectors=range for C2 errors. C2 errors are errors that are uncorrectable after the second stage of the 24/28 + 28/32 Reed Solomon correction system at audio level (2352 bytes sector size). If an audio CD has C2 errors, interpolation is needed to hide the errors. If a data CD has C2 errors, these errors are in most cases corrected by the ECC/EDC code that makes 2352 bytes out of 2048 data bytes. The ECC/EDC code should be able to correct about 100 C2 error bytes per sector.
If you find C2 errors you may want to reduce the speed using the speed= option as C2 errors may be a result of dynamic unbalance on the medium.

I have somewhere in the basement good old Plextor but no motherboard with PATA connector, can't test anything, sorry ...

Please note that in lossless community audio CD rip is done with EAC "Drive is capable of retrieving C2 error information" option set to off.

[NM64]

Please note that in lossless community audio CD rip is done with EAC "Drive is capable of retrieving C2 error information" option set to off.

Do you have more information on this, or should I go ask for more info on a dedicated audio forum (e.g. hydrogenaud.io)? I must admit that, while working with digital audio is one of my areas of expertise, ripping digital audio from CDs is... less so.

I'd been ripping discs with C2 enabled in EAC and had no idea that it was actually better to have it disabled...in which case the point of this thread is kind of moot anyway since my only desire was to make accurate rips rather than fast ones (speed was the only thing I noticed during testing - the resulting WAV file of the entire disc was 100% identical down to the SHA1 hash regardless of whether C2 was enabled or not, but it took considerably less time with C2 enabled).


(btw, since you seem to know more about audio on Linux than I do, I don't suppose you have any insight into my issue of not getting bit-perfect audio with PipeWire?)

[t42]

I think these guides can be useful
EAC Guides - Hydrogenaudio Knowledgebase