HDTenEightyP/NetNews huggingface dataset:
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: Some minor problems with the new Info-ZIP
Date: 10 Sep 92 13:57:13 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <bontchev.716054908@fbihh>, bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

| 1) There is some inconsistency in the file naming in the two archives.
| The files in the unzip50.zip archive all have lowercase-only names,
| while the files in zip19p1.zip have mixed-case names. It seems that
| the two archives have been created by two different people. At first I

  I believe they were.

| 2) The file names in the Mac and VMS directories do not conform to the
| ZipRules.

  ZipRules are useful for systems as limited as MS-DOS and CP/M. These
files are not useful in those contexts, and meaningful manes were used.
You are correct, but it doesn't matter.

| 3) The makefiles are also not consistent between the two archives. For
| instance, one of the makefiles supports the "list" tag, while the
| other doesn't.

  See my answer to #1. The same person didn't generate each Makefile (as
far as I know). If they did they have a split personality.

| 5) The most important of all. Can I create archives that are
| compatible with PKZIP 1.10 or with the old zip? I.e., is there an

  No. You will need to keep the old zip (go get zip1.1) around forever,
or until the last user turns to dust. I suggested that this capability
be kept, but most people felt that the extra code was not worth the
overhead and added code size, complexity, etc.

  I neither support nor condemn that idea, I can live with two versions
for compatibility, most people will drop the old one and hand out copies
of new unzip rather than bother with the limited version.

  For the record, at this time all my systems use new unzip, and have
both zip (1.1) and Zip(1.9) executables. I will probably make 1.9 zip
and 1.1 oldzip later, but right now I share a bunch of stuff, and
there's no point in creating files people can't read just to prove that
you have a better compressor than they do.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.compression
From: yoda@deathstar.Stanford.EDU (Terry Lee)
Subject: FAQ question.  HELP needed ASAP
Organization: Residential Computing, Stanford University
Date: Mon, 14 Sep 1992 15:55:05 GMT

I just lost the FAQ to this group on my news server.  I just need
to know if there is a UNIX program that creates .ZIP archives
and where I can find it.  Could someone please mail me the FAQ
or just the answer?  Or post the FAQ would be fine too.

Thanks in advance.

Terry
From: ajr@eng.cam.ac.uk (Tony Robinson)
Newsgroups: comp.compression
Subject: Re: Question: Voice compression
Date: 8 Sep 92 16:39:58 GMT
Organization: Cambridge University Engineering Department, UK

In comp.compression elizabec@fraser.sfu.ca (Elizabeth Fong Wah Chan) writes:
>
>I bought a third party S/W package that can digitize voice signals
>and store them into a DOS file. On average, one hour of speech 
>requires 10Mbytes of storage. Does anyone know some compression
>programs that perform well in digitized voice files and are reasonably
>fast in compression and decompression.

Apart from the general purpose compression utilities (which will get you
somewhere), there are two speech specific compressors available by anonymous
ftp:

Lossy:	  ftp.cwi.nl:/pub/adpcm.shar
Lossless: svr-ftp.eng.cam.ac.uk:misc/shorten-0.4.shar

This looks like a good time to say this new release of shorten, version 0.4,
fixes one bug for compression of sun .au files, and does a bit of tidying
up.  I can mail shorten-0.4.shar (63159 bytes) to anyone who wants it and
lacks sufficient internet connectivity.

Tony [Robinson]
Newsgroups: comp.compression
From: boberg@lysator.liu.se (Stefan Boberg)
Subject: Re: Amiga Compressing Filesystems (was: PKWARE AND ASI AGREEMENT)
Organization: Lysator Academic Computer Society, Linkoping University, Sweden
Date: Thu, 10 Sep 1992 21:03:19 GMT

fox@rei.com (Fuzzy Fox) writes:

>>  At least for the Amiga there are
>>a multitude of different data compression programs, including realtime
>>compressing filesystems [...]

>Where??  How??

  I was referring to the XFH-Handler which is part of the XPK package.
XPK has not been officially released yet, but will be within the next
couple of days. XPK is a joint effort between Urban Mueller, Kristian
Nielsen, Bryan Ford and a few more. It's an XPR-like programming 
interface for data compression routines. In this package the XFH-
Handler is included which can decompress files on the fly. The Beta
version I have also compresses on the fly (although for some types of
applications it does not work right now).

  Watch c.s.a.announce the next couple of days for the public release.

  I am also developing a compressing filesystem of my own, which is
quite different from the XPK approach (it is a real filesystem). More 
on this later when it's released.

