> i'd like to take this opportunity to point out one of my pet peeves with
> libmp3lame, and that is the lame_decoder() function takes a FILE* ... and
> then helpfully closes it for you. so that you helpfully get a SIGSEGV
> when you try to cleanup the files you open and close them again.
>
> blah.
> but otherwise, it's been going pretty good.
lame_decoder() is one of the functions that is going to be
removed from the API :-). If you want to decode in a true
library like fashon, you have to stick with
lame_decode_init() and lame_decode(). Those functions
just take buffers of mp3 data and return pcm data.
>
>
> Also! there's been some talk of removing the cmd-line parsing code from
> the library. i think that's a bad idea, at least until there's some
> documentation on what you're supposed to set in that big bit-structure,
> you have two choices, just feed it embedded cmd-args, or read the source.
> while i'm okay reading the source, it shouldn't be that hard just to
> figure which flag you need to set to get something done.
>
good point! So Takehiro: consider this another vote for keeping
parse.c in the library.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
