Hello, Mark.
> 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()
I have been tring that, though, my code always fails in bitstream output. I
don't know why, but the reson that does not work is my poor skill. ;-) I'm
in office now, so I can not show my code, but I will upload my class in this
evening.
> 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).
That's nice. I don't know the code of Kazumi, hope the error message will be
defined in one header file and some support for locale. If so people who
don't speak English can easily translate it into their own native language.
> 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.
I know the exit()s are call in fatal error case, though, it should be return
can clean up the process itself. exit() is just in ANSI library, but I think
it should not be used like gets(). And assert() macro. If we call exit() or
assert(), the process will be die without doing no clean up itself,
releasing memory, closing files, and so on. You want to say, ``OS will be do
that'', but some OS, includes MacOS are not so reliable.
> 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)
I know, but if defined the NDEBUG macro, assert() do nothing, right? If we
don't need a check, assert() should not be placed there. LAME is still under
developing, but, assert() should not be good solution for error handing. It
should be return error like exit().
> 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.
Now I don't use libsndfile, but use my altivec optimized get_audio.c. It
runs faster on my G4 processor. So I can replace it with my new C++
iostream/fstream version.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
