<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 9, 2019, 1:36 PM James Knott via talk <<a href="mailto:talk@gtalug.org" rel="noreferrer noreferrer noreferrer" target="_blank">talk@gtalug.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-08-09 01:19 PM, Russell Reiter wrote:<br>
> Jpegs are an exported file format created from aggregated image data<br>
> collected by the CCD. They are digital files and subject to<br>
> transmission errors just like any other signal. My 13 megapixel phone<br>
> saves image data directly as a jpg file. Sure the raw data has been<br>
> manipulated before writing the original, but that is much different<br>
> than having an image recorded using raw format and then exporting a<br>
> copy in a lossy format in order to save space. <br>
<br>
<br>
Perhaps you need to learn about some of the technology.  Some media,<br>
such as CDs & DVDs use forward error correction, to ensure data is<br>
copied correctly.  When you transfer data over a network, there is a<br>
checksum used with TCP, with IP(v4) and a CRC check at the Ethernet<br>
level.  On top of that some applications </blockquote></div></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Umm what if two bits of the transmitted file are inverted but the count adds up to the same checksum? Checksums report errors, it would be up to the operator to ensure the data was copied correctly. So I can't agree with the semantics of your statement about forward correction ensuring a correct copy.</span><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">I think that since all these factors deal with accidental errors the term bitrot was not correct. Bit corruption on the other hand would include those changes induced by other corrupting factors, as opposed to happenstance and transient errors. </span></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">provide their own integrity<br>
check.  So, it would be very difficult for an error to propagate.  Now</blockquote></div></div><div dir="auto"><br></div><div dir="auto">CRC as an ECC tool also has its limitations where the SNR is high. </div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am aware some media will deteriorate with time, so the sensible thing<br>
to do is make periodic backups.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Well that is where this thread started. I think the logical conclusion of that was, the ancient recording methods had the longest true lifespan and as more and more technology was introduced, so did the valid life of the data get reduced.</div><div dir="auto"></div><div dir="auto"></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
---<br>
Post to this mailing list <a href="mailto:talk@gtalug.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">talk@gtalug.org</a><br>
Unsubscribe from this mailing list <a href="https://gtalug.org/mailman/listinfo/talk" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://gtalug.org/mailman/listinfo/talk</a><br>
</blockquote></div></div></div>