0

I'm getting a couple of error messages while using the mpglib to decode MP3 data using the libmp3lame library environment.

error(#1): hip: Can't rewind stream by 74 bits!
error(#2): hip: bitstream problem, resyncing skipping 10 bytes...

Note: the "resyncing" message says 10 bytes which is 74 bits rounded up: (74 + 7) / 8 = 10.

My MP3 decoder code follows the code in the LAME frontend tool (mainly frontend/lame_main.c and frontend/get_audio.c).

The header generates no errors and I use up to 100 bytes as per the frontend tool (see the lame_decode_initfile() function in the get_audio.c file.) I even tried to read data one byte at a time while handling the header to see whether it would make a difference and... not really.

The error happens when I start passing the MP3 data after having parsed the header.

Any idea why I would be getting these error messages?

P.S. when I decode using the lame command line tool, I do not get the error.

$ lame --verbose --decode test.mp3 test-lame.wav
input:  test.mp3  (44.1 kHz, 2 channels, MPEG-1 Layer III)
output: test-lame.wav  (16 bit, Microsoft WAVE)
skipping initial 529 samples (encoder+decoder delay)
Frame# 87426/88167  168 kbps   MS

Although there seem to be a discrepancy between the number of frames but I would imagine that's because the 88167 was an estimation and not a known number of samples.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156

1 Answers1

0

Okay, I found out that I had a bug and would skip some bytes in a buffer. My implementation is a bit complex as I want to have the data streamed as fast as possible and there was one case where I missed emptying a buffer before moving forward.

So if you get that kind of error in your code but not running lame in your console, this is 99% likely to point to a bug in your code. Be patient and look at your implementation and make 100% sure that you are sending the correct data each time. If that helps you debug your problem, add a sub-function which will save what you send to the LAME decoder and compare that to your original data.

Finally, if you try to send too much data all at once, know that you will get similar errors. This is because the LAME library doesn't cache much of your data and it has the ability to only return one single frame.

On my end, I send 100 bytes at a time to the hip_decode1_headersB() function until the MP3 structure gets the header_parsed field set to true.

Then I send a maximum of 1024 (1Kb) of data at a time to the hip_decode1_headers(). However, that one is much more complicated to use. You must flush everything each time. To flush you call the function again with your data pointer and the length set to 0. The function is done flushing once it returns 0. When you do not have any more data and the function returns 0, you are done decompressing your entire set of MP3 data.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156