Sigbj�rn Skj�ret schrieb am Mon, 18 Sep 2000:
> >The fix is to do what Frank suggests: go to a data-encapsulted
> >type interface, where every parameter must be set via
> >a function. We would need to write about 100 functions
> >along the lines of: lame_set_input_samplerate().
>
> A much better (and tidier) solution is to have one function that you can pass
> a struct to, like this:
>
> lame_setup_stuff(struct LAMEprefs *prefs, unsigned int structsize);
OR:
1) use commandline like strings to setup LAME's encoding engine
handle = lame_get_handle();
lame_setup_stuff(handle, "output samplerate = 32 kHz");
lame_setup_stuff(handle, "input samplerate = 48 kHz");
lame_setup_stuff(handle, "bitrate = 128 kps");
lame_setup_stuff(handle, "channel mode = stereo");
lame_setup_stuff(handle, "coding mode = variable bitrate");
lame_setup_stuff(handle, "coding mode = average bitrate");
lame_setup_stuff(handle, "coding mode = constant bitrate");
lame_setup_stuff(handle, "lowpass = 15 kHz");
lame_setup_stuff(handle, "highpas = -1");
2) use XML to pass the setup to LAME
but, first we have to sort out the switches that are example code
specific like --mp3input, all id3 stuff, histogram, presets, decode,
ogg, fame analyzer, ....
> And then simply just don't read more than the supplied size, and be sure that
> when you extend this struct you just append new variables at the end, and
> never change the order or size of the variables (if size must change, make a
> new variable at the end)...
>
> Perhaps also a version-number of the struct as the first item to make it
> easier to decide what options to read, and which to discard...
>
>
> - CISC
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
