HDTenEightyP/NetNews huggingface dataset:
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 10 Apr 92 04:57:31 GMT
Organization: University of Vaasa, Finland

In article <1992Apr9.074614.5995@ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
>I don't understand. Does Pkware own a patent that the decompressor is
>infringing upon? Or did you find Pkware code in DISLITE? Or perhaps
>the author is under some sort of non-competition contract with Pkware?

Please also see my other reply on this.  I am exercising my
moderators rights and duties to choose what I will accept (well
within reason) to garbo.uwasa.fi archives.  Thus although your
questions might interesting for anyone who wants to consider law and
contract issues, I see no reason nor need for me to try to delve
into these detailed aspects.  They are not material in my moderating
decision for not accepting cracks to our archives. 

I prefer to try to explain this in a reasonable manner.  I could
have cut this short and taken another tack by pointing out that no
one outside our university has any say in this, and that outside
users only have privileges and no rights at FTP sites.  Although I
am not really accountable to the net, I still prefer to discuss also
these cases in a rational manner and try to give my views in a
hopefully constructive tone.  But please do not strecth it too much. 

...................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
Newsgroups: comp.compression,sci.electronics,rec.audio,sci.engr,rec.video,rec.radio.noncomm
From: apolivka@x102a.harris-atd.com (polivka al 60047)
Subject: Digital Audio Bandwidth Compressors (coders)
Organization: Harris Gov't Aerospace Systems Division
Date: Sat, 11 Apr 1992 15:27:46 GMT

I would like any information about or where to find a digital audio
bandwidth compressor that provides "reasonable quality" audio at about
20 to 30 kb/s (or less).

By reasonable quality audio, I mean something that is at least AM
radio quality, or maybe a little better.  I want to use this
compressor for both music and voice.

I do not require stereo, although I might consider using it.

I require very little dynamic range.  The ideal compressor would
perform a lot of dynamic range compression as well as other
methods (removal of redundancy, etc.) to achieve bit rate compression.
The ideal decompressor would _not_ try to recreate the original
dynamic range, but rather provide an audio output with very little
dynamic range.

I would greatly appreciate any information about such a device or
potential sources of information about such a device.

Thanks,
Al

--

------------------------------------------------------------------------
Al Polivka                       Internet: apolivka@x102a.ess.harris.com
Harris Corporation                   UUCP: uunet!x102a!apolivka
Electronic Systems Sector           phone: 407-729-2983
Melbourne, FL 32902
------------------------------------------------------------------------
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: PKZIP encryption contest
Organization: California Institute of Technology, Pasadena
Date: Tue, 14 Apr 1992 18:08:55 GMT


Nico feels that PK had to use:
>>    - special tricks to prevent PKZIP from imploding the file (strange)

Steve's claim was that the file would compress using implode, but not
compress using shrink.  If that's true, then PKZIP 1.1 could have made
pkcontst.zip using the shrink only option (-es?), which would choose to
store the file since shrinking it would make it bigger.

I don't want to look like I'm defending PKWare here--I also think that
this contest is way bogus.  Mainly because there is only one file, and
that it is not compressed.  There should be several, compressed entries
(all using the same password).  I don't think that arbitrary byte
passwords is as big a deal, since if he restricted to printables or
something, he would have simply made the password longer.  Either way
it's just as hard.  What makes it most unrealistic is that the file is
nothing like your typical zip file, which has (and I repeat) many 
compressed entries.

I have no reason to believe that they did not use PKZIP 1.10 to make
the file.  However, I also have no reason to believe that they did.
They haven't said whether they did or not.  If they did not, this also
adds greatly to the bogosity.

Mark Adler
madler@tybalt.caltech.edu
Newsgroups: comp.compression
From: gmribeir@wheaton.edu (Glauber)
Subject: Re: Too much lossy encoding?
Organization: (n.) Body of persons united for a specific purpose.
Date: Mon, 13 Apr 1992 00:31:44 GMT

Just my $.25:

The term "lossy compression" can be very misleading. What we are
concerned with is the best possible use of the storage and
transmission means we have. What JPEG does, for instance, is to
optimize the way colors are coded so that you can transmit much more
detail in less space. Since infinite storage doesn't exist, neither
does infinite bandwidth, we must use what we have the most efficient
way.

Also, my personal bet goes to fractal compression methods, which
preserve much more detail in a more intelligent way.

It is not that THESE methods are lossy. ALL digital processing of
analog quatities such as sound and image is lossy. These methods
simply let us select more intelligently WHAT we are going to lose.

					Glauber.




