HDTenEightyP/NetNews huggingface dataset:
From: jerry@ee.rochester.edu (Jerry Seward)
Newsgroups: comp.compression
Subject: Re: Zip Chunker
Date: 12 Oct 92 19:02:17 GMT
Organization: Univ of Rochester, College of Engineering and Applied Science

In article <1bcdpeINN436@agate.berkeley.edu> alsu@ocf.berkeley.edu (Alan Su) 
writes:
>Until recently, I had a program (shareware I think) that essentially took a
>pkzipped file and "chunked" it into disk-size fragments.  It was called
>ZipChunker if I'm not mistaken.  If anyone knows of where I can re-obtain a
>copy of this, I would appreciate it.  Thanks.

ZipChunker was re-released as the Archive Sizer program, which also handles
other file compression formats like LZH/ARJ/ARC, etc.  The filename is
ARCSZ100.ZIP and should be available for anonymous ftp at most MSDOS
repositories.
Newsgroups: comp.compression
From: chen@haydn.ee.uec.ac.jp (Chen Jie)
Subject: Where is Viterbi Algorithm
Organization: University of Electro-Communications, Chofu, Tokyo, JAPAN
Distribution: comp.compression
Date: Fri, 9 Oct 1992 02:06:12 GMT

Hello everybody,
Could someone tell me where I can find the source program of
Viterbi decoding algorithm?
Think you
--
____________________________________________________________________________              
               Jie Chen 
	       ITL ( Information Transmission Laboratory )
               Depart. of Electronics
               Univ.   of Electro-Communications 
               Chofu city, Tokyo 182, Japan
               E-mail: chen@mahler.ee.uec.ac.jp
-----------------------------------------------------------------------------  






Newsgroups: comp.compression
From: sigma@picasso.ipl.rpi.edu (Kevin Martin)
Subject: Re: The new Swedish Archiver
Keywords: SQZ Compression archive Squeeze
Distribution: na
Date: Wed, 14 Oct 1992 01:32:14 GMT

vporguen@unlinfo.unl.edu (victor porguen) writes:
>The Swedish SQZ is an interesting program, albeit it may never 
>become any kind of "standard" (bewcoming a "standard" would seem to 
>depend less on quality than on political influence, as has been 
>demonstrated... :-)  Look at ARJ: it's so significantly better than 
>PKZIP it's not even funny.  Yet, it's not "become a standard"...

The only real reason I can see that ZIP is more of a "standard" than ARJ,
apart from having been around longer and being more well-known, is because
ZIP has excellent versions available on many, many platforms.  That's
probably a large part of why LHARC was so successful - source code was
available and it caught on on many platforms (particularly the Amiga).

On the other hand, non-MSDOS versions of ARJ are coming "Real Soon Now",
and the UNARJ available is barely better than pitiful.  Of course, Jung
seems to be doing all the coding, so I'm not placing blame, but maybe if
attention was directed to expanding onto other platforms rather than adding
another -jz8&e3 option, ARJ would become more widely used.

-- 
Kevin Martin
sigma@ipl.rpi.edu
"We're gonna need another Timmy!"
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: data compression
Date: 15 Oct 92 10:41:34 GMT
Distribution: comp.compression
Organization: Academic Computer Centre Utrecht

I wrote:

>...
>ratio). Both ZIP and ARJ are derivates of AR002.

This is inacurate and I will correct that. The Japanese genious Okumara
(I really admire that man) invented LZHUF and AR002, from these two
LHarc and LHA were derived. Okumara has never been a speeed freak
(Yoshi takes care of that part) but he certainly has had some smart
idea's. The technology in AR002 (which is quite readable BTW) is also
used in ARJ, ZOO, PKZIP 1.93a and ZIP 1.9 and probably also in Squeeze
etc. All those programs (except ZOO) have improved LZSS engines and
faster code but the concept hasn't really changed. 

One could interpret my writing as if the SOURCES were derived from AR002
and this for ARJ only partially and for ZIP completely not the case.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
From: caeser@csd4.csd.uwm.edu (Robert Michael Trotter)
Newsgroups: comp.compression
Subject: Re: The new Swedish Archiver
Date: 16 Oct 1992 19:51:52 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Distribution: na
NNTP-Posting-Host: 129.89.7.4

