trimming status of input fastqs for FastqToBam

[basesLoaded]

Dear fgbio,

What is the recommended status of the paired end fastqs used as input for FastqToBam, trimmed or not? I have seen some pipelines that send the fastqs through cutadapt or a similar tool before generating the unaligned bam. There are other pipelines that rely on the soft-clipping done by the mapper, others mark the adapter positions in the bam, but both of these pipelines leave the FastqToBam fastqs intact. As an example, cutadapt trims the ends of the reads where the quality score dips lower than 25, trims adapter matches, and also removes any reads shorter than 35 bases. To generate the mapped bam both pipelines use bwa mem, and then merge the unmapped and mapped bams using picard MergeBamAlignment. My intuition is to keep the fastqs untrimmed and mark the low quality/adapter positions within the bam files, I am especially interested in situations where the coverage depth is over 20K.

Thank you!