your comment reminded me that I did mention Fastqz in my previous post on the topic: http://bogdan.org.ua/2013/10/17/favourite-file-compressor-gzip-bzip2-7z.html

Looks like I haven’t actually tested it, because of the concern that data recovery _might_ be too complicated with Fastqz.
For comparison, a single block damage with bzip2 would only cause the loss of between 100 and 900 K of compressed data, which – for fastq files – will probably have negligible effects.

Another reason to not test it was that it is not clear if it will see any future support.
If, for example, a change in compiler makes building fastqz not possible without first modifying the code, then it’s… bad

Maybe I’ll test it anyway – next time.

I did eventually try a newer (already parallel, I think) version of xz on genomic data, and had mixed success.
lbzip2 sometimes achieved even better ratios, mostly just a little bit worse, rarely much worse, but was always many times faster.

I must say that even with multithreading xz with default settings will likely be significantly slower than lbzip2 – on the order of 200+ seconds on the same test file and hardware, and assuming a really good parallelism implementation. For my use this is way too slow, and probably not worth the extra savings. Also, more complicated xz file format looks like another drawback to me (harder to recover data).

Clearly, everyone’s needs are different, so I’m not saying that lbzip2 is much better overall – but it is for me

I use xz for non-realtime compression (e.g. overnight backups), because although it’s slow, it’s so much better than bzip2 and, of course, if it’s overnight I don’t care if it takes half an hour or whatever to run.