I've got some points on this issue.
1. ISO docs has a number of errors and typos, this can be one of them.
May be authors wanted to set buffer restriction to maximum, but
forgot that maximum frame size corresponds to maximal bitrate
and MINIMAL samplerate and took both maxima for computation?
p. 2.4.3.4.4 in ISO 11172-3 is not apparent enough to be the truth.
2. I use 1440+512 bytes (11520 + 4096 bits) buffer in decoder.
If any bitstream uses frame buffer > 7680 bits - not a problem.
I'm sure every decoder should decode (and play music)
rather then locate incompliances in bitstream. 1 KB is not a cost.
In encoder I always use main_data_begin == 0 for 320 kbit/s
just because it is apparently written in ISO docs. And not
restricted main_data_begin for other bitrates.
3. To add an option to lame sounds good. But I think no one
need this restriction to be default.
Will --iso_layer3_buffer_restiction_ON be suitable? ;-)
Regards,
-Leonid
> > Any guesses as to why MP3Enc 3.1 upsamples to 48kHz by default at 320kbps?
> > To increase time resolution?
> >
> > -- Mat.
> >
>
> I think this is related to the 7680 mp3 buffer limitation.
> An mp3 frame can be no larger than 7680 bits. However,
> look at the framesizes at 320kbs:
>
> 320kbs/32khz 11520 bits
> 320kbs/44.1khz 8369 bits
> 320kbs/48khz 7680 bits
>
>
> Thus a 320kbs/44.1khz frame is *required* to waste 689 bits
> (8369-7680) per frame by padding the ancillary data.
> And a 320kbs frame cannot make use of the reservoir,
> since this only increases the framesize further.
>
> This also comes up with, for example, 256kbs frames. A 256kbs/44.1khz
> frame is 6687 bits. So the bitreservoir can be at most 993 bits. If
> the reservoir happened to be larger (for example, with VBR and the
> previous frame was 128kbs which allows for a larger bitreservoir) then
> again bits must be wasted only because of the 7680 bit mp3 buffer
> limitation.
>
> I think the only valid reason for this limitation is so hardware
> decoders know in advance that they need at most a 7680bit
> buffer to hold the decoded data. That is not even 1K of memory!
> I imagine most decoders could afford to allocate a 2K buffer
> instead, and then they could play back mp3 files which ignore
> this limitation. This is why I suggested we add some kind
> of option to lame to allow this.
>
> Maybe Alex Broadhead could comment on if the decoder he just
> wrote could handle this?
>
> Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
