BAM header file error

Question: BAM header file error

2.8 years ago by

Bioblazer • 40

Pune

Bioblazer • 40 wrote:

I ran the following the command to extract bam file for specific chromosomal locus.

samtools view -h accepted_hits.bam "EQ963475:334376-335722">AFLA_105440.bam

The result of command was generated with header file

<h6>first few lines output file</h6>

@HD VN:1.0 SO:coordinate @SQ SN:EQ963472 LN:4469204 @SQ SN:EQ963473 LN:4149026 @SQ SN:EQ963474 LN:2713190 @SQ SN:EQ963475 LN:2658400 @SQ SN:EQ963476 LN:2555871 @SQ SN:EQ963477 LN:2388123 @SQ SN:EQ963478 LN:2337902

When I ran the below command for conversion of bam to fastq

samtools bam2fq AFLA_105440.bam >AFLA_105440.fq

it showing error like this: [bam_header_read] EOF marker is absent. The input is probably truncated. [bam_header_read] invalid BAM binary header (this is not a BAM file).

rna-seq forum • 4.2k views

ADD COMMENT • link •

modified 2.8 years ago • written 2.8 years ago by Bioblazer • 40

Possible reasons - Eof Marker Is Absent When Processing A Bam File

ADD REPLY • link written 2.8 years ago by venu ♦ 5.8k

Hello muthubioinfotech!

Questions similar to yours can already be found at:

Error: Eof Marker Is Absent When Processing A Bam File

We have closed your question to allow us to keep similar content in the same thread.

If you disagree with this please tell us why in a reply below. We'll be happy to talk about it.

Cheers!

ADD REPLY • link written 2.8 years ago by Michael Dondrup ♦ 45k

And it's cross posted see here

ADD REPLY • link written 2.8 years ago by michael.ante • 3.0k

see that old post it didn't have any proper or appropriate explanation

ADD REPLY • link written 2.8 years ago by Bioblazer • 40

The answers in old post were perfect explanation for this problem. Even more you have not provided much details on whether this BAM is downloaded or created on your own. Did you check all the chromosomes are present in BAM (if the data is not for any single chromosome) ?

ADD REPLY • link written 2.8 years ago by venu ♦ 5.8k

The explanation was brief, the file is broken, or truncated. It might have been downloaded incompletely or the process terminated prematurely. To be sure try to read the whole file with samtools view. If that does complain too, the file is broken, if not it was this specific command (bam2fastq). If the file is broken, try to download it again and use a tool like wget or curl, and try to get a checksum for the download. If created yourself, check the output, maybe samtools was killed. One of the most common reasons we see for truncated files is simply 'disk full'.

ADD REPLY • link modified 2.8 years ago • written 2.8 years ago by Michael Dondrup ♦ 45k

Thanks for reply .I am sorry still I could not able to understand what were mention there.

ADD REPLY • link written 2.8 years ago by Bioblazer • 40

2.8 years ago by

John ♦ 12k

Germany

John ♦ 12k wrote:

You've written a sam file and called it a bam file when you did:

samtools view -h accepted_hits.bam "EQ963475:334376-335722" > AFLA_105440.bam

And bam2fq gives the following error if you give it a SAM file:

[bam_header_read] EOF marker is absent. The input is probably truncated.
[bam_header_read] invalid BAM binary header (this is not a BAM file).

To fix your issue, run samtools view -bh ./AFLA_105440.bam | samtools bam2fq -

The dash at the end is important.

ADD COMMENT • link modified 2.8 years ago • written 2.8 years ago by John ♦ 12k

2.8 years ago by

Bioblazer • 40

Pune

Bioblazer • 40 wrote:

samtools view -hb accepted_hits.bam "EQ963475:334376-335722">AFLA_105440.bam .

The above command was worked.

ADD COMMENT • link written 2.8 years ago by Bioblazer • 40

Congrats Muthu -- and you did it a better way than the way I suggested :)

However, the error you had in the first place was so obvious I think a lot of people overlooked it. How could someone not know their data is a 100Gb SAM file instead of a 1Gb BAM file? How could someone not know that their data is human-readable text and not garbled binary? No one is going to appreciate me saying this, so trust me when I say i only mention it for your sake -- but if you continue to run tools without doing any sort of checks that the tools work or gave you the output you expected, you're going to run into a lot of these silly little issues that will either slow you down - or worse - give you reasonable-looking result that are totally incorrect. Use head and tail, check filesizes, etc etc. Don't rely on the tools, as in the example above, to do everything for you :)

ADD REPLY • link modified 2.8 years ago • written 2.8 years ago by John ♦ 12k

Please log in to add an answer.

Similar posts • Search »