In article <Bw8BFv.M8C@csugrad.cs.vt.edu> rlee@csugrad.cs.vt.edu (Rich Lee) writes:
>
>Arj is far better than zip.  I can't say about SQZ. 

	You should have said, ARJ 2.3 beats PKZIP 1.1. We will have to see
	about PKZIP 2.x. I have the feeling alot of people will be suprised.
	
	I tried the SQZ program, and it does compress very well, beating
	ARJ 2.39a and PKZIP 1.1, but it is not as fast. So if you like
	compression but dont care about speed, check out SQZ.

>and it will make a arj file with max compression (-jm  way slow though but I'm
>on a 486) it will prompt me for more disks....I can use high or low density
>mixed(-va  volume auto)  and recurse subdir (-r).  What more could you want :)
	
	ARJ for other platforms. I mean why would anyone use ARJ when
	you have info-zip? 1.9 rocks!

>oh well,  I'm hoping for ARJ for UNIX!!!!
>
	Heh. :)

	Caeser
Newsgroups: comp.compression
From: hhanemaa@cs.ruu.nl (Harm Hanemaaijer)
Subject: Re: SQUEEZE? (Where to get it?)
Date: Mon, 12 Oct 1992 13:06:17 GMT
Organization: Utrecht University, Dept. of Computer Science

In <3116@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

>In <1b42boINNcf9@uwm.edu> caeser@csd4.csd.uwm.edu (Robert Michael Trotter) writes:
>
>
>>	Where can I get that program from Sweden?, called SQUEEZE?
>>	Id like to take a look at it. Please, either email me a copy, or
>>	tell me where it can be found. Thanks
>
>It is available on garbo.uwasa.fi (just as about anything I believe :-)).
>
>It is faster than ARJ 2.30 and tighter than PKZIP 1.93a.

When I tried it, it struck me that the compression ratio is actually very
similar to Info-ZIP 1.9, but with very short file headers; some files compress
exactly the same, some a few bytes better, some worse (using defaults). The 
resulting archives are a just a little smaller, but that's only because of the
headers. Its speed is comparable to Info-ZIP 1.9.
 
I guess it uses an algorithm very similar to Info-ZIP 1.9. By the way, the 
documentation is of a fairly low standard, with a funny sort of English.

H. Hanemaayer
hhanemaa@cs.ruu.nl
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Info-Zip's zip1.9 -k option
Date: 10 Oct 92 11:58:25 GMT
Organization: Academic Computer Centre Utrecht

In <1b4t7hINNq36@usenet.INS.CWRU.Edu> jls11@po.CWRU.Edu (John L. Spetz) writes:

>	I was under the impression that zip is compatible with pkzip 
>(at least the available alpha/beta versions of 1.93).  The -k option
>states in the built-in help screen that it causes zip to "simulate" a
>pkzip made zipfile.  My question is how different from a zip created
>file is the output of zip1.9 sans -k?  

I believe ZIP is default 2.0 compatible, not 1.93a. There are some
extra options conserning stream oriented archives I believe. -k is
certainly not 1.10 compatible BTW. The extra options in PKZIP 2.0
are designed by the INFO-Zip team BTW, not the other way around.

>	As a side question how compatible is the unofficial pkzip3.05 or
>whatever?  Is this a hack of the 1.93 beta or what??

Just like 1.20 2.0 2.01 2.10 its just another hack. I believe 3.05 even
has a virus distroying your harddisk.   

A very good way to know if PKZIP 2.0 is real (whenever it arives)
is to verify if it has full functional multivolume support. If it
hasn't it is a fake. If a hacker/cracker goes for the trouble to
implement multivolume as well I think he would be better of renaming
it and selling it for himself :-).

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no waranties of any kind  |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
Xref: sparky comp.compression:3519 comp.compression.research:216
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression,comp.compression.research
Subject: Re: On the fly compression
Date: 13 Oct 92 19:49:51 GMT
Followup-To: comp.compression
Organization: Academic Computer Centre Utrecht

Ronan Melennec writes:

>Hello,

>This is not exactly a research topic, but...

>I have data to send/receive over a communication channel.
>The data is highly redundant, but more in the style LZW
>algorithms are made to deal with (i.e. there are a lot of redundant
>strings).
>I'd like to have this data compressed/decompressed on the fly
>(precisely, I'd like to compress/decompress the contents of a memory
>area).

>Did anyone do the same ? Which algorithms were used ? Is there
>any source code available ?

