IPB

Welcome Guest ( Log In | Register )

How does LAME actually work?, I dont understand how the lib itsef functions
Istrebitel
post Aug 1 2011, 12:12
Post #1





Group: Members
Posts: 54
Joined: 20-October 10
Member No.: 84756



Greetings.

I am doing some experiments with audio encoding. I am right now studying sources of the LAME encoder (lastest stable).
So far, i've read every available documentation and i still wonder:

Lame encoding process goes like this:
- init
- pass parameters
- encode some frames
- close

Frames are encoded in a loop where we get values from (for example) wav file and pass them to a function that looks like this:

lame_encode_buffer_int(lame_global_flags * gfp,
const int buffer_l[],
const int buffer_r[],
const int nsamples, unsigned char *mp3buf, const int mp3buf_size)

Then we write the contents of mp3buf to disc and get values again until we get EOF.

Question: From what i've read, MP3 is supposed to have:
a) Bit reservoir
b) Consequently, Data that "overlaps" into other "frames", meaning that after the frame X header may come data of a frame from the future (for example data of X+1)

Therefore, how can we actually encode MP3 file in such fashion? I mean, say frame1 is all silence and it takes less than our bitrate (for example 128) to encode. Then we should end with a frame 1 header, then some data, and some not yet used space now allocated to bit reservoir. Then, encoding frame 2, we would first fill the unused space in frame 1's data part, and then start filling frame 2.
If we output frames one-by-one, what happens? How is this actually processed? Does LAME actually store the bit reservoir data somewhere in the GFP structure and outputs only the part of the frame that contains data of the frame, meaning say header of the frame 2 might only get put into buffer when we output frame 4 (which used bit reservoir and thus occupies space before and after frame 3 header)?

What happens at the end? For example, we end our encoding with bit reservoir bigger than a frame, this means we didnt ouput last frame header yet, however there is no more data to encode. From what i see in the frontend code, we just read wav file until we read 0 bytes, and then we stop. Or does calling encode_buffer function with nsamples=0 trigger "finalisation" of the encoding? It doesnt look like since the function contains:
if (nsamples == 0)
return 0;
Which means supplying 0 samples will make it do nothing, presumably. So how do those headers end up in the stream, or are they... dropped? But then this would mean we are loosing up to max_bit_reservoir/frame_size frames? Or is max_bit_reservoir smaller than minimum possible frame size?

I know this might be very narrow / specific question to those who have knowledge of the code, or it might even be a stupid question cos i am blind, but please if you have knowledge and time, help me.

Thanks!

This post has been edited by Istrebitel: Aug 1 2011, 12:15
Go to the top of the page
+Quote Post
 
Start new topic
Replies
lvqcl
post Aug 14 2011, 10:26
Post #2





Group: Developer
Posts: 3362
Joined: 2-December 07
Member No.: 49183



Open vc_solution\vc9_lame.sln. Build libmp3lameDLL project.
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 30th August 2014 - 14:47