-- 
Glauber Ribeiro - Wheaton College, IL  (USA)
                  gmribeir@david.wheaton.edu 
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: PKZIP encryption contest
Organization: California Institute of Technology, Pasadena
Date: Mon, 13 Apr 1992 19:57:33 GMT


I was just told by a PKWare person that the encrypted file in pkcontst.zip
*does* compress with implode or deflate, but not shrink.  However, they
did not want to use implode since then the first 100 or so bytes would be
known, and they did not want to use delfate since PKZIP 2.x isn't out yet.
They felt that deflate would not have several known bytes at the start,
so using implode would be more vulnerable than the real situation (clearly
they expect everyone to run out and buy 2.x when it comes out).  I'm not
sure I agree on that point--there are definitely characteristics of the
first several bytes of a deflated entry that are know, even if the bytes
themselves are not known.  This vastly speeds up checking of candidate
passwords that passed the encryption header test.

He also said that there is a message in the entry when decrypted, so you
will know if you got the right password.

So in short, the entry does compress, but they elected to not do so, and
if you succeed, you'll know.

Mark Adler
madler@tybalt.caltech.edu
From: gabe_sky@cats.ucsc.edu (Gabriel M. Schuyler)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Date: 10 Apr 92 09:52:35 GMT
Organization: University of California, Santa Cruz


My thoughts about lossy compression:

My worry is that lossy compression will become the standard.  It may be app-
ropriate for certain applications where image/sound quality is not important,
but when I compress files, I'd like to still have my loss-less option.
I don't mind it as long as I don't HAVE to use it, and with all the press
that new lossy compression scemes are getting, it looks like I may not have
a choice in the future.  As long as it doesn't become the standard, I'm happy.


/				|    Gabriel M. Schuyler		|
|				|    Kresge 170 - UCSC			|
|  Gabe Sky.			|    Santa Cruz, CA  95064		|
|				|    Internet: gabe_sky@cats.ucsc.edu	|
/				|    America Online:  Gabe Sky		|
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: 16: 1 data compression
Keywords: bogus, compression
Date: 8 Apr 92 17:56:56 GMT
Organization: Academic Computer Centre Utrecht

In <N02.22@csci1.csci.unt.edu> N02@csci1.csci.unt.edu (Orion) writes:

>In article <1345600001@igc.org> An-Ly Yao <anlyyao@igc.org> writes:
>...
>I invented a compression algorithm last week that compresses everything down 
>to one bit.  I'm still working on the decompression part, though.
Why stop at 1 bit. 0 bits seems better then I no longer need a computer
to store the data :-)
>                 --Orion


Nico de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (comming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: protonen@daimi.aau.dk (Lars J|dal)
Newsgroups: comp.compression
Subject: Re: 16:1 compression?
Date: 14 Apr 92 13:35:27 GMT
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark

ry01@ns1.cc.lehigh.edu (ROBERT YUNG) writes:

[stuff deleted]
>BTW, doesn't that longer to compress a file than to uncompress it? All the
>compression time is taken up by trying to find the right way to compress a
>certain strin g of data. Once that's done, uncompression should be a breeze!
>So why am I hearing people saying they can compress so and so but can't
>uncompress...????

That depends on the compression method. If the dictionary (of often
encountered strings) is saved in the compressed file. But some compression
methods (like LSW) doesn't save the dictionary. Instead it is possible
to build up the dictionary from the compressed data. That is, the dictionary
is build again during the decompression, so decompression is not necesarily
faster than compression.
For more details about LZW compression, see part 2 of the FAQ sheet
about compression (posted to news.answers once a month).

>-- 
> (%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%)
>  |  Off-campus address...                                          |
>  |     first alley down this street, left refrigerator box. :-)    |
>  |                                                                 |
>   \_________Bobby Yung_______RY01@Lehigh.Edu________X-0471________/

+--------------------------------------------------------------------------+
|      Lars J|dal       |       (quote compressed to zero bytes)           |
| protonen@daimi.aau.dk |                                                  |
|--------------------------------------------------------------------------|
| Computer Science Department  -  Aarhus University  -  Aarhus  -  Denmark |
+--------------------------------------------------------------------------+
From: herbing@netmbx.netmbx.de (Kai-Uwe Herbing)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 9 Apr 92 17:12:35 GMT
Article-I.D.: netmbx.PX51GQG
Organization: netmbx, Berlin, Germany

ts@uwasa.fi (Timo Salmi) writes:

