cram: Record counter field description is possibly off-by-one

[zaeleus]

This is in regard to CRAM format specification (version 3.1) (2024-09-04).

The record counter field in both the container (§ 7 "Container header structure") and slice headers (§ 8.5 "Slice header block") is described to be a "1-based sequential index of records in the file/stream."

However, current implementations write 0-based values, e.g., htslib:

$ samtools --version | head -2
samtools 1.21
Using htslib 1.21

$ (
samtools view --output-fmt cram --output-fmt-option seqs_per_slice=2 <<EOF
@HD	VN:1.6
r1	4	*	0	255	*	*	0	0	NNNN	!!!!
r2	4	*	0	255	*	*	0	0	NNNN	!!!!
r3	4	*	0	255	*	*	0	0	NNNN	!!!!
EOF
) | cram_dump - | grep "Rec counter"
    Rec counter:       0
        Rec counter      0
    Rec counter:       2
        Rec counter      2
    Rec counter:       0

I would expect the record counters to be 1 and 3 if they were to be 1-based. Is the description in the spec incorrect, or is the field missing a more thorough explanation on how its supposed to be tracked?

[jkbonfield]

It looks like my htsjdk produced files start counting from 0 too. It's probably where I copied the htslib implementation (via scramble).

Thanks. Will fix (the spec).