home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / faqs / comp / answers / compression-faq / part1 < prev    next >
Encoding:
Internet Message Format  |  1997-10-26  |  156.4 KB
  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news-out.internetmci.com!newsfeed.internetmci.com!141.211.144.13!newsxfer3.itd.umich.edu!oleane!jussieu.fr!excalibur!brainstorm.fr!frmug.fr.net!teaser.fr!not-for-mail
  2. From: jloup@gzip.removethis.org (Jean-loup Gailly)
  3. Newsgroups: comp.compression,comp.compression.research,news.answers,comp.answers
  4. Subject: comp.compression Frequently Asked Questions (part 1/3)
  5. Supersedes: <compr1_22sep97@gzip_org>
  6. Followup-To: comp.compression
  7. Date: 25 Oct 1997 09:27:37 +0200
  8. Organization: none
  9. Lines: 3632
  10. Sender: jloup@kerla.teaser.fr
  11. Approved: news-answers-request@mit.edu
  12. Distribution: world
  13. Expires: 15 Dec 1997 16:17:20 GMT
  14. Message-ID: <compr1_25oct97@gzip_org>
  15. Reply-To: jloup@gzip.removethis.org
  16. NNTP-Posting-Host: ppp1273-ft.teaser.fr
  17. Summary: *** READ THIS BEFORE POSTING ***
  18. Keywords: data compression, FAQ
  19. Xref: senator-bedfellow.mit.edu comp.compression:37317 comp.compression.research:2621 news.answers:115308 comp.answers:28669
  20.  
  21. Archive-name: compression-faq/part1
  22. Last-modified: Oct 25th, 1997
  23.  
  24.         "I've already explained this once, but repetition is
  25.         the very soul of the net."        (from alt.config)
  26.  
  27. This file is part 1 of a set of Frequently Asked Questions (FAQ) for
  28. the groups comp.compression and comp.compression.research.  If you
  29. can't find part 2 or 3, see item 53 below. A copy of this FAQ is available
  30. by ftp in ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/
  31. files part1 to part3. This FAQ is also accessible in the World Wide Web at
  32. http://www.faqs.org/faqs/compression-faq/part1/preamble.html or
  33. http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html
  34.  
  35. Certain questions get asked time and again, and this is an attempt to
  36. reduce the bandwidth taken up by these posts and their associated
  37. replies.  If you have a question, *please* check this file before you
  38. post.  It may save a lot of peoples time.
  39.  
  40. If you have not already read the overall Usenet introductory material
  41. posted to "news.announce.newusers", please do. It is also available by
  42. ftp in ftp://garbo.uwasa.fi/pc/doc-net/usenews.zip (see item 2 below
  43. about .zip).
  44.  
  45. If you don't want to see this FAQ regularly, please add the subject
  46. line to your kill file.  If you don't know what a kill file is, get by
  47. ftp the file ftp://rtfm.mit.edu/pub/usenet/news.answers/killfile-faq
  48. If you have corrections or suggestions for this FAQ, send them to
  49. Jean-loup Gailly <jloup@gzip.removethis.org> after fixing the email
  50. address as described. (This is a protection against junk mail. Sorry
  51. for the inconvenience.)
  52.  
  53. Part 1 is oriented towards practical usage of compression programs.
  54. Part 2 is more intended for people who want to know how compression works.
  55. Part 3 is a long (but somewhat obsolete) list of image compression hardware.
  56.  
  57. Main changes relative to the previous version:
  58.  
  59. - added three patents on compression of random data [item 9.5]
  60. - new version of BTPC [item 15]
  61. - new urls for OggSquish [item 26]
  62.  
  63. Contents
  64. ========
  65.  
  66. General questions:
  67.  
  68. [1]  What are these newsgroups about?
  69. [2]  What is this .xxx file type?
  70.      Where can I find the corresponding compression program?
  71. [3]  What is the latest pkzip version?
  72. [4]  What is an archiver?
  73. [5]  What is the best general purpose compression program?
  74. [7]  Which books should I read?
  75. [8]  What about patents on data compression algorithms?
  76. [9]  Compression of random data (WEB, Gilbert and others)
  77. [10] Fake compression programs (OWS, WIC)
  78. [11] What is the V.42bis standard?
  79. [12] I need source for the winners of the Dr Dobbs compression contest
  80. [13] I need source for arithmetic coding
  81.  
  82. Image and audio compression:
  83.  
  84. [15] Where can I get image compression programs?
  85. [16] What is the state of the art in lossless image compression?
  86. [17] What is the state of fractal compression?
  87. [18] I need specs and source for TIFF and CCITT group 4 Fax.
  88. [19] What is JPEG?
  89. [20] I am looking for source of an H.261/H.263 codec and MPEG
  90. [25] Fast DCT (Discrete Cosine Transform) algorithms
  91. [26] Are there algorithms and standards for audio compression?
  92.  
  93. Common problems:
  94.  
  95. [30] My archive is corrupted!
  96. [31] pkunzip reports a CRC error!
  97. [32] VMS zip is not compatible with pkzip!
  98. [33] I have a problem with Stacker or DoubleSpace!
  99.  
  100. Questions which do not really belong to comp.compression:
  101.  
  102. [50] What is this 'tar' compression program?
  103. [51] I need a CRC algorithm
  104. [52] What about those people who continue to ask frequently asked questions?
  105. [53] Where are FAQ lists archived?
  106. [54] I need specs for graphics formats
  107. [55] Where can I find Lenna and other images?
  108. [56] I am looking for a message digest algorithm
  109. [57] I have lost my password on a .zip file
  110.  
  111.  
  112. Part 2: (Long) introductions to data compression techniques
  113.  
  114. [70] Introduction to data compression (long)
  115.        Huffman and Related Compression Techniques
  116.        Arithmetic Coding
  117.        Substitutional Compressors
  118.           The LZ78 family of compressors
  119.           The LZ77 family of compressors
  120.  
  121. [71] Introduction to MPEG (long)
  122.        What is MPEG?
  123.        Does it have anything to do with JPEG?
  124.        Then what's JBIG and MHEG?
  125.        What has MPEG accomplished?
  126.        So how does MPEG I work?
  127.        What about the audio compression?
  128.        So how much does it compress?
  129.        What's phase II?
  130.        When will all this be finished?
  131.        How do I join MPEG?
  132.        How do I get the documents, like the MPEG I draft?
  133.  
  134. [72] What is wavelet theory?
  135. [73] What is the theoretical compression limit?
  136. [74] Introduction to JBIG
  137. [75] Introduction to JPEG
  138. [76] What is Vector Quantization?
  139. [77] Introduction to Fractal compression
  140. [78] The Burrows-Wheeler block sorting algorithm
  141.  
  142.  
  143. Part 3: (Long) list of image compression hardware
  144.  
  145. [85] Image compression hardware
  146. [99] Acknowledgments
  147.  
  148.  
  149. Search for "Subject: [#]" to get to question number # quickly. Some news
  150. readers can also take advantage of the message digest format used here.
  151.  
  152. If you know very little about data compression, read question 70 in
  153. part 2 first.
  154.  
  155. ------------------------------------------------------------------------------
  156.  
  157. Subject: [1] What are these newsgroups about?
  158.  
  159.  
  160. comp.compression is the place to discuss about data compression, both
  161. lossless (for text or data) and lossy (for images, sound, etc..).
  162. comp.compression.research was created later to provide a forum for
  163. current research on data compression and data compression algorithms;
  164. this group is now moderated. If you are not experienced in data compression,
  165. please post in comp.compression only.
  166.  
  167. An archive of this newsgroup since Oct 1993 is available in
  168. ftp://spib.rice.edu/pub/news/comp.compression/
  169.  
  170. An excellent collection of compression based information is provided at
  171. http://www.internz.com/compression-pointers.html
  172.  
  173. If you only want to find a particular compression program for a
  174. particular operating system, please read first this FAQ and the
  175. article "How to find sources" which is regularly posted in
  176. news.answers.
  177.  
  178. If you can't resist posting such a request, other groups are probably
  179. more appropriate (comp.binaries.ibm.pc.wanted, comp.os.msdos.apps,
  180. comp.sources.wanted, comp.sys.mac.wanted, comp.archives.msdos.d, comp.dsp,
  181. alt.graphics.pixutils). Please post your request in comp.compression
  182. only as a last resource.
  183.  
  184. If your question is about graphics only (no compression), please
  185. post to comp.graphics.misc, *after* reading the comp.graphics FAQ (see
  186. item 54 below). For some unknown reason, many questions about
  187. graphics are incorrectly posted to comp.compression.
  188. For questions related to audio compression, check also comp.dsp.
  189.  
  190. Please do not post any program in binary form to comp.compression.
  191. Very short sources can be posted, but long sources should be be posted
  192. to the specialized source groups, such as comp.sources.* or alt.sources.
  193. If the program is already available by ftp, just give the name of the
  194. ftp site and the full path name of the file.
  195.  
  196. As for any newsgroups, do not post the same message separately to
  197. comp.compression and comp.compression.research.
  198.  
  199. ------------------------------------------------------------------------------
  200.  
  201. Subject: [2] What is this .xxx file type?
  202.              Where can I find the corresponding compression program?
  203.  
  204.  
  205. All the programs mentioned in this section are lossless.  For most
  206. programs, one US and one European ftp site are given.  (ftp.simtel.net
  207. and garbo.uwasa.fi) Many other sites (in particular wuarchive.wustl.edu)
  208. have the same programs.
  209.  
  210. To keep this list to a reasonable size, many programs are not
  211. mentioned here. Additional information can be found in the file
  212. ftp://ftp.cso.uiuc.edu/pub/doc/pcnet/compression maintained by
  213. David Lemson (lemson@uiuc.edu). When several programs can handle
  214. the same archive format, only one of them is given. If you don't
  215. find a particular MSDOS archiver here, look also in
  216. ftp://ftp.cs.tu-berlin.de/pub/msdos/mirrors/ftp.elf.stuba.sk/pc/
  217.  
  218. Sources for additional lossless data compressors can be found in
  219.   ftp://garbo.uwasa.fi/pc/programming/lds_11.zip
  220.   ftp://ftp.simtel.net/pub/simtelnet/msdos/arcutils/lz-comp2.zip
  221.   http://wwwvms.utexas.edu/~cbloom/index.html
  222.   ftp://ftp.imag.fr/pub/archive/compression/codecs/codecs.tgz
  223.   ftp://garbo.uwasa.fi/pc/turbopas/preskit2.zip (sources in Pascal)
  224.   ftp://ftp.cs.uiowa.edu/pub/jones/compress/ (Splay tree compression)
  225.  
  226. For Macintosh programs, look on ftp://sumex-aim.stanford.edu/info-mac
  227.   on in http://hyperarchive.lcs.mit.edu/HyperArchive.html
  228. For VM/CMS, look on ftp://vmd.cso.uiuc.edu/public.477
  229. For Atari, look on ftp://atari.archive.umich.edu
  230. For Amiga, look on ftp://ftp.wustl.edu/pub/aminet/
  231.  
  232. A general purpose lossless data compression library is available in
  233. ftp://ftp.uu.net/pub/archiving/zip/zlib/zlib-1.0.4.tar.gz or zlib104.zip;
  234. see http://www.cdrom.com/infozip/zlib/ for more information.
  235. Another library favoring speed over compression ratio is available at
  236. http://www.infosys.tuwien.ac.at/Staff/lux/marco/lzo.html
  237.  
  238. If you don't know how to use ftp or don't have ftp access, read the
  239. article "How to find sources" which is regularly posted in news.answers.
  240.  
  241. If you can't find a program given below, a newer version probably exists in
  242. the same directory.  Tell me at jloup@gzip.removethis.org
  243.  
  244. A very short description of the compression algorithm is given for most
  245. programs. For the meaning of LZ77, LZ78 and LZW, see question 70 in part 2 of
  246. the FAQ.  If you are looking for the file format of a specific compression
  247. program, look at "The File Format Collection" in http://www.wotsit.demon.co.uk
  248. and/or get the sources of the decompressor. For the format of uuencode, do
  249. "man 5 uuencode" on a Unix box.
  250.  
  251. ext:  produced by or read by
  252.  
  253. .arc, .ark: arc, pkarc for MSDOS. (LZW algorithm)
  254.     ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/pk361.exe
  255.     ftp://garbo.uwasa.fi/pc/arcers/pk361.exe
  256.  
  257.       arc for Unix
  258.         ftp://ftp.ddj.com/packages/arc521e.tar.Z
  259.     ftp://garbo.uwasa.fi/unix/arcers/arc.tar.Z
  260.         Contact: Howard Chu <hyc@umix.cc.umich.edu>
  261.  
  262.       arc for VMS
  263.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/arc.exe
  264.  
  265.       for Mac
  266.     ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/stuffit-expander-352.hqx
  267.  
  268.       arc for Amiga
  269.     ftp.funet.fi:pub/amiga/fish/001-100/ff070/arc.lha
  270.  
  271. .arj: arj for MSDOS (LZ77 with hashing, plus secondary static Huffman
  272.           encoding on a block basis)
  273.         Contact: Robert K Jung <robjung@world.std.com>
  274.         http://www.websoftware.com/arj.htm
  275.         ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/arj250a.exe
  276.     ftp://garbo.uwasa.fi/pc/arcers/arj250a.exe
  277.  
  278.       unarj for Unix. Decompresses only. (There is no arj compressor for Unix.
  279.         Don't post a request.)
  280.     ftp://oak.oakland.edu/pub/misc/unix/unarj241.tar.Z
  281.     ftp://garbo.uwasa.fi/unix/arcers/unarj241.tar.Z
  282.  
  283.       unarj for Mac
  284.         ftp://mac.archive.umich.edu/mac/util/compression/unarjmac.cpt.hqx      
  285.  
  286.       unarj for Amiga
  287.     ftp.funet.fi:pub/amiga/utilities/archivers/unarj-0.5.lha
  288.  
  289. base64 (MIME encoding): This is *not* a compression issue but it keeps
  290.        coming as a question on comp.compression. So:
  291.           ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z (source)
  292.           ftp://ftp.andrew.cmu.edu/pub/mpack/mpack15d.zip        (MSDOS exe)
  293.           ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/mpack-15.hqx (Mac)
  294.           ftp://garbo.uwasa.fi/pc/decode/mime64b.zip
  295.  
  296. .bck: VMS BACKUP. BACKUP is *not* a compression program. Do "help backup".
  297.  
  298. .cab: Microsoft Cabinets
  299.     http://www.microsoft.com/workshop/prog/cab/cabdl.htm
  300.     http://www.ddj.com/ftp/1997/1997.05/cabinet.zip
  301.     ftp://ftp.mv.com/pub/ddj/1997/1997.05/cabinet.zip
  302.  
  303. .cpt: Compact Pro for Mac and Power PC
  304.          ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/compact-pro-151.hqx
  305.  
  306.       For Unix:
  307.     ftp://sumex-aim.stanford.edu/info-mac/unix/macutil-20b1.shar
  308.         ftp://ftp.cwi.nl/pub/dik/macutil2.0b3.shar.Z
  309.  
  310.       For DOS:
  311.         ftp://ftp.scruz.net/users/aladdin/public/SITEX10.EXE
  312.     ftp://garbo.uwasa.fi/pc/arcers/ext-pc.zip
  313.  
  314. .ddi:  files made by DiskDupe (Pro)
  315.      ftp://ftp.tem.nctu.edu.tw/Msdos/arcutil/unddi11u.zip
  316.      ftp://ftp.tem.nctu.edu.tw/Msdos/arcutil/x2file15.zip
  317.  
  318. .exe: self-extracting MSDOS executable (creates files on disk when run)
  319.       Run the file, or try unzip, lha or arj on it.
  320.  
  321. .exe: compressed MSDOS executable (decompresses itself in memory then runs
  322.       the decompressed code). To get the original uncompressed .exe:
  323.         ftp://garbo.uwasa.fi/pc/execomp/unp411.zip
  324.       To create such files:
  325.     ftp://ftp.simtel.net/pub/simtelnet/msdos/execomp/lzexe91e.zip
  326.     ftp://nic.funet.fi/pub/msdos/windows/util/winlite1.zip (for Windows)
  327.  
  328. .gif: gif files are images compressed with the LZW algorithm. See the
  329.       comp.graphics FAQ list for programs manipulating .gif files. See
  330.       suffix .Z below for source of LZW.
  331.  
  332. .gz, .z: gzip (or pack, see .z below). gzip uses the same algorithm as
  333.          zip 2.0x (see below); it can also extract packed and compressed files.
  334.     Contact: Jean-loup Gailly <support@gzip.removethis.org>
  335.                  http://www.gzip.org
  336.  
  337.       For Unix, MSDOS, OS/2, VMS, Atari, Amiga, Primos:
  338.     ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar (.shar or .tar.gz: source)
  339.     ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.msdos.exe (MSDOS self-extract)
  340.     ftp://ftp.simtel.net/pub/simtelnet/msdos/compress/gzip124.zip (MSDOS)
  341.     ftp://garbo.uwasa.fi/unix/arcers/gzip124.tar.Z          (source)
  342.     ftp://ftp.cdrom.com/pub/infozip/MSDOS/gzip124.exe       (MSDOS exe)
  343.     ftp://ftp.cdrom.com/pub/infozip/WIN32/gzip124xN.zip     (WIN95 & NT)
  344.         ftp://ftp.cdrom.com/pub/infozip/OS2/gz124-32.zip        (OS/2)
  345.     ftp://ftp.cdrom.com/pub/infozip/VMS/gzip124x.vax_exe    (VMS exe)
  346.         ftp://ftp.cdrom.com/pub/infozip/UNIX/SUN/gzip124x.tar.Z (Solaris 2)
  347.         http://www.gzip.org/gzip123mvs.zip                      (MVS exe)
  348.  
  349.       For Mac:
  350.        ftp://ivo.cps.unizar.es//Graficos/Public/SPDsoft/MacGzip_FAT_1.1.cpt.hqx
  351.        http://persephone.cps.unizar.es/general/gente/spd/gzip/ (MacGzip page)
  352.  
  353. .ha: ha 0.99 (improved PPMC - 4th order Markov modeling)
  354.     Contact: Harri Hirvola <harri.hirvola@vaisala.infonet.com>
  355.     ftp://garbo.uwasa.fi/pc/arcers/ha098.zip
  356.     ftp://ftp.nl.net/gopher/NLnet-connected/aipnl/ha0999.exe
  357.         ftp://sunsite.unc.edu/pub/Linux/utils/compress/ha0999p-linux.tar.gz
  358.  
  359. .hap: Hamarsoft HAP archiver (Markov modeling + arithmetic coding)
  360.       Contact: feldmann@xs4all.nl or feldmann@pi.net
  361.         ftp://garbo.uwasa.fi/pc/arcers/hap305bp.com
  362.         http://www.xs4all.nl/~feldmann
  363.  
  364. .hpk: hpack (archiver with strong encryption)
  365.       Contact: Peter Gutmann <pgut1@cs.aukuni.ac.nz>
  366.         ftp://src.doc.ic.ac.uk/computing/archiving/compress/hpack/
  367.  
  368. .hqx: Macintosh BinHex format.. (BinHex is *not* a compression program,
  369.       it is similar to uuencode but handles multiple forks.)
  370.        for Mac:
  371.     ftp://mac.archive.umich.edu/mac/utilities/compressionapps/binhex4.0.bin
  372.  
  373.        for Unix:
  374.          ftp://sumex-aim.stanford.edu/info-mac/cmp/mcvert-216.shar
  375.  
  376.        for MSDOS:
  377.      ftp://ftp.simtel.net/pub/simtelnet/msdos/mac/xbin23.zip
  378.          ftp://garbo.uwasa.fi/pc/unix/xbin23.zip
  379.  
  380. .jam: JAM real-time compressor for MSDOS
  381.        ftp://garbo.uwasa.fi/pc/arcers/jam125sw.zip
  382.  
  383. .lha:
  384. .lzh: lha for MSDOS (LZ77 with a trie data structure, plus secondary static
  385.           Huffman coding on a block basis)
  386.     ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/lha255e.exe
  387.     ftp://garbo.uwasa.fi/pc/arcers/lha255b.exe
  388.  
  389.       lharc for Unix. (LZ77 with hash table and binary trees, plus secondary
  390.           Huffman coding).  See lha for Unix below.
  391.            Warning: lharc can extract .lzh files created by
  392.            lharc 1.xx but not those created by lha.
  393.  
  394.       lharc for VMS. Same warning as for Unix lharc.
  395.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/lharc.exe
  396.  
  397.       lha for Unix.
  398.     ftp://oak.oakland.edu/pub/misc/unix/lha101u.tar.Z
  399.     ftp://garbo.uwasa.fi/unix/arcers/lha101u.tar.Z
  400.           Contact: lha-admin@oki.co.jp or oki@fs.telcom.oki.ac.jp
  401.  
  402.       lha for Mac
  403.     ftp://mac.archive.umich.edu/mac/utilities/compressionapps/maclha2.0.cpt.hqx
  404.       lha for Amiga
  405.     ftp://ftp.funet.fi/pub/amiga/utilities/archivers/LhA_e138.run
  406.       lha for OS/2:
  407.     ftp://hobbes.nmsu.edu/os2/16bit/archiver/lh2_222.zip
  408.  
  409. MIME: see base64 above
  410.  
  411. .pak: pak for MSDOS (LZW algorithm)
  412.         ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/pak251.exe
  413.     ftp://garbo.uwasa.fi/pc/arcers/pak251.exe
  414.  
  415. .pit: PackIt (Macintosh)
  416.        for Mac:
  417.          ftp://sumex-aim.stanford.edu/info-mac/cmp/stuffit-lite-35.hqx
  418.  
  419.        for Unix:
  420.          ftp://sumex-aim.stanford.edu/info-mac/cmp/mcvert-215.shar.gz
  421.          ftp://garbo.uwasa.fi/mac/arcers/mcvert-215.shar
  422.  
  423. .pp: PowerPacker (Amiga)
  424.     ftp.funet.fi:pub/amiga/fish/501-600/ff561/PPLib.lha
  425.  
  426. .rar: RAR (MSDOS) Contact: Eugene_Roshal@p0.f23.n5010.z2.fidonet.org
  427.           or Andrey Spasibozhko <as@hq.icb.chel.su>
  428.         ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/rar200.exe
  429.         ftp://garbo.uwasa.fi/pc/arcers/rar201.exe
  430.         ftp://ftp.kiae.su/msdos/arcers/rar*.exe
  431.         ftp://ftp.elf.stuba.sk/pub/pc/pack/*rar2*.exe
  432.  
  433. .sea: self-extracting archive (Macintosh)
  434.          Run the file to extract it. The self-extraction code can be
  435.          removed with:
  436.     ftp://mac.archive.umich.edu/mac/utilities/compressionapps/desea1.11.cpt.hqx
  437.     ftp://ftp.scruz.net/users/aladdin/public/SITEX10.EXE (MS Windows)
  438.  
  439. .sdn: used by the Shareware Distribution Network.
  440.       Try the decompressors for .pak or .arj (see above)
  441.  
  442. .shar:  Shell archive. This is not a compression program. Use "sh foo.shar"
  443.         to extract on Unix. For MSDOS, use:
  444.     ftp://garbo.uwasa.fi/pc/unix/unshar.zip
  445.  
  446. .sit: Stuffit for Macintosh
  447.        for Mac:
  448.          ftp://sumex-aim.stanford.edu/info-mac/cmp/stuffit-lite-35.hqx
  449.  
  450.        for Unix:
  451.          ftp://sumex-aim.stanford.edu/info-mac/cmp/unsit-15-unix.shar
  452.  
  453.        for Amiga:
  454.      ftp.funet.fi:pub/amiga/utilities/archivers/unsit-1.5c2.lha
  455.  
  456.        for MSDOS:
  457.      ftp://ftp.scruz.net/users/aladdin/public/SITEX10.EXE
  458.      ftp://garbo.uwasa.fi/pc/arcers/unsit30.zip
  459.  
  460. .?q?: Squeeze for MSDOS (do not confuse with other 'squeeze' below).
  461.       Static Huffman coding.
  462.        ftp://ftp.simtel.net/pub/simtelnet/msdos/starter/sqpc12a.com (squeeze)
  463.        ftp://ftp.simtel.net/pub/simtelnet/msdos/starter/nusq110.com (unsqueeze)
  464.  
  465. .sqz: Squeeze for MSDOS (do not confuse with other 'squeeze' above)
  466.       LZ77 with hashing.
  467.         ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/sqz1083e.exe
  468.         ftp://garbo.uwasa.fi/pc/arcers/sqz1083e.exe
  469.  
  470. .tar: tar is *not* a compression program. However, to be kind for you:
  471.       for MSDOS
  472.     ftp://ftp.simtel.net/pub/simtelnet/msdos/starter/tarread.exe
  473.     ftp://garbo.uwasa.fi/pc/unix/tar4dos.zoo
  474.  
  475.       for Unix
  476.         tar (you have it already. To extract: tar xvf file.tar)
  477.  
  478.       for VMS
  479.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/tar.exe
  480.  
  481.       for Macintosh
  482.         ftp://sumex-aim.stanford.edu/info-mac/util/tar-30.hqx
  483.  
  484.       for Amiga:
  485.     ftp.funet.fi:pub/amiga/fish/401-500/ff445/Tar.lha
  486.  
  487. .tar.Z, .tar-z, .taz: tar + compress
  488.       For Unix:     zcat file.tar.Z | tar xvf -
  489.       with GNU tar: tar xvzf file.tar.Z
  490.       for MSDOS:
  491.         ftp://garbo.uwasa.fi/pc/unix/tar320g.zip  (MSDOS exe)
  492.         ftp://ftp.kiae.su/msdos/arcers/tar*sr.zip (sources)
  493.         ftp://ftp.kiae.su/msdos/arcers/tar*_p.zip (MSDOS exe)
  494.       Other OS: first uncompress (see .Z below) then untar (see .tar above)
  495.  
  496. .tar.gz, .tgz, .tar-gz, .tar.z: tar + gzip
  497.       For Unix: gzip -cd file.tar.gz | tar xvf -
  498.         with GNU tar: tar xvzf file.tar.gz
  499.       for MSDOS:
  500.         ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/tar320g.zip
  501.         ftp://garbo.uwasa.fi/pc/unix/tar320g.zip
  502.       for MSDOS, Windows 95, NT & OS/2:
  503.         ftp://garbo.uwasa.fi/pc/unix/untgz095.zip
  504.          or http://till.home.ml.org/untgz.htm
  505.       for Windows 95 & Windows NT:
  506.          ftp://ftp.winzip.com/winzip/ or http://www.winzip.com
  507.  
  508.       Other OS: first uncompress (see .gz above) then untar (see .tar above)
  509.  
  510. .td0: (compressed MS-DOS floppy image produced by TeleDisk)
  511.       ftp://ftp.simtel.net/pub/simtelnet/msdos/diskutil/teled212.zip
  512.  
  513. .uc2: UC2 for MSDOS and OS/2. (LZ77 with secondary static Huffman encoding on
  514.      a block basis, and dynamic dictionaries shared among files.)
  515.     Contact: desk@aip.nl
  516.       ftp://garbo.uwasa.fi/pc/arcers/uc2r3.exe  (or uc2pro.exe)
  517.  
  518. .z:   pack or gzip (see .gz above). pack uses static Huffman coding.
  519.       To extract, see .gz above.
  520.  
  521. .zip: pkzip 2.04g for MSDOS. (LZ77 with hashing, plus secondary static
  522.            Huffman coding on a block basis). Contact: support@pkware.com
  523.            or http://www.pkware.com/
  524.     ftp://ftp.simtel.net/pub/simtelnet/msdos/zip/pkz204g.exe
  525.         ftp://garbo.uwasa.fi/pc/arcers/pkz204g.exe
  526.         ftp://ftp.simtel.net/pub/simtelnet/win95/compress/pk250w32.exe (WIN95)
  527.  
  528.       arcutil 2.0 for VM/CMS (unzip only, not yet compatible with pkzip 2.04)
  529.          ftp://vmd.cso.uiuc.edu/public.477/arcutil.*
  530.  
  531.       zip 1.1 for Unix, MSDOS, VMS, OS/2, ... (compatible with pkzip 1.10.
  532.      For corresponding unzip, see unzip 5.12 below).
  533.      ftp://ftp.uu.net/pub/archiving/zip/zip11.zip
  534.  
  535.       zip 2.1 and unzip 5.31 for Unix, MSDOS, VMS, OS/2, Amiga, ...
  536.           Compatible with pkzip 2.04g (LZ77 with hashing, plus secondary static
  537.           Huffman coding on a block basis). Contact: zip-bugs@lists.wku.edu
  538.           See also http://www.cdrom.com/pub/infozip/
  539.           (On SGI, do not confuse with the editor also named 'zip'.)
  540.  
  541.      ftp://ftp.cdrom.com/pub/infozip/src/zip21.zip      (source)
  542.      ftp://ftp.cdrom.com/pub/infozip/src/unzip531.*     (source)
  543.      ftp://ftp.cdrom.com/pub/infozip/MSDOS/zip21x.zip   (MSDOS exe)
  544.      ftp://ftp.cdrom.com/pub/infozip/MSDOS/unz531x*.exe (MSDOS exe)
  545.      ftp://ftp.cdrom.com/pub/infozip/WIN32/zip21xN.zip  (Win95 & NT)
  546.      ftp://ftp.cdrom.com/pub/infozip/WIN32/unz531xN.exe (Win95 & NT)
  547.          [The Win95 version supports long file names; MSDOS version doesn't]
  548.      ftp://ftp.cdrom.com/pub/infozip/OS2/*          (OS/2 exe 16&32 bit)
  549.           See also AMIGA, ATARI, MAC, UNIX, RISCOS, VMS... subdirectories.
  550.  
  551.          ftp://ftp.icce.rug.nl/infozip/src/zcrypt27.zip    (encryption source)
  552.  
  553.        for Macintosh:
  554.          ftp://mac.archive.umich.edu/mac/util/compression/unzip2.01.cpt.hqx
  555.      ftp://mac.archive.umich.edu/mac/util/compression/zipit1.31.cpt.hqx
  556.      ftp://ftp.cdrom.com/pub/infozip/MAC/unz512x.hqx
  557.     ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/stuffit-expander-352.hqx
  558.  
  559.        WinZip by Nico Mak <support@winzip.com> (uses Info-ZIP compress. code):
  560.          ftp://ftp.winzip.com/winzip/ or http://www.winzip.com   (MS Windows)
  561.  
  562. .zoo: zoo 2.10 for MSDOS (algorithm copied from that of lha, see lha above)
  563.      ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/zoo210.exe
  564.      ftp://garbo.uwasa.fi/pc/arcers/zoo210.exe
  565.  
  566.       zoo 2.10 for Unix, VMS
  567.          ftp://oak.oakland.edu/pub/misc/unix/zoo210.tar.Z
  568.      ftp://garbo.uwasa.fi/unix/arcers/zoo210.tar.Z
  569.  
  570.       zoo for Mac
  571.        ftp://mac.archive.umich.edu/mac/utilities/compressionapps/maczoo.sit.hqx
  572.  
  573.       zoo for Amiga
  574.     ftp://ftp.funet.fi/pub/amiga/utilities/archivers/Zoo-2.1.lha
  575.  
  576. .??_: Microsoft compress.exe and expand.exe. compress.exe is available
  577.     in the Windows SDK (Software Development Kit) and in
  578.        ftp://ftp.microsoft.com/softlib/mslfiles/CP0982.EXE
  579.  
  580. .F: freeze for Unix (LZ77 with hashing, plus secondary dynamic Huffman
  581.          encoding)
  582. ftp://wuarchive.wustl.edu/usenet/comp.sources.misc/volume35/freeze/part0[1-3].Z
  583.      ftp://ftp.inria.fr/system/arch-compr/freeze-2.5.tar.Z
  584.      Contact: Leonid A. Broukhis <leo@zycad.com>
  585.  
  586. .Y: yabba for Unix, VMS, ... (Y coding, a variant of LZ78)
  587.   ftp://wuarchive.wustl.edu/usenet/comp.sources.unix/volume24/yabbawhap/part*.Z
  588.   ftp://ftp.inria.fr/system/arch-compr/yabba.tar.Z
  589.   Contact: Dan Bernstein <djb@silverton.berkeley.edu>
  590.  
  591. .Z: compress for Unix ('the' LZW algorithm)
  592.       It is likely that your Unix system has 'compress' already. Otherwise:
  593.     ftp://wuarchive.wustl.edu/packages/compression/compress-4.1.tar
  594.         (not in .Z format to avoid chicken and egg problem)
  595.  
  596.     compress for MSDOS
  597.     ftp://ftp.simtel.net/pub/simtelnet/msdos/compress/comp430d.zip
  598.     ftp://garbo.uwasa.fi/pc/unix/comp430d.zip
  599.     ftp://garbo.uwasa.fi/pc/source/comp430s.zip
  600.  
  601.     compress for Macintosh
  602.     ftp://wuarchive.wustl.edu/systems/mac/info-mac/cmp/stuffit-expander-352.hqx
  603.         ftp://sumex-aim.stanford.edu/info-mac/cmp/maccompress-32.hqx
  604.  
  605.     compress for Amiga
  606.     ftp.funet.fi:pub/amiga/utilities/archivers/compress-4.1.lha
  607.  
  608.     compress for VAX/VMS
  609.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/lzcomp.exe
  610.     ftp://wuarchive.wustl.edu/packages/compression/vax-vms/lzdcmp.exe
  611.  
  612. ------------------------------------------------------------------------------
  613.  
  614. Subject: [3]  What is the latest PKZIP version?
  615.  
  616. The latest official DOS version is 2.04g. Release 2.04c had serious bugs,
  617. corrected in 2.04e and 2.04g. The latest Windows version is 2.5.
  618.  
  619. Be warned that there are countless bogus PKZIP 1.20, 2.0, 2.02, 3.00B,
  620. 3.05, 4.1 and whatever scams floating around.  They usually are hacks
  621. of PKZIP 1.93A beta test version.  Some of them are trojans and / or
  622. carry computer virii.
  623.  
  624. Note about pkzip 2.06 from a PKware employee:
  625.  
  626.     Version 2.06 was released as an INTERNAL use only IBM version.
  627.     It is identical to 2.04G, but it has IBM names in the help
  628.     screens and such. That release is meant for IBM only.
  629.  
  630. If pkunzip indicates that you need version 2.8 to extract an
  631. archive, your archive has been corrupted by a transfer not
  632. made in binary mode (see item 30 below).
  633. ------------------------------------------------------------------------------
  634.  
  635. Subject: [4] What is an archiver?
  636.  
  637.  
  638. There is a distinction between archivers and other compression
  639. programs:
  640.  
  641. - an archiver takes several input files, compresses them and produces
  642.   a single archive file. Examples are arc, arj, lha, zip, zoo.
  643.  
  644. - other compression programs create one compressed file for each
  645.   input file. Examples are freeze, yabba, compress, gzip. Such programs
  646.   are often combined with tar to create compressed archives (see
  647.   question 50: "What is this tar compression program?").
  648.  
  649. For a comparison of zip and gzip, see the gzip README file. (In short:
  650. zip is an archiver, gzip is not; only zip is compatible with pkzip.)
  651.  
  652. ------------------------------------------------------------------------------
  653.  
  654. Subject: [5] What is the best general purpose compression program?
  655.  
  656.  
  657. The answer is: it depends. (You did not expect a definitive answer,
  658. did you?)
  659.  
  660. It depends whether you favor speed, compression ratio, a standard and
  661. widely used archive format, the number of features, etc...  Just as
  662. for text editors, personal taste plays an important role. compress has
  663. 4 options, arj 2.30 has about 130 options; different people like
  664. different programs. *Please* do not start or continue flame wars on
  665. such matters of taste.
  666.  
  667. Several benchmarks of MSDOS archivers are available:
  668. - ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/actest*.zip
  669.   and http://www.geocities.com/SiliconValley/Park/4264/act.html
  670.   by Jeff Gilchrist <jeffg@nbnet.nb.ca>
  671. - ftp://garbo.uwasa.fi/pc/arcers/act-*.zip
  672.   by Jonathan Burt <jonathan@jaburt.demon.co.uk>
  673.  
  674. Please do not post your own benchmarks made on your own files that
  675. nobody else can access. If you think that you must absolutely post yet
  676. another benchmark, make sure that your test files are available by
  677. anonymous ftp.
  678.  
  679. Since all other benchmarks are for MSDOS only, here is one mainly for
  680. Unix, on a 33Mhz Compaq 386.  All programs have been run on Unix SVR4,
  681. except pkzip and arj which only run on MSDOS.
  682.  
  683. The programs compared here were chosen because they are the most
  684. popular or because they run on Unix and source is available.  For ftp
  685. information, see above. Three programs (hpack, comp-2 and ha) have
  686. been added because they achieve better compression (at the expense of
  687. speed) and one program (lzrw3-a) has been added because it favors
  688. speed at the expense of compression:
  689.  
  690. - comp-2 is in ftp://ftp.coast.net/pub/Coast/disk2/msdos/ddjmag/ddj9102.zip
  691.   (inner zip file nelson.zip),
  692. - hpack is in ftp://garbo.uwasa.fi/unix/arcers/hpack78src.tar.Z
  693. - ha 0.98 is in ftp://garbo.uwasa.fi/pc/arcers/ha098.zip
  694. - lzrw3-a is in http://wwwvms.utexas.edu/~cbloom/src/lzrw.zip
  695.  
  696. The 14 files used in the comparison are from the standard Calgary
  697. Text Compression Corpus, available in
  698. ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus/
  699.  
  700. The whole corpus includes 18 files, but the 4 files paper[3-6] are
  701. generally omitted in benchmarks. It contains several kinds of file
  702. (ascii, binary, image, etc...) but has a bias towards large files.
  703. You may well get different ratings on the typical mix of files that
  704. you use daily, so keep in mind that the comparisons given below are
  705. only indicative.
  706.  
  707. The programs are ordered by decreasing total compressed size. For a
  708. fair comparison between archivers and other programs, this size is
  709. only the size of the compressed data, not the archive size.
  710.  
  711. The programs were run on an idle machine, so the elapsed time
  712. is significant and can be used to compare Unix and MSDOS programs.
  713.  
  714. [Note: These benchmarks are now very old. I have to do them again
  715. on more recent hardware with the latest programs.]
  716.  
  717.        size     lzrw3a   compress    lharc    yabba     pkzip    freeze 
  718. version:                   4.0       1.02      1.0       1.10     2.3.5
  719. options:                                    -m300000                    
  720.        ------    -----    ------    ------    ------    ------   ------
  721. bib    111261    49040     46528     46502     40456     41354    41515 
  722. book1  768771   416131    332056    369479    306813    350560   344793 
  723. book2  610856   274371    250759    252540    229851    232589   230861 
  724. geo    102400    84214     77777     70955     76695     76172    68626 
  725. news   377109   191291    182121    166048    168287    157326   155783 
  726. obj1    21504    12647     14048     10748     13859     10546    10453 
  727. obj2   246814   108040    128659     90848    114323     90130    85500 
  728. paper1  53161    24522     25077     21748     22453     20041    20021 
  729. paper2  82199    39479     36161     35275     32733     32867    32693 
  730. pic    513216   111000     62215     61394     65377     63805    53291 
  731. progc   39611    17919     19143     15399     17064     14164    14143 
  732. progl   71646    24358     27148     18760     23512     17255    17064 
  733. progp   49379    16801     19209     12792     16617     11877    11686 
  734. trans   93695    30292     38240     28092     31300     23135    22861 
  735.     3,141,622  1,400,105 1,259,141 1,200,580 1,159,340 1,141,821 1,109,290
  736. real             0m35s     0m59s     5m03s     2m40s              5m27s
  737. user             0m25s     0m29s     4m29s     1m46s              4m58s
  738. sys              0m05s     0m10s     0m07s     0m18s              0m08s
  739. MSDOS:                                                   1m39s
  740.                         
  741.  
  742.          zoo       lha       arj      pkzip    zip      hpack   comp-2    ha
  743.         2.10    1.0(Unix)   2.30      2.04g    1.9      0.75a            0.98
  744.          ah    2.13(MSDOS)   -jm       -ex      -6                        a2
  745.        ------    ------    ------    ------  -------   ------   ------  ------
  746. bib     40742     40740     36090    35126    34950    35619    29840   26927
  747. book1  339076    339074    318382   312490   312619   306876   237380  235733
  748. book2  228444    228442    210521   206513   206306   208486   174085  163535
  749. geo     68576     68574     69209    68706    68418    58976    64590   59356
  750. news   155086    155084    146855   144545   144395   141608   128047  123335
  751. obj1    10312     10310     10333    10306    10295    10572    10819    9799
  752. obj2    84983     84981     82052    81132    81336    80806    85465   80381
  753. paper1  19678     19676     18710    18531    18525    18607    16895   15675
  754. paper2  32098     32096     30034    29568    29674    29825    25453   23956
  755. pic     52223     52221     53578    52409    55051    51778    55461   51639
  756. progc   13943     13941     13408    13341    13238    13475    12896   11795
  757. progl   16916     16914     16408    16122    16175    16586    17354   15298
  758. progp   11509     11507     11308    11200    11182    11647    11668   10498
  759. trans   22580     22578     20046    19462    18879    20506    21023   17927
  760.     1,096,166 1,096,138 1,036,934 1,019,451 1,021,043 1,005,367 890,976 845,854
  761. real    4m07s     6m03s                        1m49s   1h22m17s  27m05s
  762. user    3m47s     4m23s                        1m43s   1h20m46s  19m27s
  763. sys     0m04s     0m08s                        0m02s      0m12s   2m03s
  764. MSDOS:            1m49s     2m41s     1m43s                              14m43s
  765.  
  766. Notes:
  767.  
  768. - the compressed data for 'zoo ah' is always two bytes longer than for
  769.   lha. This is simply because both programs are derived from the same
  770.   source (ar002, written by Haruhiko Okumura, available by ftp in
  771.   ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/ar002.zip).
  772.  
  773. - hpack 0.75a gives slightly different results on SunOS. (To be checked
  774.   with latest version of hpack).
  775.  
  776. - the MSDOS versions are all optimized with assembler code and were run
  777.   on a RAM disk. So it is not surprising that they often go faster than
  778.   their Unix equivalent.
  779.  
  780. ------------------------------------------------------------------------------
  781.  
  782. Subject: [7] Which books should I read?
  783.  
  784.  
  785. [BWC 1989] Bell, T.C, Cleary, J.G. and Witten, I.H, "Text Compression",
  786.     Prentice-Hall 1989. ISBN: 0-13-911991-4. Price: approx. US$60
  787.     The reference on text data compression.
  788.  
  789. [Nel 1996] Mark Nelson & Jean-loup Gailly, "The Data Compression Book",
  790.     2nd edition. M&T Books, New York, NY 1996. ISBN 1-55851-434-1
  791.     541 pages. List price in the US is $39.95 including one PC-compatible
  792.     disk bearing all the source code printed in the book.
  793.     A practical introduction to data compression.
  794.     The book is targeted at a person who is comfortable reading C code but
  795.     doesn't know anything about data compression.  Its stated goal is to get
  796.     you up to the point where you are competent to program standard
  797.     compression algorithms.
  798.  
  799. [Will 1990] Williams, R.  "Adaptive Data Compression", Kluwer Books, 1990.
  800.     ISBN: 0-7923-9085-7. Price: US$75.
  801.     Reviews the field of text data compression and then addresses the
  802.     problem of compressing rapidly changing data streams.
  803.  
  804. [Stor 1988] Storer, J.A.  "Data Compression: Methods and Theory", Computer
  805.     Science Press, Rockville, MD. ISBN: 0-88175-161-8.
  806.     A survey of various compression techniques, mainly statistical
  807.     non-arithmetic compression and LZSS compression.  Includes complete Pascal
  808.     code for a series of LZ78 variants.
  809.  
  810. [Stor 1992] Storer, J.A. "Image and Text Compression", Kluwer Academic
  811.     Publishers, 1992, ISBN 0-7923-9243-4
  812.  
  813. [Say 1996] Sayood, Khalid. "Introduction to Data Compression",
  814.   San Francisco:  Morgan Kaufmann Publishers, 1996. ISBN 1-55860-346-8;
  815.   US&Canada $64.95. More info in http://www.mkp.com/pages/3468/index.html
  816.   The book covers both lossy and lossless compression techniques and their
  817.   applications to image, speech, text, audio, and video compression.
  818.  
  819. [BK 95] Bhaskaran V. and Konstantinides K., "Image and Video Compression
  820.     Standards: Algorithms and Architectures", Kluwer Academic Publishers, 1995.
  821.     ISBN 0-7923-9591-3
  822.  
  823. [ACG 1991] Advances in Speech Coding, edited by Atal, Cuperman, and Gersho,
  824.     Kluwer Academic Press, 1991.
  825.  
  826. [GG 1991] Vector Quantization and Signal Compression, by Gersho and Gray,
  827.     Kluwer Acad. Press, 1991, ISBN 0-7923-9181-0.
  828.  
  829. [CT 1991] Elements of Information Theory, by T.M.Cover and J.A.Thomas
  830.      John Wiley & Sons, 1991. ISBN 0-471-06259-6.
  831.  
  832. Review papers:
  833.  
  834. [BWC 1989] Bell, T.C, Witten, I.H, and Cleary, J.G.  "Modeling for Text
  835.     Compression", ACM Computing Surveys, Vol.21, No.4 (December 1989), p.557
  836.     A good general overview of compression techniques (as well as modeling for
  837.     text compression); the condensed version of "Text Compression".
  838.  
  839. [Lele 1987] Lelewer, D.A, and Hirschberg, D.S.  "Data Compression", ACM
  840.     Computing Surveys, Vol.19, No.3 (September 1987), p.261.
  841.     A survey of data compression techniques which concentrates on Huffman
  842.     compression and makes only passing mention of other techniques.
  843.  
  844.  
  845. ------------------------------------------------------------------------------
  846.  
  847. Subject: [8] What about patents on data compression algorithms?
  848.  
  849.  
  850. [Note: the appropriate group for discussing software patents is
  851. comp.patents or misc.legal.computing, not comp.compression.]
  852.  
  853. Only a very small subset of all patents on data compression are mentioned
  854. here; there are several hundred patents on lossless data compression alone.
  855. All patents mentioned here are US patents, and thus probably not applicable
  856. outside the US.  The abstracts and claims of all recent US patents can be
  857. obtained from http://patent.womplex.ibm.com/
  858. See item 70, "Introduction to data compression" for the
  859. meaning of LZ77, LZ78 or LZW.
  860.  
  861.  
  862. (a) Run length encoding
  863.  
  864. - Tsukiyama has two patents on run length encoding: 4,586,027 and 4,872,009
  865.   granted in 1986 and 1989 respectively. The first one covers run length
  866.   encoding in its most primitive form: a length byte followed by the
  867.   repeated byte. The second patent covers the 'invention' of limiting the
  868.   run length to 16 bytes and thus the encoding of the length on 4 bits.
  869.   Here is the start of claim 1 of patent 4,872,009, just for pleasure:
  870.  
  871.     1. A method of transforming an input data string comprising a plurality
  872.     of data bytes, said plurality including portions of a plurality of
  873.     consecutive data bytes identical to one another, wherein said data
  874.     bytes may be of a plurality of types, each type representing different
  875.     information, said method comprising the steps of: [...]
  876.  
  877. - O'Brien has patented (4,988,998) run length encoding followed by LZ77.
  878.  
  879.  
  880. (b) LZ77
  881.  
  882. - Waterworth patented (4,701,745) the algorithm now known as LZRW1,
  883.   because Ross Williams reinvented it later and posted it on
  884.   comp.compression on April 22, 1991. (See item 5 for the ftp site
  885.   with all LZRW derivatives.) The *same* algorithm has later been
  886.   patented by Gibson & Graybill (see below). The patent office failed
  887.   to recognize that the same algorithm was patented twice, even though
  888.   the wording used in the two patents is very similar.
  889.  
  890.   The Waterworth patent is now owned by Stac Inc, which won a lawsuit
  891.   against Microsoft, concerning the compression feature of MSDOS 6.0.
  892.   Damages awarded were $120 million. (Microsoft and Stac later
  893.   settled out of court.)
  894.  
  895. - Fiala and Greene obtained in 1990 a patent (4,906,991) on all
  896.   implementations of LZ77 using a tree data structure. Claim 1 of the
  897.   patent is much broader than the algorithms published by Fiala and
  898.   Greene in Comm.ACM, April 89. The patent covers the algorithm
  899.   published by Rodeh and Pratt in 1981 (J. of the ACM, vol 28, no 1,
  900.   pp 16-24).  It also covers the algorithms used in lharc, lha and zoo.
  901.  
  902. - Notenboom (from Microsoft) 4,955,066 uses three levels of
  903.   compression, starting with run length encoding.
  904.  
  905. - The Gibson & Graybill patent 5,049,881 covers the LZRW1 algorithm
  906.   previously patented by Waterworth and reinvented by Ross Williams.
  907.   Claims 4 and 12 are very general and could be interpreted as
  908.   applying to any LZ algorithm using hashing (including all variants
  909.   of LZ78):
  910.  
  911.      4. A compression method for compressing a stream of input data into
  912.      a compressed stream of output data based on a minimum number of
  913.      characters in each input data string to be compressed, said
  914.      compression method comprising the creation of a hash table, hashing
  915.      each occurrence of a string of input data and subsequently searching
  916.      for identical strings of input data and if such an identical string
  917.      of input data is located whose string size is at least equal to the
  918.      minimum compression size selected, compressing the second and all
  919.      subsequent occurrences of such identical string of data, if a string
  920.      of data is located which does not match to a previously compressed
  921.      string of data, storing such data as uncompressed data, and for each
  922.      input strings after each hash is used to find a possible previous
  923.      match location of the string, the location of the string is stored
  924.      in the hash table, thereby using the previously processed data to
  925.      act as a compression dictionary.
  926.  
  927.   Claim 12 is identical, with 'method' replaced with 'apparatus'.  Since
  928.   the 'minimal compression size' can be as small as 2, the claim could
  929.   cover any dictionary technique of the LZ family. However the text of the
  930.   patent and the other claims make clear that the patent should cover the
  931.   LZRW1 algorithm only. (In any case the Gibson & Graybill patent is likely
  932.   to be invalid because of the prior art in the Waterworth patent.)
  933.  
  934. - Phil Katz, author of pkzip, also has a patent on LZ77 (5,051,745)
  935.   but the claims only apply to sorted hash tables, and when the hash
  936.   table is substantially smaller than the window size.
  937.  
  938. - IBM patented (5,001,478) the idea of combining a history buffer (the
  939.   LZ77 technique) and a lexicon (as in LZ78).
  940.  
  941. - Stac Inc patented (5,016,009 and 5,126,739) yet another variation of LZ77
  942.   with hashing. The '009 patent was used in the lawsuit against Microsoft
  943.   (see above). Stac also has a patent on LZ77 with parallel lookup in
  944.   hardware (5,003,307).
  945.  
  946. - Robert Jung, author of 'arj', has been granted patent 5,140,321
  947.   for one variation of LZ77 with hashing.  This patent covers the LZRW3-A
  948.   algorithm, also previously discovered by Ross Williams. LZRW3-A was posted
  949.   on comp.compression on July 15, 1991. The patent was filed two months later
  950.   on Sept 4, 1991. (The US patent system allows this because of the
  951.   'invention date' rule.)
  952.  
  953. - Chambers 5,155,484 is yet another variation of LZ77 with hashing.
  954.   The hash function is just the juxtaposition of two input bytes,
  955.   this is the 'invention' being patented. The hash table is named
  956.   'direct lookup table'.
  957.  
  958.  
  959. (c) LZ78
  960.  
  961. - One form of the original LZ78 algorithm was patented (4,464,650) by
  962.   its authors Lempel, Ziv, Cohn and Eastman. This patent is owned
  963.   by Unisys.
  964.  
  965.  
  966. - The LZW algorithm used in 'compress' is patented by IBM (4,814,746)
  967.   and Unisys (4,558,302). It is also used in the V.42bis compression
  968.   standard (see question 11 on V.42bis below), in Postscript Level 2, in
  969.   GIF and TIFF.  Unisys sells the license to modem manufacturers for a
  970.   onetime fee (contact: Welch Patent Desk, Unisys Corp., P.O. Box 500,
  971.   Bluebell, PA 19424 Mailcode C SW 19). CompuServe is licensing the
  972.   usage of LZW in GIF products for 1.5% of the product price, of which
  973.   1% goes to Unisys; usage of LZW in non-GIF products must be licensed
  974.   directly from Unisys. For more information, see http://www.unisys.com/
  975.   or email to lzw_info@unisys.com.
  976.  
  977.      The IBM patent application was first filed three weeks before that of
  978.   Unisys, but the US patent office failed to recognize that they
  979.   covered the same algorithm. (The IBM patent is more general, but its
  980.   claim 7 is exactly LZW.)
  981.  
  982. - Klaus Holtz also claims that patent 4,366,551 for his "autosophy"
  983.   data compression method covers LZ78 and LZW. According to Holtz, most of
  984.   the largest V.42bis modem manufacturers have paid for patent licenses.
  985.  
  986. - AP coding is patented by Storer (4,876,541). (Get the yabba package
  987.   for source code, see question 2 above, file type .Y) Storer also
  988.   claims that his patent covers V.42bis.
  989.  
  990.  
  991. (d) arithmetic coding
  992.  
  993. - IBM holds many patents on arithmetic coding (4,122,440 4,286,256 4,295,125
  994.   4,463,342 4,467,317 4,633,490 4,652,856 4,792,954 4,891,643 4,901,363
  995.   4,905,297 4,933,883 4,935,882 5,045,852 5,099,440 5,142,283 5,210,536
  996.   5,414,423 5,546,080). It has patented in particular the Q-coder
  997.   implementation of arithmetic coding.  The JBIG standard, and the arithmetic
  998.   coding option of the JPEG standard requires use of the patented algorithm.
  999.   No JPEG-compatible method is possible without infringing the patent, because
  1000.   what IBM actually claims rights to is the underlying probability model (the
  1001.   heart of an arithmetic coder). (See item 75 for details.)
  1002.  
  1003.   See also below details on many other patents on arithmetic coding (4,973,961
  1004.   4,989,000 5,023,611 5,025,258 5,272,478 5,307,062 5,309,381 5,311,177
  1005.   5,363,099 5,404,140 5,406,282 5,418,532). The list is not exhaustive.
  1006.  
  1007.  
  1008. (e) predictor
  1009.  
  1010. - The 'predictor' algorithm was first described in the paper
  1011.  
  1012.     Raita, T. and Teuhola, J. (1987), "Predictive text compression by hashing",
  1013.     ACM Conference on Information Retrieval
  1014.  
  1015.   This algorithm has been patented (5,229,768) by K. Thomas in 1993. It
  1016.   is used in the Internet Draft "PPP Predictor Compression Protocol" (see
  1017.   ftp://venera.isi.edu/internet-drafts/draft-ietf-pppext-predictor-00.txt).
  1018.  
  1019. (f) compression of random data
  1020.  
  1021. - The US patent office no longer grants patents on perpetual motion machines,
  1022.   but has recently granted a patent on a mathematically impossible process
  1023.   (compression of truly random data): 5,533,051 "Method for Data Compression".
  1024.   See item 9.5 of this FAQ for details.
  1025.  
  1026.  
  1027. As can be seen from the above list, some of the most popular compression
  1028. programs (compress, pkzip, zoo, lha, arj) are now covered by patents.
  1029. (This says nothing about the validity of these patents.)
  1030.  
  1031. Here are some references on data compression patents. Some of them are
  1032. taken from the list ftp://prep.ai.mit.edu/pub/lpf/patent-list.
  1033.  
  1034. 3,914,586
  1035. Data compression method and apparatus
  1036. filed 10/25/73, granted 10/21/75
  1037. General Motors Corporation, Detroit MI
  1038. Duane E. McIntosh, Santa Ynez CA
  1039. Data compression apparatus is disclosed is operable in either a bit
  1040. pair coding mode of a word coding mode depending on the degree of
  1041. redundancy of the data to be encoded.
  1042.  
  1043. 3,976,844
  1044. Data communication system for transmitting data in compressed form
  1045. filed Apr. 4, 1975, granted Aug. 24, 1976
  1046. inventor  Bernard K. Betz, assignee Honeywell Information Systems, Inc.
  1047. [encode differences with previous line]
  1048.  
  1049. 4,021,782
  1050. Data compaction system and apparatus
  1051. inventor Hoerning
  1052. filed 04/30/1975, granted 05/03/1977
  1053. [A primitive form of LZ77 with implicit offsets (compare with previous record)]
  1054.  
  1055. 4,054,951
  1056. Data expansion apparatus
  1057. inventor R.D. Jackson, assignee IBM
  1058. filed Jun. 30, 1976, granted Oct. 18, 1977
  1059. [Covers only decompression of data compressed with a variant of LZ77.]
  1060.  
  1061. 4,087,788
  1062. Data compression system
  1063. filed 1/14/77, granted 5/2/78
  1064. NCR Canada LTD - NCR Canada Ltee, Mississauga CA
  1065. Brian J. Johannesson, Waterloo CA
  1066. A data compression system is disclosed in which the left hand boundary
  1067. of a character is developed in the form of a sequence of Freeman
  1068. direction codes, the codes being stored in digital form within a
  1069. processor.
  1070.  
  1071. 4,122,440
  1072. Method and means for arithmetic string coding
  1073. assignee IBM
  1074. filed 1977/03/04, granted 1978/10/24
  1075. [This is the basic idea of arithmetic coding. Note that the patent is
  1076. expired now.]
  1077.  
  1078. 4,286,256
  1079. Method and means for arithmetic coding using a reduced number of operations.
  1080. granted Aug 25, 1981
  1081. assignee IBM
  1082.  
  1083. 4,295,125
  1084. A method and means for pipeline decoding of the high to low order pairwise
  1085. combined digits of a decodable set of relatively shifted finite number of
  1086. strings
  1087. granted Oct 13, 1981
  1088. assignee IBM
  1089.  
  1090. 4,366,551
  1091. Associative Memory Search System
  1092. filed June 16, 1975, granted Dec. 28, 1982.
  1093. inventor Klaus Holtz, assignee Omni Dimensional Networks.
  1094.  
  1095. 4,412,306
  1096. System for minimizing space requirements for storage and transmission of
  1097. digital signals
  1098. filed May 14, 1981, granted Oct. 25, 1983
  1099. inventor  Edward W. Moll
  1100.  
  1101. 4,463,342
  1102. A method and means for carry-over control in a high order to low order
  1103. combining of digits of a decodable set of relatively shifted finite number
  1104. strings.
  1105. granted Jul 31, 1984
  1106. assignee IBM
  1107.  
  1108. 4,491,934
  1109. Data compression process
  1110. filed May 12, 1982, granted Jan. 1, 1985
  1111. inventor  Karl E. Heinz
  1112.  
  1113. 4,464,650
  1114. Apparatus and method for compressing data signals and restoring the
  1115. compressed data signals
  1116. inventors Lempel, Ziv, Cohn, Eastman
  1117. assignee Sperry Corporation (now Unisys)
  1118. filed 8/10/81, granted 8/7/84
  1119. A compressor parses the input data stream into segments where each
  1120. segment comprises a prefix and the next symbol in the data stream
  1121. following the prefix. [This is the original LZ78 algorithm.]
  1122.  
  1123. 4,467,317
  1124. High-speed arithmetic compression using using concurrent value updating.
  1125. granted Aug 21, 1984
  1126. assignee IBM
  1127.  
  1128. 4,494,108
  1129. Adaptive source modeling for data file compression within bounded memory
  1130. filed Jun. 5, 1984, granted Jan. 15, 1985
  1131. invntors Glen G. Langdon, Jorma J. Rissanen
  1132. assignee IBM
  1133. order 1 Markov modeling
  1134.  
  1135. 4,558,302
  1136. High speed data compression and decompression apparatus and method
  1137. inventor Welch
  1138. assignee Sperry Corporation (now Unisys)
  1139. filed 6/20/83, granted 12/10/85
  1140. re-examined: filed 12/14/92, granted 4/1/94.
  1141. The text of the original 1985 patent can be ftped from
  1142. ftp://ftp.uni-stuttgart.de/pub/doc/comp-patents/US4558302.Z
  1143. There is also a European Patent 0,129,439  1/2/89 for DE, FR, GB, IT
  1144. and patent pending for Japan.
  1145.  
  1146. 4,560,976
  1147. Data compression
  1148. filed 6/5/84, granted 12/24/85
  1149. Codex Corporation, Mansfield MA
  1150. Steven G. Finn, Framingham, MA
  1151. A stream of source characters, which occur with varying relative
  1152. frequencies, is encoded into a compressed stream of codewords, each
  1153. having one, two or three subwords, by ranking the source characters by
  1154. their current frequency of appearance, encoding the source characters
  1155. having ranks no higher than a first number as one subword codewords,
  1156. source characters having ranks higher than the first number but no
  1157. higher than a second number as two subword codewords, and the
  1158. remaining source characters as three subword codewords.
  1159.  
  1160. 4,586,027
  1161. Method and system for data compression and restoration
  1162. inventor Tsukimaya et al.
  1163. assignee Hitachi
  1164. filed 08/07/84, granted 04/29/86
  1165. patents run length encoding
  1166.  
  1167. 4,597,057
  1168. System for compressed storate of 8-bit ascii bytes using coded strings
  1169. of 4-bit nibbles.
  1170. inventor Snow, assignee System Development corporation.
  1171. filed 12/31/1981, granted 06/24/1986.
  1172. Compression using static dictionary of common words, prefixes and suffixes.
  1173.  
  1174. 4,612,532
  1175. Data compression apparatus and method
  1176. inventor Bacon, assignee Telebyte Corportion
  1177. filed Jun. 19, 1984, granted Sep. 16, 1986
  1178. [Uses followsets as in the pkzip 0.92 'reduce' algorithm, but the
  1179. followsets are dynamically updated. This is in effect a sort of order-1
  1180. Markov modeling.]
  1181.  
  1182. 4,622,545
  1183. Method and apparatus for image compression and Manipulation
  1184. inventor William D. Atkinson
  1185. assignee Apple computer Inc.
  1186. filed 9/30/82
  1187. granted 11/11/86
  1188.  
  1189. 4,633,490
  1190. Symmetrical adaptive data compression/decompression system.
  1191. granted Dec 30, 1985
  1192. assignee IBM
  1193.  
  1194. 4,652,856
  1195. A multiplication-free multi-alphabet arithmetic code.
  1196. granted Feb  4, 1986
  1197. assignee IBM
  1198.  
  1199. 4,667,649
  1200. Data receiving apparatus
  1201. filed 4/18/84, granted 6/30/87
  1202. inventors Kunishi et al.
  1203. assignee Canon Kabushiki Kaisha, Tokyo Japan
  1204. compression of Fax images.
  1205.  
  1206. 4,682,150
  1207. Data compression method and apparatus
  1208. inventors Mathes and Protheroe, 
  1209. assignee NCR Corporation, Dayton OH
  1210. A system and apparatus for compressing redundant and nonredundant
  1211. binary data generated as part of an operation of a time and attendance
  1212. terminal in which the data represents the time an employee is present
  1213. during working hours.
  1214.  
  1215. 4,701,745
  1216. Data compression system
  1217. inventor Waterworth John R
  1218. assignee Ferranti PLC GB, patent rights now acquired by Stac Inc.
  1219. filed 03/03/1986 (03/06/1985 in GB), granted 10/20/1987
  1220. Algorithm now known as LZRW1 (see above)
  1221. I claim:
  1222. 1. A data compression system comprising an input store for receiving
  1223. and storing a plurality of bytes of uncompressed data from an outside
  1224. source, and data processing means for processing successive bytes of
  1225. data from the input store;
  1226. the data processing means including circuit means operable to check
  1227. whether a sequence of successive bytes to be processed identical with
  1228. a sequence of bytes already processed, and including hash generating
  1229. means responsive to the application of a predetermined number of
  1230. bytes in sequence to derive a hash code appropriate to those bytes, a
  1231. temporary store in which the hash code may represent the address of a
  1232. storage location, and a pointer counter operable to store in the
  1233. temporary store at said address a pointer indicative of the position
  1234. in the input store of one of the predetermined number of bytes;
  1235. output means operable to apply to a transfer medium each byte of data
  1236. not forming part of such an identical sequence; and
  1237. encoding means responsive to the identification of such a sequence to
  1238. apply to the transfer medium an identification signal which identifies
  1239. both the location in the input store of the previous occurrence of the
  1240. sequence of bytes and the number of bytes contained in the sequence.
  1241.  
  1242. 4,730,348
  1243. Adaptive data compression system
  1244. inventor MacCrisken, assignee Adaptive Computer Technologies
  1245. filed Sep. 19, 1986, granted Mar. 8, 1988
  1246. [order-1 Markov modeling + Huffman coding + LZ77]
  1247.  
  1248. 4,758,899
  1249. Data compression control device
  1250. inventor Tsukiyama, assignee Hitachi
  1251. filed 11/20/1985, granted 07/19/1988
  1252. Limits compression to ensure that tape drive stays busy.
  1253.  
  1254. 4,792,954
  1255. Concurrent detection of errors in arithmetic data compression coding
  1256. assignee IBM
  1257. filed 1986/10/31, granted 1988/12/20
  1258.  
  1259. 4,809,350
  1260. Data compression system
  1261. filed Jan. 30, 1987, granted Feb. 28, 1989
  1262. inventor Yair Shimoni & Ron Niv
  1263. assignee Elscint Ltd., Haifa, Israel
  1264. [Image compression via variable length encoding of differences with
  1265. predicted data.]
  1266.  
  1267. 4,814,746
  1268. Data compression method
  1269. inventors Victor S. Miller, Mark N. Wegman
  1270. assignee IBM
  1271. filed 8/11/86, granted 3/21/89
  1272. A previous application was filed on 6/1/83, three weeks before the
  1273. application by Welch (4,558,302)
  1274. Communications between a Host Computing System and a number of remote
  1275. terminals is enhanced by a data compression method which modifies the
  1276. data compression method of Lempel and Ziv by addition of new character
  1277. and new string extensions to improve the compression ratio, and
  1278. deletion of a least recently used routine to limit the encoding tables
  1279. to a fixed size to significantly improve data transmission efficiency.
  1280.  
  1281. 4,841,092
  1282. continued in 5,003,307
  1283.  
  1284. 4,853,696
  1285. Code converter for data compression/decompression
  1286. filed 4/13/87, granted 8/1/89
  1287. inventor Amar Mukherjee, Maitland FL
  1288. assignee University of Central Florida, Orlando FL
  1289. Another hardware Huffman encoder:
  1290. A code converter has a network of logic circuits connected in reverse
  1291. binary tree fashion with logic paths between leaf nodes and a common
  1292. root node.
  1293.  
  1294. 4,872,009
  1295. Method and apparatus for data compression and restoration
  1296. inventor Tsukimaya et al.
  1297. assignee Hitachi
  1298. filed 12/07/87, granted 10/03/89
  1299. This patent on run length encoding covers the 'invention' of limiting
  1300. the run length to 16 bytes and thus the encoding of the length on 4 bits.
  1301.  
  1302. 4,876,541
  1303. Stem [sic] for dynamically compressing and decompressing electronic data
  1304. filed 10/15/87, granted 10/24/89
  1305. inventor James A. Storer
  1306. assignee Data Compression Corporation
  1307. A data compression system for encoding and decoding textual data,
  1308. including an encoder for encoding the data and for a decoder for
  1309. decoding the encoded data.
  1310.  
  1311. 4,891,643
  1312. Arithmetic coding data compression/de-compression by selectively
  1313. employed, diverse arithmetic encoders and decoders.
  1314. file 1986/09/15, granted 1990/01/02
  1315. assignee IBM
  1316.  
  1317. 4,901,363
  1318. System for compressing bi-level data
  1319. assignee IBM
  1320. [arithmetic coding]
  1321.  
  1322. 4,905,297
  1323. Arithmetic coding encoder and decoder system.
  1324. granted Feb 27, 1990
  1325. assignee IBM
  1326.  
  1327. 4,906,991
  1328. Textual substitution data compression with finite length search window
  1329. filed 4/29/1988, granted 3/6/1990
  1330. inventors Fiala,E.R., and Greene,D.H.
  1331. assignee Xerox Corporation
  1332.  
  1333. 4,933,883
  1334. Probability adaptation for arithmetic coders.
  1335. granted Jun 12, 1990
  1336. assignee IBM
  1337.  
  1338. 4,935,882
  1339. Probability adaptation for arithmetic coders.
  1340. granted Jun 19, 1990
  1341. assignee IBM
  1342.  
  1343. 4,941,193
  1344. Barnsley, fractal compression.
  1345.  
  1346. 4,943,869
  1347. Compression Method for Dot Image Data
  1348. filed 1988-05-04, granted 1990-07-24
  1349. assignee Fuji Photo Film Co.
  1350. Lossy and lossless image compression schemes.
  1351.  
  1352. 4,955,066
  1353. Compressing and Decompressing Text Files
  1354. filed  10/13/89, granted 09/04/90
  1355. inventor Notenboom, L.A.
  1356. assignee Microsoft
  1357. Now extended as 5,109,433
  1358. [Noted in signon screen of Word 5.5 and on the outside of the MS-DOS 5.0
  1359. Upgrade.]
  1360. A method of compressing a text file in digital form is disclosed.
  1361. A full text file having characters formed into phrases is provided by an
  1362. author.  The characters are digitally represented by bytes.  A first pass
  1363. compression is sequentially followed by a second pass compression of the
  1364. text which has previously been compressed.  A third or fourth level of
  1365. compression is serially performed on the compressed text.  For example, in
  1366. a first pass, the text is run-length compressed.  In a second pass, the
  1367. compressed text is further compressed with key phrase compression.  In a
  1368. third pass, the compressed text is further compressed with Huffman
  1369. compression.  The compressed text is stored in a text file having a Huffman
  1370. decode tree, a key phrase table, and a topic index.  The data is
  1371. decompressed in a single pass and provided one line at a time as an output.
  1372. Sequential compressing of the text minimizes the storage space required for
  1373. the file.  Decompressing of the text is performed in a single pass.  As a
  1374. complete line is decompressed, it is output rapidly, providing full text to
  1375. the user.
  1376.  
  1377. 4,973,961
  1378. Method and apparatus for carry-over control in arithmetic coding.
  1379. granted Nov 27, 1990
  1380. assignee AT&T
  1381.  
  1382. 4,988,998
  1383. Data compression system for successively applying at least two data
  1384. compression methods to an input data stream.
  1385. inventor O'Brien
  1386. assignee Storage Technology Corporation, Louisville, Colorado
  1387. filed Sep 5, 1989, granted Jan 29, 1991.
  1388. Run length encoding followed by LZ77.
  1389.  
  1390. 4,989,000
  1391. Data string compression using arithmetic encoding with simplified probability
  1392. subinterval estimation
  1393. filed 1989/06/19, granted 1991/01/29]
  1394. [shift & add instead of multiply]
  1395.  
  1396. 5,001,478
  1397. Method of Encoding Compressed Data
  1398. filed 12/28/89, granted 03/19/91
  1399. inventor Michael E. Nagy
  1400. assignee IBM
  1401. 1. A method of encoding a compressed data stream made up of a sequence of
  1402. literal references, lexicon references and history references, which
  1403. comprises the steps of:
  1404. assigning to each literal reference a literal identifier;
  1405. assigning to each history reference a history identifier;
  1406. assigning to each lexicon reference a lexicon identifier;
  1407. and emitting a data stream with said identifiers assigned to said references.
  1408. Gordon Irlam <gordoni@cs.adelaide.edu.au> says:
  1409. The invention can probably be best understood by considering the
  1410. decompressor.  It consists of a history buffer, and a lexicon buffer, both
  1411. of which are initially empty.  The history buffer contains the last n
  1412. symbols emitted.  Whenever a history buffer reference is to be output the
  1413. string so referenced is subsequently moved to the lexicon buffer for future
  1414. reference.  Thus the history buffer keeps track of strings that may be
  1415. repeated on a very short term basis, while the lexicon buffer stores items
  1416. for a longer time.  Furthermore a history reference involves specifying
  1417. both the offset and length within the history buffer, whereas a lexicon
  1418. reference simply specifies a number denoting the string.  Both buffers have
  1419. a finite size.
  1420.  
  1421. 5,003,307
  1422. Data compression apparatus with shift register search means
  1423. filed Oct. 6, 1989, granted Mar. 26, 1991
  1424. inventors George Glen A, Ivey Glen E, Whiting Douglas L
  1425. assignee Stac Inc
  1426. continuation of 4,841,092
  1427.  
  1428. 5,016,009
  1429. Data compression apparatus and method
  1430. filed 01/13/1989, granted 05/14/1991
  1431. inventors George Glen A, Ivey Glen E, Whiting Douglas L
  1432. assignee Stac Inc
  1433. LZ77 with offset hash table (extended in 5,126,739)
  1434.  
  1435. 5,023,611
  1436. Entropy encoder/decoder including a context extractor.
  1437. granted Jun 11, 1991
  1438. assignee AT&T
  1439.  
  1440. 5,025,258
  1441. Adaptive probability estimator for entropy encoder/decoder.
  1442. granted Jun 18, 1991
  1443. assignee AT&T
  1444.  
  1445. 5,045,852
  1446. Dynamic model selection during data compression
  1447. assignee IBM
  1448. [arithmetic coding]
  1449.  
  1450. 5,049,881
  1451. Apparatus and method for very high data rate-compression incorporating
  1452. lossless data compression and expansion utilizing a hashing technique
  1453. inventors Dean K. Gibson, Mark D. Graybill
  1454. assignee Intersecting Concepts, Inc.
  1455. filed 6/18/90, granted 9/17/91
  1456. [covers lzrw1, almost identical with Waterworth 4,701,745]
  1457.  
  1458. 5,051,745
  1459. String searcher, and compressor using same
  1460. filed  8/21/90, granted 9/24/91
  1461. inventor  Phillip W. Katz (author of pkzip)
  1462. In the string search method and apparatus pointers to the string to be
  1463. searched are indexed via a hashing function and organized according to the
  1464. hashing values of the string elements pointed to. The hashing function is
  1465. also run on the string desired to be found, and the resulting hashing value
  1466. is used to access the index. If the resulting hashing value is not in the
  1467. index, it is known that the target string does not appear in the string
  1468. being searched. Otherwise the index is used to determine the pointers which
  1469. correspond to the target hashing value, these pointers pointing to likely
  1470. candidates for matching the target string. The pointers are then used to
  1471. sequentially compare each of the locations in the string being searched to
  1472. the target string, to determine whether each location contains a match to
  1473. the target string.
  1474. In the method and apparatus for compressing a stream of data symbols, a
  1475. fixed length search window, comprising a predetermined contiguous portion
  1476. of the symbol stream, is selected as the string to be searched by the
  1477. string searcher. If a string to be compressed is found in the symbol
  1478. stream, a code is output designating the location within the search window
  1479. of the matching string and the length of the matching string.
  1480.  
  1481. 5,065,447 (continued in 5,347,600)
  1482. Method and apparatus for processing digital data
  1483. filed Jul. 5, 1989, granted Nov. 12, 1991
  1484. inventors Michael F. Barnsley and Alan D. Sloan
  1485. [Patents image compression with the "Fractal Transform"]
  1486.  
  1487. 5,099,440
  1488. Probability adaptation for arithmetic coders
  1489.  
  1490. 5,109,433
  1491. Compressing and decompressing text files
  1492. inventor Notenboom
  1493. assignee Microsoft
  1494. extension of 4,955,066
  1495.  
  1496. 5,126,739
  1497. Data Compression Apparatus and Method
  1498. filed Nov. 27, 1990, granted June 30, 1992.
  1499. inventor Whiting et. al
  1500. assignee Stac Inc
  1501. LZ77 with offset hash table (extension of 5,016,009)
  1502.  
  1503. 5,140,321
  1504. Data compression/decompression method and apparatus
  1505. filed 9/4/91, granted 8/18/92
  1506. inventor Robert Jung
  1507. assignee Prime Computer
  1508.  
  1509. 5,142,283
  1510. Arithmetic compression coding using interpolation for ambiguous symbols
  1511. filed 1990/07/10, granted 1992/08/25
  1512. assignee IBM
  1513.  
  1514. 5,155,484
  1515. Fast data compressor with direct lookup table indexing into history buffer
  1516. filed 9/13/1991, granted 10/13/1992
  1517. inventor Chambers, IV, Lloyd L., Menlo Park, California
  1518. assignee Salient Software, Inc., Palo Alto, California (02)
  1519. Uses a 64K hash table indexed by the first two characters of
  1520. the input string. Includes several claims on the LZ77 file format
  1521. (literal or pair offset,length).
  1522.  
  1523. 5,179,378
  1524. file Jul. 30, 1991, granted Jan. 12, 1993
  1525. inventor Ranganathan
  1526. assignee University of South Florida
  1527. Method and apparatus for the compression and decompression of data
  1528. using Lempel-Ziv based techniques.
  1529. [This covers LZ77 hardware compression with a systolic array of
  1530. processors working in parallel.]
  1531.  
  1532. 5,210,536
  1533. Data compression/coding method and device for implementing said method
  1534. assignee IBM
  1535. [PPM + arithmetic coding]
  1536.  
  1537. 5,229,768
  1538. Adaptive data compression system
  1539. granted Jul. 20, 1993
  1540. inventor Kasman E. Thomas
  1541. assignee Traveling Software, Inc. 
  1542.   A system for data compression and decompression is disclosed. A series of
  1543. fixed length overlapping segments, called hash strings, are formed from an
  1544. input data sequence. A retrieved character is the next character in the input
  1545. data sequence after a particular hash string. A hash function relates a
  1546. particular hash string to a unique address in a look-up table (LUT). An
  1547. associated character for the particular hash string is stored in the LUT at
  1548. the address. When a particular hash string is considered, the content of the
  1549. LUT address associated with the hash string is checked to determine whether
  1550. the associated character matches the retrieved character following the hash
  1551. string. If there is a match, a Boolean TRUE is output; if there is no match,
  1552. a Boolean FALSE along with the retrieved character is output. Furthermore, if
  1553. there is no match, then the LUT is updated by replacing the associated
  1554. character in the LUT with the retrieved character. [...]
  1555. [This algorithm is used in the Internet draft
  1556. "PPP Predictor Compression Protocol".]
  1557.  
  1558. 5,272,478
  1559. Method and apparatus for entropy coding
  1560. assignee Ricoh
  1561. [arithmetic coding with finite state machine]
  1562.  
  1563. 5,307,062
  1564. Coding system
  1565. filed 1992/12/15, granted 1994/04/26
  1566. assignee Mitsubishi
  1567. [binary arithmetic coding, see also 5,404,140]
  1568.  
  1569. 5,309,381
  1570. Probability estimation table apparatus
  1571. filed 1992/04/08, granted 1994/05/03
  1572. assignee Ricoh
  1573. [arithmetic coding]
  1574.  
  1575. 5,311,177
  1576. Code transmitting apparatus with limited carry propagation
  1577. filed 1992/06/19, granted 1994/05/10
  1578. assignee Mitsubishi
  1579. [arithmetic coding]
  1580.  
  1581. 5,347,600 (continuation of 5,065,447)
  1582. Method and apparatus for compression and decompression of digital image
  1583. filed 10/23/1991, granted 09/13/1994
  1584. inventors Barnsley and Sloan
  1585.  
  1586. 5,363,099
  1587. Method and apparatus for entropy coding
  1588. [arithmetic coding with state machine]
  1589.  
  1590. 5,384,867 (continued in 5,430,812)
  1591. filed 10/23/1991, granted 01/24/1995
  1592. Fractal transform compression board
  1593. inventors Barnsley et al.
  1594.  
  1595. 5,404,140
  1596. Coding system
  1597. filed 1994/01/13, granted 1995/04/04
  1598. assignee Mitsubishi
  1599. [binary arithmetic coding, see also 5,307,062]
  1600.  
  1601. 5,406,282
  1602. Data coding and decoding with improved efficiency
  1603. assignee Ricoh
  1604. [PPM & arithmedic coding]
  1605.  
  1606. 5,414,423
  1607. Stabilization of probability estimates by conditioning on prior decisions
  1608.   of a given context
  1609. assignee IBM
  1610. arithmetic coding]
  1611.  
  1612. 5,416,856
  1613. Method of encoding a digital image using iterated image transformations
  1614.   to form an eventually contractive map
  1615. filed 1992/03/30, granted 1995/05/16
  1616. inventors Jacobs, Boss and Fisher
  1617.  
  1618. 5,418,532
  1619. Method and system for efficient, multiplication-free arithmetic coding
  1620. filed 1993/05/13, granted 1995/05/23.
  1621. inventors Lei & Shaw-Min
  1622. assignee Bell Communications Research, Inc. (Livingston, NJ). 
  1623.  
  1624. 5,430,812 (continuation of 5,384,867)
  1625. Fractal transform compression board
  1626. filed 1994/05/18, granted 1995/07/04
  1627. inventors Barnsley et al.
  1628.  
  1629. 5,533,051
  1630. Method for Data Compression
  1631. filed 1993/03/12, granted 1996/07/02
  1632. inventor David C. James, assignee The James Group
  1633. This is a patent on compression of random data, see item 9.5 below.
  1634.  
  1635. Japan 2-46275
  1636. Coding system
  1637. granted Feb 26, 1990
  1638. [Patents one form of arithmetic coding.]
  1639.  
  1640.  
  1641. ------------------------------------------------------------------------------
  1642.  
  1643. Subject: [9]  Compression of random data (WEB, Gilbert and others)
  1644.  
  1645.  
  1646. [Note from the FAQ maintainer: this topic has generated and is still generating
  1647. the greatest volume of news in the history of comp.compression. Read this
  1648. before posting on this subject.
  1649.  
  1650. I intended to remove the WEB story from the FAQ, but similar affairs come up
  1651. regularly on comp.compression.  The advertized revolutionary methods have all
  1652. in common their supposed ability to compress random or already compressed data.
  1653. I will keep this item in the FAQ to encourage people to take such claims with
  1654. great precautions.]
  1655.  
  1656.  
  1657. 9.1 Introduction
  1658.  
  1659. It is mathematically impossible to compress without loss truly random data (see
  1660. below and also item 73 in part 2 of this FAQ). Yet from time to time some
  1661. people claim to have invented a new algorithm for doing so. Such algorithms are
  1662. claimed to be applicable recursively, that is, applying the compressor to the
  1663. compressed output of the previous run, possibly multiple times. Fantastic
  1664. compression ratios of over 100:1 on random data are claimed to be actually
  1665. obtained.
  1666.  
  1667. Such claims inevitably generate a lot of activity on comp.compression, which
  1668. can last for several months. The two largest bursts of activity were generated
  1669. by WEB Technologies and by Jules Gilbert. Premier Research Corporation (with a
  1670. compressor called MINC) made only a brief appearance but has recently come back
  1671. with a Web page at http://www.pacminc.com.  The Hyper Space method invented by
  1672. David C. James is a new contender with a patent obtained in July 96.
  1673.  
  1674. Other people have also claimed incredible compression ratios, but the programs
  1675. (OWS, WIC) were quickly shown to be fake (not compressing at all). This topic
  1676. is covered in item 10 of this FAQ.
  1677.  
  1678.  
  1679. 9.2 The counting argument
  1680.  
  1681. The WEB compressor (see details in section 9.3 below) was claimed to compress
  1682. without loss *all* files of greater than 64KB in size to about 1/16th their
  1683. original length. A very simple counting argument shows that this is impossible,
  1684. regardless of the compression method. It is even impossible to guarantee
  1685. lossless compression of all files by at least one bit. (Many other proofs have
  1686. been posted on comp.compression, please do not post yet another one.)
  1687.  
  1688. Assume that the program can compress without loss all files of size >= N bits.
  1689. Compress with this program all the 2^N files which have exactly N bits.  All
  1690. compressed files have at most N-1 bits, so there are at most (2^N)-1 different
  1691. compressed files [2^(N-1) files of size N-1, 2^(N-2) of size N-2, and so on,
  1692. down to 1 file of size 0]. So at least two different input files must compress
  1693. to the same output file. (This is often called the pigeon-hole principle: you
  1694. can't put 16 pigeons into 15 holes without using one of the holes twice.)
  1695. Hence the compression program cannot be lossless.  Much stronger results about
  1696. the number of incompressible files can be obtained, but the proofs are a little
  1697. more complex.  (The MINC Web page http://www.pacminc.com uses one file of
  1698. strictly negative size to obtain 2^N instead of (2^N)-1 distinct files of
  1699. size <= N-1 .)
  1700.  
  1701. This argument applies of course to WEB's case (take N = 64K*8 bits).  Note that
  1702. no assumption is made about the compression algorithm.  The proof applies to
  1703. *any* algorithm, including those using an external dictionary, or repeated
  1704. application of another algorithm, or combination of different algorithms, or
  1705. representation of the data as formulas, etc... All schemes are subject to the
  1706. counting argument.  There is no need to use information theory to provide a
  1707. proof, just basic mathematics. [People interested in more elaborate proofs can
  1708. consult http://wwwvms.utexas.edu/~cbloom/news/nomagic.html ]
  1709.  
  1710. This assumes of course that the information available to the decompressor is
  1711. only the bit sequence of the compressed data. If external information such as a
  1712. file name, a number of iterations, or a bit length is necessary to decompress
  1713. the data, the bits necessary to provide the extra information must be included
  1714. in the bit count of the compressed data.  Otherwise, it would be sufficient to
  1715. consider any input data as a number, use this as the file name, iteration count
  1716. or bit length, and pretend that the compressed size is zero.  For an example of
  1717. storing information in the file name, see the program lmfjyh in the 1993
  1718. International Obfuscated C Code Contest, available on all comp.sources.misc
  1719. archives (Volume 39, Issue 104).
  1720.  
  1721. A common flaw in the algorithms claimed to compress all files is to assume that
  1722. arbitrary bit strings can be sent to the decompressor without actually
  1723. transmitting their bit length. If the decompressor needs such bit lengths
  1724. to decode the data (when the bit strings do not form a prefix code), the
  1725. number of bits needed to encode those lengths must be taken into account
  1726. in the total size of the compressed data.
  1727.  
  1728. Another common (but still incorrect) argument is to assume that for any file,
  1729. some still to be discovered algorithm might find a seed for a pseudo-random
  1730. number generator which would actually generate the whole sequence of bytes
  1731. contained in the file. However this idea still fails to take into account the
  1732. counting argument. For example, if the seed is limited to 64 bits, this
  1733. algorithm can generate at most 2^64 different files, and thus is unable to
  1734. compress *all* files longer than 8 bytes. For more details about this
  1735. "magic function theory", see http://web2.airmail.net/markn/FAQ.html#Q19
  1736.  
  1737. Yet another popular idea is to split the input bit stream into a sequence of
  1738. large numbers, and factorize those numbers. Unfortunately, the number of
  1739. bits required to encode the factors and their exponents is on average
  1740. not smaller than the number of bits of the original bit stream, so this
  1741. scheme too cannot compress random data.
  1742.  
  1743. Steve Tate <srt@cs.unt.edu> suggests a good challenge for programs
  1744. that are claimed to compress random data by a significant amount:
  1745.  
  1746.     Here's a wager for you: First, send me the DEcompression algorithm.  Then I
  1747.     will send you a file of whatever size you want, but at least 100k.  If you
  1748.     can send me back a compressed version that is even 20% shorter (80k if the
  1749.     input is 100k) I'll send you $100.  Of course, the file must be able to be
  1750.     decompressed with the program you previously sent me, and must match
  1751.     exactly my original file.  Now what are you going to provide
  1752.     when... er... if you can't demonstrate your compression in such a way?
  1753.  
  1754. So far no one has accepted this challenge (for good reasons).
  1755.  
  1756.  
  1757. 9.3 The WEB 16:1 compressor
  1758.  
  1759. 9.3.1 What the press says
  1760.  
  1761. April 20, 1992  Byte Week Vol 4. No. 25:
  1762.  
  1763.    "In an announcement that has generated high interest - and more than a
  1764.    bit of skepticism - WEB Technologies (Smyrna, GA) says it has
  1765.    developed a utility that will compress files of greater than 64KB in
  1766.    size to about 1/16th their original length.  Furthermore, WEB says its
  1767.    DataFiles/16 program can shrink files it has already compressed."
  1768.    [...]
  1769.    "A week after our preliminary test, WEB showed us the program successfully
  1770.    compressing a file without losing any data.  But we have not been able
  1771.    to test this latest beta release ourselves."
  1772.    [...]
  1773.    "WEB, in fact, says that virtually any amount of data can be squeezed 
  1774.    to under 1024 bytes by using DataFiles/16 to compress its own output
  1775.    multiple times."
  1776.  
  1777. June 1992 Byte, Vol 17 No 6:
  1778.  
  1779.    [...] According to Earl Bradley, WEB Technologies' vice president of
  1780.    sales and marketing, the compression algorithm used by DataFiles/16
  1781.    is not subject to the laws of information theory. [...]
  1782.       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1783.  
  1784. 9.3.2 First details, by John Wallace <buckeye@spf.trw.com>
  1785.  
  1786. I called WEB at (404)514-8000 and they sent me some product
  1787. literature as well as chatting for a few minutes with me on the phone.
  1788. Their product is called DataFiles/16, and their claims for it are
  1789. roughly those heard on the net.
  1790.  
  1791. According to their flier:
  1792.  
  1793. "DataFiles/16 will compress all types of binary files to approximately
  1794. one-sixteenth of their original size ... regardless of the type of
  1795. file (word processing document, spreadsheet file, image file,
  1796. executable file, etc.), NO DATA WILL BE LOST by DataFiles/16."
  1797. (Their capitalizations; 16:1 compression only promised for files >64K
  1798. bytes in length.)
  1799.  
  1800. "Performed on a 386/25 machine, the program can complete a
  1801. compression/decompression cycle on one megabyte of data in less than
  1802. thirty seconds"
  1803.  
  1804. "The compressed output file created by DataFiles/16 can be used as the 
  1805. input file to subsequent executions of the program.  This feature of 
  1806. the utility is known as recursive or iterative compression, and will 
  1807. enable you to compress your data files to a tiny fraction of the 
  1808. original size.  In fact, virtually any amount of computer data can 
  1809. be compressed to under 1024 bytes using DataFiles/16 to compress its 
  1810. own output files muliple times.  Then, by repeating in reverse the 
  1811. steps taken to perform the recusive compression, all original data 
  1812. can be decompressed to its original form without the loss of a single 
  1813. bit."
  1814.  
  1815. Their flier also claims: 
  1816.  
  1817. "Constant levels of compression across ALL TYPES of FILES"
  1818. "Convenient, single floppy DATA TRANSPORTATION"
  1819.  
  1820. From my telephone conversation, I was assured that this is an
  1821. actual compression program.  Decompression is done by using only the 
  1822. data in the compressed file; there are no hidden or extra files.
  1823.  
  1824.  
  1825. 9.3.3 More information, by Rafael Ramirez <rafael.ramirez@channel1.com>:
  1826.  
  1827.    Today (Tuesday, 28th) I got a call from Earl Bradley of Web
  1828. who now says that they have put off releasing a software version of
  1829. the algorithm because they are close to signing a major contract with
  1830. a big company to put the algorithm in silicon.  He said he could not
  1831. name the company due to non-disclosure agreements, but that they had
  1832. run extensive independent tests of their own and verified that the
  1833. algorithm works. [...]
  1834.  
  1835. He said the algorithm is so simple that he doesn't want anybody
  1836. getting their hands on it and copying it even though he said they
  1837. have filed a patent on it. [...] Mr. Bradley said the silicon version
  1838. would hold up much better to patent enforcement and be harder to copy.
  1839.  
  1840.    He claimed that the algorithm takes up about 4K of code, uses only
  1841. integer math, and the current software implementation only uses a 65K
  1842. buffer.  He said the silicon version would likely use a parallel
  1843. version and work in real-time. [...]
  1844.  
  1845.  
  1846. 9.3.4 No software version
  1847.  
  1848. Appeared on BIX, reposted by Bruce Hoult <Bruce.Hoult@actrix.gen.nz>:
  1849.  
  1850. tojerry/chaos #673, from abailey, 562 chars, Tue Jun 16 20:40:34 1992
  1851. Comment(s). 
  1852. ----------
  1853. TITLE: WEB Technology
  1854. I promised everyone a report when I finally got the poop on WEB's
  1855. 16:1 data compression. After talking back and forth for a year
  1856. and being put off for the past month by un-returned phone calls,
  1857. I finally got hold of Marc Spindler who is their sales manager.
  1858.  
  1859. _No_ software product is forth coming, period!
  1860.  
  1861. He began talking about hardware they are designing for delivery
  1862. at the end of the year. [...]
  1863.  
  1864.  
  1865. 9.3.5 Product cancelled
  1866.  
  1867. Posted by John Toebes <toebes@bnr.ca> on Aug 10th, 1992:
  1868.  
  1869. [Long story omitted, confirming the reports made above about the
  1870. original WEB claims.]
  1871.  
  1872. 10JUL92 - Called to Check Status.  Was told that testing had uncovered a
  1873.           new problem where 'four numbers in a matrix were the same
  1874.           value' and that the programmers were off attempting to code a
  1875.           preprocessor to eliminate this rare case.  I indicated that he
  1876.           had told me this story before.  He told me that the
  1877.           programmers were still working on the problem.
  1878.  
  1879. 31JUL92 - Final Call to Check Status.  Called Earl in the morning and
  1880.           was told that he still had not heard from the programmers. [...]
  1881.           Stated that if they could not resolve the problem then there would
  1882.           probably not be a product.
  1883.  
  1884. 03AUG92 - Final Call.  Earl claims that the programmers are unable to
  1885.           resolve the problem.  I asked if this meant that there would
  1886.           not be a product as a result and he said yes.
  1887.  
  1888.  
  1889. 9.3.6 Byte's final report
  1890.  
  1891. Extract from the Nov. 95 issue of Byte, page 42:
  1892.  
  1893. Not suprisingly, the beta version of DataFiles/16 that reporter Russ Schnapp
  1894. tested didn't work. DataFiles/16 compressed files, but when decompressed, those
  1895. files bore no resemblance to their originals. WEB said it would send us a
  1896. version of the program that worked, but we never received it.
  1897.  
  1898. When we attempted to follow up on the story about three months later, the
  1899. company's phone had been disconnected. Attempts to reach company officers
  1900. were also unsuccessful. [...]
  1901.  
  1902.  
  1903. 9.4 Jules Gilbert
  1904.  
  1905. As opposed to WEB Technologies, Jules Gilbert <coffee@spock.ici.net> does not
  1906. claim to compress *all* files, but only "random or random-appearing" files.
  1907. Here are some quotes from a few of Mr Gilbert's articles, which can be helpful
  1908. to get a better idea of his claims. No comments or conclusions are given; if
  1909. you need more information contact Mr. Gilbert directly.
  1910.  
  1911.   From: coffee@spock.ici.net (Jules Gilbert)
  1912.   Newsgroups: comp.compression
  1913.   Subject: Re: No Magic Compressors, No Factoring Compressors, Jules Gilbert
  1914.     is a liar
  1915.   Date: 14 May 1996 03:13:31 -0400
  1916.   Message-ID: <4n9bqr$89k@spock.ici.net>
  1917.  
  1918.   [...]
  1919.   I will, in front of several Boston area computer scientists ('monitors'),
  1920.   people I choose but generally known to be fair and competent, under
  1921.   conditions which are sufficient to prevent disclosure of the method and fully
  1922.   protect the algorithm and other aspects of the underlying method from
  1923.   untoward discovery, use two computers, (which I am permitted to examine but
  1924.   not alter) with both machine's running Linux, and with the file-systems and
  1925.   Linux OS freshly restored from commercial CD-ROM's do the following:
  1926.  
  1927.   On one machine (the 'src-CPU') will be loaded a copy of the CALGARY-CORPUS.
  1928.   (Or other agreed on '.ZIP' or '.ARJ' file.)
  1929.  
  1930.   I will compress the CALGARY-CORPUS for transfer from the src-CPU onto 3.5"
  1931.   disks and transfer it (by sneaker-net) to the other machine for decompression
  1932.   and produce a perfect copy of the CORPUS file on the 'dst-CPU'.
  1933.  
  1934.   The CORPUS archive contents will not be 'cracked', ie', the original CORPUS
  1935.   can be encrypted and the password kept from me.  All I care about is that the
  1936.   input file is highly random-aprearing.
  1937.  
  1938.   I claim that I can perform this process several times, and each iteration
  1939.   will reduce the overall file by at least 50%, ie., a ratio of 2:1.  An
  1940.   'iteration' will constitute copying, using compression, from the src-CPU to
  1941.   the dst-CPU, and then reversing the direction to achieve another iteration.
  1942.  
  1943.   For example, for say a 4M input file, it is reasonable to expect an
  1944.   approximately 1M output file, after two complete iterations.
  1945.   [...]
  1946.   ONLY RANDOM OR RANDOM-APPEARING DATA INPUT CAN BE COMPRESSED BY MY METHOD.
  1947.   [...]
  1948.   If one iteration (of the compression 'sandwich') consists of two parts, say
  1949.   an LZ phase followed by a JG phase, the LZ method will compression by
  1950.   perhaps a ration of 2:1 (at the first iteration), perhaps much better if the
  1951.   input is text, and the JG phase will do 3-4:1, but slowly!!  During
  1952.   subsequent iterations, the LZ phase will do perhaps 1.25:1 and the JG phase
  1953.   will continue to do about 3-4:1.
  1954.  
  1955.   Experimentally, I have achieved compression results of nearly 150:1, overall,
  1956.   ^^^^^^^^^^^^^^                                                ^^^^^
  1957.   for a 60M file.  (I started with a '.arj' archive of a large DOS partition.)
  1958.   [...]
  1959.   ----------------------------------------------------------------------------
  1960.   From: coffee@spock.ici.net (Jules Gilbert)
  1961.   Newsgroups: comp.compression
  1962.   Subject: Re: Explanation: that uh, alg thing...
  1963.   Date: 15 May 1996 16:38:18 -0400
  1964.   Message-ID: <4ndfbq$cf3@spock.ici.net>
  1965.  
  1966.   [...]
  1967.   One more thing, I am preparing a short technical note to deal with the reason
  1968.   most programmers' and computer scientists' think it's impossible to (further)
  1969.   compress random input.  (Many people think that because you can't get more
  1970.   than 2^N messages from a N-bit compressed msg, that it means that you can't
  1971.   compress random input.  (Lot's of folks have told me that.)  The short story
  1972.   is:
  1973.  
  1974.   I agree that you can not get more than 2^N messages from N bits.  No question
  1975.   about it.  BUT THAT STATMENT HAS NOTHING TO DO WHATSOEVER WITH THE
  1976.   INTERPRETATION OF WHAT THOSE BITS 'MEAN'.
  1977.   [...]
  1978.   ----------------------------------------------------------------------------
  1979.   From: coffee@spock.ici.net (Jules Gilbert)
  1980.   Newsgroups: comp.compression
  1981.   Subject: Seeing is believing!
  1982.   Date: 9 Jun 1996 03:20:52 -0400
  1983.   Message-ID: <4pdu0k$otg@spock.ici.net>
  1984.  
  1985.   [...]
  1986.   If your firm needs industrial-strength compression, contact 'coffee@ici.net'
  1987.   and ask us for an on-site demonstration of our MR2 compressors.  Each can
  1988.   compress large files of 'random-appearing' information, whether RSA-encrypted
  1989.   blocks, or files already compressed using LZ-techniques.
  1990.  
  1991.   Our demonstration will give you the opportunity to observe compression of
  1992.   'random-appearing' files of at least 100MB by at least 3:1 per iteration.
  1993.   Usually, several iterations are possible.  (These are minimum figures easily
  1994.   exceeded.)
  1995.   [...]
  1996.   ----------------------------------------------------------------------------
  1997.   From: coffee@spock.ici.net (Jules Gilbert)
  1998.   Newsgroups: comp.compression
  1999.   Subject: Re: My remarks on Jules Gilbert
  2000.   Date: 24 Jul 1996 18:05:44 -0400
  2001.   Message-ID: <4t66no$9qq@spock.ici.net>
  2002.  
  2003.   [...]
  2004.   My claims can not possibly be true IF I'M PLAYING BY THE 'RULES' THAT YOU
  2005.   ASSUME APPLY TO ME.  (Sorry to shout).
  2006.  
  2007.   Clearly, anyone sending a signal (in the Shannon context), is constrained by
  2008.   limits which make it impossible to compress RAD ('random-appearing data')
  2009.   input.
  2010.   [...]
  2011.   1)  I can't compress bits any better than the next guy.  Maybe not as well,
  2012.       in fact.  
  2013.  
  2014.   2)  I have designed an engine that accepts RAD input and emits far too little
  2015.       data to reconstitute the original data, based on conventional
  2016.       assumptions. Okay!   I know this.
  2017.  
  2018.   3)  But, I none-the-less reconstitute the original data.
  2019.   [...]
  2020.   ----------------------------------------------------------------------------
  2021.   From: coffee@soran.ici.net (Jules Gilbert)
  2022.   Newsgroups: comp.compression
  2023.   Subject: Re: Jules Gilbert's New Compresssion Technology
  2024.   Date: 12 Aug 1996 08:11:10 -0400
  2025.   Message-ID: <4un70u$a2r@soran.ici.net>
  2026.  
  2027.   I have multiple methods for compressing RAD.  Watch carefully:
  2028.  
  2029.   MR1 does 3:1, on large buffers and is repeatable until the volume of input
  2030.   data falls below 128k or so.  (This figure is under user control, but
  2031.   compreesion quality will suffer as the buffer size is decreased).  Recent
  2032.   changes make this method about as fast as any conventional compressor.
  2033.  
  2034.   MR2 does at least 6:1, with a minimum buffer size of perhaps 32k.  It is also
  2035.   repeatable.  MR2 does not actually compress, though.  Instead, it translates
  2036.   an input buffer into an output buffer of roughly equivalent size.  This
  2037.   output buffer contains mostly constants, and other things, such as simple
  2038.   sequences: 28,29,31,32,33,35,40,41,42,43,44,45.  (An actual sequence of
  2039.   bytes).  Obviously, this kind of information is readily compressed, and that
  2040.   is why I claim that MR2 can achieve a minimum of 6:1.  Again, like MR1, this
  2041.   process can be re-applied over it's own output.
  2042.  
  2043.   When, I've said, "No, it's impossible to compress by 100:1" I was trying to
  2044.   get this audience to see this as realistic.  But I can compress RAD files
  2045.   100:1 if allowed to re-process the output through the same process.  I first
  2046.   actually achieved a 100:1 compression level in March of this year using tools
  2047.   ^^^^^^^^^^^^^^^^^^^^^^^^^
  2048.   designed for experimenting in RAD issues.  But now I have C programs which
  2049.   have been written to be easy to understand and are intended to be part of my
  2050.   technology transfer process for clients.
  2051.   [...]
  2052.   So, can someone compress by 100:1 or even 1000:1?  Yes! But ONLY if the input
  2053.   file is sufficiently large.  A 1000:1 compression ratio would require a very
  2054.   large input file, and, at least for PC users, archive files of this size are
  2055.   almost never produced.
  2056.   ----------------------------------------------------------------------------
  2057.   From: coffee@soran.ici.net (Jules Gilbert)
  2058.   Newsgroups: comp.compression
  2059.   Subject: Re: Gilbert's RAD compression product
  2060.   Date: 18 Aug 1996 08:40:28 -0400
  2061.   Message-ID: <4v72vs$quc@soran.ici.net>
  2062.  
  2063.   [...]
  2064.   (In my original remarks), I am quoted above as claiming that a 3,152,896 byte
  2065.   'tar 'file (conventionally compressed to 1,029,790 bytes) can be compressed
  2066.   to 50*1024 bytes.  It's an accurate quote.
  2067.  
  2068.   Now how can that be possible?
  2069.  
  2070.   If a gzip compressed version of the Corpus requires roughly a 1MB, what do I
  2071.   do with the 950k bytes I don't store in the compressed intermediate file?
  2072.  
  2073.   Well, that's certainly a puzzler!
  2074.  
  2075.   For now, all I will say is that it does not go into the compressed
  2076.   intermediate file.  And because it doesn't, Shannons' channel capacity axioms
  2077.   apply only to the 50k component.
  2078.   ----------------------------------------------------------------------------
  2079.   From: coffee@soran.ici.net (Jules Gilbert)
  2080.   Newsgroups: comp.compression
  2081.   Subject: Some answers about MR1
  2082.   Date: 22 Aug 1996 23:45:54 -0400
  2083.   Message-ID: <4vj9hi$pkb@soran.ici.net>
  2084.  
  2085.   [...]
  2086.   However, arrangements are being made to do another demo in September at MIT. 
  2087.  
  2088.   One of the files compressed and decompressed will be the Corpus, after it's
  2089.   already been compressed using ARJ, a good quality conventional compressor.
  2090.   (It should be about a 1MB at that point).  My program has made the corpus
  2091.   as small as 6k, although that requires SEVERAL separate physical passes.
  2092.   ^^^^^^^^^^^^^^
  2093.   Because we will only have a few minutes to spend on this single file, I'll
  2094.   likely stop at 250k or so.
  2095.  
  2096.   Under Linux, the total size of the compressor and decompressor load modules
  2097.   is about 50k bytes.  And under DOS, using the Intel C compiler (a great
  2098.   product, but sadly, not sold anymore), the same files total about 300k bytes.
  2099.  
  2100.   MR1 contains code that is highly dependent on the particularities of a host
  2101.   computer's floating point processor, or more correctly, architectural differ-
  2102.   ences existing between the source machine and the target machine would likely
  2103.   cause failure to de-compress.
  2104.   [...]
  2105.  
  2106.  
  2107. 9.5 Patents on compression of random data or recursive compression
  2108.  
  2109. 9.5.1 David C. James
  2110.  
  2111. On July 2, 1996, David C. James was granted patent 5,533,051 "Method for data
  2112. compression" for a method claimed to be effective even on random data.
  2113.  
  2114.   From: u137@aol.com (Peter J. Cranstone)
  2115.   Newsgroups: comp.compression
  2116.   Subject: Re: Jules Gilbert's Compression Technology
  2117.   Date: Sun Aug 18 12:48:11 EDT 1996
  2118.  
  2119.   Wh have just been issued a patent (US. #5,533,051) and have several more
  2120.   pending on a new method for data compression. It will compess all types of
  2121.   data, including "random", and data containing a uniform distribution of
  2122.   "0's" and "1's".
  2123.   [...]
  2124.  
  2125. The first line of the patent abstract is:
  2126.  
  2127.   Methods for compressing data including methods for compressing highly
  2128.   randomized data are disclosed.
  2129.  
  2130. Page 3, line 34 of the patent states:
  2131.  
  2132.   A second aspect of the present invention which further enhances its ability
  2133.   to achieve high compression percentages, is its ability to be applied to
  2134.   data recursively. Specifically, the methods of the present invention are
  2135.   able to make multiple passes over a file, each time further compressing the
  2136.   file. Thus, a series of recursions are repeated until the desired
  2137.   compression level is achieved.
  2138.  
  2139. Page 27, line 18 of the patent states that the claimed method can compress
  2140. without loss *all* files by at least one bit:
  2141.  
  2142.   the direct bit encode method of the present invention is effective for
  2143.   reducing an input string by one bit regardless of the bit pattern of the
  2144.   input string.
  2145.  
  2146. The counting argument shows that this is mathematically impossible (see section
  2147. 9.2) above. If the method were indeed able to shrink any file by at least one
  2148. bit, applying it recursively would shrink gigabytes down to a few bits.
  2149.  
  2150. The patent contains evasive arguments to justify the impossible claims:
  2151.  
  2152. Page 12, line 22:
  2153.  
  2154.   Of course, this does not take into account any overhead registers or other
  2155.   "house-keeping" type information which must be tracked. However such
  2156.   overhead tends to be negligible when processing the large quantities of
  2157.   data typically encountered in data compression applications.
  2158.  
  2159. Page 27, line 17:
  2160.  
  2161.   Thus, one skilled in the art can see that by keeping the appropriate
  2162.   counters, the direct bit encode method of the present invention is
  2163.   effective for reducing an input string by one bit regardless of the bit
  2164.   pattern of the input string. Although a certain amount of "loss" is
  2165.   necessary in keeping and maintaining various counters and registers, for
  2166.   files which are sufficiently large, this overhead is insignificant compared
  2167.   to the savings obtained by the direct bit encode method.
  2168.  
  2169. The flaw in these arguments is that the the "house-keeping" type information
  2170. is *not* negligible. If it is properly taken it into account, it cancels any
  2171. gains made elsewhere when attempting to compress random data.
  2172.  
  2173. The patent contains even more evasive arguments:
  2174.  
  2175. Page 22, line 31:
  2176.  
  2177.   It is commonly stated that perfectly entropic data streams cannot be
  2178.   compressed. This misbelief is in part based on the sobering fact that for a
  2179.   large set of entropic data, calculating the number of possible bit pattern
  2180.   combinations is unfathomable. For example, if 100 ones and 100 zeros are
  2181.   randomly distributed in a block 200 bits long, there are
  2182.      200C100 = 9.055 10^58
  2183.   combinations possible. The numbers are clearly unmanageable and hence the
  2184.   inception that perfectly entropic data streams cannot be compressed. The
  2185.   key to the present compression method under discussion is that it makes no
  2186.   attempt to deal with such large amounts of data and simply operates on
  2187.   smaller portions.
  2188.  
  2189. The actual claims of the patent are harmless since they only describe
  2190. methods which cannot work (they actually expand random data instead of
  2191. compressing it). For example, claims 6 and 7 are:
  2192.  
  2193.  6. A method of compressing a stream of binary data, comprising the steps of:
  2194.   A) parsing n-bits from said stream of binary data;
  2195.   B) determining the value of said parsed n-bits;
  2196.   C) based on the results of step B, coding said values of said n-bits in at
  2197.      least one of a first, second, and third target string, wherein coding
  2198.      said value includes generating a plurality of code strings and
  2199.      correlating said value with one of said code strings and dividing said
  2200.      correlated code string variable length codes and dividing at least some
  2201.      of said into at least first and second segments, and assigning at least
  2202.      one of said correlated code string segments to at least one of said
  2203.      first, second, and third target strings, wherein at least one of said
  2204.      plurality of codes is not greater than n-1 bits long.
  2205.  
  2206.  7. The method of compressing a stream of binary data of claim 6, wherein n=2.
  2207.  
  2208. Making abstraction of the legalese, claim 7 says in short that you can
  2209. compress an arbitrary sequence of two bits down to one bit.
  2210.  
  2211. 9.5.2 Michael L. Cole
  2212.  
  2213. Patent 5,488,364 "Recursive data compression", granted Jan. 30, 1996,
  2214. also claims that recursive compression of random data is possible. See
  2215. http://www.teaser.fr/~jlgailly/05488364.html for the text and a short
  2216. analysis of this patent.
  2217.  
  2218. 9.5.3 John F. Remillard
  2219.  
  2220. Patent 5,486,826 "Method and apparatus for iterative compression of
  2221. digital data" uses methods very similar to those of the "magic
  2222. function theory" (see section 9.2 above).  The patent is available at
  2223. http://patent.womplex.ibm.com/details?patent_number=5486826
  2224.  
  2225. See also from the same person patent 5,594,435 "Permutation-based data
  2226. compression" http://patent.womplex.ibm.com/details?patent_number=5594435 
  2227. The assignee for this patent is Philosophers' Stone LLC. (The Philosopher's
  2228. Stone is the key to all the riches in the universe; an LLC is a Limited
  2229. Liability Corporation.)
  2230.  
  2231. ------------------------------------------------------------------------------
  2232.  
  2233. Subject: [10] Fake compression programs (OWS, WIC)
  2234.  
  2235.  
  2236. Some programs claimed to achieve incredible compression ratios are completely
  2237. fake: they do not compress at all but just stored the uncompressed data in
  2238. hidden files on the hard disk or keep it in unused clusters. Needless to say,
  2239. such programs are dangerous and should never be used because there is a
  2240. significant risk of losing all the data.
  2241.  
  2242. The OWS program just remembers which clusters contained the data on the hard
  2243. disk. The data can be recovered only if those clusters are not used again for
  2244. another file.
  2245.  
  2246. The WIC program searches for the first directory in drive C: and creates a
  2247. hidden file called WINFILE.DLL containing a copy of all the original files.
  2248. If you copy the compressed file to another computer (which doesn't have the
  2249. file WINFILE.DLL), WIC reports a CRC error.
  2250.  
  2251. ------------------------------------------------------------------------------
  2252.  
  2253. Subject: [11] What is the V.42bis standard?
  2254.  
  2255.  
  2256. A description of the V.42bis standard is given in "The V.42bis
  2257. standard for data-compressing modems," by Clark Thomborson
  2258. <cthombor@theory.lcs.mit.edu>, IEEE Micro, Oct 1992, pp. 41-53. 
  2259.  
  2260. If you are looking for freeware source of V.42bis, please read the note
  2261. below by Peter Gutman explaining why there is no such source code.
  2262.  
  2263. Short introduction, by Alejo Hausner <hausner@qucis.queensu.ca>:
  2264.  
  2265.   The V.42bis Compression Standard was proposed by the International
  2266.   Consultative Committee on Telephony and Telegraphy (CCITT, now ITU-T) as
  2267.   an addition to the v.42 error-correction protocol for modems. Its purpose
  2268.   is to increase data throughput, and uses a variant of the
  2269.   Lempel-Ziv-Welch (LZW) compression method.  It is meant to be
  2270.   implemented in the modem hardware, but can also be built into the
  2271.   software that interfaces to an ordinary non-compressing modem.
  2272.  
  2273.   V.42bis can send data compressed or not, depending on the
  2274.   data.  There are some types of data that cannot be
  2275.   compressed.  For example, if a file was compressed first,
  2276.   and then sent through a V.42bis modem, the modem would not
  2277.   likely reduce the number of bits sent.  Indeed it is likely
  2278.   that the amount of data would increase somewhat.
  2279.  
  2280.   To avoid this problem, the algorithm constantly monitors the
  2281.   compressibility of the data, and if it finds fewer bits
  2282.   would be necessary to send it uncompressed, it switches to
  2283.   transparent mode.  The sender informs the receiver of this
  2284.   transition through a reserved code word.  Henceforth the
  2285.   data is passed as plain bytes.
  2286.  
  2287.   While transmitting in transparent mode, the sender maintains
  2288.   the LZW trees of strings, and expects the receiver to do
  2289.   likewise.  If it finds an advantage in returning to
  2290.   compressed mode, it will do so, first informing the receiver
  2291.   by a special escape code.  Thus the method allows the
  2292.   hardware to adapt to the compressibility of the data.
  2293.  
  2294.   The choice of escape code is clever.  Initially, it is a
  2295.   zero byte.  Any occurrence of the escape code is replaced,
  2296.   as is customary, by two escape codes.  In order to prevent a
  2297.   string of escape codes from temporarily cutting throughput
  2298.   in half, the escape code is redefined by adding 51 mod 256
  2299.   each time it is used.
  2300.  
  2301.  
  2302. A note from Peter Gutman <pgut01@cs.auckland.ac.nz> about V.42bis
  2303. implementations:
  2304.  
  2305.   V.42bis is covered by patents, and the licensing terms are rather complex
  2306.   because you need to license it from multiple organisations.  At one point
  2307.   British Telecom were charging something like 30,000 pounds for a license
  2308.   (this was a few years ago, things may have changed since then). Because of
  2309.   this, noone has ever implemented a freely-available version of V.42bis as
  2310.   you'd find in a modem.  There is a Unix implementation (called "compact") of
  2311.   a V.42bis-like algorithm which comes with a great many disclaimers that it
  2312.   can only be used for research purposes. [Note from FAQ maintainer: "compact"
  2313.   is available in
  2314.      http://ftp.sunet.se/ftp/pub/usenet/comp.sources.misc/volume15/compact_sv/
  2315.   The 'shrink' method of zip 1.1 (see item 2 above) is also similar to V.42bis]
  2316.  
  2317.   If you've ever wondered why noone other than modem manufacturers ever use
  2318.   V.42bis for anything, this is it.  
  2319.  
  2320.  
  2321. Some CCITT (ITU-T) standards documents are available by ftp in
  2322. ftp://ftp.fdn.org/pub/Library/Ccitt-standards/ccitt/
  2323.  
  2324. A mail server for CCITT (ITU-T) documents is available at teledoc@itu.arcom.ch
  2325. or itudoc@itu.ch. A Gopher server is also available at gopher://info.itu.ch
  2326.  
  2327. The V42bis standard is also in
  2328. ftp://ftp.std.com/obi/Standards/Telcom/CCITT/v42bis.asc.Z
  2329.  
  2330. For ISO documents, try http://www.iso.ch/
  2331.  
  2332. See also item 20 below for other sites with standards documents.
  2333.  
  2334. ------------------------------------------------------------------------------
  2335.  
  2336. Subject: [12] I need source for the winners of the Dr Dobbs compression contest
  2337.  
  2338.  
  2339. The source of the top 6 programs of the Feb 91 Dr Dobbs data compression
  2340. contest are available by ftp on
  2341.   ftp://ftp.simtel.net/pub/simtelnet/msdos/compress/ddjcompr.zip
  2342.   ftp://garbo.uwasa.fi/pc/source/ddjcompr.zip
  2343.  
  2344. The sources are in MSDOS end-of-line format, one directory per
  2345. program.  Unix or VMS users, use "unzip -a ddjcompr" to get correct
  2346. end-of-lines (add -d to recreate the directory structure if you are
  2347. using an obsolete version of unzip such as 4.1). Three of the 6
  2348. programs are not portable and only run on MSDOS. compact and urban
  2349. work on Unix, sixpack only requires minor modifications.
  2350.  
  2351. ------------------------------------------------------------------------------
  2352.  
  2353. Subject: [13] I need source for arithmetic coding
  2354.  
  2355.  
  2356. (See question 70 for an introduction to arithmetic coding.)
  2357.  
  2358. The source for the arithmetic coder described in Chap.5 of Bell, Cleary, and
  2359. Witten's book "Text Compression" (see question 7 above) (or, equivalently, in:
  2360. Witten, Neal, and Cleary's article "Arithmetic Coding for data Compression"
  2361. from Communications of the Association for Computing Machinery, 30 (6),
  2362. pp.520-540, June, 1987) is in ftp://ftp.cpsc.ucalgary.ca/pub/projects/ar.cod/
  2363. It only comes with a simple order-0 model but it's set up so that adding your
  2364. own more sophisticated one is straightforward. Look also in
  2365. ftp://munnari.mu.oz.au/pub/arith_coder
  2366.  
  2367. A low precision arithmetic coding implementation avoiding hardware
  2368. division is available on the same site in
  2369. ftp://ftp.cpsc.ucalgary.ca/pub/projects/arithmetic.coding/low.precision.version
  2370. file low.precision.version.shar
  2371.  
  2372. Kris Popat <popat@image.mit.edu> has worked on "Scalar Quantization
  2373. with Arithmetic Coding."  It describes an arithmetic coding technique
  2374. which is quite general and computationally inexpensive.  The
  2375. documentation and example C code are available via anonymous ftp from
  2376. media-lab.media.mit.edu (18.85.0.2), in /pub/k-arith-code.
  2377.  
  2378. The program 'urban' in ddjcompr.zip (see item 12 above) is a high order
  2379. arithmetic coder working at the bit level. It is written by Urban Koistinen
  2380. <md85-epi@nada.kth.se>.
  2381.  
  2382. The DMC program is available in ftp://plg.uwaterloo.ca/pub/dmc/*.c. It
  2383. implements the algorithm described in "Data Compression using Dynamic
  2384. Markov Modelling", by Gordon Cormack and Nigel Horspool, Computer
  2385. Journal 30:6 (December 1987).  This program uses Guazzo's version of
  2386. arithmetic coding.
  2387.  
  2388. An implementation of Moffat's arithmetic coder is available in
  2389. http://www.cs.dartmouth.edu/~jmd/ArithCoder.tar.gz
  2390.  
  2391. ------------------------------------------------------------------------------
  2392.  
  2393. Subject: [15] Where can I get image compression programs?
  2394.  
  2395.  
  2396. JPEG:
  2397.     Source code for most any machine:
  2398.     ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6a.tar.gz
  2399.     ftp://nic.funet.fi/pub/graphics/packages/jpeg/jpegsrc.v6.tar.gz
  2400.     Contact: jpeg-info@uunet.uu.net (Independent JPEG Group)
  2401.  
  2402.     ftp://havefun.stanford.edu/pub/jpeg/JPEGv1.2.1.tar.Z   (has lossless mode)
  2403.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2404.  
  2405.     ftp://ftp.cs.cornell.edu/pub/multimed/ljpg.tar.Z (lossless jpeg)
  2406.  
  2407.     xv, an image viewer which can read JPEG pictures, is available in
  2408.     ftp://ftp.cis.upenn.edu/pub/xv/xv-3.10a.tar.Z
  2409.  
  2410. JPEG-LS (LOCO-I):
  2411.     http://www.hpl.hp.com/loco/
  2412.  
  2413. MPEG: If you don't find here what you are looking for, check also
  2414.   http://www.mpeg.org and http://www.powerweb.de/mpeg/
  2415.  
  2416.     ftp://havefun.stanford.edu/pub/mpeg/MPEGv1.2.1.tar.Z
  2417.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2418.  
  2419.     ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/play/
  2420.                                                mpeg_play-2.3-patched-src.tar.gz
  2421.     Contact: mpeg-bugs@cs.berkeley.edu
  2422.  
  2423.     ftp://flash.bu.edu/pub/code/mpeg_system/mpeg_system_source_v1.0.tar.gz
  2424.     (MPEG-I Multi-Stream System Layer encoder/player; includes an
  2425.      enhanced version of mpeg_play)
  2426.     Contact: Jim Boucher <jboucher@spiderman.bu.edu> or Ziv Yaar <zyaar@bu.edu>
  2427.  
  2428.     ftp://ftp.mni.mcgill.ca/pub/mpeg/mpeg_lib-1.2.tar.gz [MPEG library]
  2429.     Contact: Gregory Ward <greg@pet.mni.mcgill.ca>
  2430.  
  2431.     ftp://nvr.com/pub/NVR-software/Product-1.0.4.tar.Z
  2432.     (free demo copy of NVR's software toolkit for SPARCstations)
  2433.     Contact: Todd Brunhoff <toddb@nvr.com>
  2434.  
  2435.     ftp://havefun.stanford.edu/pub/mpeg/MPEGv1.2.1.tar.Z
  2436.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2437.  
  2438.     ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/play/
  2439.                                                mpeg_play-2.3-patched-src.tar.gz
  2440.     Contact: mpeg-bugs@cs.berkeley.edu
  2441.  
  2442.     ftp://flash.bu.edu/pub/code/mpeg_system/mpeg_system_source_v1.0.tar.gz
  2443.     (MPEG-I Multi-Stream System Layer encoder/player; includes an
  2444.      enhanced version of mpeg_play)
  2445.     Contact: Jim Boucher <jboucher@spiderman.bu.edu> or Ziv Yaar <zyaar@bu.edu>
  2446.  
  2447.     ftp://ftp.mni.mcgill.ca/pub/mpeg/mpeg_lib-1.2.tar.gz [MPEG library]
  2448.     Contact: Gregory Ward <greg@pet.mni.mcgill.ca>
  2449.  
  2450.     ftp://nvr.com/pub/NVR-software/Product-1.0.4.tar.Z
  2451.     (free demo copy of NVR's software toolkit for SPARCstations)
  2452.     Contact: Todd Brunhoff <toddb@nvr.com>
  2453.  
  2454.     http://www.mpeg.org/MSSG or ftp://ftp.mpeg.org/pub/mpeg/mssg/
  2455.       Contacts:  MPEG Software Simulation Group <mssg@mpeg.org>
  2456.       Concerning VMPEG: Stefan Eckart <stefan@chromatic.com>
  2457.  
  2458.     http://www.mpegtv.com (MPEGTV Software MPEG Video Player for Unix)
  2459.     Contact: Tristan Savatier <tristan@mpeg.org>
  2460.  
  2461. H.261(P*64):
  2462.     havefun.stanford.edu:pub/p64/P64v1.2.tar.Z
  2463.     Contact: Andy Hung <achung@cs.stanford.edu> (see item 20 below)
  2464.  
  2465.     ftp://zenon.inria.fr/rodeo/ivs/last_version/ivs*-src.tar.gz
  2466.     (Inria videoconference system)
  2467.     Contact: Thierry Turletti <turletti@sophia.inria.fr> (see item 20 below).
  2468.  
  2469. H.263: (by Telenor Research)
  2470.     http://www.nta.no/brukere/DVC/h263_software
  2471.  
  2472. JBIG:
  2473.     ftp://nic.funet.fi/pub/graphics/misc/test-images/jbig.tar.gz.
  2474.  
  2475.     ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/JBIG/jbigkit-0.9.tar.gz
  2476.     Contact: Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
  2477.  
  2478. PNG: For code and sample images, see:
  2479.     http://www.wco.com/~png/
  2480.     ftp://ftp.uu.net/graphics/png/
  2481.     ftp://swrinde.nde.swri.edu/pub/png/
  2482.  
  2483. mg: (the MG system for compressing and indexing text and images, see item 16)
  2484.     ftp://munnari.oz.au/pub/mg/*
  2485.     Contact: Stuart Inglis <singlis@cs.waikato.ac.nz>
  2486.  
  2487. BTPC: Binary Tree Predictive Coding
  2488.     http://www.engr.mun.ca/~john/btpc.html
  2489.     Contact: John Robinson <john@monet.uwaterloo.ca>
  2490.  
  2491. epic: (Efficient Pyramid Wavelet Coder, see item 72)
  2492.     http://www.cis.upenn.edu/~eero/epic.html
  2493.     Contact: Eero P. Simoncelli <eero.simoncelli@nyu.edu>
  2494.     C source code provided. The "Lenna" test image is available as part of
  2495.     the EPIC package, where it is named "test_image".
  2496.  
  2497. hcompress: (wavelet image compression, see item 72)
  2498.     ftp://stsci.edu/software/hcompress/hcompress.tar.Z
  2499.  
  2500. wavethresh: (wavelet software for the language S)
  2501.     http://www.stats.bris.ac.uk/pub/software/wavethresh/wavethresh2.2/
  2502.     Contact: gpn@maths.bath.ac.uk
  2503.  
  2504. rice-wlet: (wavelet software, see item 72)
  2505.     ftp://cml.rice.edu/pub/dsp/software/rice-wlet-tools.tar.Z
  2506.  
  2507. Wavelet Transform Coder Construction Kit:
  2508.     http://www.cs.dartmouth.edu/~gdavis/wavelet/wavelet.html
  2509.     Contact: Geoff Davis <gdavis@cs.dartmouth.edu>
  2510.  
  2511. scalable: (2 & 3 dimensional subband transformation)
  2512.     ftp://robotics.eecs.berkeley.edu/pub/multimedia/scalable2.tar.Z
  2513.     Contact: scalable@robotics.eecs.berkeley.edu
  2514.  
  2515. SPIHT: (Set Partitioning in Hierarchical Trees, wavelet-based)
  2516.     http://ipl.rpi.edu/SPIHT/
  2517.  
  2518. compfits:
  2519.     ftp://uwila.cfht.hawaii.edu/pub/compfits/compfits.tar.Z
  2520.     Contact: Jim Wright <jwright@cfht.hawaii.edu>
  2521.  
  2522. fitspress:
  2523.     ftp://cfata4.harvard.edu/pub/fitspress08.tar.Z
  2524.  
  2525. tiff:
  2526.     For source and sample images, see question 18 below.
  2527.  
  2528. DCT algorithms used to be in:
  2529.     ftp://etro.vub.ac.be/pub/transfer/DCT_ALGORITHMS/
  2530.     Contact: Charilos Christopoulos <chchrist@etro2.vub.ac.be> for the sources
  2531.  
  2532. xanim: (X11 animation viewer, supports Quicktime and several other formats)
  2533.     ftp://ftp.x.org/contrib/applications/xanim2683.tar.Z
  2534.     ftp://ftp.shell.portal.com/pub/podlipec/xanim26978.tar.gz
  2535.  
  2536. ppm2pz: (lossless 24-bit image compression)
  2537.     http://www.jyu.fi/~kuru/compression.html
  2538.  
  2539. A demo of image compression using neural networks is available in
  2540. http://www.ee.duke.edu/~cec/index.html.
  2541.  
  2542. For fractal compression programs, see item 17 below.
  2543. For Vector Quantization software, see item 76 in part 2 of this FAQ.
  2544. For image compression hardware, see item 85 in part 3 of this FAQ.
  2545.  
  2546. ------------------------------------------------------------------------------
  2547.  
  2548. Subject: [16] What is the state of the art in lossless image compression?
  2549.  
  2550.  
  2551. The JBIG algorithm is one of the best available for lossless image
  2552. compression.  For an introduction to JBIG, see question 74 in part 2.
  2553.  
  2554. JBIG works best on bi-level images (like faxes) and also works well on
  2555. Gray-coded grey scale images up to about six or so bits per pixel.  You
  2556. just apply JBIG to the bit planes individually.  For more bits/pixel,
  2557. lossless JPEG provides better performance, sometimes. (For JPEG, see
  2558. question 19 below.)
  2559.  
  2560. You can find the specification of JBIG in International Standard
  2561. ISO/IEC 11544 or in ITU-T Recommendation T.82. You can order a copy
  2562. directly from ISO (www.iso.ch) or ITU (www.itu.ch) or from your
  2563. National Standards Body. In the USA, call ANSI at (212) 642-4900.
  2564.  
  2565.  
  2566. See also the MG system containing an implementation of the 'FELICS'
  2567. algorithm of P.G. Howard and J.S. Vitter.  FELICS usually gives better
  2568. and faster compression than lossless JPEG, at least for 8-bit
  2569. grayscale images. (See item 15 above for ftp location). From the MG
  2570. README file:
  2571.  
  2572.   The MG system is a suite of programs for compressing and
  2573.   indexing text and images. Most of the functionality implemented
  2574.   in the suite is as described in the book ``Managing Gigabytes:
  2575.   Compressing and Indexing Documents and Images'', I.H. Witten, A.
  2576.   Moffat, and T.C. Bell; Van Nostrand Reinhold, New York, 1994, ISBN
  2577.   0-442-01863-0; US $54.95; call 1 (800) 544-0550 to order.
  2578.  
  2579.   These features include:
  2580.  
  2581.   -- text compression using a Huffman-coded semi-static word-based
  2582.      scheme
  2583.   -- two-level context-based compression of bi-level images
  2584.   -- FELICS lossless compression of gray-scale images
  2585.   -- combined lossy/lossless compression for textual images
  2586.   -- indexing algorithms for large volumes of text in limited main
  2587.      memory
  2588.   -- index compression
  2589.   -- a retrieval system that processes Boolean and ranked queries
  2590.   -- an X windows interface to the retrieval system
  2591.  
  2592. Paul Howard's PhD thesis, which among other things describes FELICS,
  2593. is available in ftp://ftp.cs.brown.edu/pub/techreports/93/cs93-28.ps.Z
  2594.  
  2595.  
  2596. JPEG-LS is the emerging ISO standard for lossless/near-lossless 
  2597. compression of continuous-tone images. Marcelo Weinberger
  2598. <marcelo@hplwein.hpl.hp.com> says about it:
  2599.  
  2600.   JPEG-LS is being developed by ISO/IEC JTC1/SC29/WG1 (final committee
  2601.   draft document FCD14495-1 as of July 1997), and it is based on HP's
  2602.   LOCO-I algorithm (reference: M. Weinberger, G. Seroussi, G. Sapiro,
  2603.   "LOCO-I: A Low Complexity, Context-Based, Lossless Image Compression
  2604.   Algorithm," Proc.  IEEE Data Compression Conference, Snowbird, Utah,
  2605.   March-April 1996). [...]
  2606.  
  2607.   The main feature of JPEG-LS is its superior placement in the
  2608.   compression/complexity trade-off curve. Tested over a wide variety of
  2609.   image types, it was shown to be, on the average, within about 4% of the
  2610.   best available lossless image compression at a fraction of the
  2611.   complexity.  In particular, JPEG-LS significantly outperforms FELICS
  2612.   and lossless JPEG Huffman at similar levels of complexity (it also
  2613.   outperforms lossless JPEG arithmetic, which is of significantly higher
  2614.   complexity). [...]
  2615.  
  2616.   A software implementation of JPEG-LS, is now available at:
  2617.         http://www.hpl.hp.com/loco/
  2618.   There, the DCC'96 paper on LOCO-I is also available. The standard draft
  2619.   is also available through a link to the official JPEG Web site.
  2620.  
  2621. ------------------------------------------------------------------------------
  2622.  
  2623. Subject: [17] What is the state of fractal compression?
  2624.  
  2625. You may want to read first item 77 in part 2 of this FAQ:
  2626. "Introduction to Fractal compression".
  2627.  
  2628.  
  2629. from Tal Kubo <kubo@zariski.harvard.edu>:
  2630.  
  2631. According to Barnsley's book 'Fractals Everywhere', this method is
  2632. based on a measure of deviation between a given image and its
  2633. approximation by an IFS code.  The Collage Theorem states that there is
  2634. a convergent process to minimize this deviation.  Unfortunately,
  2635. according to an article Barnsley wrote for BYTE a few years ago, this
  2636. convergence was rather slow, about 100 hours on a Cray, unless assisted by
  2637. a person.
  2638.  
  2639. Barnsley et al are not divulging any technical information beyond the
  2640. meager bit in 'Fractals Everywhere'.  The book explains the idea of IFS
  2641. codes at length, but is vague about the application of the Collage theorem
  2642. to specific compression problems.
  2643.  
  2644. There is reason to believe that Barnsley's company has
  2645. *no algorithm* which takes a given reasonable image and achieves
  2646. the compression ratios initially claimed for their fractal methods.
  2647. The 1000-to-1 compression advertised was achieved only for a 'rigged'
  2648. class of images, with human assistance. The best unaided
  2649. performance I've heard of is good lossy compression of about 80-1.
  2650.  
  2651. Steve Tate <srt@duke.cs.duke.edu> confirms:
  2652.  
  2653. Compression ratios (unzoomed) seem to range from 20:1 to 60:1...  The
  2654. quality is considerably worse than wavelets or JPEG on most of the
  2655. non-contrived images I have seen.
  2656.  
  2657. But Yuval Fisher <fisher@inls1.ucsd.edu> disagrees:
  2658.  
  2659. Their performance has improved dramatically beyond what they were
  2660. talking about in BYTE a few years ago.  Human assistance to the
  2661. compression is no longer needed and the compression time is
  2662. reasonable, although the more time and compute power you throw at the
  2663. compression, the smaller the resulting file for the same level of
  2664. quality.
  2665.  
  2666. Geoffrey A Stephenson <ketlux@ketlux.demon.co.uk> adds:
  2667.  
  2668. Iterated systems are shipping a general purpose compressor at about
  2669. 300 Pounds in the UK that claims "640x480 24 bit colour compression of
  2670. about 1 min at 922k -> 10k on a 486/50 software only, decomp. to 8
  2671. bits in 3 secs, etc." At a recent multimedia conference in London they
  2672. handed out free demo disks that show the decomp. in action. The
  2673. package runs under both DOS anf WIN (DLLs provided for use in
  2674. applications). They also sell a board to speed up compression and
  2675. offer versions supporting full motion video (but not apparently at all
  2676. SVGA sizes like the static picture version). I have not yet got my
  2677. hands on a full version to test different types of pictures, but
  2678. friends have a and claim it looks good.
  2679.  
  2680.  
  2681. Thomas W. Colthurst <thomasc@athena.mit.edu> clarifies the distinction
  2682. between IFS and the Fractal Transform:
  2683.  
  2684. It is time, once and for all, to put to death the Barnsley myth that
  2685. IFSs are good for image compression.  They are not.  Various algorithms
  2686. have been proposed for this "inverse problem" ranging from the trendy
  2687. (genetic algorithms) to the deep (moment methods) to the ad hoc (the
  2688. hungry algorithm) to the absurd (the so-called "graduate student
  2689. algorithm", consisting of locking up a grad student in a tiny office
  2690. with a SGI workstation and not letting them out until they come up
  2691. with a good IFS for your image).  They are all useless for practical
  2692. image compression.
  2693.  
  2694. In fact, there are even good theoretical reasons for believing that
  2695. IFSs will never be useful for image compression.  For example, even
  2696. if you have an IFS for object A and an IFS for object B, there is no
  2697. way to combine these IFSs to get an IFS for object A union B or
  2698. object A intersect B.
  2699.  
  2700. Even Barnsley himself admits, in his latest book, that he doesn't use
  2701. IFS image compression.  Instead, he uses the so-called "fractal
  2702. transform," which is really just a variant of vector quantization
  2703. where you use the image itself, sampled at a higher scale, as the
  2704. VQ codebook.  To be fair, the fractal transform can be analyzed using
  2705. local IFSs, but local IFSs are immensely more complicated and general
  2706. than normal IFSs, to the point where one feels suspect even using the
  2707. word "IFS" to describe them.
  2708.  
  2709. It should be emphasized that the fractal transform is a real, working
  2710. method that performs about as well as other existing methods like VQ
  2711. or the discrete cosine transform. The fractal transform will probably
  2712. never beat vector quantization (VQ) as for size of the compressed
  2713. image, but does have the advantage that you don't need to carry your
  2714. codebook around.  The latest results have it slightly winning over
  2715. the discrete cosine transform; only time and more research will tell
  2716. if this advantage persists.  Just like VQ, the fractal transform
  2717. takes a while to compress, but is quick at decompression (Barnsley's
  2718. company has hardware to do this in realtime).
  2719.  
  2720. In short, IFSs are good for just about everything fractals are (and
  2721. more!), but are absolutely horrid for image compression.
  2722.  
  2723.  
  2724. Programs:
  2725.  
  2726. Check http://links.uwaterloo.ca/ for pointers to some fractal compression
  2727. programs and lots of papers on fractal compression.
  2728.  
  2729. The Waterloo BragZone (http://links.uwaterloo.ca/bragzone.base.html
  2730. or ftp://links.uwaterloo.ca/pub/BragZone/ ) compares the results of
  2731. various image compression schemes against a 32 element test suite.
  2732. Numerous rate-distortion graphs, data tables, and sample images are available.
  2733.  
  2734. A fractal image compression program is available by ftp in
  2735. ftp://inls.ucsd.edu/pub/young-fractal/yuvpak20.zip ; it contains source for
  2736. compression and decompression, source for X-windows decompression,
  2737. MSDOS executables and images. [Note from FAQ maintainer: Fisher's
  2738. program (see below) implements the same algorithm but is more general;
  2739. see http://inls.ucsd.edu/y/Fractals/ for the source code.]
  2740.  
  2741. A fractal image decompression program (note: decompression only) is
  2742. available in ftp://inls.ucsd.edu/pub/inls-ucsd/fractal-2.0.tar
  2743. In the same directory, fractal_paper.ps.Z is the paper "Fractal image
  2744. compression" by Yuval Fisher, Siggraph 92.  Reading this paper is
  2745. required to understand how the Young compression programs (see above) works.
  2746.  
  2747. A note from Yuval Fisher <yfisher@ucsd.edu>:
  2748.  
  2749.     Connect to http://inls.ucsd.edu/y/Fractals/ .  There is
  2750.     information there on my new book of contributed articles on
  2751.     fractal image compression, as well as the book's table of
  2752.     contents, some C code to encode and decode raw byte files of any
  2753.     size using a quadtree method, a manual explaining the use of the
  2754.     code, a fractal image compression bibliography (not guaranteed to
  2755.     be complete or close to it), some better executable code with
  2756.     sample encodings, and the SIGGRAPH '92 course notes on fractal
  2757.     image compression (these are based on appendix A of Chaos and
  2758.     Fractals by Peitgen et al., Springer Verlag). [The C code is also
  2759.     available in ftp://inls.ucsd.edu/pub/inls-ucsd/frac_comp.tar.Z ]
  2760.  
  2761. Another fractal compression program is available by ftp in
  2762. ftp://vision.auc.dk/pub/Limbo/Limbo*.tar.Z. It is also based on quadtrees,
  2763. as yuvpak20 and frac_comp.
  2764.  
  2765. The source code for the program published in the Oct 93 issue of
  2766. Byte is in ftp://ftp.uu.net/published/byte/93oct/fractal.exe. This is
  2767. a self-extractible arc file (must be run on MSDOS for extraction).
  2768. The source code is for a TARGA video board. [Note from FAQ maintainer:
  2769. this code is taken from Barnsley's book "Fractal Image Compression";
  2770. it implements the brute force method and is thus very slow.]
  2771.  
  2772. Iterated Systems have released a beta version of their fractal imager.
  2773. It will let you view a number of formats including JPG and do
  2774. conversions to their fractal format.  The program can be downloaded
  2775. from http://www.iterated.com
  2776.  
  2777. "The Data Compression Book" (see [NEL 1996] in item 7 above) contains
  2778. a chapter on fractal compression; it includes source code for a simple
  2779. fractal compression program. The source is also available at
  2780. http://www.teaser.fr/~jlgailly/frac-1.0.tar.gz
  2781.  
  2782. Several fractal compression programs, including a volume coder, are available
  2783. at http://www.eecs.wsu.edu/~wcochran/
  2784.  
  2785. Several papers on fractal image compression are available on
  2786. ftp.informatik.uni-freiburg.de in directory /documents/papers/fractal . A
  2787. biliography is in ftp://schmance.uwaterloo.ca/pub/Fractal/fractal.biblio.ps.Z
  2788.  
  2789. References:
  2790.   A. Jacquin, 'Fractal image coding based on a theory of iterated
  2791.     contractive image transformations', Proc. SPIE Visual Communications
  2792.     and Image Processing, 1990, pages 227-239.  (The best paper that explains
  2793.     the concept in a simple way.)
  2794.  
  2795.   A. Jacquin, "A Fractal Theory of Iterated Markov Operators with
  2796.     Applications to Digital Image Coding", PhD Thesis, Georgia Tech, 1989.
  2797.   It can be obtained from university microfilms for $35, phone 1-800-521-0600.
  2798.  
  2799.   M. Barnsley, L. Anson, "Graphics Compression Technology, SunWorld,
  2800.     October 1991, pp. 42-52.
  2801.   M.F. Barnsley, A. Jacquin, F. Malassenet, L. Reuter & A.D. Sloan,
  2802.     'Harnessing chaos for image synthesis', Computer Graphics,
  2803.     vol 22 no 4 pp 131-140, 1988.
  2804.   M.F. Barnsley, A.E. Jacquin, 'Application of recurrent iterated
  2805.     function systems to images', Visual Comm. and Image Processing,
  2806.     vol SPIE-1001, 1988.
  2807.   A. Jacquin, "Image Coding Based on a Fractal Theory of Iterated Contractive
  2808.     Image Transformations" p.18, January 1992 (Vol 1 Issue 1) of IEEE Trans
  2809.     on Image Processing.
  2810.   A.E. Jacquin, 'A novel fractal block-coding technique for digital
  2811.     images', Proc. ICASSP 1990.
  2812.   G.E. Oien, S. Lepsoy & T.A. Ramstad, 'An inner product space
  2813.     approach to image coding by contractive transformations',
  2814.     Proc. ICASSP 1991, pp 2773-2776.
  2815.   D.S. Mazel, Fractal Modeling of Time-Series Data, PhD Thesis,
  2816.     Georgia Tech, 1991.    (One dimensional, not pictures)
  2817.   S. A. Hollatz, "Digital image compression with two-dimensional affine
  2818.     fractal interpolation functions", Department of Mathematics and
  2819.     Statistics, University of Minnesota-Duluth, Technical Report 91-2.
  2820.     (a nuts-and-bolts how-to-do-it paper on the technique)
  2821.   Stark, J., "Iterated function systems as neural networks",
  2822.     Neural Networks, Vol 4, pp 679-690, Pergamon Press, 1991.
  2823.   Monro D M and Dudbridge F, "Fractal block coding of images",
  2824.     Electronics Letters 28(11):1053-1054 (1992)
  2825.   Beaumont J M, "Image data compression using fractal techniques",
  2826.     British Telecom Technological Journal 9(4):93-108 (1991)
  2827.   Fisher Y, "Fractal image compression", Siggraph 92
  2828.   Graf S, "Barnsley's Scheme for the Fractal Encoding of Images",
  2829.     Journal Of Complexity, V8, 72-78 (1992).
  2830.   Monro D.M. 'A hybrid fractal transform', Proc ICASSP 93, pp. V: 169-72
  2831.   Monro D.M. & Dudbridge F. 'Fractal approximation of image blocks',
  2832.     Proc ICASSP 92, pp. III: 485-488
  2833.   Monro D.M., Wilson D., Nicholls J.A. 'High speed image coding with the Bath
  2834.     Fractal Transform', IEEE International Symposium on Multimedia Technologies
  2835.     Southampton, April 1993
  2836.   Jacobs, E.W., Y. Fisher and R.D. Boss.  "Image Compression:  A study
  2837.     of the Iterated Transform Method."  _Signal Processing 29_  (1992) 25-263
  2838.   Vrscay, Edward R.  "Iterated Function Systems:  Theory, Applications,
  2839.     and the Inverse Problem."  _Fractal Geometry and Analysis_,
  2840.     J. Belair and S. Dubuc (eds.)  Kluwer Academic, 1991.  405-468.
  2841.  
  2842. Books:
  2843.     Fractal Image Compression: Theory and Application, Yuval Fisher (ed.),
  2844.     Springer Verlag, New York, 1995.
  2845.     To order the book, call 1-800-SPRINGER and ask for the book with
  2846.     ISBN number 0-387-94211-4 or check http://www.springer-ny.com/
  2847.  
  2848.     Fractal Image Compression
  2849.     Michael F. Barnsley and Lyman P. Hurd
  2850.     ISBN 0-86720-457-5, ca. 250 pp., $49.95
  2851.     Copies can be ordered directly from the publisher by sending a message
  2852.     to kpeters@math.harvard.edu with name, address and a Mastercard or
  2853.     Visa card number with expiration date.
  2854.  
  2855. Barnsley's company is:
  2856.  
  2857. Iterated Systems, Inc.
  2858. 5550A Peachtree Parkway, Suite 650
  2859. Norcross, GA  30092
  2860. tel: 404-840-0310 or 1-800-4FRACTL
  2861. fax: 404-840-0806
  2862. In UK: Phone (0734) 880261, Fax (0734) 880360
  2863.  
  2864. ------------------------------------------------------------------------------
  2865.  
  2866. Subject: [18] I need specs and source for TIFF and CCITT group 4 Fax
  2867.  
  2868.  
  2869. Specs for Group 3 and 4 image coding (group 3 is very similar to group 4)
  2870. are in CCITT (1988) volume VII fascicle VII.3. They are recommendations
  2871. T.4 and T.6 respectively. There is also an updated spec contained in 1992
  2872. recommendations T.1 to T.6.
  2873.  
  2874. CCITT (now ITU-T) specs are available by anonymous ftp (see above answer on
  2875. V.42bis).  The T.4 and T.6 specs are on src.doc.ic.ac.uk in directory
  2876. /computing/ccitt/ccitt-standards/ccitt/1988/ascii, files 7_3_01.txt.Z and
  2877. 7_3_02.txt.Z respectively.
  2878.  
  2879. The following paper covers T.4, T.6 and JBIG:
  2880.  
  2881.   "Review of standards for electronic imaging for facsimile systems"
  2882.   in Journal of Electronic Imaging, Vol. 1, No. 1, pp. 5-21, January 1992.
  2883.  
  2884.  
  2885. Source code can be obtained as part of a TIFF toolkit - TIFF image
  2886. compression techniques for binary images include CCITT T.4 and T.6:
  2887.  
  2888.     ftp://ftp.sgi.com/graphics/tiff/tiff-v3.4beta035-tar.gz
  2889.     Contact: sam@engr.sgi.com
  2890.  
  2891. There is also a companion compressed tar file (v3.0pics.tar.Z) that
  2892. has sample TIFF image files. A draft of TIFF 6.0 is in TIFF6.ps.Z.
  2893. Concerning JPEG compression in TIFF 6.0, Tom Lane <tgl@sss.pgh.pa.us> adds:
  2894.  
  2895.   TIFF 6.0's scheme for incorporating JPEG compression (spec section 22) has
  2896.   a bunch of serious deficiencies.  Don't use it.  A revised design is given
  2897.   by TIFF Technical Note #2, ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt
  2898.   The revised design will replace section 22 in TIFF 7.0, and is implemented
  2899.   in Sam Leffler's libtiff.  See also item 75 of this FAQ for more JPEG info.
  2900.  
  2901. Software for reading and writing CCITT Group 3 and 4 images is
  2902. also available in directory ftp://merry.cs.monash.edu.au/pub/alanf/TIFF_FAX
  2903. Contact: Alan Finlay <alanf@bruce.cs.monash.edu.au>.
  2904.  
  2905.  
  2906. See also question 54 below.
  2907.  
  2908. ------------------------------------------------------------------------------
  2909.  
  2910. Subject: [19] What is JPEG?
  2911.  
  2912.  
  2913. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  2914. JPEG stands for Joint Photographic Experts Group, the original name of the
  2915. committee that wrote the standard.  JPEG is designed for compressing either
  2916. full-color or gray-scale digital images of "natural", real-world scenes.
  2917. It does not work very well on non-realistic images, such as cartoons or
  2918. line drawings.
  2919.  
  2920. JPEG does not handle black-and-white (1-bit-per-pixel) images, nor does it
  2921. handle motion picture compression.  Related standards for compressing those
  2922. types of images exist, and are called JBIG and MPEG respectively.
  2923.  
  2924. Regular JPEG is "lossy", meaning that the image you get out of decompression
  2925. isn't quite identical to what you originally put in.  The algorithm achieves
  2926. much of its compression by exploiting known limitations of the human eye,
  2927. notably the fact that small color details aren't perceived as well as small
  2928. details of light-and-dark.  Thus, JPEG is intended for compressing images that
  2929. will be looked at by humans.  If you plan to machine-analyze your images, the
  2930. small errors introduced by JPEG may be a problem for you, even if they are
  2931. invisible to the eye.  The JPEG standard includes a separate lossless mode,
  2932. but it is rarely used and does not give nearly as much compression as the
  2933. lossy mode.
  2934.  
  2935. Question 75 "Introduction to JPEG" (in part 2 of this FAQ) gives an overview
  2936. of how JPEG works and provides references for further reading.  Also see the
  2937. JPEG FAQ article, which covers JPEG software and usage hints.  The JPEG FAQ
  2938. http://www.faqs.org/faqs/jpeg-faq/part1/preamble.html is
  2939. posted regularly in news.answers by Tom Lane <tgl@netcom.com>.
  2940. (See also question 53 "Where are FAQ lists archived".)
  2941.  
  2942. For JPEG software, see item 15 above.
  2943. For JPEG hardware, see item 85 in part 3 of this FAQ.
  2944.  
  2945. ------------------------------------------------------------------------------
  2946.  
  2947. Subject: [20] I am looking for source of an H.261/H.263 codec and MPEG
  2948.  
  2949. Many standards and draft recommendations (including H.261, H.263,
  2950. H.320, H.324), are available in http://www.imtc.org/imtc/
  2951.  
  2952. The H.261 spec is available in
  2953. ftp://ftp.fdn.org/pub/Library/Ccitt-standards/ccitt/1992/h/h261.doc.z
  2954.  
  2955. For H.261 hardware, see item 85 in part 3 of this FAQ.
  2956.  
  2957. Current drafts of H.324 and related recommendations including H.263 are
  2958. available in ftp://ftp.std.com/vendors/PictureTel/h324/
  2959.  
  2960. Telenor Research have made available a complete simulation of
  2961. H.263. See http://www.nta.no/brukere/DVC/h263_software
  2962.  
  2963. from Thierry TURLETTI <turletti@sophia.inria.fr>:
  2964.  
  2965.      IVS (INRIA VIDEOCONFERENCING SYSTEM)
  2966.       - X11-based videoconferencing tool for SPARC, HP,  DEC  and
  2967.      Silicon Graphic workstations.
  2968.  
  2969.      ivs allows users  to  conduct  multi-host  audio  and  video
  2970.      conferences  over  the  Internet. ivs requires a workstation
  2971.      with a screen with 1, 4, 8 or  24  bits  depth.   Multi-host
  2972.      conferences  require  that  the  kernel support multicast IP
  2973.      extensions (RFC 1112).
  2974.  
  2975.      On video input, video frames are grabbed  by  the  VideoPix,
  2976.      SunVideo or Parallax boards for SparcStations or Raster Rops
  2977.      board for HP stations or the IndigoVideo board for SGI  IRIS
  2978.      Indigo workstations.  or the VIDEOTX board for DEC stations.
  2979.      No special hardware apart from  the  workstation's  build-in
  2980.      audio hardware is required for audio conference.
  2981.  
  2982.      Video encoding is done according to the H.261 standard.
  2983.      The video stream can be encoded in either Super CIF 
  2984.      (704x576 pixels) format or  CIF  (352x288  pixels) format or 
  2985.      QCIF (176x144 pixels). Default format is CIF.
  2986.  
  2987.      Sources, binaries & manuals are freely available by anonymous 
  2988.      ftp from zenon.inria.fr in the rodeo/ivs directory. An INRIA
  2989.      report describing this application is also available in the 
  2990.      same directory.
  2991.  
  2992.      If you ftp & use this package, please send all remarks or 
  2993.      modifications made to <turletti@sophia.inria.fr>. If you want 
  2994.      to be added or deleted to the ivs-users mailing list, please send 
  2995.      e-mail to ivs-users-request@sophia.inria.fr.
  2996.  
  2997.  
  2998. from Andy Hung <achung@cs.stanford.edu>:
  2999.  
  3000. Public domain UNIX C source code to do both image and image sequence
  3001. compression and decompression is available by anonymous ftp:
  3002.  
  3003. MPEG-I            ftp://havefun.stanford.edu/pub/mpeg/MPEGv*.tar.Z
  3004. CCITT H.261(P*64)    ftp://havefun.stanford.edu/pub/p64/P64v*.tar.Z
  3005. JPEG            ftp://havefun.stanford.edu/pub/jpeg/JPEGv*.tar.Z
  3006.  
  3007. These codecs operate on raw raster scanned images.
  3008.  
  3009. A software program to display raw raster-scanned YUV images and image
  3010. sequences on X grayscale or color monitors is provided by a program in
  3011. ftp://havefun.stanford.edu/pub/cv/CVv*.tar.Z
  3012. If you are using the codecs above, we recommend that you ftp this file
  3013. over as well.
  3014.  
  3015. The source code has been compiled on DEC and SUN workstations.
  3016. Caution: the P64 codec has not been tested compliant (any available
  3017. p64 video streams would be much appreciated - please let us know at
  3018. achung@cs.stanford.edu).  The other codecs have been tested with
  3019. streams from other encoders.
  3020.  
  3021. We also have some IPB MPEG-I video coded streams in pub/mpeg/*.mpg;
  3022. and P64 video streams in pub/p64/*.p64 that we have generated using
  3023. our codecs.
  3024.  
  3025. For a more complete description see the file
  3026. havefun.stanford.edu:pub/README.
  3027.  
  3028. ------------------------------------------------------------------------------
  3029.  
  3030. Subject: [25] Fast DCT (Discrete Cosine Transform) algorithms
  3031.  
  3032.  
  3033. Many image compression methods, including the JPEG, MPEG, and H.261 standards,
  3034. are based on the discrete cosine transform.  A good overall introduction to
  3035. DCT is the book "Discrete Cosine Transform---Algorithms, Advantages,
  3036. Applications" by K.R. Rao and P. Yip (Academic Press, London, 1990),
  3037. ISBN 0-12-580203-X. This has an extensive, though already dated, bibliography.
  3038.  
  3039. Here are some references mostly provided by Tom Lane <tgl@sss.pgh.pa.us>.
  3040. (This list is now rather dated.)
  3041. Most of these are in IEEE journals or conference proceedings, notably
  3042. ICASSP = IEEE Intl. Conf. on Acoustics, Speech, and Signal Processing.
  3043. ICCAS = IEEE Intl. Conf. on Circuits and Systems.
  3044. DCC = Data Compression Conference.
  3045.  
  3046. Polynomial Transform Computation of the 2-D DCT, Duhamel & Guillemot,
  3047.   ICASSP '90 p. 1515.
  3048. A Forward-Mapping Realization of the Inverse DCT, McMillan & Westover,
  3049.   DCC '92 p. 219.
  3050. A Fast Algorithm for 2-D DCT, Cho, Yun & Lee, ICASSP '91 p. 2197.
  3051. Fast Algorithm and Implementation of 2-D DCT, Cho & Lee, Tr. CAS v38 p. 297.
  3052. A DCT Chip based on a new Structured and Computationally Efficient DCT
  3053.   Algorithm, Duhamel, Guillemot & Carlach, ICCAS '90 p. 77.
  3054. Trade-offs in the Computation of Mono- and Multi-dimensional DCTs,
  3055.   Vetterli, Duhamel & Guillemot, ICASSP '89 p. 999.
  3056. Practical Fast 1-D DCT Algorithms with 11 Multiplications,
  3057.   Loeffler, Ligtenberg & Moschytz, ICASSP '89 p. 988.
  3058. New Scaled DCT Algorithms for Fused Multiply/Add Architectures,
  3059.   Linzer & Feig, ICASSP '91 p. 2201.
  3060. Fast Algorithms for the 2-D Discrete Cosine Transform, Kamangar & Rao,
  3061.   IEEE Tr. Computers, v C-31 p. 899.
  3062. Fast 2-D Discrete Cosine Transform, Vetterli, ICASSP '85 p. 1538.
  3063. A Two-Dimensional Fast Cosine Transform, Haque, Tr. ASSP v ASSP-33 p. 1532.
  3064. Real-Time Parallel and Fully Pipelined 2-D DCT Lattice Structures with
  3065.   Application to HDTV Systems, Chiu & Liu, Tr. CAS for Video Tech, v 2 p. 25.
  3066. J.F. Blinn, "What's the Deal with the DCT", IEEE Computer Graphics and
  3067.   Applications, July 1993, pp.78-83.
  3068. A C Hung and TH-Y Meng, "A Comparison of fast DCT algorithms, Multimedia 
  3069.   Systems", No. 5 Vol. 2, Dec 1994
  3070.  
  3071. For actual implementations, try the JPEG and MPEG software listed
  3072. in item 15.
  3073.  
  3074. ------------------------------------------------------------------------------
  3075.  
  3076. Subject: [26] Are there algorithms and standards for audio compression?
  3077.  
  3078.  
  3079. Yes. See the introduction to MPEG given in part 2 of this FAQ.
  3080.  
  3081. A lossless compressor for 8bit and 16bit audio data (.au) is available
  3082. in ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/coding/shorten.tar.gz
  3083. or http://www.softsound.com/ShortenDownload.html
  3084. Shorten works by using Huffman coding of prediction residuals.
  3085. Compression is generally better than that obtained by applying general
  3086. purpose compression utilities to audio files. Also supports lossy
  3087. compression.  Contact: Tony Robinson <ajr@eng.cam.ac.uk>.
  3088.  
  3089. Audio software is available on sunsite.unc.edu in subdirectories of
  3090. /pub/electronic-publications/IUMA/audio_utils:
  3091. - An MPEG audio player is in mpeg_players/Workstations/maplay1_2.tar.Z.
  3092. - The sources of the XING MPEG audio player for Windows is in
  3093.   mpeg_players/Windows/mpgaudio.zip.
  3094. - An encoder/decoder is in converters/source/mpegaudio.tar.Z.
  3095.  
  3096. MSDOS audio software is available in
  3097. ftp://ftp.simtel.net/pub/simtelnet/msdos/sound/
  3098. In particular, MPEG-2 audio software is in ampegsrc.zip and ampeg43.zip.
  3099.  
  3100. MPEG audio files are available in ftp.iuma.com and http://www.iuma.com/
  3101.  
  3102. Copied from the comp.dsp FAQ posted by guido@cwi.nl (Guido van Rossum):
  3103.  
  3104.   Strange though it seems, audio data is remarkably hard to compress
  3105.   effectively.  For 8-bit data, a Huffman encoding of the deltas between
  3106.   successive samples is relatively successful.  For 16-bit data,
  3107.   companies like Sony and Philips have spent millions to develop
  3108.   proprietary schemes.
  3109.  
  3110.   Public standards for voice compression are slowly gaining popularity,
  3111.   e.g. CCITT G.721 and G.723 (ADPCM at 32 and 24 kbits/sec).  (ADPCM ==
  3112.   Adaptive Delta Pulse Code Modulation.)  Free source code for a *fast*
  3113.   32 kbits/sec ADPCM (lossy) algorithm is available by ftp from ftp.cwi.nl
  3114.   as /pub/audio/adpcm.shar.  (** NOTE: if you are using v1.0, you should get
  3115.   v1.1, released 17-Dec-1992, which fixes a serious bug -- the quality
  3116.   of v1.1 is claimed to be better than uLAW **)
  3117.  
  3118.   (Note that U-LAW and silence detection can also be considered
  3119.   compression schemes.)
  3120.  
  3121. Information and source code for adpcm are available in
  3122. http://www.nb.rockwell.com/ref/adpcm.html
  3123.  
  3124. Source for Sun's free implementation of CCITT compression types G.711,
  3125. G.721 and G.723 is in ftp://ftp.cwi.nl/pub/audio/ccitt-adpcm.tar.gz
  3126.  
  3127. You can get a G.721/722/723 package by email to teledoc@itu.arcom.ch, with
  3128. GET ITU-3022
  3129. as the *only* line in the body of the message.
  3130.  
  3131.  
  3132. A note on u-law from Markus Kuhn <mskuhn@immd4.informatik.uni-erlangen.de>:
  3133.  
  3134.   u-law (more precisely (greek mu)-law or 5-law if you have an 8-bit
  3135.   ISO terminal) is more an encoding then a compression method,
  3136.   although a 12 to 8 bit reduction is normally part of the encoding.
  3137.   The official definition is CCITT recommendation G.711. If you want
  3138.   to know how to get CCITT documents, check the Standards FAQ
  3139.   posted to news.answers or get the file standards-faq by ftp in
  3140.   directory ftp://rtfm.mit.edu/pub/usenet/news.answers/
  3141.  
  3142.  
  3143. See also the comp.dsp FAQ for more information on:
  3144.  
  3145. - The U.S. DoD's Federal-Standard-1016 based 4800 bps code excited linear
  3146.   prediction voice coder version 3.2a (CELP 3.2a)
  3147. - The U.S. DoD's Federal-Standard-1015/NATO-STANAG-4198 based 2400 bps
  3148.   linear prediction coder version 53 (LPC-10e v53)
  3149. - Realtime DSP code and hardware for FS-1015 and FS-1016
  3150.  
  3151. The comp.dsp FAQ is in comp.dsp with subject "FAQ: Audio File Formats" and in
  3152. ftp://rtfm.mit.edu/pub/usenet/news.answers/audio-fmts/part1
  3153.  
  3154.  
  3155. CELP C code for Sun SPARCs is in ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z
  3156. An LPC10 speech coder is in ftp://ftp.super.org/pub/speech/lpc10-1.0.tar.gz ;
  3157. a derived version is in http://www.arl.wustl.edu/~jaf/lpc/lpc10-1.1.tar.gz
  3158.  
  3159. Source code for ITU-T (CCITT) G.728 Low Delay CELP speech compression
  3160. is in ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/sources/ldcelp-2.0.tar.gz
  3161.  
  3162.  
  3163. Recommended reading:
  3164.   Digital Coding of Waveforms: Principles and Applications to Speech and
  3165.   Video.  N. S. Jayant and Peter Noll.  Prentice-Hall, 1984, ISBN
  3166.   0-13-211913-7.
  3167.  
  3168. Information on GSM sound compression is available at
  3169. http://ccnga.uwaterloo.ca/~jscouria/gsm.html
  3170.  
  3171.  
  3172. from Markus Kuhn <mskuhn@immd4.informatik.uni-erlangen.de>:
  3173.  
  3174.   One highest quality sound compression format is called ASPEC and has
  3175.   been developed by a team at the Frauenhofer Institut in Erlangen (Germany)
  3176.   and others.
  3177.  
  3178.   ASPEC produces CD like quality and offers several bitrates, one is
  3179.   128 kbit/s. It is a lossy algorithm that throws away frequencies that
  3180.   aren't registered in the human cochlea in addition to sophisticated
  3181.   entropy coding. The 64 kbit/s ASPEC variant might soon bring hifi
  3182.   quality ISDN phone connections. It has been implemented on standard DSPs.
  3183.  
  3184.   The Layer 3 MPEG audio compression standard now contains what is officially
  3185.   called the best parts of the ASPEC and MUSICAM algorithms. A reference is:
  3186.  
  3187.     K.Brandenburg, G.Stoll, Y.F.Dehery, J.D.Johnston, L.v.d.Kerkhof,
  3188.     E.F.Schroeder: "The ISO/MPEG-Audio Codec: A Generic Standard for Coding
  3189.     of High Quality Digital Audio",
  3190.     92nd. AES-convention, Vienna 1992, preprint 3336
  3191.  
  3192.  
  3193. from Jutta Degener <jutta@cs.tu-berlin.de> and Carsten Bormann
  3194. <cabo@cs.tu-berlin.de>:
  3195.  
  3196.   GSM 06.10 13 kbit/s RPE/LTP speech compression available
  3197.   --------------------------------------------------------
  3198.  
  3199.   The Communications and Operating Systems Research Group (KBS) at the
  3200.   Technische Universitaet Berlin is currently working on a set of
  3201.   UNIX-based tools for computer-mediated telecooperation that will be
  3202.   made freely available.
  3203.  
  3204.   As part of this effort we are publishing an implementation of the
  3205.   European GSM 06.10 provisional standard for full-rate speech
  3206.   transcoding, prI-ETS 300 036, which uses RPE/LTP (residual pulse
  3207.   excitation/long term prediction) coding at 13 kbit/s.
  3208.  
  3209.   GSM 06.10 compresses frames of 160 13-bit samples (8 kHz sampling
  3210.   rate, i.e. a frame rate of 50 Hz) into 260 bits; for compatibility
  3211.   with typical UNIX applications, our implementation turns frames of 160
  3212.   16-bit linear samples into 33-byte frames (1650 Bytes/s).
  3213.   The quality of the algorithm is good enough for reliable speaker
  3214.   recognition; even music often survives transcoding in recognizable 
  3215.   form (given the bandwidth limitations of 8 kHz sampling rate).
  3216.  
  3217.   Version 1.0 of the implementation is available per anonymous ftp from
  3218.   ftp.cs.tu-berlin.de in the directory /pub/local/kbs/tubmik/gsm/ ;
  3219.   more information about the library can be found on the World-Wide Web
  3220.   at http://www.cs.tu-berlin.de/~jutta/toast.html .
  3221.   Questions and bug reports should be directed to jutta@cs.tu-berlin.de
  3222.   and cabo@informatik.uni-bremen.de .
  3223.  
  3224.  
  3225. from Bob Kimball <rkimball@qualcomm.com>:
  3226.  
  3227.   I work for Qualcomm Inc. and we are designing a digital cellular telephone
  3228.   system.  Our phone uses our variable rate vocoder (QCELP) which is designed
  3229.   for speach and compresses 64Kb/s speach to 8Kb/s through 1Kb/s with 8Kb/s
  3230.   being full rate and 1Kb/s for 1/8 rate speach.  It works great for speach.
  3231.  
  3232.   The QCELP process is documented in our Common Air Interface (CAI) which is
  3233.   available for anonymous ftp from lorien.qualcomm.com in /pub/cdma
  3234.   each chapter is a postscript file.  The vocoder is described in appendix A.
  3235.   The whole document is quite large.  This is the document which is currently
  3236.   going through the TIA standard committee so it is not a final version.  The
  3237.   appendix on the vocoder should be almost identical to the final version...
  3238.   whenever that comes out.
  3239.  
  3240.  
  3241. from Nicola Ferioli <ser1509@cdc835.cdc.polimi.it>:
  3242.  
  3243.   ftp://ftp.simtel.net/pub/simtelnet/msdos/sound/vocpak20.zip
  3244.     Lossless 8-bit sound file compressor
  3245.  
  3246.   VOCPACK is a compressor/decompressor for 8-bit digital sound using a
  3247.   lossless algorithm; it is useful to save disk space without degrading
  3248.   sound quality.  It can compress signed and unsigned data, sampled at any
  3249.   rate, mono or stereo.  Since the method used is not lossy, it isn't
  3250.   necessary to strip file headers before compressing.
  3251.  
  3252.   VOCPACK was developed for use with .VOC (SoundBlaster) and .WAV (Windows)
  3253.   files, but any 8-bit sound can be compressed since the program takes no
  3254.   assumptions about the file structure.
  3255.  
  3256.   The typical compression ratio obtained goes from 0,8 for files sampled at
  3257.   11 KHz to 0,4 for 44 Khz files.  The best results are obtained with 44 KHz
  3258.   sounds (mono or stereo): general-purpose archivers create files that can be
  3259.   twice longer than the output of VOCPACK.  You can obtain smaller values
  3260.   using lossy compressors but if your goal is to keep the sound quality
  3261.   unaltered you should use a lossless program like VOCPACK.
  3262.  
  3263. from Harald Popp <popp@iis.fhg.de>:
  3264.  
  3265.   new version 1.0 of ISO/MPEG1 Audio Layer 3 Shareware available
  3266.  
  3267.   major improvements of the new version:
  3268.        - encoder works twice as fast
  3269.        - improved file handling for encoder including .WAV files
  3270.  
  3271.   You may download the shareware from fhginfo.fhg.de (153.96.1.4)
  3272.   from the directory /pub/layer3
  3273.  
  3274.   The source code for the MPEG1 audio decoder layer 1, 2 and 3 is
  3275.   now available on fhginfo.fhg.de (153.96.1.4) in /pub/layer3/public_c.
  3276.  
  3277.   There are two files:
  3278.      mpeg1_iis.tar.Z     (Unix: lines seperated by line feed only)
  3279.      mpeg1iis.zip        (PC: lines seperated by carriage return and line feed)
  3280.  
  3281. For more information about this product and MPEG Audio Layer 3, see
  3282. the document "Informations about MPEG Audio Layer-3" maintained by
  3283. Juergen Zeller <zeller@iis.fhg.de>, available in
  3284. ftp://fhginfo.fhg.de/pub/layer3/MPEG_Audio_L3_FAQ.html
  3285.  
  3286. from Monty <xiphmont@athena.mit.edu>:
  3287.  
  3288.   OggSquish is a compression package designed to reduce the file size of
  3289.   digitized 8 and 16 bit audio samples (or samples of any periodic
  3290.   data).  OggSquish will operate on files sampled at any speed, but it is
  3291.   designed to work with very high quality samples, for example, CD
  3292.   quality samples.
  3293.  
  3294.   [OggSquish is now at http://world.std.com/~xiph/OggSquish/ or
  3295.    http://web.mit.edu/afs/sipb/user/xiphmont/OggSquish/html-pages/ ]
  3296.  
  3297. from Dmitrij V. Schmunk <shmunk@csd.inp.nsk.su>:
  3298.  
  3299.   Take a look at http://www.inp.nsk.su/~shmunk/
  3300.   This compressor gives you about 2-3 times better compression
  3301.   for 44.1kHz stereo sound then MPEG layer-3.
  3302.  
  3303. from Dennis Lee <denlee@ecf.utoronto.ca>
  3304.  
  3305.   WA incorporates lossless audio codecs (similar to SHORTEN and OggSquish)
  3306.   into an easy to use archiver program.  WA only supports compression of the
  3307.   popular ".WAV" audio format.  To the author's knowledge, WA can compress
  3308.   waveform data better than any existing software.  With default settings, WA
  3309.   also compresses faster than PKZIP, so it is convenient to use.  This
  3310.   software can be found at http://www.ecf.utoronto.ca/~denlee/software.html
  3311.  
  3312. from Jack Berlin <jberlin@jpg.com>:
  3313.  
  3314.   Pegasus has a new lossless sound compressor based on our patent pending
  3315.   arithmetic coder. Currently beats Shorten in all cases. Trial app for
  3316.   Windows: ftp://207.69.208.43/jpg.com/SPSEXE.ZIP  ($39 to register)
  3317.   http://www.pegasusimaging.com/sound.html
  3318.  
  3319. ------------------------------------------------------------------------------
  3320.  
  3321. Subject: [30] My archive is corrupted!
  3322.  
  3323.  
  3324. The two most common reasons for this are
  3325.  
  3326. (1) failing to use the magic word "tenex" (when connected to SIMTEL20 and
  3327.     other TOPS20 systems) or "binary" (when connected to UNIX systems) when
  3328.     transferring the file from an ftp site to your host machine.  The
  3329.     reasons for this are technical and boring.  A synonym for "tenex" is
  3330.     "type L 8", in case your ftp doesn't know what "tenex" means.
  3331.  
  3332. (2) failing to use an eight-bit binary transfer protocol when transferring
  3333.     the file from the host to your PC.  Make sure to set the transfer type
  3334.     to "binary" on both your host machine and your PC.
  3335.  
  3336. gopher is also known to corrupt binary files. In particular, if gzip
  3337. complains about a multi-part file, it's likely that the .gz file
  3338. has been corrupted by gopher. Use ftp in binary mode instead.
  3339.  
  3340. ------------------------------------------------------------------------------
  3341.  
  3342. Subject: [31] pkunzip reports a CRC error!
  3343.  
  3344.  
  3345. The portable zip 1.1 contains many workarounds for undocumented restrictions
  3346. in pkunzip. Compatibility is ensured for pkunzip 1.10 only. All previous
  3347. versions (pkunzip 1.0x) have too many bugs and cannot be supported. This
  3348. includes Borland unzip.
  3349.  
  3350. So if your pkunzip reports a CRC error, check that you are not using
  3351. an obsolete version. Get either pkzip 2.04g or unzip 5.12 (see question
  3352. 2 above for ftp sites). To generate zip files compatible with pkunzip 1.10,
  3353. use zip 1.1 (see item 2 above for ftp site).
  3354.  
  3355. ------------------------------------------------------------------------------
  3356.  
  3357. Subject: [32] VMS zip is not compatible with pkzip!
  3358.  
  3359.  
  3360. The problem is most likely in the file transfer program.
  3361.  
  3362. Many use kermit to transfer zipped files between PC and VMS VAX.  The
  3363. following VMS kermit settings make VMS-ZIP compatible with PKZIP:
  3364.  
  3365.                                              VMS kermit        PC kermit
  3366.                                            ---------------   --------------
  3367.  
  3368. Uploading PKZIPped file to be UNZIPped:    set fi ty fixed    set fi ty bi
  3369. Downloading ZIPped file to be PKUNZIPped:  set fi ty block    set fi ty bi
  3370.  
  3371. If you are not using kermit, transfer a file created by pkzip on MSDOS
  3372. to VMS, transfer it back to your PC and check that pkunzip can extract it.
  3373.  
  3374. ------------------------------------------------------------------------------
  3375.  
  3376. Subject: [33] I have a problem with Stacker or DoubleSpace!
  3377.  
  3378.  
  3379. The newsgroup comp.compression is *not* the appropriate place to
  3380. discuss about one specific program on one specific operating system.
  3381. Since you have bought a legal copy of Stacker or MSDOS 6.x, you have
  3382. the documentation of your product; please read it. If you can't find
  3383. the answer in the documentation, please report the problem to the Stac
  3384. or Microsoft customer support. (For Stac, use one of StacTec@aol.com,
  3385. StacMacTec@aol.com or StacOS2tec@aol.com.)  If you really feel that the
  3386. net has to know about your problem, please post in one of the MSDOS
  3387. newsgroups, such as comp.os.msdos.apps or comp.binaries.ibm.pc.d.
  3388.  
  3389. ------------------------------------------------------------------------------
  3390.  
  3391. Subject: [50] What is this 'tar' compression program?
  3392.  
  3393.  
  3394. tar is not a compression program. It just combines several files
  3395. into one, without compressing them. tar file are often compressed with
  3396. 'compress', resulting in a .tar.Z file. See question 2, file type .tar.Z.
  3397. GNU tar has the capability to (de)compress files as well.
  3398.  
  3399. When you have to archive a lot of very small files, it is often
  3400. preferable to create a single .tar file and compress it, than to
  3401. compress the individual files separately. The compression program can
  3402. thus take advantage of redundancy between separate files.  The
  3403. disadvantage is that you must uncompress the whole .tar file to
  3404. extract any member. You can also improve compression by grouping
  3405. files by type, as in:
  3406.  
  3407.   tar cvf - `ls | sort -t. +1` | gzip > file.tar.gz
  3408.  
  3409. ------------------------------------------------------------------------------
  3410.  
  3411. Subject: [51] I need a CRC algorithm
  3412.  
  3413.  
  3414. As its name implies (Cyclic Redundancy Check) a crc adds redundancy whereas
  3415. the topic of this group is to remove it. Yet this question comes up often in
  3416. comp.compression.
  3417.  
  3418. The file ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt is a pretty
  3419. comprehensive description of the whole CRC concept, including a C program.
  3420.  
  3421. See also:
  3422. - Schwaderer W.D., "CRC Calculation", April 85 PC Tech Journal, pp.118-133.
  3423. - "Calculating CRCs by Bits and Bytes", BYTE Magazine, September 1986
  3424. - Ramabadran T.V., Gaitonde S.S., "A tutorial on CRC computations", IEEE
  3425.   Micro, Aug 1988.
  3426. - the source of all archivers, such as the file makecrc.c in the Info-ZIP
  3427.   sources (see extension .zip in item 2)
  3428.  
  3429.  
  3430. The following C code (by Rob Warnock <rpw3@sgi.com>) does CRC-32 in
  3431. BigEndian/BigEndian byte/bit order.  That is, the data is sent most
  3432. significant byte first, and each of the bits within a byte is sent most
  3433. significant bit first, as in FDDI. You will need to twiddle with it to do
  3434. Ethernet CRC, i.e., BigEndian/LittleEndian byte/bit order. [Left as an
  3435. exercise for the reader.]
  3436.  
  3437. The CRCs this code generates agree with the vendor-supplied Verilog models
  3438. of several of the popular FDDI "MAC" chips.
  3439.  
  3440. u_long crc32_table[256];
  3441. /* Initialized first time "crc32()" is called. If you prefer, you can
  3442.  * statically initialize it at compile time. [Another exercise.]
  3443.  */
  3444.  
  3445. u_long crc32(u_char *buf, int len)
  3446. {
  3447.         u_char *p;
  3448.         u_long  crc;
  3449.  
  3450.         if (!crc32_table[1])    /* if not already done, */
  3451.                 init_crc32();   /* build table */
  3452.         crc = 0xffffffff;       /* preload shift register, per CRC-32 spec */
  3453.         for (p = buf; len > 0; ++p, --len)
  3454.                 crc = (crc << 8) ^ crc32_table[(crc >> 24) ^ *p];
  3455.         return ~crc;            /* transmit complement, per CRC-32 spec */
  3456. }
  3457.  
  3458. /*
  3459.  * Build auxiliary table for parallel byte-at-a-time CRC-32.
  3460.  */
  3461. #define CRC32_POLY 0x04c11db7     /* AUTODIN II, Ethernet, & FDDI */
  3462.  
  3463. init_crc32()
  3464. {
  3465.         int i, j;
  3466.         u_long c;
  3467.  
  3468.         for (i = 0; i < 256; ++i) {
  3469.                 for (c = i << 24, j = 8; j > 0; --j)
  3470.                         c = c & 0x80000000 ? (c << 1) ^ CRC32_POLY : (c << 1);
  3471.                 crc32_table[i] = c;
  3472.         }
  3473. }
  3474.  
  3475. ------------------------------------------------------------------------------
  3476.  
  3477. Subject: [52] What about those people who continue to ask frequently asked
  3478.               questions in spite of the frequently asked questions document?
  3479.  
  3480.  
  3481. Just send them a polite mail message, referring them to this document.
  3482. There is no need to flame them on comp.compression.  That would just
  3483. add more noise to this group.  Posted answers that are in the FAQ are
  3484. just as annoying as posted questions that are in the FAQ.
  3485.  
  3486. ------------------------------------------------------------------------------
  3487.  
  3488. Subject: [53] Where are FAQ lists archived?
  3489.  
  3490.  
  3491. Many are crossposted to news.answers.  That newsgroup should have a
  3492. long expiry time at your site; if not, talk to your sysadmin.
  3493.  
  3494. FAQ lists are available in http://www.faqs.org/faqs/ and ftp://rtfm.mit.edu
  3495. The comp.compression FAQ that you are reading is in
  3496.   http://www.faqs.org/faqs/compression-faq/part1/preamble.html
  3497.   http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html
  3498.   ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/
  3499.  
  3500. If you don't have FTP access, you can access the archives by mail
  3501. server.  Send an email message to mail-server@rtfm.mit.edu
  3502. containing the commands
  3503.     send usenet/news.answers/compression-faq/part1
  3504.     send usenet/news.answers/compression-faq/part2
  3505.     send usenet/news.answers/compression-faq/part3
  3506. For instructions, send an email message to the same address with the
  3507. words "help" and "index" (no quotes) on separate lines. If you don't
  3508. get a reply, check your return address, or add a line such as
  3509.     path myname@foo.edu
  3510.  
  3511. ------------------------------------------------------------------------------
  3512.  
  3513. Subject: [54] I need specs for graphics formats
  3514.  
  3515. Get the book by Murray & vanRyper "Encyclopedia of graphics file formats",
  3516. O'Reilly & associates, ISBN 1-56592-058-9.
  3517.  
  3518. See also the comp.graphics FAQ and the Graphics Formats FAQ. The latter is in
  3519. ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq/
  3520. http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/fileformats-faq/top.html
  3521.  
  3522. Check also "The File Format Collection" in http://www.wotsit.demon.co.uk
  3523.  
  3524. ------------------------------------------------------------------------------
  3525.  
  3526. Subject: [55] Where can I find Lenna and other images?
  3527.  
  3528. The Waterloo BragZone (http://links.uwaterloo.ca/bragzone.base.html
  3529. or ftp://links.uwaterloo.ca:/pub/BragZone/ ) compares the results of
  3530. various image compression schemes against a 32 element test suite.
  3531. Sample images are available.
  3532.  
  3533. The Computer Vision Home Page has many links to test images in
  3534. http://www.cs.cmu.edu:80/afs/cs/project/cil/ftp/html/v-images.html
  3535.  
  3536. A bunch of standard images (lenna, baboon, cameraman, crowd, moon
  3537. etc..) used to be in ftp://eedsp.gatech.edu/database/images . The
  3538. images are in 256-level grayshades (256x256 pixels, 256 "colors").
  3539.  
  3540. [Note: the site ipl.rpi.edu mentioned below keeps changing. Images
  3541. stay there for a while then disappear. They are again available at
  3542. the time of writing (27 Dec 93).]
  3543.  
  3544. The site ipl.rpi.edu (128.113.14.50) has standard images in two
  3545. directories:
  3546.    ftp://ipl.rpi.edu/pub/image/still/usc 
  3547.    ftp://ipl.rpi.edu/pub/image/still/canon
  3548.  
  3549. (The directory /pub/image/sequence was taken offline because of
  3550. possible copyright problems, but has come back again. In particular,
  3551. Miss America is in subdirectories of /pub/image/sequence/missa.)
  3552.  
  3553. In each of those directories are (usually) the following directories:
  3554.    bgr     - 24 bit blue, green, red
  3555.    color   - 24 bit red, green, blue
  3556.    gray    - 8 bit grayscale uniform weighted
  3557.    gray601 - 8 bit grayscale CCIR-601 weighted
  3558.  
  3559. And in these directories are the actual images.  
  3560.  
  3561. For example, the popular lena image is in
  3562.    ftp://ipl.rpi.edu/pub/image/still/usc/bgr/lena        # 24 bit BGR
  3563.    ftp://ipl.rpi.edu/pub/image/still/usc/gray/lena-y.ras # 8 bit gray
  3564.  
  3565. All of the images are in Sun rasterfile format.  You can use the pbm
  3566. utilities to convert them to whatever format is most convenient.
  3567. [pbm is available in ftp://ftp.ee.lbl.gov/pbmplus*.tar.Z ].
  3568. Questions about the ipl archive should be sent to help@ipl.rpi.edu.
  3569.  
  3570.  
  3571. There are few gray-scale still images and some raw data of test results
  3572. available in directory ftp://nic.funet.fi/pub/graphics/misc/test-images/
  3573. There are lots of .gif images in ftp://nic.funet.fi/pub/pics/
  3574.  
  3575. Medical images can be found in:
  3576.   ftp://decaf.stanford.edu/pub/images/medical/mri
  3577.   ftp://eedsp.gatech.edu/database/images/wchung/medical
  3578.   ftp://omicron.cs.unc.edu/pub/projects/softlab/CHVRTD
  3579.  
  3580. The WWW address for the National Library of Medicine is http://www.nlm.nih.gov
  3581. A list of health and medical related Internet resources is available ftp://in
  3582. ftp.sura.net/pub/nic/HealthResources/medical.resources.3-94
  3583.  
  3584. Rodney Peck <rodney@balltown.cma.com> is interested in some method
  3585. of establishing a canonical ftp database of images but does not have
  3586. the resources to provide an ftp site for that database. Send suggestions to
  3587. rodney@balltown.cma.com.
  3588.  
  3589.  
  3590. Beware: the same image often comes in many different forms, at
  3591. different resolutions, etc... The original lenna image is 512 wide,
  3592. 512 high, 8 bits per pel, red, green and blue fields.  Gray-scale
  3593. versions of Lenna have been obtained in two different ways from the
  3594. original:
  3595.  (1) Using the green field as a gray-scale image, and
  3596.  (2) Doing an RGB->YUV transformation and saving the Y component.
  3597. Method (1) makes it easier to compare different people's results since
  3598. everyone's version should be the same using that method.  Method (2)
  3599. produces a more correct image.
  3600.  
  3601. For the curious: 'lena' or 'lenna' is a digitized Playboy centerfold, from
  3602. November 1972. (Lenna is the spelling in Playboy, Lena is the Swedish spelling
  3603. of the name.) Lena Soderberg (ne Sjooblom) was last reported living in her
  3604. native Sweden, happily married with three kids and a job with the state liquor
  3605. monopoly.  In 1988, she was interviewed by some Swedish computer related
  3606. publication, and she was pleasantly amused by what had happened to her
  3607. picture.  That was the first she knew of the use of that picture in the
  3608. computer business.  A scan of the original Lenna from Playboy is available at
  3609. http://www.cs.cmu.edu/~chuck/lennapg/lenna.shtml
  3610.  
  3611. The editorial in the January 1992 issue of Optical Engineering (v. 31 no. 1)
  3612. details how Playboy has finally caught on to the fact that their copyright on
  3613. Lena Sjooblom's photo is being widely infringed. However Wired says in
  3614. http://www.wired.com/news/culture/story/4000.html "Although Playboy is
  3615. notorious for cracking down on illegal uses of its images, it has decided to
  3616. overlook the widespread distribution of this particular centerfold".
  3617.  
  3618. The CCITT (ITU-T) test images are in ftp://ftp.cs.waikato.ac.nz/pub/ccitt/
  3619. and http://www.cs.waikato.ac.nz/~singlis/ccitt.html
  3620. [The images in ftp://nic.funet.fi/pub/graphics/misc/test-images/ccitt*.tif are
  3621. corrupted.] This set is commonly used to compare binary image compression
  3622. techniques. The images are 1728x2376 pixels.
  3623.  
  3624. ------------------------------------------------------------------------------
  3625.  
  3626. Subject: [56] I am looking for a message digest algorithm
  3627.  
  3628.  
  3629. Look in ftp://ftp.rsa.com/pub . MD4 and MD5 are there.
  3630. See also http://wsspinfo.cern.ch/sec/cert/tools/md5/
  3631. This question would be more appropriate on sci.crypt.
  3632.  
  3633. ------------------------------------------------------------------------------
  3634.  
  3635. Subject: [57] I have lost my password on a .zip file
  3636.  
  3637. This question would be more appropriate on sci.crypt.
  3638.  
  3639. See http://www.photobooks.com/~hedgehog/passwords/pkzip.html
  3640. Here are a few programs to break pkzip encryption:
  3641. ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/zipcrack.c.gz
  3642. ftp://idea.sec.dsi.unimi.it/pub/security/crypt/rpub.cl.msu.edu/crypt/msdos/zipcrack*
  3643. ftp://idea.sec.dsi.unimi.it/pub/security/crypt/rpub.cl.msu.edu/crypt/other/zipcrack.c
  3644. ftp://ftp.ox.ac.uk/pub/crypto/cryptanalysis/fzc104.zip
  3645. ftp://ftp.ox.ac.uk/pub/crypto/cryptanalysis/pkcrack.zip
  3646. ftp://ftp.ox.ac.uk/pub/crypto/cryptanalysis/zipcrk20.zip
  3647.  
  3648. These are brute force crackers. A known plaintext attack is also possible,
  3649. see http://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack.html
  3650. or ftp://ripem.msu.edu/pub/crypt/docs/kocher-pkzip-attack.ps.gz
  3651.  
  3652.           End of part 1 of the comp.compression faq.
  3653.