Hi Heng
I think there could be a possible bug in the seqtk trimfq option. here is a contrived example. If I run this read through it I get back the same read. I am using the latest version from github.
@2260:7:1101:14363:3089/1
CCTGCATTCTCACTCGTGTGGGCTCCACGACTGGGTCACCCCGCCGCTTCACTGCCCACACGACGCTCCCCTACCCATCCACACACCCGGCACGAATGCAGGTTCTTGTGTGAATGCCACGGCTTCGGTGGGGGGTTTGAGCCCCGCTCC
+
bbbeeeeegggffihhhhiihihihiiiihiifihhiiihihhhghgggeeeeeddcdcccccc^accaccc^a[^bcc`[bbcccWX]accccacccc`ba[bbccb]`^^bcdccc_b]]TX[bBBBBBBBBBBBBBBBBBBBBBBBB
i think the space in the read is getting messed up but I think you can get the idea.
Expected result : below is a just a made up answer but I would expect the trimming algo to remove low quality bases from both end and beginning. In this this case the last ~24 bases of the read are low quality (ASCII(B) - 64 = 2 ) and should be trimmed.
@2260:7:1101:14363:3089/1
CCTGCATTCTCACTCGTGTGGGCTCCACGACTGGGTCACCCCGCCGCTTCACTGCCCACACGACGCTCCCCTACCCATCCACACACCCGGCACGAATGCAGGTTCTTGTGTGAATGCCACGGCTTC
+
bbbeeeeegggffihhhhiihihihiiiihiifihhiiihihhhghgggeeeeeddcdcccccc^accaccc^a[^bcc`[bbcccWX]accccacccc`ba[bbccb]`^^bcdccc_b]]TX[b
-A
you should also state of what you expect to see and why. It is not obvious from your example.
edited the question with expected answer. I assumed that it was obvious my bad.