Welcome Guest ( Log In | Register )

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

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


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.


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

BonkEnc developer

Group: Developer
Posts: 78
Joined: 17-January 03
From: Hamburg
Member No.: 4611

LAME always outputs complete frames, but each call to lame_encode_buffer can return 0..n frames. So if the first block of data to encode does not fill a complete frame, you simply get no data back from the first call. Then if the second block fills the rest of frame 1 and the complete frame 2, you will get both frames returned at once.

At the end of an encoder run, lame_encode_flush is called to flush the internal buffers and possibly return one last frame that is not completely filled (padded with zeros / silence).

So it's actually:

- init
- pass parameters
- encode some frames
- flush
- close
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: 27th November 2015 - 19:22