home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.os.msdos.apps:4734 comp.bbs.waffle:2373
- Path: sparky!uunet!mcsun!sun4nl!alchemy!accucx!nevries
- From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
- Newsgroups: comp.os.msdos.apps,comp.bbs.waffle
- Subject: Re: Stacker's TRUE compression ratio
- Message-ID: <3057@accucx.cc.ruu.nl>
- Date: 13 Sep 92 15:26:22 GMT
- References: <1992Sep12.130358.5693@midway.uchicago.edu> <TB5ZqB2w165w@presoft.com>
- Followup-To: comp.os.msdos.apps
- Organization: Academic Computer Centre Utrecht
- Lines: 31
-
- In <TB5ZqB2w165w@presoft.com> steve@presoft.com (Steve Kohlenberger) writes:
-
- >pynq@quads.uchicago.edu (George Jetson) writes:
-
- >> I.e., I think if you uuencode something then compress the result,
- >> you end up with a ZIP that is *bigger* than the original binary.
-
- >This is a ZIP limitation. UUENCODE expands the data in a relatively
- >simple and repeating way. ZIP is unable to compress it much further
- >because it assumes that the 'data' playing field is relatively flat.
- >The algorythms were not expecting hacked bytes from a previously
- >compressed format.
-
- Yes, nut notice that the uuencoded file is already bigger than the binary
- but that the compressed uuencoded file will be smaller than the uncompressed
- one. The Huffman encoding layer in most modern compressors (ARJ, LHA, ZIP,
- PKZIP) will make use of the fact not all possible characters are used.
-
- >Steve
- >
- > Steve Kohlenberger, PreSoft Architects Internet: steve@presoft.com
- > Novell Professional Developer (714) 538-6002
- > Specialists in NLM and Disk/Tape Driver development for NetWare 3.X/4.X
-
-
- Nico E. de Vries
- _ _
- O O USENET nevries@cc.ruu.nl
- o This text reflects MY personal opinions, nothing else.
- \_/ This text is supplied 'AS IS', no waranties of any kind apply.
- Don't waste your time on complaining about my hopeless typostyle.
-