Ah, well, I dont believe that I want each coefficient set seperated, that
is against the iso definition of the mpeg standard, right?
anyway, I just need to figure out where in the code is the frame ready to
be outputted as one frame. does the buffer that is written contain only
one frame at a time? is that what formatbitstream does? maybe i should
study the code a lil harder b4 coming for help.
-kali
On Thu, 4 Nov 1999, Mark Taylor wrote:
>
> > how can I read the mp3 data outputted by lame frame by frame? I noticed
> > in common.c that all the bits are stuffed into a bit stream and then
> > shoved down the pipe, I couldnt figure out though, before that point, when
> > each frame was formed? My point in doing so: I want to serve the
> > microsoft media client. they require that the frames are all of uniform
> > size and that there is some funky header preceding each mp3 frame. that is
> > why I need the individual frames. and also, where can I find out the
> > individual frame sizes in bytes? I emailed mark taylor already regarding
> > individual frame size uniformity, and he told me that I just need to set
> > the padding bit to 0 in order to have uniform frames, will this cause
> > problems of any sort? thanks a bunch yall.
> > -kali
> >
>
> You will probably have to be more specific. An MP3 frame looks like:
>
> header
> side info
> data
>
> The size of the frame varies by at most one byte (at 44.1khz). AT
> 48khz, all frames will be the same length.
>
> However, the actual encoded coefficients for a given frame will
> usually be spread over two frames. For example, 20% of it might be in the
> data block of the previous frame, and 80% is stored in the data
> block of the current frame.
>
> This size of the encoded coefficients is variable, it can range
> from 0 to 6000 bits more or less, and it is impossible to make
> every frame use exactly the same amount of data.
>
> Because of this, a frame is not a selfcontained unit. You
> usually need at least two frames before you can decode one frame worth
> of data.
>
> Some decoders work by creating new "meta frames" which contain
> the header, side info and all data associated for that frame.
> If MS wants this kind of information, you are going to have to
> really muck around with the bitstream. The mp3asm code does some
> of this.
>
> Mark
>
>
>
>
>
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
