Marc DUMONT

OK. "My" problem is solved, I was indeed pushing bad data to the encoder, on some incoming stream packet losses, but LAME library is not responsible for that. The only open point left is the capability of LAME encoder to be resilient to error from input buffer... I leave you, authors, solving or not this point. Thanks.

I almost agree with you, but may be float "NaN" is not a real case to push into the encoder anyway.... That one, for sure, immediately produces the assertion. This is not a real 'crash', by the way, I mean this does not run into access violation/buffer overrun or something like this. This is an assertion (critical last-chance check) which causes program abort() at the end.

Continuing my investigation shows that the encoder is maybe not-so-responsible but the decoder is.... In fact my test application decodes MP3 then recodes it over a real-time stream. But sometimes the input stream "looses" some packets, which causes MP3 decoding errors but concealed (not crashing). But it seems to leave some uninitialized float-data at the MP3 decoder output....

[Currently validating] I saw, at least, uninitialized arrays in psymodel.c like wsamp_L, wsamp_S (and probably the other ones), that may have some influence after many frames encoding. It seems I have many "NaN" values finally propagated.... on the FFT result "energy" and then the assertion on "el". I'm not sure if this is a MSBuild / gcc compilers perhaps known difference ? A fact is non-static arrays are never initialized. I remember some years a go I (privately) fixed a same kind of bug in layer2.c/decode_layer2_frame...

Hi. Same for me (*), currently reproductible in DEBUG version. I'm stuying it (development mode). This problems occurs since a long time for me, at least 3.99 version, but I was not using the encoder so much. Now I want to track this problem. For now what I have is that "el" value comes to 'UNDEFINED' float value (not correct negative) like -1.#IND ... I'm tracking the call stack a bit upper to see what causes fftenergy[] and perhaps wsampl_l[] to become invalid .... all around FFT code anyway. (*)...

Hi. Same for me, currently reproductible in DEBUG version. I'm stuying it (development mode). This problems occurs since a long time for me, at least 3.99 version, but I was not using the encoder so much. Now I want to track this problem. For now what I have is that "el" value comes to 'UNDEFINED' float value (not correct negative) like -1.#IND ... I'm tracking the call stack a bit upper to see what causes fftenergy[] and perhaps wsampl_l[] to become invalid .... all around FFT code anyway.