HDTenEightyP/NetNews huggingface dataset:
From: jmorriso@ee.ubc.ca (John Paul Morrison)
Subject: Packages for FEC (opposite of compression!)
Organization: University of BC, Electrical Engineering
Date: Tue, 24 Nov 1992 01:03:07 GMT



I can't find a newsgroup on forward error correction, which adds
redundancy to data (opposite of compression, to remove redundancy)

But I thought there might be a few people here who'd know if there
any free/PD toolkits for FEC, just as there are kits for compression
(after all, removing useless redundancy is just as important as adding
consistent useful redundancy to the problem of data transmission)

I'm interested in experimenting with a few techniques. If anyone has some
code for Reed-Solomon FEC codes, or Hamming, or block codes etc. that
would be neat. Also, if anyone has any interesting error detection techniques
that would be nice (I mean if there are new, neat techniques, not standard
parity or CRC polynomials)
-- 
__________________________________________________________________________
 John Paul Morrison                     |  
 University of British Columbia, Canada |  
 Electrical Engineering                 |   .sig file without a cause
 jmorriso@ee.ubc.ca              VE7JPM |  
________________________________________|_________________________________
Newsgroups: comp.compression
From: roe2@ellis.uchicago.edu (Cave Newt)
Subject: Re: ZIPfix
Reply-To: roe2@midway.uchicago.edu
Organization: University of Chicago
Date: Sat, 21 Nov 1992 19:33:52 GMT

rogerj@aix.rpi.edu (Diversion (Jeff Rogers)) writes:

>Is there an Info-ZIP version of zipfix? Or any other type of zipfix (besides
>pkzipfix)? Something that will take a corrupted zipfile (or truncated
>zipfile) and extract the 'good' information from it? 

Alas, no.  All of us agree it would be a Good Thing, and all of
us have expressed interest in writing such a thing someday, but
we also have a huge backlog of improvements to Zip and UnZip to
do first.  If PKZIPFIX won't do it for you, your only recourse
at the moment is probably to use a binary editor (or possibly
funzip in conjunction with "tail +###c bad.zip"--funzip can
extract the first file in a zipfile, and tail could be used to
"lop off 'is 'ead" for a second, third, fourth, ..., pass).

Sorry...

Greg Roelofs
From: dougmc@ccwf.cc.utexas.edu (Doug McLaren)
Newsgroups: comp.compression
Subject: Re: Q: How well do random files crunch?  A: Not very.
Date: 19 Nov 92 07:50:53 GMT
Organization: Doug's House of Disco

In article <1992Nov13.135437.19044@decuac.dec.com> bell@ufp.enet.dec.com () writes:

>Ok, let's talk about random files.  Say I produce a file filled with
>random bytes, based on a fairly equal-distribution function.

Well, the way I understand it, if your file is completely random, you
will not be able to compress it at all.

