htsjdk produces CRAM files with zero length blocks that have a compression codec listed. An empty block post-compression is valid. An empty-block in RAW (uncompressed) is also valid, but if it states it is compressed by a specific codec then the contents of the block should be a valid byte stream for that codec (even if it decodes to zero bytes).
This was tested using htsjdk 2.26.11 with build 11.0.16+8-post-Ubuntu-0ubuntu118.04.
Steps to reproduce
The easiest way to reproduce this to convert the above file back to CRAM again using SamFormatConverter. I did this to validate it still happens and it isn't just a historic problem.
Expected behaviour
Zero length blocks should ideally just not be stored, as they're not required, but if it's easier code-wise to keep them there then the method field should be RAW, so no attempt is made to uncompress them.
Description of the issue:
htsjdk produces CRAM files with zero length blocks that have a compression codec listed. An empty block post-compression is valid. An empty-block in RAW (uncompressed) is also valid, but if it states it is compressed by a specific codec then the contents of the block should be a valid byte stream for that codec (even if it decodes to zero bytes).
An example from SAMEA3302751.alt_bwamem_GRCh38DH.20200922.Finnish.simons.cram view using
cram_dump
:Your environment:
This was tested using htsjdk 2.26.11 with build 11.0.16+8-post-Ubuntu-0ubuntu118.04.
Steps to reproduce
The easiest way to reproduce this to convert the above file back to CRAM again using SamFormatConverter. I did this to validate it still happens and it isn't just a historic problem.
Expected behaviour
Zero length blocks should ideally just not be stored, as they're not required, but if it's easier code-wise to keep them there then the method field should be RAW, so no attempt is made to uncompress them.
See https://github.com/zaeleus/noodles/issues/131 for a case where this triggered an error in a spec-compliant decoder.