What happens if a scratched CD is ripped to MP3?
Good CD ripper software like cdparanoia try their best to correct bad readings of a CD and will go over the affected part multiple times; sometimes for several minutes until the data is recovered. This is possible because CDs contain checksums for error correction and should detect a misreading straight away.
Due to this strategy, CD ripper software has a much higher chance of recovering the correct data than a typical CD playback device which is designed to playback in real time.
In the rare case that a portion of the data (which would be audio in your example) remains unreadable, the ripper will typically just skip that segment. So with an encoded MP3 file, it will skip the bad section (which could be either interpolated or audibly skipped in the resulting audio file).
The MP3 file format consists of frames. Each frame starts with eleven "1" bits and also a couple bytes of metadata controlling the bit rate and defining some other attributes. Each frame is independent, it was designed this way to support streaming.
Frames can have a CRC - an error check. It's optional.
The operating system will likely retry reading if it encounters bad sectors on a CD (CD hardware has its own error checking mechansim before the MP3 encoder even sees anything). Assuming the decoder is not working off of a buffer, the decoder won't receive new data during this process and will have to stop. If the operating system can't read the data, it may report an error to the operating system, which will eventually be reported to the process hosting the MP3 encoder. Depends on the software what happens exactly here.
A couple of possible things can happen if the data from CD is read incorrectly and still makes it to the decoder (this probably would not happen on a PC but could in a car stereo or other non-PC device):
An MP3 decoder looks for those eleven 1 bits to find the start of a frame - if it doesn't find them it will probably stop decoding until the next frame.
If the header data is bad, it may play the frame at the wrong bitrate since the byte indicating which bitrate may be wrong.
If the header CRC bit is set and the CRC doesn't match, the decoder will probably throw the frame out and not play it. Most MP3 files don't have the CRC bit set.
If the payload (data after the header) is wrong, the MP3 decoder will try to play it.
A decoder's job is to take the compressed data and generate uncompressed data to hand over to an "upper" level. That upper level actually uses the uncompressed data to drive an audio device. I would hazard to guess most encoders/audio driver setups have a buffer - with a configurable size - where the MP3 decoder can build up some data for the audio driver and allow retrying of reads.
So, anyway, if the decoder has stopped because it's not getting data, the upper level actually driving the audio might do any of the below:
- Upper level outputs silence. You would hear a break in the audio.
- Decoder stops filling data into an audio buffer, but upper level continues playing what is there. Audio buffers are typically "circular" which means they are not zeroed out but constantly overwritten with new data. You will hear a skip which is a portion of the previous audio playing.
- Upper level is smart and tries to interpolate what "should" be there. I don't think this is very common.
If the decoder outputs bad data, you will hear static or pops in the audio.
Reference.
In the best case, the ripper manages to retrieve enough data that the track plays just fine. In the second best case, it gives up and doesn't produce an audio track because it cannot. In the worst case, you get an audio file which sounds like when you attempt to play the track in a regular CD player or even worse (pauses, repeats, stuttering, blips, etc).
My experience with cdparanoia-based rippers has generally been mainly best-case, but I've encountered all three scenarios.