Basically, entropy must always increase.  A random file already has the maximum
entropy for a file of that length, so you can't compress it.  (compression
increases entropy while decreasing (or increasing -- sometimes a compression
scheme will increase the size of the file, but that's irrelavent here) the
size.

Now, if your file isn't completely random, then it's certainly possible
that it could be compressed

Of course, it's possible to have a 100,000 byte file thats completely
'0's come up randomly, but the odds against this are so astronomical ...
(the infinite number of monkeys idea is nice, but has nothing to do with the
real world.  One million monkeys typing 100 wps for the total age of the
universe aren't likely to come up with even ONE work of Shakespear.)

But I digress ...
-- 
----------------------- \  Zippy says:
Doug McLaren,            \  First, I'm going to give you all the ANSWERS to
DemoN on IRC              \  today's test.. So just plug in your SONY WALKMANS
dougmc@ccwf.cc.utexas.edu  \  and relax!!
-------------------------- /
From: itdhs056@hamlet.ucdavis.edu (Doug Mak)
Newsgroups: comp.compression
Subject: PKunzip 2.02 bogus??
Date: 17 Nov 92 18:31:57 GMT
Organization: Davis High School, CA

I heard from local area that pkunzip and pkzip 2.02 is A HACKED VERSION
	and this bogus version tends to erase data from your HDD..!!!!

pkware announced that they didn't release such version--2.02, they also found
this version is running all over the country's bbs'es.. if you have it, don't use it 
or ask pkware company..  and some of the v2.01 (that could be in your PC) also
found the same problem...

I'm not sure it this is true.. but i prefer avoid using v2.02

----

Doug <St.Seiya>
From: morley@camins.camosun.bc.ca
Newsgroups: comp.compression
Subject: Is my PKZIP 2.01 a fake?
Date: 17 Nov 92 22:44:15 GMT
Organization: Camosun College

I keep seeing messages that say PKZIP 2.0 is still "on the way"...  The
other day an instructor here gave me a copy of PKZIP 2.01  What gives?
I've heard that there was (is?) some sort of trojan warning concerning
PKZIP 2.x  However, this version I received works fine (or so it appears).
It also has many more options than version 1.93 has.  It comes complete
with docs that detail the changes since 1.93, etc.  It seems like an
awful lot of work just to make some sort of trojan.  Am I missing
something here?

Please reply to me directly as I don't read this group often.

Thanks for your time,

MARK
morley@camins.camosun.bc.ca
Newsgroups: comp.compression
From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Q: How well do random files crunch? A: Not very.
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 21 Nov 92 22:59:03 GMT

dougmc@ccwf.cc.utexas.edu (Doug McLaren) writes:

>In article <1992Nov13.135437.19044@decuac.dec.com> bell@ufp.enet.dec.com () writes:

>>Ok, let's talk about random files.  Say I produce a file filled with
>>random bytes, based on a fairly equal-distribution function.

>Well, the way I understand it, if your file is completely random, you
>will not be able to compress it at all.

>Basically, entropy must always increase.  A random file already has the maximum
>entropy for a file of that length, so you can't compress it.  (compression
>increases entropy while decreasing (or increasing -- sometimes a compression
>scheme will increase the size of the file, but that's irrelavent here) the
>size.

>Now, if your file isn't completely random, then it's certainly possible
>that it could be compressed

>Of course, it's possible to have a 100,000 byte file thats completely
>'0's come up randomly, but the odds against this are so astronomical ...
>(the infinite number of monkeys idea is nice, but has nothing to do with the
>real world.  One million monkeys typing 100 wps for the total age of the
>universe aren't likely to come up with even ONE work of Shakespear.)

But iff such a file cropped up, it would compress better. The thing to note
is, you cannot decrease the MEAN size. As soon as some of the n-byte
patterns a n-byte file may assume 256^{8n} has different probabilities,
a compression might increase entropy, decreasing mean size.

Now you could just add, say, one bit to tell whether you tried compression
or not on the remainder of the file, and compress only where you might gain.
Information theory tells you that having random files, ANY compression
will not provide a sufficient gain even that often that the prolongation
by one bit would be compensated in the long run.
From: wieck@jwminhh.hanse.de (Jan Wieck)
Subject: Re: ARJ password cracker.
Organization: Private Site under Mach386
Date: Mon, 16 Nov 1992 23:00:12 GMT

From article <1992Nov14.065336.17744@nwnexus.WA.COM>, by ralphs@halcyon.com (Ralph Sims):
> Matthew E. Bernold <MEB117@psuvm.psu.edu> writes:
> 
>>only copy he has left is in the archive, and he can't get to them.  I know
>>I've read about password crackers for WordPerfect documents, and .ZIP files.
>>Is there such a beast for .ARJ files?
> 
> Maybe I'm missing something, but what good is a password that anyone can
> crack?
> 

	Absolutely right!!!

	One sunday, i got an alarm-call from a client, (chemical industry,
	producing 500 tonns of polypropylene per day). They cannot start
	their process-computer, holding all the production relevant 
	information in his database. Remember that PP costs between 1.00
	and 3.00 US$ per kilogram (depending on the quality). So look at
	the clock from now on.

	Some hours later, i sat in front of the console. Starting all of
	the system. After that, there was a new menu on the operator's
	display: "DATA RECOVERY". That was the only, that could be 
	selected. Doing so, the system asked for "RECOVERY PASSWORD".
	I got all rights for the system, but that password wasn't stored
	in the system's rights database - so what to do now?

	After some hacking i knew, the password already stood on the
	screen. Thank's to the client's system-manager, who was in
	holyday's (and unreachable). He prevented hundredthousands of
	loss by using a crackable password.


	Until later, Jan.

-- 
# Any language keeps its own misunderstandings; #
# why shouldn't programming languages do?       #
#                                               #
#            wieck@jwminhh.hanse.de (Jan Wieck) #
From: jloup@chorus.fr (Jean-Loup Gailly)
Newsgroups: comp.compression
Subject: Re: Need a compressor for sparse bit datastream
Keywords: compression technique
Date: 17 Nov 92 09:48:37 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France

Tom Lane <tgl+@cs.cmu.edu> writes:

> Arithmetic compression code is easy to come by, see the comp.compression FAQ.
[...]
> Are you sure the 0's and 1's are uncorrelated?  If not, higher-order
> arithmetic coding might work

The program 'urban' in ddjcompr.zip (see item 12 of the FAQ) is a high
order arithmetic coder working at the bit level, which is appropriate
for the given application. The program is written by Urban Koistinen
<md85-epi@nada.kth.se>.

  wsmr-simtel20.army.mil in pd1:<msdos.compress>ddjcompr.zip. [192.88.110.2]
  garbo.uwasa.fi:/pc/source/ddjcompr.zip [128.214.87.1]

Jean-loup Gailly
Newsgroups: comp.compression
From: fsmadja@figment.shearson.com (Frank Smadja)
Subject: Re: Data compression SOURCES available NOW !!!
Followup-To: comp.compression
Reply-To: fsmadja@alfred.shearson.com
Organization: Lehman Brothers
Distribution: usa
Date: Wed, 18 Nov 1992 18:45:57 GMT



Nico de Cries says:
>Hi,
>
>It took some time but LDS_10 finally made it to garbo! Thanks
>to Timo for helping me with that.
>
>I made version 1 of the LDS (lossless datacompression sources) kit.
>I noticed lots of people want sources for datacompressors and it
>can be hard to get them. Especially good ones. I have spend a fortune
>on collecting compression sources (I need them for an archiver I
>am working on) and decided to create a package containing the ones
>I think are most wanted and interesting.
>
>The kit includes AR002 (comparable with ARJ 2.39, LHA, ZOO 2.11,
>PKZIP 1.93a, ZIP 1.9), LZW, Huffman, Splaytree's, Ashford, LZHUF,
>LZSS, LZARI, ARI, higher order ARI etc.
>
>The file is available on garbo.uwasa.fi, /pc/programming/LDS_10.ZIP
>
>

Is this file available at other sites?
Is there a good readme? Can this code compile to DLLS? etc.

Frank
From: @FtCollins.NCR.COM
Newsgroups: comp.compression
Subject: entropy of video
Date: 17 Nov 92 19:47:48 GMT
Reply-To: @FtCollins.NCR.COM
Distribution: usa
Organization: NCR MED, FT. Collins, CO. 80525  (303) 223-5100



Has anyone measured the entropy of real video?
(NTSC or otherwise)

Are there any published results on this?

Thanks,

Jim Prater - NCR Microelectronics, Advanced Development
From: tjhuang@vax1.umkc.edu
Newsgroups: comp.compression
Subject: ? JPEG + En/decryption
Date: 15 Nov 92 09:27:51 GMT
Article-I.D.: vax1.1992Nov15.032751.1
Organization: University of Missouri - Kansas City

Hi!
   I am a graduate student at Univ. of MO - Kansas City. Currently I am doing
research on still picture compression (JPEG) combining with en/decryption.
Can someone kindly tell me any book or research paper disscussing on this
specific field?

Thank you in advance

T.J. Huang
From: abirenbo@rigel.cel.scg.hac.com (Aaron Birenboim)
Newsgroups: comp.compression
Subject: Re: Math Question
Date: 16 Nov 92 15:41:22 GMT
Organization: Hughes Aircraft Colorado Engineering Labs

In article <24005@hacgate.SCG.HAC.COM> abirenbo@rigel.cel.scg.hac.com (Aaron Birenboim) writes:
>
>While working on an optimization problem related to compression
>I bumped into the following nasty little problem :
>
>   evaluate:
>
>                {           [(i+1)q                                      }
>             d  {           [                                            }
>            --- {  Integral [      (x - (i + 0.5) q)^2 * exp(-c * x) dx  }
>             dq {           [                                            }
>                {           [i*q                                         }
>

the answer i was seeking was "Leibnitz rule".  its quite useful.
Patrich smith was kind enough to send me the definition:

      / b(y)
d    |
--   |        f(x,y) dx   =
dy   |
    /  a(y)
	  
	  
	  
    / b(y)
    |        d
    |        -- f(x,y) dx   +  b'(y)f(b(y),y)  -  a'(y)f(a(y),y)
    |        dy
    /  a(y)
			      
thanks to all those who replied!


--
Aaron Birenboim         |
birenb@hac2arpa.hac.com |
                        |
H (303) 871-8271        |
Newsgroups: comp.compression
From: ohumukin@spectra.com (Kawika Ohumukini)
Subject: Re: Voice Mail Card and Stacker
Organization: Spectragraphics Corporation
Date: Tue, 17 Nov 92 00:08:30 GMT

I hate to follow up my own article but this is relevant
-------------------------------------------------------------------

In article <1992Nov16.214530.305@spectra.com> ohumukin@spectra.com (Kawika Ohumukini) writes:
>
>Stacker reported   1.2:1 compression ratio

After reading the documentation further I found the following:

Sampling Rate:      7.95KHz, 8bits
Compression Rate:   2:1
Data Storage Rate:  3.9Kb per second
Blanking:           0-30%

Can anyone give me their thoughts on how they arrive at a 2:1 ratio and
still leave room for stacker to compress the data file?

Again, thanks for any information.

Kawika
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: The Best Compression around, PD or NOT PD
Date: 20 Nov 92 19:45:41 GMT
Organization: Academic Computer Centre Utrecht

(Raphe Berry III) writes:

>Hi,

>I am new to this group and I was wondering what is the best compression 
>program around.  I have been using for most of my like Pkzip, but after
>using Lharc on my Unix account and on my Dos machine, I am now in love.
>But I want better compression, I don't care if it takes a long time...
>I just got to have it!!  Prefer it to be pd too, but doesn't have to 
>be.

Better is a subjective matter. In your opinion better means more compression. 
There are currently two programs (archivers) which are best (in compression)
abd common usable. ZIP 1.9 (from InfoZIP not from PKWARE) and ARJ 2.30. They
are about equal on compression. 

Even better compression can be achieved with HPACK (available on garbo BTW).
It is slower (but not extremely) and still a complete archiver.

If only compression matters and you can live without an archiver the
Ashford is the best compressor in existence. It is also the slowest (and
I am 99% sure you ain't going to use it of you see HOW slow). Also
notice Ashford sometimes failes to compress a file (it has some bugs).
The same applies to e.g. PKZIP 1.10 but Ashford failes much more often.

Ashford source is part of my own LDS_10 package.
Please also notice the FAQ has more detailed figures on compression
comparissions.

Locating the comp.compression ==> FAQ <== :
 * The FAQ is posted often to comp.compression and should also be available
   on news.answers as "comp.compression Frequently Asked Questions".
 * The FAQ is also available by anonymous ftp on rtfm.mit.edu [18.72.1.58]
   in directory /pub/usenet/news.answers/compression-faq, files part1 and part2.
 * If you don't have FTP access, you can get the FAQ by a mail
   server.  Send an email message to mail-server@pit-manager.mit.edu
   containing the command "help" (no quotes) for more information.
 * If all above REALLY fails, request the files from nevries@cc.ruu.nl
Locating lossless data compression ==> SOURCES <== :
  garbo.uwasa.fi /pc/programming/lds_10.zip contains most known sources
  for lossless data compression.

>Raphe Berry III

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.unix.aux
From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Subject: Re: Yep... that's right. Latest 'tc' released (3.10)
Keywords: tc tape driver
Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Organization: NASA/Goddard Space Flight Center
Date: Mon, 16 Nov 1992 18:21:22 GMT

jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:

>As promised, 'tc' version 3.10 is now available here on jagubox via
>anon-ftp

Look for NEWtc310.tar.Z in /pub...
-- 
    Jim Jagielski               | "It is not I who am crazy...
    jim@jagubox.gsfc.nasa.gov   |  it is I who am MAD!"
    NASA/GSFC, Code 734.4       |
    Greenbelt, MD 20771         |            - Ren
From: J.Purchase@cs.ucl.ac.uk (Jan Purchase)
Newsgroups: comp.unix.aux
Subject: Re: "top" for AUX
Date: 19 Nov 92 03:09:22 GMT



David Coster writes:
 > 
 > Does anybody know of a "top" program for AUX?  I have gotten used to
 > having it available on all the other machines I work on, and would
 > like to have it running on my home machine as well.
 > 

David,

I'd be really grateful if you would forward any replies to me. I
also need "top". Many Thanks.

Cheers,
Jan.

-----------------------------------------------------------------------
Dr Jan Purchase - University College London, UK - purchase@cs.ucl.ac.uk
-----------------------------------------------------------------------
From: un032463@wvnvms.wvnet.edu
Newsgroups: comp.unix.aux
Subject: A Second Call To Slip Users (Bitter/Sweet Success)
Date: 16 Nov 92 04:48:42 GMT
Organization: West Virginia Network for Educational Telecomputing

O.K. I now have a slip connection at 2400 BPS.  Now my ONLY problem is that
when I go up to 9600 baud (Compression off), the whole thing goes to pieces.
I can telnet into my server, give my username, password it prints a couple of 
lines, then FREEZES!!  That's all she wrote for that session (and subsequent
sessions).  Question:  Why does this NOT work at 9600 or Why DOES this work
at 2400?  I am sure you all know how sloooooow 2400 is.  Any help would be
great.  Thanks!

							Mike Manzo
						West Virginia University
						      NASA USRA/ADP
From: pierre@bohica.tucson.az.us (Pierre Padovani)
Newsgroups: comp.unix.aux
Subject: tty login problems
Keywords: tty, stty, setenv
Date: 22 Nov 92 00:43:23 GMT
Organization: UofA HACKS

My A/UX system has, currently, 1 mac hooked up to it's printer port as a tty, and 
we are running into some problems. When loging into the A/UX system from the remote
mac via Microphone II we are unable to use stty to modify the number of rows and
we are completely unable to use setenv from this tty. Is this a limitation of 
the A/UX tty ports? Or is something not set correctly? The speed of the port is
set to 19200 if that make any difference.

Also I saw this posted once bfefore, but how, if your not root, can one see the boot
partition(mac partition) when logged in as a normal user? It never seems to mount
when I log in as myself.

One other question...has anyone gotten video spigot to work with A/UX? It just seems
to crash my mac/OS process.

  -=pierre
---------------------------------------
pierre padovani
pierre@hacks.arizona.edu
pierre@cs.arizona.edu
pierre@bohica.tucson.az.us
Newsgroups: comp.unix.aux
From: fred@ivhs.mot.com (Fred Brunner)
Subject: Re: Desktop file's getting screwed up, What to do?
Organization: Motorola IVHS Group - Northbrook IL
Date: 18 Nov 92 18:02:26 GMT

I have observed that the Finder in 3.0 never picks up the correct
application icon even after it has been launched. If I want icons
to be reconciled with applications, I have to rebuild the desktop,
which takes forever.

In general, though, the system is pretty stable unless the Mac environment
hangs and I have to crash out of it. Then I lose the Desktop info,
as I would expect.

-FB

-- 
---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   
Fred Brunner - Sr. Systems Engineer (all opinions expressed solely my own)
Intelligent Vehicle/Highway Systems Group - Motorola, Inc.
---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---
Newsgroups: comp.unix.aux
From: lewis@sophists.com (Lewis G. Pringle)
Subject: Re: A/UX 3.0 partition slower than Mac Partition
Date: Fri, 20 Nov 1992 20:02:47 GMT
Organization: Sophist Solutions

In article <1257@jagubox.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
>li@oculus.loni.ucla.edu (James Li) writes:
>
>>When working from Mac Applications, access to the Mac Partition is several
>>times faster than a folder/directory under the root (/) partition.  Is
>>this normal, and if so, could someone explain why?  Also, is there anything
>>that can be done to make this faster?
>
>Could it be the simple fact that the MacPartition is many times _smaller_
>than "/"...?


I seriously doubt it. I've noticed the same thing. Looking up file names
is at least 10 to 100 times slower on a AUX partition than a mac partition.
Saving files seems about 4 or 5 times slower.

I must admit my mac partition is smaller (200K vs 700K) but I've used
even larger mac partitions in the past and never noticed any degredation.

My guess is that the main problem has to do with mapping a case-insensative
file system onto a case sensative one. I don't know how they do this, but
if they do it without kernel support, that might explain the slowdown.
Or perhaps just sloppyness.

			Lewis.


-- 
Reading peoples signatures is a real waste of time.

lewis@sophists.com                                  (Lewis Gordon Pringle, Jr.)
Newsgroups: comp.unix.aux
From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Subject: Re: A/UX 3.0 partition slower than Mac Partition
Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Organization: NASA/Goddard Space Flight Center
Date: Mon, 23 Nov 1992 18:22:12 GMT

lewis@sophists.com (Lewis G. Pringle) writes:

>In article <1257@jagubox.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
>>li@oculus.loni.ucla.edu (James Li) writes:
>>
>>>When working from Mac Applications, access to the Mac Partition is several
>>>times faster than a folder/directory under the root (/) partition.  Is
>>>this normal, and if so, could someone explain why?  Also, is there anything
>>>that can be done to make this faster?
>>
>>Could it be the simple fact that the MacPartition is many times _smaller_
>>than "/"...?


>I seriously doubt it. I've noticed the same thing. Looking up file names
>is at least 10 to 100 times slower on a AUX partition than a mac partition.
>Saving files seems about 4 or 5 times slower.

With the A/UX file system, A/UX must "translate" files to MacOS format.

If you want to speed up access (etc) to these files, change them from
AppleSingle to AppleDouble (see fcnvt)...

In any case, the size of A/UX _does_ cause some performance "problems"...
The size of the Desktop* files can get pretty big!
-- 
    Jim Jagielski               | "It is not I who am crazy...
    jim@jagubox.gsfc.nasa.gov   |  it is I who am MAD!"
    NASA/GSFC, Code 734.4       |
    Greenbelt, MD 20771         |            - Ren