>I fully agree that the decision of PKWare to have the option to make
>pkliting irreversible was a bad one from the point of virus checking
>and I wish that they would change their policy.  Nevertheless there
>is no way I will accept this file to garbo FTP archives unless
>PKWare officially and explicitly sanctions such dislite programs. 
>Acquiring such a permission is up to the writer of a dislite.  We
>will _not_ be part in any compromizing situation. 

>...................................................................
>Prof. Timo Salmi
>Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
>School of Business Studies, University of Vaasa, SF-65101, Finland
>Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun

What about removing UNLZEXE from your archive, or has the author obtained
permission from Fabrice Bellard to write it :-)

Lets get serious, i don't see any reason not to put DISLITE on your archive,
than supporting PKWARE with its policy not to release source codes and its
policiy to sell non-US-residents crippled versions of PKZIP, instead obtaining
permission from the government to sell the full functional one with AV-checking
included.

Nothing personal, and I like your good work on keeping a great European
archive site.

Sincerely
Kai
-- 
------------------------------------------------------------------------------- Kai-Uwe Herbing      |   voice 49-30-8520892              |   I don't claim any Rheinstrasse 6-7     |   fax   49-30-8520769              |   warranty for tips D-1000 Berlin 41     |                                    |   tricks, hints and Fed.Rep.of Germany   |   email herbing@netmbx.netmbx.de   |   suggestions given -------------------------------------------------------------------------------
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 8 Apr 92 19:59:26 GMT
Organization: University of Vaasa, Finland

In article <2328@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>In my PKLite, DIET, LZEXE comparission I noted the existence of an utility
>to reverse the "irreversable compression" oprion of PKLite. I never got
>so much responses to one single item. Everyone wants to know where to get it.
>I am aware of all kinds of misuses of the program but I assume the fact I
>could download it from the local BBS means lots of people (especialy crackers)
>already have it anyway.
>I uploaded it to garbo for general availability. I don't know how garbo
>works normally (first upload) but I followed the instructions so it probably 
>arives there soon.

I fully agree that the decision of PKWare to have the option to make
pkliting irreversible was a bad one from the point of virus checking
and I wish that they would change their policy.  Nevertheless there
is no way I will accept this file to garbo FTP archives unless
PKWare officially and explicitly sanctions such dislite programs. 
Acquiring such a permission is up to the writer of a dislite.  We
will _not_ be part in any compromizing situation. 

...................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
Newsgroups: comp.compression
From: gmribeir@wheaton.edu (Glauber)
Subject: Re: Where is the new PKZIP?
Organization: (n.) Body of persons united for a specific purpose.
Date: Mon, 13 Apr 1992 06:49:07 GMT

If memory doesn't fail, when PC Magazine did an special on compressors
sometime last fall, ARC 7 showed pretty well. I've never seen ARC 7, so
I can't say for sure. I'd ever thought that SEA was the bad guy in
this story: SEA is the big company vs. poor little PK. 

This is the first time i'm hearing someone say that this may have been
the other way around. I'd like to know what really happened...

Also, at the time of the lawsuit, sharewhare was a brave new idea; now
many people are getting pretty much fed up with it.

I wonder how many registrations PK gets from non-business owners. It's
very hard for any commercial compressor to compete with ARJ, which is
free for non-commercial use. Also, ZOO and LHA are free for anybody.

All this doesn't mean we need to spend bandwidth flaming SEA. If you
like ARJ, use it, try to convert other people to it, but why attack
SEA? 

					Glauber.

-- 
Glauber Ribeiro - Wheaton College, IL  (USA)
                  gmribeir@david.wheaton.edu
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: Where is the new PKZIP?
Date: 13 Apr 92 13:51:09 GMT
Organization: Academic Computer Centre Utrecht

In <1992Apr13.064907.28500@wheaton.wheaton.edu> gmribeir@wheaton.edu (Glauber) writes:

>If memory doesn't fail, when PC Magazine did an special on compressors
>sometime last fall, ARC 7 showed pretty well. I've never seen ARC 7, so
>I can't say for sure. I'd ever thought that SEA was the bad guy in
>this story: SEA is the big company vs. poor little PK. 

>This is the first time i'm hearing someone say that this may have been
>the other way around. I'd like to know what really happened...
We have heard by know what SEA had to say, lets see if PKWARE responds. If
they don't respond we should start drawing conclusions and asking PKWARE
direct questions. But it might be possible SEA is lying to us (althought
I have to admit that it is very unlikely).

>Also, at the time of the lawsuit, sharewhare was a brave new idea; now
>many people are getting pretty much fed up with it.

