# Denoise-single error associated with --p-trunc-len values

**URL:** https://forum.qiime2.org/t/denoise-single-error-associated-with-p-trunc-len-values/1130
**Category:** User Support
**Tags:** dada2
**Created:** [August 31, 2017, 9:41pm UTC](https://forum.qiime2.org/t/denoise-single-error-associated-with-p-trunc-len-values/1130 "2017-08-31T21:41:57Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![ebolyen](https://forum.qiime2.org/user_avatar/forum.qiime2.org/ebolyen/32/11_2.png) [@ebolyen](https://forum.qiime2.org/u/ebolyen)
#### Post date: [August 31, 2017, 10:23pm UTC](https://forum.qiime2.org/t/denoise-single-error-associated-with-p-trunc-len-values/1130/2 "2017-08-31T22:23:35Z")

</div>

Hey @kmw,

I'm not familiar with OBItools, but it does seem that with the ` --fastq-output` option supplied it uses the Sanger PHRED 33 offset, so my guess is that it is just adding the quality scores where the overlap is (I could be entirely wrong here).

Of greater concern is I don't think using DADA2 on this data really makes sense as it is [expecting raw sequence data](https://github.com/benjjneb/dada2/issues/161#issuecomment-263940652) which allows it to infer where sequencing error may have occurred. @benjjneb, is this a fundamental expectation of DADA2, or would you still get "reasonable", but not ideal, results if merging was done before-hand?

Perhaps we can focus on getting your paired-end data into QIIME 2 as `SampleData[PairedEndSequencesWithQuality]` (skipping OBItools)? Then `dada2 denoise-paired` can take you the rest of the way.

Otherwise another option might be to do your own quality filtering, and then import an OTU table and representative sequences; using QIIME 2 only for the "downstream" analysis.

---

_[View the full topic](https://forum.qiime2.org/t/denoise-single-error-associated-with-p-trunc-len-values/1130)._