Document the ambiguity of 1-base long seq with QUAL *

[jkbonfield]

This is an extreme edge case likely to never occur, but nevertheless tool implementors still need to know how to handle it. Given it may be QUAL 9 or it may be QUAL "unknown", we treat it as always unknown.

Fixes #715

[github-actions[bot]]

Changed PDFs as of cca15e80c9ba49444a010ea03f1dcf54864c7789: SAMv1 (diff).

[github-actions[bot]]

Changed PDFs as of 7915c3d5beedfbfd5dc88f335a2f3604529fe0c6: SAMv1 (diff).

[jmarshall]

I have finally got around to finishing up my draft of adjusting this footnote. (The diff PDF preview has gone slightly mad — the actual change is the new footnote 17 on page 9.) It's been so long that I can't remember the details, but this is a tidied-up version of the text lying around in my specs directory after discussions on this one in meetings a few months ago.

The changes are basically:

• Avoid referring to this as ambiguous — now that the spec provides a ruling (albeit in a footnote), it's not ambiguous.
• I think we discussed offering advice on what tools should do if they have a single-base QUAL of 9 to write out. The second sentence does so, and says do it for all of SAM/BAM/CRAM to avoid issues later when BAM/CRAM files are viewed as SAM. But I'd also be happy if you preferred to drop that and just have the first sentence for succinctness.

[jmarshall]

On the merged commit, @colinhercus comments (https://github.com/samtools/hts-specs/commit/f7809caf3db2e1cf531c5c87e9238c56f98f0e32#commitcomment-162178132):

In this situation Novoalign has always reduced the base quality to 8. I don't plan to change it.

(The PR recommends adjusting the base quality to 10.)

I wish you'd noticed this updated PR in the month before we merged it… :smile: Or in the two years since the issue was first noted as an issue on this repository… :smile: :smile:

I thought of looking to see if any of the base quality binning strategies used either 8 or 10 or a nearby value, but in the end we picked 10 arbitrarily. Do you recall whether you picked 8 arbitrarily or was there some reasoning behind the choice?

[colinhercus]

It was almost arbitrary. I just felt reducing by 1 was better than increasing it.

On Wed, 16 Jul 2025 at 09:38, John Marshall @.***> wrote:

jmarshall left a comment (samtools/hts-specs#724) https://github.com/samtools/hts-specs/pull/724#issuecomment-3076441000

On the merged commit, @colinhercus https://github.com/colinhercus comments (f7809ca#commitcomment-162178132 https://github.com/samtools/hts-specs/commit/f7809caf3db2e1cf531c5c87e9238c56f98f0e32#commitcomment-162178132 ):

In this situation Novoalign has always reduced the base quality to 8. I don't plan to change it.

(The PR recommends adjusting the base quality to 10.)

I wish you'd noticed this updated PR in the month before we merged it… 😄 Or in the two years since the issue was first noted as an issue on this repository… 😄 😄

I thought of looking to see if any of the base quality binning strategies used either 8 or 10 or a nearby value, but in the end we picked 10 arbitrarily. Do you recall whether you picked 8 arbitrarily or was there some reasoning behind the choice?

— Reply to this email directly, view it on GitHub https://github.com/samtools/hts-specs/pull/724#issuecomment-3076441000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALRZ6QQOW7ZOUZO7DEJZO33IWUK5AVCNFSM6AAAAAB7PY7IX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZWGQ2DCMBQGA . You are receiving this because you were mentioned.Message ID: @.***>