-<para>Hardware compression is detected by measuring
-the writing speed difference of the tape drive
-when writing an amount of compressable and uncompresseable data.
-It does not rely on the status bits of the tape drive or the OS parameters.
-If your tape drive has very large buffers or is very fast, the program
-could fail to detect hardware compression status reliably.</para>
-
-<para>During the first pass, it writes files that are estimated to be 1%
-of the expected tape capacity. It gets the expected capacity from
-the -e command line flag, or defaults to 1 GByte. In a perfect world
-(which means there is zero chance of this happening with tapes :-),
-there would be 100 files and 100 file marks.</para>
-
-<para>During the second pass, the file size is cut in half. In that same
-fairyland world, this means 200 files and 200 file marks.</para>
-
-<para>In both passes the total amount of data written is summed as well as the
-number of file marks written. At the end of the second pass, quoting
-from the code:</para>
-
-<para>* Compute the size of a filemark as the difference in data written
-between pass 1 and pass 2 divided by the difference in number of
-file marks written between pass 1 and pass 2. ... *</para>
-
-<para>So if we wrote 1.0 GBytes on the first pass and 100 file marks, and
-0.9 GBytes on the second pass with 200 file marks, those additional 100
-file marks in the second pass took 0.1 GBytes and therefor a file mark
-is 0.001 GBytes (1 MByte).</para>
-
-<para>Note that if the estimated capacity is wrong, the only thing that happens
-is a lot more (or less, but unlikely) files, and thus, file marks,
-get written. But the math still works out the same. The -e flag is
-there to keep the number of file marks down because they can be slow
-(since they force the drive to flush all its buffers to physical media).</para>
-
-<para>All sorts of things might happen to cause the amount of data
-written to vary enough to generate a big file mark size guess. A little
-more "shoe shining" because of the additional file marks (and flushes),
+<para>If the device cannot reliably report its comprssion status (and as of
+this writing, no devices can do so), hardware compression is detected by
+measuring the writing speed difference of the tape drive when writing an amount
+of compressable and uncompresseable data. If your tape drive has very large
+buffers or is very fast, the program could fail to detect hardware compression
+status reliably.</para>
+
+<para>Volume capacity is determined by writing one large file until an error,
+interpereted as end-of-tape, is encountered. In the next phase, about 100
+files are written to fill the tape. This second phase will write less data,
+because each filemark consumes some tape. With a little arithmetic,
+&amtapetype; calculates the size of these filemarks.</para>
+
+<para>All sorts of things might happen to cause the amount of data written to
+vary enough to generate a strange file mark size guess. A little more
+"shoe shining" because of the additional file marks (and flushes),