--
Stefan Boberg - AP & EE student at Linkoping Institute of Technology, Sweden
Author of LhA, ArjA and LhArcA. Co-author of Alien Breed, Project X, Full
Contact and Miami Chase.
    EMail: boberg@lysator.liu.se, lha@augs.se       FidoNet: 2:204/404
--
Stefan Boberg - AP & EE student at Linkoping Institute of Technology, Sweden
 Author of LhA, ArjA and LhArcA. Co-author of Alien Breed, Project X, Full
  Contact and Miami Chase.
    EMail: boberg@lysator.liu.se, lha@augs.se       FidoNet: 2:204/404
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: CCITT H.261 /Ftp site
Date: 6 Sep 92 11:07:59 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France

Clark D. Thomborson <cthombor@theory.lcs.mit.edu> writes:

> I just checked ftp.uu.net for doc/standards/ccitt.  An empty
> directory.

This fact has been stated in the FAQ posted on Aug 11th:

   Main changes relative to the previous version:
   [...]
   ccitt standards are no longer on ftp.uu.net (item 11)

A correct ftp location is given in the FAQ. I am very often sending
email to people asking FAQ questions, to avoid bothering all the
readers of comp.compression. But this question on CCITT standards is
really so frequent that I make an exception today.  If you want the
specs of H.261, V42bis, TIFF, CCITT group 3 or 4 Fax, please check the
FAQ first. I have just posted the FAQ two days ago, but just in case
I give below my standard instructions to get it.

Jean-loup Gailly
jloup@chorus.fr

The FAQ is 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 commands
    send usenet/news.answers/compression-faq/part1
    send usenet/news.answers/compression-faq/part2
For instructions, send an email message to the same address with the
words "help" and "index" (no quotes) on separate lines. If you don't
get a reply, check your return address, or add a line such as
    path myname@foo.edu
Newsgroups: comp.compression.research
From: dak@cip-s02.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: using a compression routine.
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 10 Sep 92 10:52:25 GMT

sven@laire.hotb.sub.org (Sven Wachter) writes:


>Mark Nelson
>The Data Compression Book
>Prentice Hall

>ISBN 0-13-202854-9

>Answers to all your questions, all of the algorithems need to be
>optimised, they are written to be readable, not space or time
>efficient.

And I thoght compression algorithms should be at least space efficient:)
Newsgroups: comp.compression.research,comp.compression,alt.comp.compression
From: sboswell@sdcc13.ucsd.edu (Xianity is stupid)
Newsgroups: comp.compression.research
Subject: Not-stream-based substitution compression
Date: 15 Sep 92 21:40:35 GMT
Organization: UC San Diego -- 1992 "Wannabe Real College" semi-finalist

The FAQ only mentions stream-based substitution compression, i.e.
the LZ family.  Are there any books, research papers, or other info
on substitution compression where the program is allowed to look at
the data all at once & decide how to compress it?

Thanks for any pointers.

Steve Boswell
whatis@ucsd.edu
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression.research
Subject: Re: Best Compression Algor...?
Date: 5 Sep 92 15:31:32 GMT
Organization: Academic Computer Centre Utrecht

In <188i67INNndi@usenet.INS.CWRU.Edu> aj681@cleveland.Freenet.Edu (Carlin Wiegner) writes:


>BTW, I've been wondering what the best compression algol is...
>For normal OS use that is.... Arcing (PC),Compactor (Mac),
>TAR(UNIX)??? Please email me a reply if there is one....
>CW

"Best" is a subjective term. ARJ 2.3 and ZIP 1.9 are currently state of the
art in usefull general purpose compression (fast & compact) (LHA being
third at a small distance). ZIP 1.9 is available for very much platforms.

For optimal compression (max ratio) the best available compressor is
the Ashford compressor. The best existing seems to be the SAKDC 
(Swich Army Knife Data Compressor) but that is not publically available.

The fastest compressor is copy :-). Second place is the Finish submission 
to the Dr Dobbs compression contest. Third place is for the excelent LZRW
compression family.

For more information, availability of sources, locations etc see the
comp.compression FAQ.

>Carlin E. Wiegner    

Nico E. de Vries
_ _
O O  USENET nevries@cc.ruu.nl  FIDO 2:281/708.1  COMPUSERVE "soon" ???? 
 o   This text reflects MY opinions, not that of my employer BITECH.      
\_/  This text is supplied 'AS IS', no waranties of any kind apply.      
     Don't waste your time on complaining about my hopeless typostyle.

