As ever on this forum, a little knowledge.....
Data Is stored on a CD using a redundant self correcting encoding sceme known as a hamming code. The specific system is called Reed-Solomon encoding. Data is stored as blocks, and depending on the level of redundancy in the data, a given number of errors can be detected, and a given (smaller number) or errors corrected. The enthusiastic student should look up Reed - Solomon on Wikipedia.
The more redundancy in the data, the more robust the disk, but the less data can be stored. That's why yellow book CDroms (which have a higher data redundancy) store less data than redbook music CDs.
So, for a CD player doing a one pass 'on the fly ' read, the hardware error correction in the drive will attempt to correct any errors encountered. If the level of corruption is too high, it will be able to detect the error, but not fix it. In this case, the drive will either leave the value of the errored sample the same as the previous sample, or perform a linear interpolation to the next known good sample and make the missing data up (too old to remember which).
This is where a rip and a CD player differ. If the hardware error correction can't fix the error, a CD player has to move on, in contrast, if the controlling software of a rip receives an error flag from the drive, it can ask the drive to have another go. CD drives are mechanical systems, in particular the stepper drive to the laser head has backlash, and 'having another go' can place the laser in a slightly different position relative to the disc which allows a successful read to take place. This is why you sometimes hear a drive on a PC sawing away as repeated attempts to read an errored section are made by repositioning the laser read head.
So, it is quite possible for a rip to be able to extract more correct data from a cd than a CD player, doesn't make the music from the rip any better than the original recording, just less wrong than the CD player.
A note about the 'checksum'. This has nothing to do with the error correction on the drive, but is an overall test of the entire track calculated by the ripping software. It's a lot more complicated than Chris's example above - (google cyclic redundancy check) but it performs the same function. If two rips have the same checksum, then it is likely that the data is the same - this is a final test of accuracy of the rip, and if in error, some ripping program's will have another go at the entire track.