home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / sigm / vol294 / crunch20.lbr / CRUNCH20.DOC < prev    next >
Encoding:
Text File  |  1986-12-17  |  4.8 KB  |  98 lines
  1.  
  2.  
  3.  
  4.                                CRUNCH  v2.0
  5.  
  6.  
  7.      CRUNCH  v2.0 is a state of the art file compression utility.   It
  8.      embodies  all  of the concepts employed in the  UNIX  COMPRESS  /
  9.      ARC512  algorithm, but is additionally enhanced by a  "metastatic
  10.      code  reassignment" facility.  This is one of several concepts  I
  11.      am  developing as part of an effort to advance  data  compression
  12.      techniques beyond current performance limits.  I believe this  is
  13.      the first time this principle has been proposed or implemented.
  14.  
  15.      The  code  reassignment is augmented with a  refined  incremental
  16.      compression  ratio  analysis for adaptive reset.   This  provides
  17.      additional  improvement, especially on files with certain  struc-
  18.      tural  variations.   (It  is  ironic to note  that  if  the  file
  19.      ARC512.EXE is CRUNCHed, the resulting file is nearly 14%  smaller
  20.      than  the  file produced when that program is  used  to  compress
  21.      itself).   Although short files will generally produce  the  same
  22.      results  as  the above mentioned utilities, CRUNCH  saves  a  few
  23.      extra bytes by eliminating zero fill between code length changes.
  24.  
  25.      Please  note that the above discussion relates to  file  compres-
  26.      sion, not to the relative merits of ARC's vs. LBR's as structures
  27.      for  collections of files.  Also note that the  quoted  ratio  is
  28.      not claimed to be typical.
  29.  
  30.  
  31.      Other improvements include:
  32.  
  33.      1.  Use of multi-sector I/O when running in a CP/M 3.0+  environ-
  34.      ment   (automatically   selected  when  appropriate).    May   be
  35.      permanently deactivated if desired.
  36.  
  37.      2.   Relaxed restrictions on filenames (eg. files with a  "Z"  as
  38.      the  middle  extension character, such as .AZM files, are  not  a
  39.      problem).
  40.  
  41.      3.   Improved wildcard operation- non critical errors will  abort
  42.      only the current file, not the entire operation.
  43.  
  44.      4.   "Verbose" and "Quiet" modes of operation.  The former  gives
  45.      full running progress reports while compressing, including number
  46.      of input and output records, compression ratio, "codes  assigned"
  47.      and  "codes reassigned".  Although some of this  information  has
  48.      limited usefulness, it is amusing to watch.  "Quiet" may be  pre-
  49.      ferred  when using slow (or printing) terminals, and  will  allow
  50.      the  results  of up to 24 wildcard operations to  remain  on  the
  51.      console.
  52.  
  53.      5.   Optional  prompt before erasure of  pre-existing  files.   A
  54.      warning  will be issued if an existing file is about to be  over-
  55.      written.  This feature can be deactivated if desired.
  56.  
  57.      6.   Full compatibility with all crunched files.  UNCR  2.0  will
  58.      uncrunch  all  "crunched" files, regardless of which  version  of
  59.      CRUNCH was used to create them.  CRUNCH v2.0 will always use  the
  60.      improved algorithm to create new files.
  61.  
  62.  
  63.      
  64.      7.  "Confirm" mode of operation. Used in conjunction with a wild-
  65.      card  filespec, this option allows selectively crunching  or  un-
  66.      crunching a subset of all files matching the spec.  The user will
  67.      be prompted (Y/N) for each file matching file; a response of  "N"
  68.      will simply move on to the next file.
  69.  
  70.      8. Continuous checking for ^C abort.
  71.  
  72.      9.   Inclusion of a "NOP" code. In addition to the normal special
  73.      EOF and RESET codes, the new structure sets aside two  additional
  74.      codes  as reserved (one "NOP", one "SPARE").  The "NOP" code  can
  75.      be inserted into the data stream at any point and will always  be
  76.      ignored  by the uncruncher.  One possible use of this would be  a
  77.      "Telenet Trap"- where the CRUNCH program would monitor its output
  78.      and  insert a NOP code if it saw that the output would  otherwise
  79.      produce  an  undesired sequence (ref: R. Freed's  PCP-WARN.MQG  /
  80.      PCP-FIX.MQG), thus producing files guaranteed to be transmittable
  81.      while using PC-PURSUIT.  Although the current CRUNCH program does
  82.      not yet monitor for this, the structure is already set up so this
  83.      (or  any other sequence) could be inhibited at any time, yet  all
  84.      files  would remain upward/downward compatible. Other data  comp-
  85.      ression schemes do not have this flexibility.
  86.  
  87.  
  88.      NOTES:
  89.  
  90.      If crunching a file ever causes the result to be larger or  equal
  91.      to  the original, the program will prompt for whether you  really
  92.      want  to keep the result or not.  CRUNCH does not attempt to  de-
  93.      termine  whether conventional squeezing would produce  a  smaller
  94.      file (this is quite unlikely in other than object [.COM /.REL] or
  95.      certain numeric data files). If you want to know, squeeze it  and
  96.      find out.
  97. 
  98.