"I would admit my mistakes, if I had any ..."  (Bumper Sticker)
Newsgroups: comp.compression.research
From: cew6@po.CWRU.Edu (Carlin E. Wiegner)
Newsgroups: comp.compression.research
Subject: Info on on-the-fly voice compression...
Date: 13 Sep 1992 19:51:10 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: thor.ins.cwru.edu


I apologize if this is the wrong section and please point me 
the right way if it isn't...

I'm in the process of writing a program that will allow users
to talk to people on other machines over a network (in
realtime). Thus I need to find away to compress the audio
in real-time and was wondering if anyone could give me the
name of a book or help me personally. I have a dedicated 
Motorola Digital Signal Procesor on each machine to do
some progressing (I will program it in assembler). thanks
ahead of time and please email the replies...
CW
Newsgroups: comp.compression.research
From: kol@hal.nta.no (Karl Olav Lillevold FST Student)
Subject: Bits needed to code image block?
Organization: Norwegian Telecom Research
Date: Fri, 11 Sep 92 06:20:36 GMT

I am not very experienced in validating compression algorithms, and
I now need to estimate the number of bits needed to code an image block
of an error image. The error image is the result of a motion
compensation, and I assume the coding procedure will be something
DCT-like, i.e. blockwise coding.

I have one advice: Find the squared error of each block and subtract
the gain obtainable by removing correlation. This should (somehow) 
give me an estimate of the needed number of bits.

My questions are:
1) Does anyone have a practical solution to this problem?
2) Is there a common procedure that is normally used so that
   different algorithms can be compared without needing to
   do the actual coding? (I have seen results based on
   both SNR and entropy)


Karl Olav Lillevold                email: kol@hal.nta.no
Student Norwegian Institute of Technology  (electronics)
Diploma at Norwegian Telecom Research (image processing)
From: sven@laire.hotb.sub.org (Sven Wachter)
Newsgroups: comp.compression.research
Subject: Re: using a compression routine.
Distribution: world
Date: 8 Sep 92 12:32:00 GMT
Organization: Organization is a waste of energy!

In article <1992Aug28.023752.18650@umbc3.umbc.edu> grabenst@umbc4.umbc.edu (Mr. Michael Grabenstein; ACS (GUEST)) writes:
>	OK, I have a programming question (hope this is the
>appropriate sub). If I were to write a compression program (ie.
>an archiving program) what are the implied legal problems?
>Also Where could I find a C source that would compress various
>types of files relatively well? Suggested books of algorithms?
>Thanks!

Mark Nelson
The Data Compression Book
Prentice Hall

ISBN 0-13-202854-9

Answers to all your questions, all of the algorithems need to be
optimised, they are written to be readable, not space or time
efficient.

Sven
--
/////////////////////////////////////////////////////////////////
//   Sven Wachter,  Neckarstr. 14,  6050 Offenbach,  Germany   //
/////////////////////////////////////////////////////////////////
//   Sven_Wachter@f.maus.de   ///   sven@laire.hotb.sub.org    //
/////////////////////////////////////////////////////////////////
Newsgroups: comp.compression.research,alt.fractals
From: jgs@photon.uucp (Joe Shanks)
Subject: Re: reference request
Organization: Photon Research Associates, Inc.
Date: Tue, 8 Sep 1992 22:10:33 GMT

     You can probably obtain a paperback copy from  

		University Microfilms, @ (800) 521-0600,

for ~ 30 dollars.

								Joe
--
===================================================================
Joe Shanks   					jgs@photon.com
Photon Research Assoc., Inc.         (619) 455-9741 [fax: 455-0658]
9393 Town Center Dr., # 200,  San Diego, CA  92121
Newsgroups: comp.compression.research
From: dieter@cs.kuleuven.ac.be (Dieter van Melkebeek)
Subject: reference request
Organization: Dept. Computerwetenschappen K.U.Leuven
Date: Tue, 8 Sep 1992 16:29:24 GMT


      Hello,

   I am a thesis-student of the university of Leuven (Belgium),
who is desperately (and boldly) looking for the following
reference :

 Reuter,L. Hodges,
 Rendering and Magnification of Fractals Using Iterated Function
 Systems, Ph. D. thesis,
 School of Mathematics, Georgia Institute of Technology  (1987)

   Can anybody help me in any way (by example by providing an 
appropriate e-mail adress) ?  Thank you.

   Kris Van Baelen
From: cole.erskine@spacebbs.com (Cole Erskine) 
Newsgroups: comp.compression
Subject: QUESTION: VOICE COMPRESSI
Date: 10 Sep 92 06:21:00 GMT
Distribution: na
Organization: SPACE BBS - Menlo Park, CA - 10 Lines + 4gB - 415-323-4193
Reply-To: cole.erskine@spacebbs.com (Cole Erskine) 

