Parallel decompression of FASTQ files generated by seqkit

Greetings,

I am the author of Genozip (www.genozip.com) - a software package for compressing FASTQ / BAM / VCF.

When compressing a fastq file, Genozip first inflates the gzip compression before re-compressing with genozip. Many fastq files are compressed with BGZF (bgzip) - BGZF is essentially a concatenation of 64KB gzip blocks, with the crucial property of populating the gzip optional Extra field with the length of the compressed block. This allows downstream applications, like htslib, aligners and also Genozip, to fan out the gzip blocks to multiple threads for parallel decompression - as it is possible to know the length of a gzip block without decompressing it.

I have recently encountered a FASTQ file that I think was generated by seqkit - it appears to be a concatenation of gzip blocks, each containing, when uncompressed, 1 MB of fastq data - the hallmark of pgzip compression. Unfortunately, since there is no information as to the length of a compressed block, Genozip as well as any other applications cannot parallelize decompressing it.

To solve this issue, I would like to suggest that you add an Extra subfield containing the compressed length of the block. As a reference, in page 13 of the SAM specification you can see how this is done in BGZF: https://samtools.github.io/hts-specs/SAMv1.pdf. An alternative solution would be switching from pgzip to bgzf.

Thanks,

-divon

Start by locating seqkit's FASTQ compression path and its use of pgzip, then compare the generated gzip blocks with the BGZF Extra-field format described in the linked SAM specification. Done means choosing and implementing one supported approach—recording compressed block lengths or switching to BGZF—so downstream tools can parallelize decompression.