[mad-dev] MAIN_DATA buffer

Kshitiz Malik kshitizmalik@yahoo.com
Fri, 12 Jul 2002 01:09:26 -0700 (PDT)


I have been struggling with MAD's code for quite some
time now, and have managed to
understand almost all of it - except I haven't been
able to figure out the way
it manages a buffer of main_data for mp3 files.
(I am working solely on the MP3 part of the decoder)
The problem is, the function mad_frame_decode(which
decodes ONE entire frame, excluding
the polyphase filterbank) works as follows:

1) Read the sideinfo(the header's already been

   [ I don't know why, but apparently Rob had named
all main_data_end pointers
     as main_data_begin. Of course, main_data_end for
one frame is the beginning 
     of main data for the other frame.... but they're
slightly misleading        ]

2) Depending on the value of main_data_end of the
current frame,
   it collects together the main_data which has been
buffered till now in
   an array, stream->(*main_data). I couldn't figure
out how Rob does this.
   He actually looks at the NEXT frame, reads its
main_data_end pointer, calculates
   a variable named frame_space according to:
     frame_space = stream->next_frame -
   This is the no. of bytes of main_data(which may
belong to ANY of the subsequent frames)
   present in the current frame.
   So far, so good.
   Next up is the statement:
      md_len = si.main_data_begin + frame_space -

   This has me absolutely stumped.

       ||| header +sideinfo | main_data         |||
head + si |  main_data        ||| 
si.main_data_begin              next_md_begin

   If frame_space was the length of main data in the
second frame above,
   md_len would be "the no. of main_data bytes in the
next frame". But frame_space
   is the length of the first frame (above), so I
don't really know what md_len stands for.
   Can someone please help me out here???

   From this point onward, I absolutely cannot
understand the way Rob is bufferring
   up main_data. I see a couple of memcpy's(), and I
can guess what's happenning,
   but I'm not really sure.
   Also Rob, how did you manage keeping a main_data
buffer without using a circular

3) After all this is done , III_decode is called,
which is passed a pointer named ptr,
  which happens to point to the beginning of main_data
for the current frame.
  III_decode actually decodes the Huffman bits ....and
does the actual decoding.

Can somebody please help me out with how the main_data
buffer is built up
(I know the basics, i.e, main_data of the current
frame may be present in any of the 
previous frames, mani_data_end is a negative offset
from the end of the frame...etc...etc)

Thanks a lot!!


Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free