Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

possible (new) method of doing audio cd quality error rate analysis? #534

Open
walterav1984 opened this issue Apr 24, 2021 · 3 comments
Open
Labels
Feature New feature Needed: discussion More discussion needed before anything can be done (or still no agreement has been reached) On Hold Waiting for other actions

Comments

@walterav1984
Copy link

Stumbled upon a twitter post by Hector Martin @marcan quoted: https://twitter.com/marcan42/status/1381544164832108545

... There's no way to get raw error counts (pre ECC) off of most CD-ROM drives, but the subchannel has no ECC, so that works as a proxy for quality...

He uses subchannel "without ecc" data to be able to do audio CD error rate analysis by comparing it with normal ecc corrected data: https://github.com/marcan/cd-analysis

Not sure if this insight is new, or even usefull for this whipper project CDR/CD. I only found reference in libcdio changelog 1.0 of dropping subchannel support.

Feel free to use/close this issue.

@github-actions
Copy link

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing instructions.

@marcan
Copy link

marcan commented Apr 24, 2021

It works well, for what it's worth. Still need to run the proper numbers, but here's 93 CD-Rs from 10 different brands visualized.
cdrs2

That said, this is mostly useful to figure out how close to corrupting audio data a CD that otherwise rips fine is. I think there are simpler ways of finding out if the audio data itself is borked (and a good subchannel is not a hard guarantee that the audio part isn't bad.

Relevant: at least on my drive, sometimes the subcode "slips" and ends up offset vs the audio data. This seems to usually be a -3 sector offset, sometimes more in rough spots, and not consistent rip to rip. I currently compensate for this once I get a valid subcode CRC with a timestamp mismatch, and backtrack in case any immediately previous subcode sectors were bad to compensate (otherwise the skewed subcode would be recognized as lots of errors for those sectors).

Note that this method relies on knowing in advance what the subcode is supposed to be. I can do this for my CDs because I'm burning them with no fancy anything, the subcode is straight mode 1 timestamps and that's it. If you don't know what the subcode is at all, the best you can do is flag whole sectors as good/bad (which is still pretty useful info for low-level errors). Alternatively, you could add a heuristic that attempts to derive subcode info (e.g. you can probably interpolate a broken sector between two good ones if the track/index does not change, unless other modes are in use; more heuristics could help recover those).

@JoeLametta
Copy link
Collaborator

Hi, currently whipper prints messages like these:

Track 1 finished, found 122 Q sub-channels with CRC errors
Track 2 finished, found 65 Q sub-channels with CRC errors
Track 3 finished, found 51 Q sub-channels with CRC errors
Track 4 finished, found 257 Q sub-channels with CRC errors
Track 5 finished, found 78 Q sub-channels with CRC errors

The information is taken from cdrdao and can be used as a rough estimation of the CD's "health".
I'm not sure we can use a similar technique for more than providing informative messages...

@JoeLametta JoeLametta added Feature New feature Needed: discussion More discussion needed before anything can be done (or still no agreement has been reached) On Hold Waiting for other actions labels May 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature Needed: discussion More discussion needed before anything can be done (or still no agreement has been reached) On Hold Waiting for other actions
Projects
None yet
Development

No branches or pull requests

3 participants