I’m trying to demonstrate the robustness of the error-correcting codes used in a common audio CD. My idea is to take a disc and drill a series of holes in it, starting from a few thousandths of an inch and working up. When I play the disk, the smaller holes should go unnoticed as the codes correct around the missing data. I can tell “where” on the disc the larger holes are, because they will wipe out enough data to have an audible effect, but is there any way to find out where in the audio stream the smaller holes are?
Not the really small ones, because those will be small enough that the data will be completely reconstructed. The slightly larger ones will cause better players to interpolate the data, and you may be able to see that on an oscilloscope (it will look light a straight line between the start end the end points). Some CD readers (back in the olden days) had an internal test point that allowed the monitoring of error data; I’m not sure if newer ones still do.
A point on the disk doesn’t correspond to a point in time in the audio. One of the many techniques simultaneously operating in CD players is that the signal is chopped into segments that are then staggered in time. One instant in the music will be spread over a long length of the track. I don’t know if it’s more or less than the circumference of the disk, but I’d bet it’s more, so that an instant of music appears distributed over random angles of one or more track.
By the way, the same thing happens in satellite radio. That’s why you can drive under a bridge for several seconds and not miss anything. It’s also why it takes a few seconds to hear a new channel after you’ve selected it - of course, all the segments must be stored in electronic memory and reassembled in the right order, with the oldest segments being stored the longest. You have to fill this buffer before you can start listening. Everything you hear has to be a few seconds old.
I’m guessing that satellite TV works the same because a channel change takes a few seconds most of the time. Dish I believe uses MPEG4 compression now, so there’s some decoding time too.