Try two - I'm guessing the first one bounced due to the excess of LOVE on
the net...
Howdy Mark,
> -----Original Message-----
> From: Mark Taylor [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 01, 2000 10:18 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [MP3 ENCODER] MP3Enc upsampling /buffer
...
> > 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)
'part2_3_length' is less than 4096 _bits_. 'dist10' uses a (main/ancillary
data) buffer of 4096 _bytes_ - i.e. way, way too many bits!
> 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.
Not including ancillary data, of course, but that shouldn't matter unless
you're trying to handle a multichannel bitstream.
> 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!
Yes, the buffer limitation only really affects main (and possibly ancillary)
data collection. (Which makes the number 7680 fairly arbitrary, as it is
the size of an entire frame.) You always have to have a 'frame' buffer to
hold the current frame data as it is decoded (unless you want to do it
sequentially, as I suppose a hardware designer might). Then you need
someplace to cache the main data while you build up an entire _audio_
frame's worth.
Layer-III decoding is significantly more complicated than layer-I/II, due to
the fact that the main data for a frame can be contained in previous frames.
Thus, you basically have to buffer all the main (and usually ancillary) data
you encounter while decoding until you have main_data_begin less than or
equal to the amount of buffered data. If it weren't for this requirement,
you could just 'buffer data from the current frame', which is what you do do
with the other layers. I suppose you could buffer until you filled the
buffer and then decode until you have decoded everything you can (as you
described for hardware), but it makes more sense to just buffer until you
know you have a full frame, so that you can pipeline things.
...
> 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):
I'd have to check to make sure, but I doubt that the ISO decoder detects
nonzero main_data_begin as an error for 320 kbit/s streams. Your VBR
example certainly shows why it shouldn't. The docs generally seem to
predate any serious thought about VBR, though, so it seems entirely possible
that ISO just hadn't thought about it at the time.
Alex
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