Hi,
   Most voice samplers operate at a standard sampling rate of 8KHz and
use 8-bit quantization, resulting in 28.8MBytes to store one hour of
speech.
   My company, Analogical Systems, has implemented a 4800 bps CELP
vocoder based upon the Ariel PC-56 DSP card for the PC (this card has
a Motorola DSP56001 on it). The resulting compression ratio is 13.3:1,
requiring only 2.16MBytes to store one hour of speech.
   Demonstration systems (including the Ariel PC-56 board) are
available from Analogical Systems for only $595. The demo systems
have a real-time synthesizer (playback) and non-real-time analyzer
(recorder).

Cole Erskine
Analogical Systems
2916 Ramona
Palo Alto, CA 94306
(415) 323-3232
                                                                 
Newsgroups: comp.compression
From: gmribeir@david.wheaton.edu (Glauber)
Subject: Re: INFO-ZIP congretulations!
Organization: (n.) Body of persons united for a specific purpose.
Date: Sat, 5 Sep 1992 14:08:17 GMT

In article <3040@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>
>I have been wrong here. Compression seems to be between 0.1% better and 
>0.2% worse on average (depending on file type and characteristics). The
>compression speed of the tigtest mode seems to be about 20% slower 
>than PKZIP 1.93a which is very impressive. Even more than at first sight. 
>
>Nico E. de Vries

And it feels very fast if you don't use -9 maximum compression.

The only thing that doesn't work in ms-dog is funzip, and
probably very few people would care, anyway. But the funzip that
came with zip19p1x.zip either locks or reboots my machine. (Maybe
this is their idea of fun :-)

Interesting new way of storing directories.

Anyway. Very very good work.

					Glauber
-- 
Glauber Ribeiro - Wheaton College, IL  (USA)
                  glauber@david.wheaton.edu 
                  glauber@vpnet.chi.il.us
Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: A minor bug in ARJ 2.30
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 15 Sep 92 07:15:55 GMT

Hello, everybody!

I discovered something which I believe is a minor bug in ARJ version
2.30 (it probably exists in the previous versions too). Here is what
happens:

If you enter the command

	arj t *

this is supposed to mean "Test the integrity of all ARJ archives in
the current directory". If all the archives are OK, the command works
fine and dandy. However, if one of the archives is corrupted, the
program not only reports this - it also terminates (with the
appropriate errorlevel) and refuses to process the rest of the
archives.

