Compression Algorithms

CiderPress supports every compression algorithm listed in the NuFX and Binary II specifications, as well as those listed in the "NuFX addendum" on www.nulib.com.  The actual compression code lives in the NufxLib library, however, and the library can be built with some or all of the compression code disabled.  You can see which algorithms are enabled by going to the Compression Preferences screen.

No compression

Exactly what it says: the contents are not compressed in any way.

Squeeze (sometimes "SQueeze")

This format became popular under CP/M with the "sq" and "usq" commands, which created ".QQ" or ".QQQ" files.  These appeared on the Apple II as Donald Elton's "sq3" and "usq2" utilities, and un-squeezing became part of Floyd Zink's "BLU" utility.  The algorithm, a combination of RLE (Run-Length Encoding) and Huffman encoding, is generally inferior to LZ-based techniques, and Squeeze fell out of common use after ShrinkIt was released.  It was, however, an official part of the NuFX format specification.

Most NuFX utilities can handle Squeezed files, but ProDOS 8 ShrinkIt has a bug that prevents it from unpacking the files correctly.  GS/ShrinkIt handles them correctly.  No Apple II utility actually creates Squeezed NuFX archives.

Dynamic LZW/1

Originally designed to compress tracks on 5.25" disks, the original ShrinkIt compression algorithm grabs a 4K chunk of data, compresses it with RLE, and then compresses the result with LZW (Lempel-Ziv-Welch).  A 16-bit CRC is computed on each compressed chunk.

All NuFX utilities can handle this algorithm.

Dynamic LZW/2

This is a slightly improved version of the original, first introduced in GS/ShrinkIt.  All NuFX utilities can handle this algorithm, making this the best choice for compressing Apple II files.

LZC-12

Before ShrinkIt was born, UNIX systems had the "compress" command.  A fairly pure implementation of the LZW algorithm, "compress" was widely used until the Unisys GIF/LZW controversy sped adoption of the superior "gzip".  LZC-12 produces output equivalent to "compress -b12", i.e. LZW with a maximum code length of 12 bits.

The algorithm was first supported in NuLib, and can be unpacked by NuLib, NuLib2, and GS/ShrinkIt.

LZC-16

Just like LZC-12, but the maximum code length is increased to 16 bits.  Usually offers improved compression over LZC-12, though it's only noticeable on larger files.

Same compatibility as LZC-12.

Deflate

This algorithm uses LZH (Lempel-Ziv + Huffman), which is in a different LZ family from LZW.  The algorithm became popular in archive utilities like LHArc, and eventually became the standard PKZIP archive format.  Some of the authors of the free "Info-Zip" utility decided to write a replacement for UNIX "compress" called GNU Zip ("gzip" for short), using the same algorithm.  It quickly became popular, and "deflate" is now defined as an Internet standard (RFC 1951), and is used for everything from file distribution to PNG graphics.  It was first implemented for NuFX archives in NuLib2 v1.1, and is the best general-purpose compression that CiderPress has to offer.

Unfortunately, few NuFX utilities can unpack this format.  It is unlikely you will ever be able to access "deflated" files on an Apple II.  Only use this for archives that will only be accessed from CiderPress or NuLib2.

Bzip2

This is a relatively new format that relies on the BWT (Burrows-Wheeler Transform) algorithm.  It is slower and more memory-intensive than "deflate", but does exceptionally well on large collections of text files or source code.  It is becoming the standard way to compress source code distributed on the Internet.  It is generally inferior to "deflate" on Apple II files, so unless you have an 800K disk image full of text files there's not much point in using it.

It was first implemented for NuFX archives in NuLib2 v1.1, and it is unlikely to be supported by anything else, so it's usually disabled in NufxLib.