{"id":29,"date":"2008-02-07T02:37:39","date_gmt":"2008-02-07T02:37:39","guid":{"rendered":"http:\/\/clayb.net\/blog\/?p=29"},"modified":"2012-05-04T19:40:54","modified_gmt":"2012-05-04T19:40:54","slug":"lempel-ziv-markov-algorithm-and-7-zip","status":"publish","type":"post","link":"https:\/\/clayb.net\/blog\/lempel-ziv-markov-algorithm-and-7-zip\/","title":{"rendered":"Lempel Ziv Markov Algorithm and 7-Zip"},"content":{"rendered":"<p>I&#8217;ve been working with the LZMA compression algorithm and code for a little while playing around with rewriting it in C and just understanding the algorithm and how it works. Certainly it&#8217;s attracted some attention with its impressive compression ratios, especially for just random bits of one&#8217;s disk. However, I&#8217;ve also found a lot of confusion about what is LZMA and what is 7-Zip. As in some ways 7-Zip is LZMA&#8217;s interface and in some ways and it&#8217;s completely orthogonal to a discussion about LZMA. So hopefully these questions and answers can clarify some things for folks just starting to look into this cool compression algorithm.<\/p>\n<p><b>What is LZMA and what&#8217;s it have to do with 7za?<\/b><\/p>\n<p><!--more--><\/p>\n<p>Lempel-Ziv-Markov-Algorithm (<a href=\"http:\/\/en.wikipedia.org\/wiki\/Lempel-Ziv-Markov_algorithm\">LZMA<\/a>) is a very nifty compression algorithm recently designed by Igor Pavlov. The algorithm is implemented in a few different software packages, but it&#8217;s most often discussed for being in the 7-Zip archiver <tt>7za<\/tt>(1).<\/p>\n<p>The 7-Zip archiver, by Pavlov as well, was originally written for Windows but later ported to Unix. The 7-Zip archiver is an archiver (like <tt>tar<\/tt>(1) or <tt>cpio<\/tt>(1)), which outputs in the 7z Format. The format is open and supports multiple compression algorithms. LZMA compression is the default for the format, however, it also supports bzip2 and deflate (gzip), amongst others. The format supports (AES-256) encryption, but not being designed for a Unix system originally UID\/GID pairs aren&#8217;t stored, similarly directories aren&#8217;t (or at least don&#8217;t seem) supported on Unix systems &#8211; a significant drawback for an archive format.<\/p>\n<p><b>Why would I use LZMA?<\/b><\/p>\n<p>LZMA is a kick-butt compression algorithm for size&#8217;s sake. It does a super job of compressing files usually providing a 10% addition to bzip2 compression, but not always. For example, a SPARC binary <tt>\/usr\/bin\/gimp-2.4<\/tt> on my Ultra 45 is 4,997KB and LZMA compressed it to 1,411KB for a savings of 72%, versus <tt>bzip2 -9<\/tt> which resulted in a 1,923KB file size for a savings of 62% only. Again, a SPARC core dump lying around from some application test was 3,588KB which LZMA got to 2,051KB (a 43% savings) and <tt>bzip2 -9<\/tt> got 2,307KB (for a 36% savings). Meanwhile, for a 130KB English LaTeX document in ASCII encoding using LZMA compression compressed it to 11KB (91.5% savings), but <tt>bzip2 -9<\/tt> achieved 10KB (92.3% savings). (Similar results occur for my <tt>\/usr\/sfw\/man\/man1\/gcc.1<\/tt> where I got for the original,LZMA, and <tt>bzip2 -9<\/tt> 514K,104K,99K respectively.) Oh well, can&#8217;t win them all. Still, on random chunks of my disk using <tt>dd<\/tt>(1) LZMA seems to do closer to the binary performance than anything (likely due to the composition of my disk being largely binary files).<\/p>\n<p><b>Well LZMA looks cool, tell me more:<\/b><\/p>\n<p>LZMA though new, and very little documented, is an adaptation of LZ77 with the goal of large compression and fast decompression. It uses range encoding (to deflate&#8217;s (gzip) Huffman coding), and uses a large dictionary as necessary (up to ~1GB) which is searched with various hashing algorithms stored applied to various binary tree algorithms or a hashed array of lists. There is an on-disk format for LZMA. The LZMA on-disk format is different from the 7z Format which is not solely a wrapper for the LZMA on-disk format &#8211; one must transcode\/convert them. The LZMA format is very straight-forward: first, the properties used by the LZMA encoder, then, the dictionary size, and uncompressed size, followed by the actual compressed data.<\/p>\n<p>The compression algorithm has been primarily written in C++ (but C# and Java ports are available too). A C decompression example is provided by the <a href=\"http:\/\/www.7-zip.org\/sdk.html\">LZMA SDK<\/a>, however, no non-OO port of the compression algorithm seems yet available.<\/p>\n<p><b>So why do I care about <tt>7za<\/tt>(1) anyways?<\/b><\/p>\n<p>Though some other tools support LZMA and have been written to take advantage of it, few tools allow one to compress a file with LZMA other than <tt>7za<\/tt>(1), which currently is a feature rich &#8220;LZMAzip&#8221; akin to <tt>gzip<\/tt> and <tt>bzip2<\/tt>. The easiest way to use <tt>7za<\/tt>(1) for compression is with the standard in\/out <tt>-si<\/tt> and <tt>-so<\/tt> flags to make it part of a <tt>tar<\/tt>(1) or <tt>cpio<\/tt>(1) pipeline as previous compression utilities have been used for years, just remember your data will be compressed not just in LZMA, but LZMA and the 7z Format too (not an overhead worry &#8211; just something to understand). If you&#8217;d like to play with <tt>7za<\/tt>(1) now, you can. If you&#8217;re running Nevada build 79 or newer, p7zip version 4.55 went back into the SFW Consolidation on November 16th making <tt>\/usr\/bin\/7za<\/tt> available.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I&#8217;ve found a lot of people are excited by the Lempel-Ziv-Markov-Algorithm, and many are playing with it through the 7-Zip archiver, however, it seems there&#8217;s some confusion about where one ends and the other starts. I hope to explain my understanding of the two for those who are interested, and to ensure I understand it coherently as well!<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"_links":{"self":[{"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/posts\/29"}],"collection":[{"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/comments?post=29"}],"version-history":[{"count":0,"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/posts\/29\/revisions"}],"wp:attachment":[{"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/media?parent=29"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/categories?post=29"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/clayb.net\/blog\/wp-json\/wp\/v2\/tags?post=29"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}