Hi Osamu,
I would be opposed to converting LAME to c++, but what about
the following (this is what lame_enc.dll does):
Write a C++ wrapper which does its own file I/O, and just
calls the following routines:
lame_init()
lame_init_params()
lame_encode_buffer() <-- called many times, with any size input,
lame_encode_finish()
These routines have some fprintf(stderr,...) calls, but these will
soon be replaced with generic error message code from Iwasa Kazmi (so
they can be disabled, or captured for displaying in another window).
There are just a few exit()'s left in these 4 routines (all fatal
errors), but these will soon be replaced by returns, so the above 4
routines will return an error code if something goes wrong.
Any other improvements to make these routines more library-like
would be appreciated.
The assert()'s are in the code are only for debugging,
they are disabled if you define NDEBUG. (thise seems to
be a standard C thing)
The routines for parsing arguments and file I/O in get_audio.c do not
act like library routines - they have many error messages and
exits. But these routines are really only for the
LAME command line encoder . The approach above is the correct way to use
LAME in another application.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
