Convert TZO to TAR.BZ2 Online (From LZO Speed to Bzip2's Block-Sorting Ratio)

What a TZO Archive Is and Why It Exists

A .tzo file is a tar archive compressed with lzop, the command-line tool built around Markus Oberhumer's LZO compression library. Lzop's own manual describes .tzo as a shorthand for .tar.lzo, referring to the identical underlying format. LZO's entire design centers on speed, especially decompression speed, rather than shrinking the file as much as possible, which is exactly why it turns up in embedded Linux firmware, router operating systems, and time-critical backup pipelines where fast unpacking matters more than a smaller stored file.

Bzip2 takes essentially the opposite position on that trade-off. Written by Julian Seward and released in 1996, it uses the Burrows-Wheeler Transform, a data-reordering step applied to fixed-size blocks of up to 900 KB, followed by move-to-front encoding and Huffman coding, and it generally compresses more tightly than LZO on typical data at the cost of noticeably slower compression and decompression. Converting from .tzo to .tar.bz2 means fully decompressing the original LZO-compressed tar stream, then recompressing that same tar content with a fundamentally different, heavier algorithm.

The tar layer underneath is unaffected by either compression choice. Tar stores each file as a 512-byte header block recording its name, permissions, and size, immediately followed by that file's data, one entry after another in a single sequential stream with no built-in index of its contents — a design that predates both LZO and bzip2 by decades and traces back to writing archives onto magnetic tape. Whichever compressor eventually wraps around that finished stream, the tar structure itself stays identical, which is why the original .tzo file has to be fully decompressed back down to that plain tar form before bzip2 can compress it again from scratch.

A Simple Dictionary Scan Against a Block-Sorted, Multi-Pass Encoder

Lzop's default lzo1x_1 method performs a relatively lightweight Lempel-Ziv-style scan for repeated byte sequences, without the additional entropy-coding stage most other general-purpose compressors add on top. Bzip2's approach involves considerably more computation per block: the Burrows-Wheeler Transform rearranges the block's bytes to group similar contexts together, a move-to-front transform then converts that rearranged data into a form with more easily compressible patterns of repetition, and Huffman coding finishes the job by assigning shorter codes to more frequent symbols. Each of those stages costs CPU time that LZO's simpler design skips entirely.

Bzip2's block-based structure also creates a genuine practical benefit LZO doesn't offer in the same way: because each block compresses independently, tools like pbzip2 can compress or decompress different blocks across multiple CPU cores simultaneously, and a bzip2 archive with one damaged block can sometimes still be partially recovered using the bzip2recover utility, extracting whatever undamaged blocks remain readable. LZO's compressed output has its own per-block checksums for corruption detection, using Adler-32 by default or CRC-32 if requested, but detecting damage isn't the same as being able to recover the rest of the archive around it the way bzip2's block independence allows.

On most typical data, especially text and source code, bzip2's heavier multi-stage approach compresses meaningfully tighter than LZO's lighter dictionary scan, which is the direct, expected trade for the additional processing time bzip2 requires on both the compression and decompression side.

What Rebuilding This Archive With Bzip2 Gains and Costs

• Gain — a smaller archive on most typical data: bzip2's Burrows-Wheeler-based compression generally beats LZO's lighter matching by a real, measurable margin.
• Gain — block-level partial recovery: bzip2's independent 900 KB blocks can sometimes be partially salvaged with bzip2recover if part of the archive gets damaged.
• Lose — LZO's fast decompression: bzip2 decompresses noticeably more slowly than LZO, which matters directly if the archive is meant for a time-critical or resource-constrained decompression step.
• Gain — much broader mainstream tool support: bzip2 is installed by default on nearly every Linux distribution and supported by 7-Zip, WinRAR, and PeaZip, unlike LZO's narrower toolchain.
• Lose — low CPU and memory overhead: bzip2's multi-stage compression needs more processing time and working memory than LZO's simpler scheme, a real cost on constrained hardware.
• Unchanged — the actual file contents: both LZO and bzip2 are lossless, so anything extracted afterward is identical to the original, regardless of which algorithm compressed it.

Which Systems Actually Support Each Format Today

Reading a .tzo file requires the lzop utility itself, or GNU tar used with its --lzop flag, since mainstream Windows and macOS archive managers generally don't support LZO decompression natively — a real, current gap that keeps .tzo files mostly confined to Linux, Unix, and embedded-systems contexts where lzop is already installed for a specific purpose.

Bzip2 sits solidly inside default tooling almost everywhere by comparison. GNU tar integrates it directly through the -j or --bzip2 flag, it ships by default on essentially every Linux distribution, and 7-Zip, WinRAR, and PeaZip all read and write .tar.bz2 archives on Windows and macOS without needing anything extra installed. This is a real, current compatibility upgrade over the original .tzo file's much narrower software support.

Package managers make closing the LZO gap straightforward on Linux at least — lzop is available through apt, dnf, or equivalent tools on virtually every mainstream distribution — so the real compatibility difference discussed here is mostly about Windows and macOS default installations, and about embedded firmware environments that were never meant to support general-purpose desktop archive tools in the first place.

Real Problems Reported Around This Specific Conversion

A documented complaint in cross-platform development threads involves a .tzo file produced on a Linux build server that a Windows-based teammate can't open at all, since neither 7-Zip nor WinRAR includes LZO decompression support by default — teams generally resolve this by installing a Windows-compatible lzop build, or by having the Linux side rebuild the archive as .tar.bz2 before sharing it more broadly.

A second, opposite report shows up in embedded-firmware discussions: a firmware image rebuilt as .tar.bz2 for easier distribution or archival turns out to be entirely unusable for the actual deployment step, because the target device's bootloader was specifically written to decompress LZO-compressed data quickly and has no bzip2 decoder built into its limited firmware at all. Bzip2's slower decompression would likely be a problem for that boot-time use case even if a decoder existed, since the whole reason LZO got chosen there in the first place was decompression speed on constrained hardware.

A third, more general complaint involves compression time surprising users who are accustomed to lzop finishing almost instantly: rebuilding a large .tzo archive as .tar.bz2 can take noticeably longer for the same volume of data, since bzip2's multi-stage Burrows-Wheeler-based encoding does considerably more computational work per block than LZO's simpler scan-and-replace approach.

A fourth pattern involves memory usage on constrained systems attempting the conversion itself: bzip2's default block size of 900 KB requires roughly several times that amount of working memory during compression to hold the block data plus the intermediate structures the Burrows-Wheeler Transform and Huffman coding stages need, which can be a real constraint on the same low-memory embedded devices that chose LZO in the first place. Running the conversion on a more capable machine, rather than the embedded device itself, is the documented workaround in these specific cases.

LZO's Speed Focus Set Beside Bzip2's Block-Sorting Ratio Focus

Questions About Trading LZO Speed for Bzip2 Compression

Will my archive shrink after converting from .tzo to .tar.bz2?
Generally, yes. Bzip2's Burrows-Wheeler-based compression usually beats LZO's lighter, speed-focused matching by a real margin, especially on text and source code.

Why does converting to bzip2 take longer than the original lzop compression did?
Bzip2 performs several additional encoding stages per block that LZO skips entirely for the sake of speed, which is the direct, expected cost of its better compression ratio.

Can a damaged .tar.bz2 file still be partially recovered?
Often, yes. Bzip2 compresses data in independent blocks of up to 900 KB, and a tool like bzip2recover can sometimes extract the undamaged blocks even if part of the file is corrupted.

Should I convert a firmware image meant for a device's bootloader to bzip2?
Not for the deployed version. If the bootloader specifically expects LZO-compressed data for fast boot-time decompression, converting to bzip2 will likely make the image unusable there.

Does this conversion lose or alter any of the actual file data?
No. Both LZO and bzip2 are lossless compression schemes, so every file extracted afterward is identical to what was originally inside the .tzo archive.

Why does this conversion need so much memory on my device?
Bzip2's default 900 KB block size requires several times that amount of working memory during compression for its Burrows-Wheeler and Huffman coding stages, which can strain low-memory embedded hardware. Running the conversion on a more capable machine avoids the problem.