Header Missing Error Mp3 transcode

[GoogleCodeExporter]

I am writing a program that transcodes mp3files to mp3s with a small
standart bitrate. But testing the software with several files produces
errors with most testmp3s.
It seems that Xuggler does not like most mp3 files of my collection.
Only very few mp3s were accepted:

What steps will reproduce the problem?

execute the following Java code with the sample files i uploaded:

http://188.40.236.134/sample-mp3s/sample.mp3

         // create a media reader
         IMediaReader reader = ToolFactory.makeReader("input.mp3");

         // add a viewer to the reader, to see the decoded media
         reader.addListener(ToolFactory.makeWriter("output.mp3", reader));

         // read and decode packets from the source file and
         // and dispatch decoded audio and video to the writer
         while (reader.readPacket() == null)
           ;

OS Windows7
Java 1.6
Xuggler 3.3.940

Attach relevant log/output files.
Log:
2009-12-10 13:31:32,775 [btpool0-0] WARN  org.ffmpeg - [mp3 @ 0x95e1670]
max_analyze_duration reached
2009-12-10 13:31:55,059 [btpool0-0] ERROR org.ffmpeg - [mp3 @ 0x95462b0]
Header missing

java.lang.RuntimeException: error -1 decoding audio
    at com.xuggle.mediatool.MediaReader.decodeAudio(MediaReader.java:549)
    at com.xuggle.mediatool.MediaReader.readPacket(MediaReader.java:469)

thx

Original issue reported on code.google.com by emanuel....@gmail.com on 10 Dec 2009 at 1:02

[GoogleCodeExporter]

I have this same problem.  I had an old audio MP3 ripped from the sound track 
of a
DVD.  Mplayer command could play it without complaint, but Xuggle libraries had 
same
issue.  I re-encoded it to a new MP3 using lame (mp3 in, mp3 out) at the same 
rates
and Xuggle could read the new MP3.  

This is a problem. I use mplayer command line to create raw PCM (WAV) data from
various formats and wanted to convert it all to Java using Xuggle.  Attached is 
a
small sample (dd if=bad.mp3 of=Sample.mp3 bs=1024 count=1024) that exhibits the 
same
problem.

Original comment by daniel.o...@gmail.com on 30 Mar 2010 at 5:36

Attachments:

• Sample.mp3

[GoogleCodeExporter]

Have the same problem too. Any workaround?

Original comment by juangon@gmail.com on 3 Sep 2011 at 7:57

[GoogleCodeExporter]

I'm getting this too, for all MP3 files on a 64bit Linux box.

Is it possible to upgrade ffmpeg? Is it worth building from HEAD?

Original comment by elstenso...@googlemail.com on 24 Oct 2011 at 3:51

[GoogleCodeExporter]

I solved it by doing readNextPacket before the readNextPacket iteration...I 've 
seen this solution searching in Xuggler forums...

Original comment by juangon@gmail.com on 24 Oct 2011 at 3:57

[GoogleCodeExporter]

Thanks for letting me know. I've seen it too (you mean this right: 
http://groups.google.com/group/xuggler-users/browse_thread/thread/d01ac1f024afb8
5d ?), but it didn't work for me.

Could you post some sample code?

Here's what I'm doing (apologies, this is Scala):

val reader = ToolFactory.makeReader(encodedFile.getAbsolutePath());
val writer = ToolFactory.makeWriter(decodedFile.getAbsolutePath(), reader);
try {
  reader.addListener(writer);
  while (reader.readPacket() == null) {
  }
} finally {
  reader.close()
}

Original comment by elstenso...@googlemail.com on 8 Nov 2011 at 4:24

[GoogleCodeExporter]

Mmm I didn't use MediaListener, but I guess just read once before the iteration:

val reader = ToolFactory.makeReader(encodedFile.getAbsolutePath());
val writer = ToolFactory.makeWriter(decodedFile.getAbsolutePath(), reader);
try {
  reader.addListener(writer);
  reader.readPacket()
  while (reader.readPacket() == null) {
  }
} finally {
  reader.close()
}

Original comment by juangon@gmail.com on 8 Nov 2011 at 4:27

[GoogleCodeExporter]

I tried that, it doesn't work, I still get "header missing" messages. I also 
get the occasional message as so with some files:

ERROR org.ffmpeg - [mp3 @ 0x248b7d0] incomplete frame

Could you post your code?

Original comment by elstenso...@googlemail.com on 10 Nov 2011 at 10:02

[GoogleCodeExporter]

I don't use MediaListener at the moment due to this and other problems in some 
files.
I developed my own algorithm, will post here when I refactor it a little.

Original comment by juangon@gmail.com on 10 Nov 2011 at 10:08

[GoogleCodeExporter]

BTW, I can't avoid "incomplete frame" error in logs.

Original comment by juangon@gmail.com on 10 Nov 2011 at 10:12

[GoogleCodeExporter]

I think it must be a general issue in ffmpeg. If I use ffmpeg directly on the 
command line I get the same message:

[mp3 @ 0x232ae20] Header missing
Error while decoding stream #0.0
size=   24651kB time=143.10 bitrate=1411.2kbits/s    
video:0kB audio:24651kB global headers:0kB muxing overhead 0.000174%

Interestingly, I have two copies of this track with slightly different lengths. 
The other one works fine, both in ffmpeg and xuggler. I wonder if this is 
related: https://ffmpeg.org/trac/ffmpeg/ticket/4 .

Original comment by elstenso...@googlemail.com on 10 Nov 2011 at 10:44

[GoogleCodeExporter]

Thanks for that. Yep the problem seems with the length of some packet. 

Original comment by juangon@gmail.com on 10 Nov 2011 at 11:16

[GoogleCodeExporter]

I think a report I submitted a few months back might be related: 
http://code.google.com/p/xuggle/issues/detail?id=266

The byte buffer used internally for reading from a stream has a fixed size, 
which is decided based upon the size of the *first frame* in the MP3 stream. 
This would be all well and fine if MP3s had fixed frame lengths within a file, 
but they don't.

So, if the first frame in a VBR MP3 is silence then it will be very short, and 
the byte buffer created will never be able to read a frame longer than that 
(which will be practically ever other frame in the stream) since it has 
allocated only a small number of bytes equal to the size of our first silent 
frame. All attempts to read further into the stream will then catastrophically 
fail.

Original comment by adriangu...@gmail.com on 10 Nov 2011 at 6:06

[GoogleCodeExporter]

In the end I couldn't get this working, so I used JLayer instead for MP3s and 
Xuggler for everything else.

It's quite possible these are just my MP3s that are broken, but as Xuggler was 
only decoding 18% of them I had to try something else. JLayer decoded 99.6% of 
them, and I'm happy with that.

Original comment by elstenso...@googlemail.com on 16 Nov 2011 at 12:57

[GoogleCodeExporter]

Hi,
I found a solution for this.
I used DecodeAndPlayAudio sample. Without too many words, just take a look on 
attached file. Looks like it works for me(i still didn't test it enough).

Original comment by vazdauta...@gmail.com on 16 Jan 2012 at 12:15

Attachments:

• DecodeAndPlayAudio.java