3 ms·

I never thought about it that way, thank you! It makes me wonder what audio format could be fun to corrupt this way. FLAC, maybe?

driax 13y ago
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.
- DebianUser 13y ago
  I don't think it has much to do with the fact that it is lossless, but rather that it does not compress in a suitable way. In the scheme of things outlined by GGP. Whether such scheme implies lossy is a question that needs to be demonstrated imho.
jensnockert 13y ago
Each block is independent in FLAC (and quite short), and therefore wouldn't generate as interesting artifacts.
saidajigumi 13y ago
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.
dspillett 13y ago
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".

driax 13y ago

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.

DebianUser 13y ago
I don't think it has much to do with the fact that it is lossless, but rather that it does not compress in a suitable way. In the scheme of things outlined by GGP. Whether such scheme implies lossy is a question that needs to be demonstrated imho.

jensnockert 13y ago

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

saidajigumi 13y ago

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.

dspillett 13y ago

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".