text: user6273: I have been working with several tools on bam files recently and I am not sure how I should interpret some of the outputs.
  samtools idxstats mapped.sorted.bam
  
  Chr1    15096   0   0
  Chr2    33397   0   0
  Chr3    43888   41  0
  Chr4    20819   1   0
  *   0   0   34
  
  Documentation says third and fourth column give "mapped reads" and "unmapped reads". So I interpreted the last line (*) as the number of unmapped reads as this is the only line with a non 0 value at this field.
  Then I used 
  bam splitChromosome --in mapped.sorted.bam --out test/aln.
  
  Reference Name: chr6 has 6 records
  Reference Name: Chr7 has 1 records
  Reference Name: Chr3 has 41 records
  Reference Name: Chr4 has 1 records
  Reference Name: * has 34 records
  
  And looking at the bams outputted (one per reference sequence) in test/ I find an aln.UnknownChrom.bam that I am not sure where it comes from. I actually found 97 unique reads ID in it, where I was waiting for 34 or less. 
  So my first question is : Does "*" actually means "all reads that didn't mapp" and this information is stored in way I didn't know about in BAM files ?
  And my second question would be : Anybody knows where this aln.UnknownChrom.bam comes from when using splitChromosome ? It is a source of error in a pipeline I am building and I'd like to get rid of it, if these are not actual mapping informations.
  
  user6955: As per the SAM/BAM format specifications:
  
  "RNAME: Reference sequence NAME of the alignment. If @SQheader lines are present, RNAME(if not ‘*’) must be present in one of the SQ-SN tag. An unmapped segment without coordinate has a ‘*’ at this field.  However, an unmapped segment may also have an ordinary coordinate such that it can be placed at a desired position after sorting.  If RNAME is ‘*’, no assumptions can be made about POS and CIGAR." -- http://samtools.github.io/hts-specs/SAMv1.pdf, emphasis mine
  
  So, yes, these are the unmapped reads. 
  I haven't used this splitChromosome utility before myself, but as it splits the BAM file into one BAM file per chromosome, I suspect it simply also creates a BAM file for the unknown (*) chromosome. Why the numbers don't match I can't tell.
  How to deal with that file in your pipeline will depend on what the pipeline is meant to do. But if you aren't interested in these reads, I suppose you could simply remove it before continuing to the next step.
  
original_text: 6273: <p>I have been working with several tools on bam files recently and I am not sure how I should interpret some of the outputs.</p>
  
  <pre><code>samtools idxstats mapped.sorted.bam
  </code></pre>
  
  <pre><code>Chr1    15096   0   0
  Chr2    33397   0   0
  Chr3    43888   41  0
  Chr4    20819   1   0
  *   0   0   34
  </code></pre>
  
  <p>Documentation says third and fourth column give "mapped reads" and "unmapped reads". So I interpreted the last line (<code>*</code>) as the number of unmapped reads as this is the only line with a non 0 value at this field.</p>
  
  <p>Then I used </p>
  
  <pre><code>bam splitChromosome --in mapped.sorted.bam --out test/aln.
  </code></pre>
  
  <pre><code>Reference Name: chr6 has 6 records
  Reference Name: Chr7 has 1 records
  Reference Name: Chr3 has 41 records
  Reference Name: Chr4 has 1 records
  Reference Name: * has 34 records
  </code></pre>
  
  <p>And looking at the bams outputted (one per reference sequence) in <code>test/</code> I find an <code>aln.UnknownChrom.bam</code> that I am not sure where it comes from. I actually found 97 unique reads ID in it, where I was waiting for 34 or less. </p>
  
  <p>So my <strong>first question</strong> is : Does "*" actually means "all reads that didn't mapp" and this information is stored in way I didn't know about in BAM files ?</p>
  
  <p>And my <strong>second question</strong> would be : Anybody knows where this <code>aln.UnknownChrom.bam</code> comes from when using <code>splitChromosome</code> ? It is a source of error in a pipeline I am building and I'd like to get rid of it, if these are not actual mapping informations.</p>
   6955: <p>As per the SAM/BAM format specifications:</p>
  
  <blockquote>
    <p>"RNAME: Reference sequence NAME of the alignment. If @SQheader lines are present, RNAME(if not ‘*’) must be present in one of the SQ-SN tag. <strong>An unmapped segment without coordinate has a ‘*’ at this field.</strong>  However, an unmapped segment may also have an ordinary coordinate such that it can be placed at a desired position after sorting.  If RNAME is ‘*’, no assumptions can be made about POS and CIGAR." -- <a href="http://samtools.github.io/hts-specs/SAMv1.pdf" rel="nofollow noreferrer">http://samtools.github.io/hts-specs/SAMv1.pdf</a>, emphasis mine</p>
  </blockquote>
  
  <p>So, yes, these are the unmapped reads. </p>
  
  <p>I haven't used this <code>splitChromosome</code> utility before myself, but as it splits the BAM file into one BAM file per chromosome, I suspect it simply also creates a BAM file for the unknown (<code>*</code>) chromosome. Why the numbers don't match I can't tell.</p>
  
  <p>How to deal with that file in your pipeline will depend on what the pipeline is meant to do. But if you aren't interested in these reads, I suppose you could simply remove it before continuing to the next step.</p>
  