First, see the file STYLEGUIDE ************************************************************************ TESTING ======= If you make changes, please test. There is a python script in the test/ directory which will compare two versions of lame using a bunch of CBR and ABR options. To run this script, copy your favorite (and short!) wav file to the lame/test directory, and run: % cd lame/test % ./lametest.py [-w] CBRABR.op castanets.wav lame_orig lame_new ************************************************************************ LAME API For a general outline of the code, see the file API. Also, frontend/main.c is a simple front end to libmp3lame.a The guts of the code are called from lame_encode_buffer(). lame_encode_buffer() handles buffering and resampling, and then calls lame_encode_frame() for each frame. lame_encode_frame() looks like this: lame_encode_frame_mp3(): l3psycho_anal() compute masking thresholds mdct_sub() compute MDCT coefficients iteration_loop() choose scalefactors (via iteration) which determine noise shapping, and choose best huffman tables for lossless compression format_bitstream format the bitstream. when data+headers are complete, output to internal bit buffer. copy_buffer() copy internal bit buffer into user's mp3 buffer ************************************************************************ ADDING NEW OPTIONS control variable goes in lame_global_flags sturct. Assume the variable is called 'new_variable'. You also need to write (in get_set.c): lame_set_new_variable() lame_get_new_variable() And then document the variable in the file USAGE as well as the output of "lame --longhelp" And add a "--option" style command line option to enable this variable in parse.m Note: for experimental features that you need to call from the frontend but that should not be part of the official API, see the section at the end of get_set.c. These functions should *NOT* be prototyped in lame.h (since that would indicate to the world that they are part of the API). ************************************************************************ THREADSAFE: Lame should now be thread safe and re-entrant. The only problem seems to be some OS's allocate small stacks (< 128K) to threads launched by applictions, and this is not enough for LAME. Fix is to increase the stack space, or move some of our automatic variables onto the heap with by using bug-prove malloc()'s and free(). ************************************************************************ Global Variables: There are two types of global variables. All data in both strucs is initialized to zero. 1. lame_global_flags *gfp These are input paramters which are set by the calling program, and some information which the calling program may be interested in. This struct instantiated by the call to lame_init(). 2. lame_internal_flags *gfc Most global variables go here. All internal data not set by the user. All 'static' data from old non-reentrant code should be moved here. Defined in util.h. Data for which the size is known in advace should be explicitly declaired (for example, float xr[576]); Data which needs to be malloc'd is handled by: 1. in lame_init_params(), malloc the data 2. be sure to free the data in freegfc() If the data to be malloc'd is large and only used in certain conditions (like resampling), use the following: this has the disadvantage that it is hard to catch and return error flags all the way back up the call stack. 1. Add an initialization variable to the gfc struct: lame_init_resample 2. In the resample routine, there should be some code like this: if (0==gfc->lame_init_resample) { gfc->lame_init_resample=1; /* initialization code: malloc() data, etc */ } 3. The data should be free'd in the routine freegfc().