Compression on CDs

[Peter]

On Thu, 25 Oct 2007 18:46:00 -0500
Loye Young <loye.young at iycc.net> wrote:

> On Thursday, October 25, 2007 5:46:01 pm Soren Hansen wrote:
> > I'm quite sure this is not true. The burning process and the error
> > correction mechanisms employed on compact disks is complete agnostic
> > towards the nature of the data stored on the medium. From anything
> > below the application level, the data on the CD is just ones and
> > zeroes (and the occasional out-of-band data such as track
> > boundaries) whose likelyhood of read or write error is the same
> > regardless of the entropy of the data stream it's a part of.
> 
> Soren,
> 
> What you say is true as far as it goes, but the issue isn't whether
> there are more read/write errors, but instead whether the read/write
> errors that do occur actually make a difference.
> 
> Think of it like meteorites hitting the earth. Gene Shoemaker of the
> US Geological Society estimated that an impact event with a force of
> the Hiroshima bomb hits the Earth approximately once a year. 
> http://www.vectorsite.net/taimpact.html. But fortunately, most of the
> world is covered by oceans and wilderness lands, so the vast majority
> of all meteorites that fall from the sky fall harmlessly into the sea
> or on places nobody cares about (like Arkansas, USA, where the
> residents call them UFOs and blame the French, the Russians, or the
> Pope). See
> http://en.wikipedia.org/wiki/Impact_event#Modern_impact_events. So,
> apart from the occasional sci-fi thriller, meteorites don't cause
> much damage. If, however, the whole world were covered with land that
> were as densely populated as Tokyo or New York City, meteorites would
> be of greater concern. 
> 
> Similarly, if data on a disk is not compressed, large areas on the
> medium are essentially empty, so read or write errors, while they may
> occur, don't often affect data that's important. Compression, on the
> other hand, more efficiently uses that space, so more of the surface
> area actually has data. Thus, the same number of read/write errors
> are relatively more likely to affect important data. The higher the
> compression, the greater the density of important data and the
> greater likelihood that read/write errors will cause failure. 
> 
> Apart from theoretical analysis, I observe (as least anecdotally)
> that disks with compressed data have higher failure rates than with
> uncompressed data. I don't think I'm alone in my observations, but I
> admit that I haven't conducted rigorous scientifically tests, either. 
> 
> Happy Trails, my friend.
> 
> Loye Young
> 

Your analogy with meteorites is not correct.
The data on the CD is populated area, dense (compressed) or not), on the
CD. You won't have read/write errors in area's where there is no data as
you won't touch that area of the CD. If all data is compressed into one
file, one read/write error will impact all files in the compressed file
and there for you're loss will be greater.

If you get a read/write error in your populated area you have a
problem. The impact of the problem depends on the importance of the
file you are trying to copy. 

If you're error occurs during the copying of the kernel(Tokyo) you won't
be able to run your OS but if it occurs while copying the
calculator(Antartica) program, too bad you can't run the calculator but
your OS is still working. Both cases have nothing to do with
compression.

As a matter of fact if you take your analogy of the meteorites files
should always be compressed by themselves because the space the file
will take up on CD is smaller and there for less prone for a read/write
error.

Now if start of with a corrupt ISO you won't be able to burn the
image at all.

-- 
Peter van der Does

GPG key: E77E8E98
IRC: Ganseki on irc.freenode.net
Blog: http://blog.avirtualhome.com
Jabber ID: pvanderdoes at gmail.com

GetDeb Package Builder
http://www.getdeb.net - Software you want for Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20071026/e1808f51/attachment.pgp>