>> For the decoder part, when decoding on the fly during encoding, it
>> should never call exit. When using as decoding lib, well, that seems
>> to be still a problem.
> I see. This decoding part seems to have been a headache of ours, huh? I
> have two questions about it:
> * Aside from the licensing issues, how feasible is to rip it apart and
> use another library for decoding streams?
For LAME encoder itself, it won't be more complicate than using libSndFile.
The point is, we need some hooks in the decoder for the frame analyzer.
So we would still need HIP for MP3x anyway.
> This way, any potential security flaw (or even common errors) that we
> might have in the hip part of lame could be off-loaded to people
> specializing in that. But that's just part of the benefits, of course.
> We would have a leaner library also.
> * The decoding part is used (mainly) by the encoder for the computation
> of the replaygain values, is that correct?
Yes and no, for replaygain accurate we need HIP. With replaygain-fast we
look at the input data.
Then we have the clip-detection code too, which works on decoded data.
A solution, working for the LAME executable, could be, moving those
out of the lame encoding library and put them into the frontend code.
> If yes, would it be possible to avoid the decoding phase and calculate
> that during the encoding process, therefore giving the users that want
> the replaygain values a possible speed gain?
> It seems that some of the tools (like, say, mp3gain) would deliver
> results acceptable for those that use --replaygain-fast and they don't
> seem to need to decode the file (do they?).
Personally, I've never used our clip-detect and replaygain-accurate
But, as we have them, I'm quite sure there are people using them.