Heh, at my first startup I used to get members of the audio codec team wandering over when there was a bug. I'd listen to the corrupted playback, draw out the codec block diagram, and point right to the likely error locations. As another commenter mentions, these were all lossy codecs. The character of noise would be very interesting much of the time -- effectively turning the decoder into a synthesizer.

FLAC would probably be a bad example, since it is lossless. It makes fewer assumptions about the content of the audio file, since it anyway has to encode all of the noise and minor stuff. Making too many assumptions of the content would only necessitate a facility to introduce specified noise into the audio later. Which I can't imagine would be both fast and small.

Most audio and video formats are based on encoding relatively short block independent of what has come before - otherwise when you skip into the middle of the track the player would need to read everything up to that point before being able to restart play.

Many video formats do look back a fair number of frames, so you do sometimes see corruption remain and spread for a few seconds, but then you hit a key frame or block boundary where everything resets and all is suddenly well again.

Audio compression is usually a different bag entirely: over a given time period the compression algorithm looks for what it can leave out or merge from the input signal over that time because human ears are unlikely to hear the difference, there is much less opportunity (compared to still images and video) to be able to encode "copy that chunk from a frame or few back, rotate/skew/what-ever it a small amount, then change these few blobs".

Each block is independent in FLAC (and quite short), and therefore wouldn't generate as interesting artifacts.