It depends a bit on machine and memory what you should do. If you have
enough speed and memory (speed is likely in datacommunication since
most channels are reletively slow) LZHUF should be usable or even
LZARI. Look in the FAQ for sources of AR002 and INFO-Zip. If you
want maximum speed for LZHUF buy the NoGate or the PKWARE data compression
library.  

If LZHUF is too large or too complex you might considder the LZRW
family or the Finish turbocompressor in the Dr Dobbs compression
contest. They are both memory oriented. See the FAQ for more info.

>Ronan Melennec 
Newsgroups: comp.compression,comp.dsp
From: bryan@nosc.mil (Dale Bryan)
Subject: video compression
Organization: Naval Ocean Systems Center, San Diego, CA
Date: Wed, 7 Oct 1992 14:43:50 GMT

Is MPEG the only video compression technique being pursued as a standard?  What about anything using subband coding or fractal compression?  What transmission
data rate is MPEG targeted for?  Who are the companies making chipsets for MPEG?

Dale Bryan
email: bryan@marlin.nosc.mil
From: caeser@csd4.csd.uwm.edu (Robert Michael Trotter)
Newsgroups: comp.compression
Subject: Re: SQUEEZE? (Where to get it?)
Date: 13 Oct 1992 15:04:30 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.7.4

In article <3132@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>In <zappe.718944042@tubue> zappe@mikro.ee.tu-berlin.de (Harald Zappe) writes:
>
>When the speed is usable (not more than 5 times slower than PKZIP?)
>I agree. The Ashford compressor for example is superior to PKZIP
>in ratio but extremely slow. Even on a 486/33 is is useless
>for large (>5k :-() files.
>
	Wow, You settle for 5 times slower? When compressing a network
	drive or such, 5 times slower could be very nasty. The one thing
	I like about PKZIP, that I dont think anyone else has done yet, is
	the speed. Sure the new ARJ is suppose to be faster, but even in
	PKZIP 1.1, the -es option is fast. Even the defeault speed is fast,
	comparitively speaking. I have read on the PKWARE BBS, that the
	new 2.x is going to be even faster than the 1.93a, and get better
	compression. I for one am glad they are taking time to make sure
	they do things right, and Ill be happy whenver PKZIP 2.x ships. :)

	Caeser

	
Xref: sparky comp.compression:3515 comp.compression.research:215
From: melennec@stna.dgac.fr (Ronan Melennec STNA 7C p8240 BD22)
Newsgroups: comp.compression,comp.compression.research
Subject: On the fly compression
Date: 13 Oct 92 17:18:29 GMT
Organization: STNA 95 rue Henri Rochefort 91025 Evry Cedex 33(1)60.79.80.00

Hello,

This is not exactly a research topic, but...

I have data to send/receive over a communication channel.
The data is highly redundant, but more in the style LZW
algorithms are made to deal with (i.e. there are a lot of redundant
strings).
I'd like to have this data compressed/decompressed on the fly
(precisely, I'd like to compress/decompress the contents of a memory
area).

Did anyone do the same ? Which algorithms were used ? Is there
any source code available ?

Regards,
-- 
Ronan Melennec              | Service Technique de la Navigation Aerienne
+33 1 60 79 82 40           | Departement 7
melennec@stna7.stna.dgac.fr | 95, rue Henri Rochefort, 91025 EVRY CEDEX, FRANCE
Newsgroups: comp.compression
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: The new Swedish Archiver
Keywords: SQZ Compression archive Squeeze
Organization: Gandalf Data Ltd.
Distribution: na
Date: Wed, 14 Oct 1992 13:07:14 GMT

In <1992Oct13.051733.19606@unlinfo.unl.edu> vporguen@unlinfo.unl.edu (victor porguen) writes:

>Writes Harald Zappe (zappe@mikro.ee.tu-berlin.de) on the subject of 
>the new SQZ archiver:

>> - where is the use of 'Yet Another Compressor',  WHEN
>> - it's not compatible to any other packer  (1)
>> - the compression ratio is not significantly better 
>>  than that of others

Add to the list the fact that the algorithm is also patented,
U.S. 4,814,746 Miller et al, Data Compression Method.

