Hi Mark,
I would love to add this to the LAME distribution! And think
it is worth making the necessary changes to LAME.
A couple of questions:
Which version of LAME are you working with? A lot of work *has* been
done to make LAME re-entrant. This has not yet been tested or
debugged (maybe you would like to volunteer? :-), but most of the work
is done.
In particular, all private memory structures (i.e. all non-constant
static variables) have been moved into the (now massive)
"global_flags" struct, including bs, l3_side and scalefac_band which
you had to deal with below.
I also think the new code should also allow user selected
initalizations of any of the options without having to write your own
initaliation routine. The suggested way to do this
(this is what the DLL does) would be:
1. lame_init(&gf) (sets default values of all parameters)
2. Your code which can override all settings
3. lame_init_params(&gf) sets internal LAME related stuff based
on various options.
>
> I've written an ActiveX control that uses the LAME library to convert WAV
> files to MP3 files (I did this because I couldn't seem to find the LameX
> control on the web).
>
> I'm willing to either (a) put this into the LAME "source pool" or (b)
> publish it as an adjunct to LAME.
>
> I think option (a), however, requires some modifications to the LAME source
> code. I also have some questions about the LAME code that I bet someone on
> this list can answer. Or educate me on what I'm getting confused about,
> which is just as good <grin>...
>
> 1) The ActiveX control currently does not use lame_init to initialize the
> lame global flags structure. Instead, it does its own initialization, based
> on user-selected values for a variety of properties that the control exposes
> (I can explain why I took this approach if anyone is interested, or would
> like to offer some alternatives). Because lame_init initializes some private
> memory structures, I had to modify lame.h and lame.c to publicly expose
> those initialization routines. This entailed adding the following to lame.c
> (with corresponding entries put into lame.h):
>
> void xlame_init_private_struc()
> {
> memset(&bs, 0, sizeof(Bit_stream_struc));
> memset(&l3_side,0x00,sizeof(III_side_info_t));
> init_bit_stream_w(&bs);
> }
>
> void xlame_init_scalefac(lame_global_flags *gfp)
> {
> int i;
> for (i = 0; i < SBMAX_l + 1; i++) {
> scalefac_band.l[i] =
> sfBandIndex[gfp->samplerate_index + (gfp->version * 3)].l[i];
> }
> for (i = 0; i < SBMAX_s + 1; i++) {
> scalefac_band.s[i] =
> sfBandIndex[gfp->samplerate_index + (gfp->version * 3)].s[i];
> }
> }
>
> 2) I am a little concerned that the LAME code may not be re-entrant, which I
> think could cause oddball problems for users of an ActiveX control. My
> concern is based on those same private structures that I cited in (1), and
> any other similar structures that may exist in the code base.
>
> If two instances of the ActiveX control (in the same container program) try
> to do conversions simultaneously I think there is the potential for
> conflict.
>
> Would it be possible to put all of the structures used in a conversion into
> the lame global flags structure? That way each conversion would be an
> independent, stand-alone activity.
>
> - Mark
> mark@REMOVETHIS [EMAIL PROTECTED]
>
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
