HDTenEightyP/NetNews huggingface dataset:
From: @FtCollins.NCR.COM
Newsgroups: comp.compression
Subject: JPEG question
Date: 8 Jan 93 23:55:56 GMT
Reply-To: @FtCollins.NCR.COM
Distribution: usa
Organization: NCR MED, FT. Collins, CO. 80525  (303) 223-5100

I've been reading the new JPEG book by Pennebaker and Mitchell,
and I'm wondering about implementing the coefficient quantization
function (where you reduce the number of bits in the coefficients
before Huffman or arithmetic coding). They give an example table,
and I notice that most of the numbers in there are not powers of 2.
Since powers of 2 are so easy to divide by, I would think that
using them would be desirable here - especially since the JPEG
standard does not specify what quantization table you must use.
Does anyone know if quantization tables used in common JPEG
software (or hardware) are chosen to take advantage of the power
of 2 divide?

Jim Prater
NCR Microelectronics
jim.prater@FtCollins.ncr.com

Newsgroups: comp.compression
From: mrmarcel@eos.ncsu.edu (Mike Marcelais)
Subject: Re: PKZIP 2.04c vs. ARJ 2.39b (and LHA/ZOO) Compression Results ** UPDATED
Keywords: archive compress ARJ PKZIP LHA ZOO
Organization: North Carolina State University
Date: Sat, 9 Jan 1993 20:04:22 GMT

In article <726586156rommel.root@jonas.gold.sub.org>, rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:
|> >My previous comments heralded PKZIP as #1, but with their bug reports
|> >and ARJ's improved speed I have decided to wait the extra 7 seconds
|> >for a more little reliability.  I'm going to continue to use ARJ.
|> 
|> Unfortunately, ARJ is a one-platform-only program. There are
|> (especially among USENET readers) a lot of people who don't use MS-DOS
|> for one reason or another. Robert K. Jung has promised development of
|> a portable C version for *years* but nothing has shown up so far,
|> please correct me if I'm wrong. And I have asked him for this even
|> *before* I joined Info-ZIP.
|> Kai Uwe Rommel
|> Info-ZIP

Well, the ARJer is only for MSdos, but there is a C version of unarj for
multiple platforms abailable at places like:
bode.ee.ualberta.ca:/pub/newstuff/unarj230.tar.Z
cscihp.ecst.csuchico.edu:/pub/geos/unarj230.tar.Z
faramir.informatik.uni-oldenburg.de:/pub/dkbtrace/utils/unarj230.tar.Z
goya.dit.upm.es:/info/unix/archive/unarj230.tar.Z
sugrfx.acs.syr.edu:/pub/incoming/mine/arj/unarj230.tar.Z

(archie is great!)

-- 

+-------------------------------------+------------------------------+
|  Mike Marcelais                     | mrmarcel@eos.ncsu.edu        |
|  356 Tucker, Box 04783, NCSU        | Fourth Bryan Productions     |
|  Raleigh, NC  27607                 | #include <disclaim.h>        |
+-------------------------------------+------------------------------+
| if the above address bounces, then try the address below:          |
| mrmarcel%eos.ncsu.edu@ncsuvx.ncsu.edu                              |
+--------------------------------------------------------------------+
Newsgroups: comp.compression
From: pieterh@sci.kun.nl (Peter Herweijer)
Subject: Re: Source for Lempel-Ziv
Keywords: lempel
Organization: University of Nijmegen, The Netherlands
Distribution: comp
Date: Thu, 7 Jan 1993 14:01:37 GMT

In <hess.726398005@swt7> hess@swt7.informatik.uni-hamburg.de (Hauke Hess) writes:

