>
> > 2. I use 1440+512 bytes (11520 + 4096 bits) buffer in decoder.
> > If any bitstream uses frame buffer > 7680 bits - not a problem.
>
> I do a similar, but less smart, thing in my decoder. I use 7680 + 4096 bits
> for the buffer, where 7680 is the 'maximum' frame size (though I only ever
> buffer main/ancillary data) and 4096 is the max main_data_begin. I think I
> may switch it to yours above. In any case, in software it's just a #define,
> and most machines have RAM to burn these days...
>
> > I'm sure every decoder should decode (and play music)
> > rather then locate incompliances in bitstream. 1 KB is not a cost.
>
> Amen.
>
> My decoder has the buffer limitations above. Since we basically always run
> at 64 kbit stereo, I could probably make my buffer much smaller, but I'm
> trying to be a compatible as I can for now. If I ran into a bitstream that
> crashed my decoder for buffer reasons, I'd definitely just up the size.
>
> I should note, BTW, that the ISO 'dist10' package uses a BUFFER_SIZE of 4096
> bytes... Doh.
>
Maybe this is the buffer for a single granule, rather than the whole
frame? (since part2_3_length is < 4096)
Which leads me to suggest the following:
A reasonable max buffer size might be: 4096*4=16384 (or should that be
4095*4?) since this is the largest possible frame size.
The buffer limitation must only be used to buffer the data from the
mp3 stream? mpg123 buffers data from the current frame until it gets
to the header for the second frame (or end of file) and only then does
it start to decode. The buffer is just malloc()'d, with no
limitations other than system memory. So mpg123 should have no
problem with these types of streams.
I guess I could imagine a hardware player buffering mp3 data and only
allocating at most 7680 bits for the mp3 data buffer. Once this
buffer is full, it decodes a frame and then fills the buffer again.
But it is hard to imagine a software encoder would be written this way!
Also, the MPEG2 spec allows for much larger frame sizes because
for the 5.1 channel encoding, the 3,4 and 5 channels are encoded
in the ancillary data. layer III, 44.1khz multichannel audio
allows for frame sizes up to 947kbs. (which leads to another
possible non-standard extension that well written player should handel:
free format, fixed bitrates up to 947kbs!)
Another question is the 320kbs main_data_begin. Although LAME
currently enforces the 7680 bit limit, it does not actually force
main_data_begin=0 for 320kbs frames as Leonid suggests. Take the
following (VBR) example (numbers made up):
bits added
max_bits bits used main_data_begin to reservior
Frame 0: 128kbs 3200 3100 0 100
Frame 1: 128kbs 3200 2900 100 300
Frame 2: 320kbs 8200 7680 400 520
Frame 3: 128kbs 3200 3900 920 -700
If frame 2 requires main_data_begin = 0, it would force us
to waste 400 bits (by adding 400 bits into the ancillary data of
frame 1).
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
