It's my understanding that is about generating the .iso file from the .deb files, not about generating the .deb files from source. Generating .deb from source in a reproducible way is still a work in progress.
For the major browsers, this probably makes little difference, but for anything else, this will most likely result in not verifying the revocation status of certificates anymore or making things slower.
As far as I know, most browser vendors already download the CRLs, and then update the browsers based on what they downloaded. For instance firefox seems to be using CRLite. There is a lack of support for something like that in the non-major browsers and non-browsers. The alternative they have is to download the CRL instead of the OCSP reply, which is larger, probably making things slower. Or they could just not check the status, which is most likely what will happen.
CRLite changes the failure mode of the status check, it no longer just ignores error in downloading the status information.
I did some research a while ago into ensuring up to date CRLs for a non-browser use case. Besides the problem of the massive size of CRLs, I couldn't find good tools for automatic updates across all trusted CRLs.
My conclusion was that it isn't really practical unless you only trust one or two CAs.
Making something like CRLite more like a standard seems worthwhile. I looked at the Mozilla bits but AFAICT there’s not much if any documentation of the low-level bits and pieces.
C2 is error detection, not correction. C1 is the error correction. I think what wikipedia is trying to say is that the C2 error detection just points out something is wrong, even after the C1 error correction, and so you can't fix it. But a data CD has additional error correction, so it can correct more errors.
An audio CD has 2352 audio bytes per sector. The sector also contains C1 error correction and C2 error detection.
On a data CD, those 2352 bytes are split in 2048 data bytes, plus an additional 4 error detection, 276 error correction, plus some other bytes including an address. So there is an extra layer of error correction.
This is based on submission to AccurateRip. As I understand it, it's how many tracks submitted by users owning that drive match the what AccurateRip considers the correct rip.
> As I understand it, it's how many tracks submitted by users owning that drive match the what AccurateRip considers the correct rip.
Wait: I'm pretty sure that's not how it works at all. No matter the drive, there's only one correct rip. And two people won't, by coincidence, happen to read the same disc with the exact same error(s).
So when you rip and compare to the AccurateRip DB, you know you have the correct rip if it matches the one already in the DB.
I don't think AccurateRip "considers" rips correct not: to me it knows with 100% guarantee. Which is the entire selling point of the AccurateRip DB. And which is why it's called that way.
If you care about accurate rips on Linux, the best tool to use is whipper: https://github.com/whipper-team/whipper. It makes use of the AccurateRip database, which is used to calculate the statistics. I don't know about any other native Linux application that makes use of it. Other tools like cdparanoia, and all the other wrappers around it, just attempt to read it multiple times and still get the wrong result, as the post shows.
The frustrating thing about AccurateRip is that several open source apps can pull down from it to compare your local rip, but IIRC the only app that is allowed to push rips back up to the AccurateRip DB (and hence make it more "accurate") is the proprietary, Windows-only EAC.
As one of the other links explains, ripping the same CD on the same drive a 100 time might still not produce the correct rip. Something like AccurateRip works by having multiple copies of the CD scanned, and then voting which one is the correct version.
I forgot that CTDB (http://db.cuetools.net/) exists, which is is an alternative to AccurateRip. CUETools is open source Windows software to rip CDs. Instead of just providing a checksum of the track, it provides error correction information. So instead of just getting that you probably have a bad rip, and keep getting a bad rip, it's possible to correct the rip. EAC has a CTDB plugin that's installed by default, whipper currently doesn't support it.
AccurateRip is not something from EAC, it's from dbpoweramp.