Maybe I am misunderstanding what the `t' command is supposed to do,
but I think that it would be nice if -all- the archives are checked
and -all- corruptions are reported...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: comp.compression
From: markh@csd4.csd.uwm.edu (Mark)
Subject: Re: Compressing English text to 1.75bits or better (80%)
Keywords: FAQ
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Sat, 12 Sep 1992 15:47:13 GMT

In article <1992Sep12.103552.24873@rhrk.uni-kl.de> marpia@sun.rhrk.uni-kl.de (David Powers [Informatik]) writes:
>Perhaps this information should go into the FAQ question [73] on
>the theoretical limits of compression.

I have in mind an compression algorithm.  It has a list of every single
text that was produced anywhere, is being produced, or ever will be
produced, and indexes each with a unique 64 bit number.

This algorithm will compress every English text to 64 bits.  Admittedly, it's
software implementation could be a memory and CPU hog, but still...
Newsgroups: comp.compression
From: roelofs@pan.arc.nasa.gov (Cave Newt)
Subject: Re: Pkunzip error "incons. loc. header"!!!!!!
Organization: University of Chicago
Date: Wed, 9 Sep 92 18:10:35 GMT

spissinger@urz.unibas.ch writes:

>I have the following problem with pkunzip: I downloaded zipped files from
>ftp-sites and transferred them with versatermPro/Kermit to our PC which is a
>Macintosh.                                       ^^^^^^
 ^^^^^^^^^
>When I unzip the files on my IBM-PC with Pkunzip I get for some files the error
>message "inconsistent local header for.." and the resulting file is empty.
>So I looked at the zip-file and found that after 5 or 6 lines there is written
>"appl????", which is not in the original file on the vax. Maybe this is the
>cause for this mess.                                 ^^^

You don't give enough information to know for sure, but the problem
is probably in your transfers.  First of all, have you done this before?
If so, has it worked?  If not, make sure you are using the appropriate
BINARY mode to do the transfer.  If the VAX is a VMS VAX and not a Unix
VAX, that means "set file type fixed" on the VAX side, "set file type
binary" on the PC side (I think).  If the Mac has a MacBinary setting
of some sort, don't use that.  And finally, you might try Info-ZIP's
UnZip (this is a blatant plug, but you asked for it)--it has all sorts
of work-arounds for bugs in other people's programs.  From the sound of
your error message, however, it probably won't work either; but it might
give a more useful error message.

>Can this be repaired?  And HOW?

Probably not. :-)

Greg Roelofs
Newsgroups: comp.compression
From: kko@fraser.sfu.ca (Samuel Ko)
Subject: Re: HELP I need a decompressor
Keywords: help lzh
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 7 Sep 1992 08:35:01 GMT

pmueller@ux4.cso.uiuc.edu (Pete Mueller) writes:

>I'm looking for an un-lzh utility for MS-DOS. The problem is i needed it
>yesterday!!! I've check all of the ftp sites i know and can't find it anywhere
>i tried wuarchive, but no luck, the one they had acted strange on my machine.
>(it never stopped reading, just kept going for ever...)  

If you still need an un-lzh utility after yesterday, you should get
lha213.exe ... which is available from /mirrors/msdos/arc-lbr at
wuarchive ...

Also, while you are at wuarchive, why not get my compilation of the
most useful msdos programs at simtel and garbo (useful14.zip in 
/mirrors/garbo.uwasa.fi/filelist) which has a section on compression /
decompression programs ...

Samuel Ko (kko@sfu.ca)
From: leo@zelator.in-berlin.de (Stefan Hartmann)
Newsgroups: comp.compression
Subject: Re: MPEG, computer rendered, and artifacts
Date: 13 Sep 92 17:26:22 GMT
Organization: Puplic-Access-Xenix-System

In <1992Sep10.230306.3798@umr.edu> quandt@mcs213c.cs.umr.edu (Brian Quandt) writes:


>I have a question about MPEG, artifacts, and computer generated images.

>I have seen problems when JPEG is used on a simple scene such as one
>rendered by a computer, apparently, the 'high energy' associated with
>lines and such don't work well when dealing with DCT's etc.

>What about MPEG?  Since MPEG is similar to JPEG in that it uses a DCT
>to obtain a portion of its' compression, do artifacts still present
>a problem? I was thinking that since MPEG deals with mulitiple frames
>that the artifact problem may be less then JPEG, or in the least
>an algorithm could be constructed that would cause the artifacts in
>successive frames to 'cancel each other out'.

>I remember seeing the same discussion about JPEG a while ago.  I'd like
>to see a summary if anyone has kept one.  Also what methods were propsed
>to deal with the problem (smoothing etc).  Who has seen and worked on this
>problem?  Anyone, investigating this problem with MPEG?

>					Brian Quandt


>oh yeah, a non-related question, does anyone know how to forward a 
>news article to another person (i.e., in elm the command is 'b' for bounce).
>Pipeing to mail doesn't do it, I'd like to keep the 'subject' line intact.


Hi,
get the birdisba.mpg file in:
ftp 130.231.240.17  in pub/mpeg  and have a look at it.
Use the win3.x MPEGXING.LZH player for display.

I figured out, that the quality of the encoding depends on the
luminace and contrast of the supplied pictures.  If you give the
pictures more brightness and less contrast, they seem to have less
artfacts.

Best regards Stefan Hartmann.
email to: leo@zelator.in-berlin.de


-- 
 
*************************************************************
*  Stefan Hartmann       This is how to contact me:         *
*  EMAIL: leo@zelator.in-berlin.de                          *
*  Phone : ++ 49 30 344 23 66      FAX : ++ 49 30 344 92 79 *
*************************************************************
Organization: Penn State University
Date: Wed, 9 Sep 1992 16:39:01 EDT
From: <F0O@psuvm.psu.edu>
Newsgroups: comp.compression
Subject: Re: LZW/GIF
Distribution: world

In article <18jmksINNm8f@agate.berkeley.edu>, c60b-1fk@e260-1c.berkeley.edu
(Ahmon Dancy) says:

>Greetings.  I am looking for information on lzw and/or GIF compression.
>I've read a few files and they just don't give me a clue.  Can anyone
>point me in the right direction?  These prefixes and suffixes are evading me.

   Yes, I'd also like to get my hands on the code for compressing and
decompressing GIF images.  If anyone knows of any FTP sites or articles
I could read, I'd appreciate it!

                                                             [Tim]
Newsgroups: comp.compression