3 ms·

That's actually pretty nifty, and shows what a little bit of corruption does to an image. Hopefully more systems will start shipping with checksumming file sys

That's actually pretty nifty, and shows what a little bit of corruption does to an image. Hopefully more systems will start shipping with checksumming file systems by default. Even better if they have error correction. I still have some of the first MP3s I ripped back in the late 90s. They still play, but it sounds like a scratched CD. HDDs aren't as robust as we'd like to think.

baddox 13y ago
Have you had those MP3s on the same disk since the 90s? That would be the only practical way that bits would flip.
- sitharus 13y ago
  They've been across about 4 different disks. I copy using SCP, so it's unlikely that the corruption happened over the network, most likely it was between the CPU and disk as it was being read/written.
  - sixothree 13y ago
    Another possibility is that the encoding program did something slightly non-standard which is no longer recognized by modern decoders?
    - sitharus 13y ago
      It's possible, but I'd expect modern decoders to be more resilient to out of spec files. I'd share them, but copyright and all that.
      - Amadou 13y ago
        A couple of things you could do. Get an mp3 error checker and see if it has anything to say about the particular files. You also might want to grab EncSpot Pro (free, for windows) to figure out exactly what codec you used. Chances are that if the codec was buggy, then it's been documented such a google search on the specific codec and version will probably turn up people talking about the known errors.
vitovito 13y ago
JPEG actually support self-repair: when you save out a JPEG, you can insert "restart markers" every so often, which basically repeat the original headers and allows a decoder to recover from any corruption. If you put enough restart markers in an image, you can swap or replace the compressed blocks between any given sets of restart markers in the same image without glitching it.
voltagex_ 13y ago
This won't help you now, but you could also keep parity files (PAR2 et. al) on a separate disk/media in case of corruption.

baddox 13y ago

Have you had those MP3s on the same disk since the 90s? That would be the only practical way that bits would flip.

sitharus 13y ago
They've been across about 4 different disks. I copy using SCP, so it's unlikely that the corruption happened over the network, most likely it was between the CPU and disk as it was being read/written.
- sixothree 13y ago
  Another possibility is that the encoding program did something slightly non-standard which is no longer recognized by modern decoders?
  - sitharus 13y ago
    It's possible, but I'd expect modern decoders to be more resilient to out of spec files. I'd share them, but copyright and all that.
    - Amadou 13y ago
      A couple of things you could do. Get an mp3 error checker and see if it has anything to say about the particular files. You also might want to grab EncSpot Pro (free, for windows) to figure out exactly what codec you used. Chances are that if the codec was buggy, then it's been documented such a google search on the specific codec and version will probably turn up people talking about the known errors.

vitovito 13y ago

JPEG actually support self-repair: when you save out a JPEG, you can insert "restart markers" every so often, which basically repeat the original headers and allows a decoder to recover from any corruption. If you put enough restart markers in an image, you can swap or replace the compressed blocks between any given sets of restart markers in the same image without glitching it.

voltagex_ 13y ago

This won't help you now, but you could also keep parity files (PAR2 et. al) on a separate disk/media in case of corruption.