>I wonder how many registrations PK gets from non-business owners. It's
>very hard for any commercial compressor to compete with ARJ, which is
>free for non-commercial use. Also, ZOO and LHA are free for anybody.

>All this doesn't mean we need to spend bandwidth flaming SEA. If you
>like ARJ, use it, try to convert other people to it, but why attack
>SEA?

They probably made the same mistake as I did. PKWARE officially blaimes
SEA and SEA didn't respond. Now the time set by the court is over and
SEA starts telling there side of the story (which PKWARE somhow did
long ago). I senserely hope the truth comes out. I have always avoided
ARC because of it (until a short while ago, I actually think there
are some interesting things in it).


>					Glauber.

>-- 
>Glauber Ribeiro - Wheaton College, IL  (USA)
>                  gmribeir@david.wheaton.edu 


Nico de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (coming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: Too much lossy encoding?
Keywords: PASC, audio
Date: 13 Apr 92 16:20:41 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <32529@darkstar.ucsc.edu>, gabe_sky@cats.ucsc.edu (Gabriel M. Schuyler) writes:

|  My worry is that lossy compression will become the standard.  It may be app-
|  ropriate for certain applications where image/sound quality is not important,
|  but when I compress files, I'd like to still have my loss-less option.
|  I don't mind it as long as I don't HAVE to use it, and with all the press
|  that new lossy compression scemes are getting, it looks like I may not have
|  a choice in the future.  As long as it doesn't become the standard, I'm happy.

  I share some of your concern, that non-lossy compression will fall by
the wayside, used only by a few people who care about preservation of
data. More importantly, lossy compression is being used
innappropriately.

  I think there are three cases in which lossy compression is best
avoided, either as a rule or on a case by case basis:

 a) starting with preprocessed data. A good example is feeding GIFs or
TIFFs into a JPEG compressor. In some cases the result is perfectly
acceptable, while in other, particularly when a lot of dithering apperas
in the 8 bit image, the quality can be visibly degraded, and the
compression is minimal over GIF. GIFs of halftone (newsprint) images are
particularly bad, since they have only two colors and lots of high
frequencies. But they still get used, and work VERY poorly.

 b) when computers look at the data rather than people. Computers NOTICE
changes in a few pixels, and may fail to match images, find things which
aren't there, etc.

 c) when color range must be preserved over a number of images. This one
gets interesting, such as when a number of digitized photos are viewed,
and all images are acceptable one at a time, but displaying several on
the screen at once makes it obvious that the colors have not been
preserved in the same way for each images. This is an effect with either
frequency data loss (JPEG primarily) or quantization loss (GIF, et al).
Particularly when digitizing large images which must be done in parts
and joined later, preservation of full 24 bit color is a must, and
compressed Targa or 24 bit TIFF becomes appropriate.

  I don't agree that it's bad to have lossy standards, but I do agree
that there's a possibility that it will result in less effort going into
non-lossy compression techniques, both in research and implementation.
High compression is great, and I love being able to get my whole for
four generations on a floppy disk. However, that doesn't make lossy
compression suitable for everything, and I hope that Tiff24 doesn't
represent the best we ever see in non-lossy compression.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: lye@fraser.sfu.ca (William Michael Lye)
Subject: Dynamic Huffman Coding
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Sun, 5 Apr 1992 16:44:07 GMT

Can anyone point me to a code sample which does dynamic Huffman coding?  In C?

Thanks in advance...
-- 
Bill Lye, lye@sfu.ca
SFU claims these views....NOT!
From: lusardi@sybil.cs.Buffalo.EDU (Christopher Lusardi)
Newsgroups: comp.compression
Subject: The Bug in Mark Nelson's DCT Image Compression Program
Date: 8 Apr 92 15:07:31 GMT
Organization: State University of New York at Buffalo/Comp Sci
Originator: lusardi@sybil.cs.Buffalo.EDU

First, has anyone implemented Mark Nelson's dct based image compression 
algorithm from his book. When I compress a raw (320 byte * 200 byte) image, 
I can't put the image on the screen again after decompression.

The original raw image and the decompressed image are the same size
-- 64000 bytes -- and the two images are similar except the decompressed 
image has extra blank lines.

Does anyone have any suggestions for me? 

Second, why does Nelson talk about a quality factor of zero on the command 
line. I use only from 1 to 25, because in one section of the book, he also
hints at using one. 

-- 
Christopher M. Lusardi     University At Buffalo     lusardi@acsu.buffalo.edu