Maybe Dan Bernstein could respond  ??
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 
Newsgroups: comp.compression
From: sl313028@silver.ucs.indiana.edu (O.K. I'm Jon)
Subject: Re: Need a program that determines file compression methods.
Organization: Indiana University
Date: Thu, 8 Oct 1992 01:44:03 GMT

do a "type [filename]" command.  I know that PKzipped files have 
PK... as the first few characters...i don't know about the others.

(oh yeah, someone PLEASE try to give me an answer to my stacker question
keywords: abort, retry, fail? )

jon madison
sl313028@ucs.indiana.edu
From: alsu@ocf.berkeley.edu (Alan Su)
Newsgroups: comp.compression
Subject: Zip Chunker
Date: 12 Oct 1992 17:48:30 GMT
Organization: U.C. Berkeley Open Computing Facility
NNTP-Posting-Host: tornado.berkeley.edu

Until recently, I had a program (shareware I think) that essentially took a
pkzipped file and "chunked" it into disk-size fragments.  It was called
ZipChunker if I'm not mistaken.  If anyone knows of where I can re-obtain a
copy of this, I would appreciate it.  Thanks.

Newsgroups: comp.compression
From: magnus@bark-fddi.ii.uib.no (Magnus Alvestad)
Subject: ?
Reply-To: magnus@ii.uib.no
Organization: CE at UVBS / HOS / RNoN and CS-S at UiB, N.
Date: 17 Oct 92 03:02:52

I have a compressed file with this signature:

QP^L^@^@^@^@^B^@^@

any tips on how I can uncompress it?

-Magnus
Newsgroups: comp.compression
From: zappe@mikro.ee.tu-berlin.de (Harald Zappe)
Subject: Re: SQUEEZE? (Where to get it?)
Organization: ZRZ/TU-Berlin
Date: Tue, 13 Oct 1992 02:40:42 GMT

- I know this 'SQUEEZE', its ratio, and its docu, BUT
- where is the use of 'Yet Another Compressor',  WHEN
  - it's not compatible to any other packer  (1)
  - the compression ratio is not significantly better than that of others
    (OK, it's the first public release, so it may become better...)

(1) What I would like to see is a general pack/unpack utility, which is
    able to
    - automaticly detect to type of an existing archive (.tar.z, lha, lzh,
      arj, zoo, zip, (sqz???) to extract the contents. The source code of
      unarj 2.3, zoo 2.1, Info-ZIP 1.9/5.0, LHARC V? could be used to build
      such an 'intelligent' unpacker.
    - automaticly choose the best compression methode of all available
      (of course with the cost of time). I know that the old SEA-ARC was
      doing something like this: try all methodes and take the best.
      I think with the permanent increase of machine speed (HW) the
      compression is more worth than the speed (algorithm).

Specific standards like JPEG, MPEG will not solve the problem of the large
variety of 'general purpose packers'. So the utilities should try to support
several formats (compare SOX in the sound region, Alchemy for Images).
(But now I have left the topic 'squeeze')

Harald


#----------------------------------------------------------------------------

zappe@mikro.ee.tu-berlin.de      | |
zappe@sony1.sietec.de            |-+-
zappe@idefix.sietec.de           | |/
                                   /
                                  /__
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: SQUEEZE? (Where to get it?)
Date: 13 Oct 92 10:30:54 GMT
Organization: Academic Computer Centre Utrecht

In <zappe.718944042@tubue> zappe@mikro.ee.tu-berlin.de (Harald Zappe) writes:

>- I know this 'SQUEEZE', its ratio, and its docu, BUT
>- where is the use of 'Yet Another Compressor',  WHEN
>  - it's not compatible to any other packer  (1)
>  - the compression ratio is not significantly better than that of others
>    (OK, it's the first public release, so it may become better...)

Agreed. Only PAK has been compatible to PKZIP BTW (quite impressive
program, noone uses it unfortulately for NoGate). Compatibility
is hard to achieve.

>(1) What I would like to see is a general pack/unpack utility, which is
>    able to
>    - automaticly detect to type of an existing archive (.tar.z, lha, lzh,
>      arj, zoo, zip, (sqz???) to extract the contents. The source code of
>      unarj 2.3, zoo 2.1, Info-ZIP 1.9/5.0, LHARC V? could be used to build
>      such an 'intelligent' unpacker.

There are archiver tools like arcmaster which more or less achieve this.
They use the real programs but who cares as long as the user doesn't
havr to fiddle with all those commands and options.

>    - automaticly choose the best compression methode of all available
>      (of course with the cost of time). I know that the old SEA-ARC was
>      doing something like this: try all methodes and take the best.

This was to determine if a LZW or a Huffman style compressor should
be used. For modern LZHUF engines the compare of multiple methods
is often a waste of time.

>      I think with the permanent increase of machine speed (HW) the
>      compression is more worth than the speed (algorithm).

When the speed is usable (not more than 5 times slower than PKZIP?)
I agree. The Ashford compressor for example is superior to PKZIP
in ratio but extremely slow. Even on a 486/33 is is useless
for large (>5k :-() files.

>Specific standards like JPEG, MPEG will not solve the problem of the large
>variety of 'general purpose packers'. 

Especially not since better solutions than JPEG are available.

>So the utilities should try to support
>several formats (compare SOX in the sound region, Alchemy for Images).
>(But now I have left the topic 'squeeze')

Meybe in the future a single winner will evolve or programs will become
compatible with each other. NoGate did somethinl like that in the past.

>Harald

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Why does PKZIP 2.X have hardware conflicts????
Date: 8 Oct 92 16:17:55 GMT
Organization: Academic Computer Centre Utrecht

In <1992Oct7.040456.185822@ns1.cc.lehigh.edu> ry01@ns1.cc.lehigh.edu (ROBERT YUNG) writes:

>PKZIP 2.X is being delayed because of hardware problems. Why is this. Does 2.X
>use some really "bypass DOS and go right to the hardware" kind of magic to get
>good compression? I thought they just have to stick in a new algorithm or
>something.

PKWARE *claims* thet their delay is because of a bug on several 486
boards. The conflict is between the DMA and the external processor
cache. They have sources in C which seem to prove problems exist on
some boards.

The problem has nothing to do with special lowlevel tricks. PKZIP is
reasonable clean programmed. In the past they has some problems with
386 support, probably due to the POPAD instruction, but thats about it.
All other problems their software has have been bugs. 

Notice this is a CLAIM of PKWARE. Many people believe PKWARE has
trouble with some serious bugs or PKWARE is going to brake its
Info-ZIP, PKZIP for UNIX, PKZIP 1.93a compatibility promis and
is working on something completely new. There are also rumours
PKZIP 2.0 will have a new (graphical?) user interface.

>   I like ARJ but it's too slow. Is ARJ 3.X *much* faster at decompressing?

ARJ 2.39 is quite fast already. Perhaps it will always be a bit slower
than PKZIP but decompression is I/O bound and will therefore not
differ much, especially not in future versions and on newer, faster
computers. Also notice ARJ unlike PKZIP 1.01 and PKZIP 1.10 does
not seem to have reliability problems. PKZIP is known to compress
some files without being able to decompress them. (bugs in PKZIP,
not in PKUNZIP for 1.10 BTW). Furthermore ARJ is free for private
use and Robert Jung is working much harder and faster to improve
his product.

>       \___(Robert) Bobby Yung_______RY01@Lehigh.Edu___/{

Nico E. de Vries
 _ _
 O O  USENET nevries@cc.ruu.nl This text reflects MY opinions, nothing else.
  o   This text is supplied 'AS IS', no waranties of any kind apply.
 \_/  Don't waste your time on complaining about my hopeless typostyle.
Newsgroups: comp.compression
From: lance@actrix.gen.nz (Lance Andrewes)
Subject: Re: Compression for VMS
Organization: Actrix Networks
Date: Fri, 16 Oct 1992 21:28:59 GMT

$ennsnr@brandonU.ca wrote:
>Could someone please tell me an ftp address where I can find a compression
>program for the vax?

Zoo and Info Zip/Unzip are the only ones I am familiar with.
These come with C source.

unzip50.zoo   Info Unzip v5.0
zip19.zoo     Info Zip v1.9

zoo21e.exe ?? Zoo v2.1

The zip/unzip sources should be on ftp-os2.nmsu.edu.  I recently
had these compiled with VMS C.  The source files first had to
be edited slightly to give the proper line-termination characters.
The guy that installed it used lse for this.

The file "zoo21e.exe" is a self-extracting zoo (which must be
unzoo'd on a MS-DOS system).  The sources can be
compiled under VMS etc etc (although we haven't yet installed
it).  Don't know where it came from, but you can of course
search for it, (or for "zoo21") on an Archie server.

(I tried emailing this, but brandonU.ca bounced it twice)
-- 

 _______  Email: Lance.Andrewes@actrix.gen.nz / andrewes@met.govt.nz
////      Mail : PO Box 10575,Wellington,New Zealand 6036   *ZL2AJH*