>Hi,
>
>I would like to save some space by storing long data structures
>temporary in a compressed form. Though I don`t want to loose much
>time in compressing and decompressing them, I look for a
>lempel-ziv coder/decoder source, that will make it as simple as
>possible to store and retrive huge arrays.

	[...]

>Hauke

I don't remember exactly, but you may want to look through either
the 1989 or 1990 issues of Dr Dobb's.  There's a good article on
LZW compression somewhere. It's featured on the cover, if that helps.

The algorithm and its implementation are fairly simple, once you've
understood the principles.

Peter Herweijer
pieterh@sci.kun.nl
Newsgroups: comp.compression
From: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: PKZip 2.04c quick impressions
Organization: Qualcomm, Inc., San Diego, CA
Date: Wed, 6 Jan 1993 00:53:09 GMT

rdippold@cancun.qualcomm.com (Ron Dippold) writes:
>Also, info-zip folks:  several files which I downloaded from
>archive.toronto.edu which had been packed with Info-Zip failed with
>CRC errors when I unpacked them with PKUnzip 2.04c.  Unzip handled the
>same files with no problem.  I don't have any files I know were packed

I take it all back!  It does happen, yes, but only when I run it from
a batch file.  It does happen with Info-Zip made files, but also with
PKZIP made files.  Interesting, eh?

  pkunzip -o -d 669bliss.zip

works fine, but if I put that exact same line in a batch file called
a.bat and run "a" I get all sorts of strange errors, and even
sometimes it asks me to "Insert disk #1"!  I can get that last one
pretty reliably as well by forcing a disk and path, as in:

  pkunzip -o -d c:\zip\669bliss.zip

Even without running it in a batch file.

Looks like no more mucking around with the validation checks!  Whew...
-- 
Cat, n: A soft, indestructible automaton provided by nature to be kicked when
things go wrong in the domestic circle. -- Ambrose Bierce
Newsgroups: comp.compression
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: Re: pkzip 2.04c / unzip v5.0 compatibility
Keywords: passwords problem.
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 8 Jan 93 22:47:24 GMT

In article <1993Jan8.130724.21237@julian.uwo.ca> brianb@julian.uwo.ca (Brian Borowski) writes:
>If I zip up a file with pkzip 204c with password encryption,
>I find that unzip 5.0 cannot unzip such a file.  It asks for
>the password, but will not undo the file.
>
>Has anyone else observed this behaviour?  If I am not doing something
>right, let me know please.

The encryption algorithm seems to be implemented differently in the
new pkzip, but the change shouldn't be hard to add to Info-Zip --
instead of having two bytes of the crc32 at the end of the encryption
header, the final byte of this header is a zero.  (The others are
pseudorandom.)

-- Paul Kocher
kocherp@leland.stanford.edu
From: kko@fraser.sfu.ca (Samuel Ko)
Newsgroups: comp.compression
Subject: Re: Source for Lempel-Ziv
Keywords: lempel
Date: 8 Jan 93 01:49:26 GMT
Distribution: comp
Organization: Simon Fraser University, Burnaby, B.C., Canada

allan@cs.UAlberta.CA (Allan Sullivan) writes:

>There is a book called "The Data Compression Book" by Newton which
                                                       ^^^^^^  
>covers LZ77 and LZ78 compression. Some versions of the book come
>with a cover disk which has source code for compression.

Ooooo ... that should be Nelson (Mark Nelson) ... IMNSHO, that is the
best book on data compression ... But you need a basic understanding of the
C programming language to read it ... After reading it, you should be able
to write you own compression program (I'm trying to write one :) ...

-- 
><-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-><
| Samuel C. Ko (aka The Smart One / BOZO) <--> a celebrity & DOS/UNIX wizard :)
:) kko@sfu.ca <--> Outspoken,Highly-talented,Charming... I post this for You! |
[-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-]
Xref: sparky comp.compression:4303 comp.dcom.fax:2363 comp.graphics:13341
From: rastek@world.std.com (keith losset)
Subject: Huffman Help
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 5 Jan 1993 22:38:47 GMT

	Help!  We are attempting to implement a Dynamic Huffman compression
on byte-length source words by using the treatment in Storer's _Data Comp-
ression:  Methods and Theory_ (pg. 42/43).  We have a misunderstanding about
the trie algorithm that involves the following three parts:

	1.  Initialize the trie to contain one "unseen leaf".
	2.  When an unknown source word x is received, send its character
	    code and the code of the unseen leaf and then create two children
	    for the unseen leaf -- a leaf for the character just received and
	    a new unseen leaf.
	3.  All the while, increment the weight of each node as it is visited
	    and exchange it with its right sibling when and if its weight 
	    exceeds that of its right sibling.

A code is generated for a redundant character by traversing the tree.
	We read this generalization to mean that if you receive 255 different
characters, that the 255th you would generate a 255 bit code because it would
be 255 levels down the tree thanks to step 2.  Obviously, something is missing
here and we would be very appreciative if someone could clarify it for us.

		- poconnor@rastek.com

-- 
Keith Losset, Rastek Corporation, 205-882-0882    jkl@hunan.rastek.com
Newsgroups: comp.compression
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: Re: PKZip 2.04c quick impressions (Screen problems)
Organization: DSG, Stanford University, CA 94305, USA
Date: Thu, 7 Jan 93 23:44:05 GMT

In article <1993Jan7.092414.17223@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>Here is one more feature to ponder.  I use a screen scrollback
>buffer (buffit30) which captures bios screen writes to a buffer. 
>Very handy for some purposes.  The new pkzip confuses it.  The only
>things that get sent are the eolns, so that if you look at the
>scroll-back buffer you are faced with blank pages.  Perhaps 2.04
>uses some kind of a weird mix of bios and direct screen writes.  A
>frustrating feature.  I wish there were some method of turning off
>the direct writes.

While looking at the encryption yesterday, I noticed that the program
seemed to be using interrupt 29, of all things, to do its screen writes.
According to _DOS_Programmer's_Reference_ (published by QUE), this is
"fast putchar," but is a reserved function used internally by DOS only.
The entry concludes, "This interrupt is intended for use with DOS
device drivers, and is not documented as being supported beyond DOS
V2.0.  It is _not_ to be used in applications programs."

From the code it looked like there might be a way to disable this,
though I have no idea what it might be.  (Might try ">con"...)

-- Paul Kocher
kocherp@leland.stanford.edu
From: ichoi@husc10.harvard.edu (Isaac Choi)
Newsgroups: comp.compression
Subject: PKWare's on-the-fly Compression Product...
Date: 12 Jan 93 20:29:52 GMT
Article-I.D.: husc10.ICHOI.93Jan12122952
Distribution: comp
Organization: Harvard Arts and Sciences Computer Services, Cambridge, MA


PCWeek (January 4) says that PKWare is working on an on-the-fly compressor
and that it hopes it'll be out next year (read "the next century"). My
question is, with a market filled with products like Stacker, what can
PKWare offer that they don't have?

Isaac Choi
ichoi@husc.harvard.edu
Newsgroups: comp.compression
From: smlg1015@uxa.cso.uiuc.edu (Stuart M Lichtenthal)
Subject: Is there a PKLITE for Windows .EXE files?
Organization: University of Illinois at Urbana
Date: Sat, 9 Jan 1993 00:54:31 GMT

Dear compressionists:

I just read the doc file for pklite115 and found that Windows
executable files should not be compressed with pklite.  Is there
some other program that compresses Windows executables in a way
similar to PKLITE?  By this I mean that the compressed executable
should be able to run as is.

Thanks,

Stuart Lichtenthal smlg1015@uxa.cso.uiuc.edu
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.compression
Subject: Re: pkzip 2.04c / unzip v5.0 compatibility
Date: 9 Jan 93 00:46:51 GMT
Organization: CWI, Amsterdam

In article <1ikfkpINN4me@gap.caltech.edu> madler@cco.caltech.edu (Mark Adler) writes:
 > What is identical is the *format* of the compressed data, which
 > essentially defines what a zip decompressor has to do.  It does not
 > put any restrictions on how that compressed data stream is generated.
 > In particular, it does not say how matching strings are found.

I want to stress this.  One other thing though, you have to agree on a
maximum buffer size when doing compression/decompression.  Otherwise
a compressor using a larger buffer would outwit a decompressor using a
smaller buffer.  But a well written decompressor will find that, and
might even adapt itself.
 > 
...
 > This basic principle is what allows competing companies to agree on
 > standard compressed data streams, like JPEG, JBIG, MPEG, etc.  The
 > standard allows common decoders for the format, but the companies
 > compete with more efficient and more effective *encoders*, as wellas
 > cheaper or better implementations of the decoders.
 > 
Right.  Make public the format your compression algorithm creates.  This
will allow users on other platforms than where your compressor runs on
to decompress the files (which might increase your sales).  A bad example
can be found in the MacIntosh community where there is no official public
knowledge about how the compressors encode the data.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.compression
From: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: First impression, PKZIP 2.04c
Organization: Qualcomm, Inc., San Diego, CA
Date: Fri, 8 Jan 1993 18:47:29 GMT

eduard@htsa.aha.nl (Eduard Beijnes) writes:
>A reason for me to use arj is the good multi-volume support
>(i heard pkzip sucks)

It does.  It ONLY works with actual physical floppies (okay, any
removable media), and the naming convention means you can't keep the
different parts of the archive in a subdirectory on your hard disk
without doing some renaming.
-- 
Your motivation?  Your motivation is your pay packet on Friday.  Now get
on with it.   -- Noel Coward to actor
Newsgroups: comp.compression
From: robjung@world.std.com (Robert K Jung)
Subject: Re: ARJ 2.30 minor bug
Organization: The World Public Access UNIX, Brookline, MA
Distribution: comp
Date: Fri, 8 Jan 1993 21:39:22 GMT

rdippold@cancun.qualcomm.com (Ron Dippold) writes:

>robjung@world.std.com (Robert K Jung) writes:
>>After due consideration of this problem, it seems acceptable not to call
>>situations such as "ARJ a test dummy.bat dummy.bat" an error.  Since LHA
>>does not consider this wrong and since ARJ is styled after LHA, ARJ at the
>>next release will NO LONGER consider this an error.

>After pontificating like that on the exclusion list, I've gotta
>know... was I right? :)

Actually, the add_list routine would return a zero match when the filename
argument was excluded or already added to the internal list of filenames.
The routine now returns a positive match for both of these situations so
that "ARJ a test -xd*.* dummy.bat sort.bat" will not return an error.

>P.S. the new PKZip is making the solidity of ARJ look more and more
>impressive. 

I hope that the next release of ARJ will be as solid as ARJ 2.30 is. :)

Regards,
Robert K Jung
From: eric@cse.fau.edu (Eric L. Thav)
Newsgroups: comp.compression
Subject: Re: Virus Infection -- pkz204c.zip
Date: 9 Jan 93 21:18:14 GMT
Organization: Florida Atlantic University, Boca Raton, FL, USA

The reports of PKZIP 2.04c containing a virus are due to a problem present
in the virus signatures of a few virus scanners, most notably the Norton
AntiVirus.  Norton has issued a new set of virus detect signatures which
will no longer falsely report that "Maltese Amoeba" virus in PKZIP 2.04c.

                                                     /* Eric */
-- 
signature not found, format hard disk instead? (Y/N)_
Eric L. Thav               Florida Atlantic University - Boca Raton, FL
INTERNET: eric@cse.fau.edu     CIS: 71053,3462 | Florida Marlins - 1993
FIDONET: 1:369/68.1           PRODIGY: HKHF18A |  World Series Champs!
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.compression
Subject: Re: PKZip 2.04c quick impressions
Date: 10 Jan 93 22:49:37 GMT
Organization: negligable

In article <3559@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
:In <814@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
:
:[About PKZIP 2.04c multivolume support]
:
:>It seems it could mark the sector (which should have been done during
:>formatting of the disk anyway) and try and find the next good sector,
:>OR get rid of the (potentially flawed) disk and redo those 19 sectors
:>on the next disk.
:
:Actually PKZIP does the opposite. If a sector is marked BAD in the
:FAT its quick format removes the mark making it good again. A very
:bad thing for file integrity.

AAAAAAAAAAAACCCCCCCCCKCKKKKKKKKK!!!!!!!!!!

Tell me you are joking!!!  Please!?!????!?!?!???????

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lazy day, Sunday afternoon.			|
Like to get your feet up, watch TV.		|	-Richard Hartman	
Sunday roast is something good to eat,		|	hartman@uLogic.COM
must be lamb to day 'cause beef was last week!	|

Newsgroups: comp.compression
From: h8915726@hkuxb.hku.hk (Medusa de NetHack)
Subject: Re: Did PKWare fix that famous 486 bug?
Reply-To: h8915726@hkuxa.hku.hk
Organization: University of Hong Kong
X-Newsreader: Tin 1.1 PL4
Date: Sat, 9 Jan 1993 17:29:36 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
: OK, now that the new PKZIP is out and that we all know that it is full
: if small, annoying bugs, could anybody check whether they have fixed
: at least that famous bug that allegedly caused them to delay the
: release for more than a year?
: 
: They have released a program that checks for the presence of the bug,
: so you can check whether it exists on your machine (only 80486-based
: machines with external memory cacheing enabled). It doesn't exist on
: mine, so I am unable to check, but what the heck is the option '-('
: for in PKZIP? (Except the express the impression of the users of the
: new version, if you put a colon in front of it?)
: 

	I run PKUNZIP (v2.04c...) on  my 486DX-50, first time
	ok, second time, it REBOOTS my computer. I don't know
	if it's related to DMPI support since I run QDPMI, but
	I use PKUNZIP -3 apparently prevent it reboots...

--
Medusa
University of Hong Kong
H8915726@hkuxa.hku.hk
Newsgroups: comp.compression
Subject: PKWare Phone #??
From: skriefal@eeyore.stcloud.msus.edu (Scott Kriefall)
Date: 4 Jan 93 23:19:45 -0600
Organization: St. Cloud State Univ., MN

Could someone please inform me of PKWare's new phone number?  There old
number (1-414-352-7176) appears to have been disconnected.
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: PKZip 2.04c Patent
Date: 5 Jan 93 16:26:42 GMT
Organization: Academic Computer Centre Utrecht

In <rdippold.726236599@cancun> rdippold@cancun.qualcomm.com (Ron Dippold) writes:

>BTW, the new PKZip says 

>  PKZIP Reg. U.S. Pat. and Tm. Off.   Patent No. 5,051,745

>Did the old one have anything similar?
>-- 

PKZIP 1.10 has "patent pending".
PKZIP 1.93 a has the same patent number PKZIP 2.04c has.

>Wood is highly ecological, since trees are a renewable resource.

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

To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at 
garbo.uwasa.fi /pc/programming. Make files for Borland C are included. 
Newsgroups: comp.compression
From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: comp.compression
Subject: Re: SuperCompression?
Date: 6 Jan 93 00:36:01 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <1993Jan01.160904.15472@rose.com> ariel.frailich@rose.com (ariel frailich) writes:
>Compression ratios of 33:1?  70:1???
>
>If it's not a misprint or misinterpretation, how is this possible?  Does 
>anyone have any information on this?

I imagine it's highly dependent on exactly what is being compressed.  If
you insert 500 zeros between each character, you can get 250:1 compression
with RLE.

I have a feeling that, if "Supercompression" got 33:1 ratios on your average
ordinary text file, it would be a product in and of itself.

>Ariel Frailich
>ariel.frailich@rose.com

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
Newsgroups: comp.compression
From: TCSAR03@waccvm.corp.mot.com (Germain Leutwyler)
Subject: DID YOU KNOW DIET144.ZIP ?
Organization: Motorola
Date: 8 Jan 1993 02:54:33 MST

Hi,

Just to share some info...

I found few weeks ago the above utility in the well-known but anonymous
ftpsite nic.funet.fi under \pub\msdos\utilities\filutl.

I use it for all files on my HD but it is not an archiver !

All files could be made self-extractable (.EXE, .COM, .SYS) including
programs with overlays (!!!) and DATA files too.

This utility could be run in TSR mode, the memory space used is
minimal and speed is adequate (transparent for the user).

It is a good alternative versus complete subdirectories archivers for
people being short in space with their HD. Try it and let me know your
feelings afterwards !

Best regards and happy new year,
Germain
From: schepers@watserv1.uwaterloo.ca (Peter Schepers)
Newsgroups: comp.compression
Subject: PKZIP 2.04c
Date: 6 Jan 93 20:02:30 GMT
Organization: University of Waterloo

Newsgroups: comp.compression
Subject: PKZIP 2.04c
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: University of Waterloo
Keywords:

This is actually a response to a posting by Mr. Nico De Vries...


I have been toying with PKZIP running under OS/2 2.0 GA/SP, and have
experienced some interesting problems as well. Up until a few minutes ago,
I could not get it to work reliably. So I went ahead and screwed around
with the DOS settings, to see what could possibly happen.

One of the interesting things is PKZIP detects XMS, EMS, DPMI, micro type
all automatically. So these are the settings I decided to change. 

First off, don't try to run PKZIP under OS/2 with no XMS set. I found this
was a sure way to generate a program fault (i.e This Program Encountered
an Error message). At this point the session is dead. When set for
64k, the whole system trapped with a TRAP 6.  It  still seemed to cause
problems. So I left it at 1 Mb. So far so good.

As soon as I had done this, I switched the Dos FS session to the
background, and promptly PKZIP generated an error again. Close down the
session again.

OK. Set XMS to 1Mb. Set EMS to 1Mb. Leave DPMI alone. Try it again in the
background. Crash again.

OK. Set XMS to 1Mb. Set EMS to 1 Mb. Turn DPMI off. Now it works? Go
figure.

Toying with the EMS settings by the way seems to make no difference. 

So the settings seem to be.... DPMI off, EMS doesn't matter, XMS to 1 Mb.
This seems to work. 

Can someone else verify my findings?


P.S. Right now in the background, I am compressing the whole WATCOM C
directory (all 6 Megs of it.) So far so good... I just checked and it
worked nicely.




From the workbench/universe of:         :       "Help! Help! I'm being
schepers@watserv1.uwaterloo.ca          :   repressed!"   - Monty Python
------------------------------------------------------------------------------ 
Peter Schepers     University of Waterloo     Waterloo     Ontario     Canada.
Newsgroups: comp.compression