Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2(pesnta.1.3) 9/5/84; site epicen.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!umcp-cs!gymble!lll-crg!dual!qantel!intelca!t4test!t12tst!epicen!jbuck
From: jbuck@epicen.UUCP (Joe Buck)
Newsgroups: net.dcom,net.micro
Subject: Re: Squeezing program files.
Message-ID: <148@epicen.UUCP>
Date: Fri, 14-Jun-85 23:27:51 EDT
Article-I.D.: epicen.148
Posted: Fri Jun 14 23:27:51 1985
Date-Received: Thu, 20-Jun-85 20:40:30 EDT
References: <1414@ecsvax.UUCP> <784@turtlevax.UUCP> <1861@ukma.UUCP> <8072@ucbvax.ARPA>
Reply-To: jbuck@epicen.UUCP (Joe Buck)
Distribution: net
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 21
Xref: watmath net.dcom:1038 net.micro:10817

compress will almost always fail when trying to compress an encrypted file,
at least if the encryption is good. A good encryption algorithm removes
correlation between adjacent characters and makes all 256 bytes roughly
equally probable. So compress can't do anything with encrypted data. You
could compress first, then encrypt though.

Another place where compress fails badly is on sampled speech files,
where two bytes are used to hold each speech sample. The reason is that
compress can't exploit the situation when numerical values vary slowly;
it can only deal with repeated patterns. Other algorithms are much more
successful at compressing speech.

Similar problems exist on files containing float data (unless there are
lots of repeated values).

But it's great for text and executable images, the latter because they
have lots of zeros and because some instructions are very common with
respect to others.
-- 
Joe Buck		Entropic Processing, Inc. (epi)
	  		{ucbvax,ihnp4}!dual!epicen!jbuck