Let's develop an open-source media archive standard

From: Dwight K. Elvey <dwight.elvey_at_amd.com>
Date: Wed Aug 11 19:45:26 2004

>From: "Antonio Carlini" <a.carlini_at_ntlworld.com>
>
>> The necessity of CRC's depend on what you plan on doing with the data.
>> If it is just going to be sitting in a nice, safe box, then
>> it doesn't
>> matter.
>
>True. Unless you've gone to the trouble of archiving the
>stuff because you would like it to be reliably retrievable
>at some point in the future.
>
>If reliable retrieval in the future is of no concern,
>then I propose a format conisting of an empty file.
>At least you'll be certain of what you get :-)
>
>Seriously, after all the discussion of bit-rot on
>various media, how can you consider some sort of
>checksum to be anything other than essential?
>
>Some sort of error-correcting code might be an
>even better idea.
>
>Antonio
>
>

Hi
 Part of the problem here is that if the file containing
the archive had any bit rot, most systems designed to
read that media would simply fail to read the information.
In many cases, it might not even be possible to read the
CRC after the error occured.
 For error correction, one must also realize that one
can only correct a single burst of errors that is
smaller than a size specified by the correction method.
Most of these can at least detect any single bit error.
 I have been known to recover data from cassette tapes
by simply recording all of the data that comes out and
modifying the data after the error. In my case, it was
machester encoded and, by flipping and shifting the data,
I was able to determine the size of the missing data.
In some cases, the check sum was used to replace the missing
bits. Still, in this case, I was able to bypass the normal
code that read the media. I'm not against putting CRC's
in, I'm just stating that there are limitations to its
usefulness if something is lost other than to detect the
loss.
 To keep from losing things still takes full redundency.
Dwight
Received on Wed Aug 11 2004 - 19:45:26 BST