From ednutter@aol.com Mon Jul 4 10:34:53 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1882" "" " 4" "July" "1994" "00:53:07" "-0400" "EdNutter" "ednutter@aol.com" nil "41" "Re: HELP...need compression libs..." "^From:" nil nil "7" nil nil nil nil] nil) Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!spool.mu.edu!sol.ctr.columbia.edu!newsxfer.itd.umich.edu!gatech!swrinde!pipex!sunic!EU.net!uunet!newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail Newsgroups: comp.compression Organization: America Online, Inc. (1-800-827-6364) Lines: 41 Message-ID: <2v84jj$38i@search01.news.aol.com> References: NNTP-Posting-Host: search01.news.aol.com From: ednutter@aol.com (EdNutter) Sender: news@search01.news.aol.com Subject: Re: HELP...need compression libs... Date: 4 Jul 1994 00:53:07 -0400 In article , thor@netcom.com (Brad Viviano (Thor)) writes: Brad, I'd better mention up front that I work for Stac electronics. I do online & phone support for Stacker for DOS and Mac. You didn't specify, but I assume you're talking about a PKZIP or other Lempel-Ziv type of compressed archive. I don't think you'll be able to do what you ask. Lempel-Ziv essentially looks across a section of the file looking for repeating data. It makes one copy of the data in a library, and replaces all other occurances of the data with a pointer to the original. There are many varients of the technique, some tuned for speed, some for sheer compression. PKZIP & LHARC are tuned for compression. The problem is that you can't index into the compressed file in any reliable way without reading the library, and in effect decompressing the data on the fly. You would be doing a sequential scan of the whole file rather than a random seek to a known offset. You may want to consider disk compression. Programs such as Stacker compress on a cluster or allocation block (Mac speak for the same thing) basis. A program accessing a file tells the OS it wants to look at x bytes of data starting at offset y into the file. The OS calculates that offset y will be in cluster z, and tells the disk driver to get the corresponding sectors. If the disk driver is Stacker, it finds the sectors containing the compressed data, decompresses them, and shortly the OS hands the x bytes to the application. The tradeoffs are... Stacker uses RAM, although on modern machines most of it lives in extended memory. The logic for a program to UNZIP on the fly would use RAM also. Stacker only gets about 1/2 to 2/3 of the compression that PKZIP or LHARC get. On the other hand, Stacker is much faster than the archive programs. Hope this was informative. Ed, aka StacMacTec@aol.com From nevries@aip.nl Thu Jul 7 18:24:30 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!EU.net!sun4nl!aipnl!nevries From: nevries@aip.nl (Nico de Vries [AIP-NL]) Newsgroups: comp.compression Subject: Re: compression algorythems Distribution: world Message-ID: <773609026snx@aip.nl> References: <2vg26c$9mm@industrial.com> Date: Thu, 07 Jul 94 19:23:46 GMT Organization: AIP-NL (Ad Infinitum Programs) Lines: 15 wanco@industrial.com writes in article <2vg26c$9mm@industrial.com>: > > Does anyone know where I can get the algorythems for some of the > 'standard' compression programs like .zip, .sit, .arj, .arc, .tar, .zoo, > .pit, and .cpt.? AR002 (FTP garbo.uwasa.fi:/pc/programming/lds_11.zip) is quite close to ZIP, ZOO and ARJ. It is also relatively easy to read. > Please write to me at: > wanco@industrial.com Take care, Nico de Vries [AIP-NL, UltraCompressor II development] From jwang@atitech.ca Fri Jul 8 12:28:04 1994 Newsgroups: comp.compression Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!cs.utexas.edu!utnut!torn!uunet.ca!uunet.ca!hq!jwang From: jwang@atitech.ca (Jason Zhicheng Wang) Subject: Re: ADPCM Message-ID: Sender: news@news.atitech.ca Nntp-Posting-Host: sun3 Organization: ATI Technologies Inc. Date: Thu, 7 Jul 1994 22:14:48 GMT Lines: 22 To: davidm@marcam.com Subject: Re: ADPCM Newsgroups: comp.compression In-Reply-To: <2ufi2n$3mt@yeshua.marcam.com> References: <2ufdf1$tun@elvis.syl.sj.nec.com> Organization: ATI Technologies Inc. Cc: Bcc: ADPCM stands for Adaptive Differential Pulse Code Modulation. It is a compression technique which encodes the predictive residual instead of the original waveform signal so that the compression efficiency is improved by a predictive gain, in short. (Jason) Z. Wang Senior Software Engineer (Compression Specialist) ATI Technologies, Inc. 33 Commerce Valley Drive East Thornhill, Ontario, Canada L3T 7N6 From nevries@aip.nl Tue Jul 19 13:45:48 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!EU.net!sun4nl!aipnl!nevries From: nevries@aip.nl (Nico de Vries [AIP-NL]) Newsgroups: comp.compression Subject: Re: Seeking C source of in-memory compression program Distribution: world Message-ID: <774534040snx@aip.nl> References: <1994Jul18.082247.428@ifi.unizh.ch> Date: Mon, 18 Jul 94 12:20:40 GMT Organization: AIP-NL (Ad Infinitum Programs) Lines: 21 maffeis@ifi.unizh.ch writes in article <1994Jul18.082247.428@ifi.unizh.ch>: > > Hello! > > I'm seeking a simple compression utility written in either C or C++. > It should permit compression of a RAM area containing some ASCII text > and store the result in another area. I.e., I need a procedure like > > int compress(char *original, int originalSize, char *compressed); LZRW1 and Finish (FTP garbo.uwasa.fi:/pc/programming/lds_11.zip.) both work OK in memory. Both sources in LDS already allow memory to memory (de)compression. > Any hint is appreciated! > > silvano Take care, Nico de Vries [AIP-NL, UltraCompressor II development]