轉載 max mp3 frame size

[mad-dev] max mp3 frame size?

Rob Leslie rob@mars.org
Thu, 17 Jan 2002 16:54:05 -0800

• Previous message: [mad-dev] max mp3 frame size?
• Next message: [mad-dev] max mp3 frame size?
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

Joshua Haberman wrote:
> Currently Audacity uses a 64k input buffer when reading mp3s with libmad.
> This has worked great for the most part, but I've received a report that
> one particular mp3 will put Audacity into an infinite loop upon import.
> Since a trace revealed that the input callback was looping endlessly, I
> suspected that the buffer wasn't big enough to hold an entire frame, and
> the input callback was sending libmad the same partial frame over and over.
> 
> I suggested that this user double the input buffer size, and that fixed
> the problem.
> 
> Earlier when I asked you about this issue, you said mp3 frames are
> relatively small (around 418 bytes) so I'm very surprised that 64k wasn't
> big enough to hold an entire frame. Can you think of any other reason why
> increasing the buffer size would solve this problem?

Sounds like it could be a bug in your input/streaming code, triggered by the
unlucky buffer size? Out of curiosity, what bitrate and sampling frequency was
the mp3 that caused problems?

> Is there a maximum size for mp3 frames that I could safely set as the
> buffer size, or would I have to dynamically size the buffer to be
> completely safe?

The absolute theoretical maximum frame size is 2881 bytes: MPEG 2.5 Layer II,
8000 Hz @ 160 kbps, with a padding slot. (Such a frame is unlikely, but it was
a useful exercise to compute all possible frame sizes.) Add to this an 8 byte
MAD_BUFFER_GUARD, and the minimum buffer size you should be streaming to
libmad in the general case is 2889 bytes.

Theoretical frame sizes for Layer III range from 24 to 1441 bytes, but there
is a "soft" limit imposed by the standard of 960 bytes. Nonetheless MAD can
decode frames of any size as long as they fit entirely in the buffer you pass,
not including the MAD_BUFFER_GUARD bytes.

A 64K buffer is surely large enough, which makes me think you have a different
kind of problem...

-- 
Rob Leslie
rob@mars.org