Hi!
Thanks a ton Rob, for the help. However....... If the first 9 bits(in MPEG 1 Layer 3) of sideinfo referred to main_data_begin, as you pointed out, then I'm absolutely clear about the way main_data is collected(i.e, if the first 9 bits are main_data_begin, which is a negative offset from the beginning of the frame which points to the start of the current frame's main_data). However, ISO/IEC 11172-3 does refer to the first 9 bits as "main_data_end" (please see section 2.4.1.7 of 11172-3, and figure 3-A.7.2 of the same document). The above mentioned figure also illutrates that main_data_end(or the first 9 bits) is a negative offset from the end of the frame pointing to the 'end' of the current frame's main_data. Now, I understand that these 9 bits are probably actually a negative offset from the beginning of the frame(all the mp3 files I've seen have these 9 bits = 0 for the first frame, which points to the fact that this is probably a negative offset from the beginning), but the standard clearly states otherwise(i.e, it states that this is a negative offset from the end of the frame, pointing to the end of the current frame's main_data). Did I read the standard wrong, or did I read an older version of the standard, or did ISO publish errata for 11172-3, or is it an error in the standard, or, the least likely of the above, is this a bug............
By the way, I have been working on developing a parallel version of MAD, and uptil now, I have written two programs which run on a Beowulf Cluster which use MAD's code and decode mp3 files in parallel(there was a requirement to analyse strategies for decoding audio in parallel). Both of these perform decently well, with a linear scaleability :-). If Rob(or anyone else) is interested in these, do tell me. I also have lots of profiling data on mp3 decoding using MAD, which clearly show the most computationally intensive functions.
And Rob, thanks for writing MAD! If there's any way in which I can contribute to further development of MAD, I'll be honored.
Kshitiz
--- mad-dev-request@lists.mars.org wrote:
Send mad-dev mailing list submissions to mad-dev@lists.mars.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.mars.org/bin/mailman/listinfo/mad-dev or, via email, send a message with subject or body 'help' to mad-dev-request@lists.mars.org
You can reach the person managing the list at mad-dev-admin@lists.mars.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of mad-dev digest..."
Today's Topics:
- Re: MAIN_DATA buffer (Rob Leslie)
--__--__--
Message: 1 Date: Fri, 12 Jul 2002 09:32:54 -0700 Subject: Re: [mad-dev] MAIN_DATA buffer From: Rob Leslie rob@mars.org To: mad-dev@lists.mars.org
On Friday, July 12, 2002, at 01:09 AM, Kshitiz Malik wrote:
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:
- Read the sideinfo(the header's already been
decoded)
[ 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
]
main_data_begin is the name used by ISO/IEC 11172-3 to describe the offset of the beginning of a frame's main_data relative to the frame's header. It also happens to be the end of the previous frame's main_data, but in the context of decoding the current frame, "main_data_begin" should not at all be misleading.
Note that although it is a positive number, it denotes the number of bytes *before* the current frame that the main_data actually begins, not counting bytes used by previous frame headers or side information.
- 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 -
mad_bit_nextbyte(&stream->ptr);
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 -
next_md_begin;
This has me absolutely stumped.
This calculates the effective length of the current frame's main_data: the number of bytes between the current frame's main_data_begin and the next frame's main_data_begin. frame_space is the number of bytes between the end of the current frame's side info and the next frame header, i.e. as you said, bytes of main_data which may belong to *any* of the current or subsequent frames. We add to this the number of bytes of main_data preceding the current frame (i.e. main_data_begin) and then subtract the number of bytes belonging to the next or subsequent frames (i.e. next_md_begin).
To make things clearer, imagine the case when main_data_begin is always 0. In this case, every frame's main_data is contained entirely between frame headers, and the length is exactly frame_space. Now consider one frame whose main_data_begin is 1, but the rest are still 0. The main_data length of this frame is one byte larger because it begins one byte earlier. The main_data length of the *previous* frame is one byte smaller.
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 queue??
The general assumption is that once a frame has been decoded, its frame data area will no longer be accessible, so any data that might belong to future frames is copied to the main_data buffer. When the next frame is processed, the rest of the frame's main_data is appended to the buffer in a contiguous fashion and the audio data is decoded. Then the buffer is re-initialized with the remaining data that might belong to future frames, and the process repeats.
- 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)
I think this might be the source of your misunderstanding: there is nothing called main_data_end, and main_data_begin is a negative offset from the *beginning* of the frame, not the end.
Cheers,
-- Rob Leslie rob@mars.org
End of mad-dev Digest
__________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com