LAME mp3 codec gives errors, how to fix?

Question

linux

I use LAME mp3 encoder in C++ program. Ubuntu 14.04.1 system, gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, not overclocked. When I run the program, I get the following errors in the output:

This is a fatal error. It has several possible causes:90% LAME compiled with buggy version of gcc using advanced optimizations 9% Your system is overclocked 1% bug in LAME encoding libraryInternal buffer inconsistency. flushbits <> ResvSizebit reservoir error

My code based on the code from frontend/lame_main.c:

unsigned char mp3buffer[LAME_MAXMP3BUFFER];

lame_t lame = lame_init();
lame_set_in_samplerate(lame, 44100);
lame_set_out_samplerate(lame, 44100);
lame_set_num_channels(lame, 1);
lame_set_mode(lame, MONO);
lame_set_quality(lame, 0);
lame_set_brate(lame, 128);
lame_init_params(lame);

int iread = 0;
int imp3 = 0;

do
{
    iread = file.read((char *)buf, buf_size * sizeof(float));

    if(iread > 0)
    {
        int current_pcm_size = iread / sizeof(float);

        static float filtered_buffer[buf_size];
        if(fstart > 0.0) // bandpass filtering
        {
            ippsFIR64f_32f(buf, filtered_buffer, current_pcm_size,
                                       filter->pState);
        }
        else
        {
            memcpy(filtered_buffer, buf, iread);
        }

        imp3 = lame_encode_buffer_ieee_float(
             lame, filtered_buffer, filtered_buffer,
             current_pcm_size, mp3buffer, 0);

        f_mp3.write((char *)mp3buffer, imp3);
    }
} while(iread > 0);

imp3 = lame_encode_flush(lame, mp3buffer, sizeof(mp3buffer));

if(imp3 >= 0)
    f_mp3.write((char *)mp3buffer, imp3);

f_mp3.flush();

lame_close(lame);

How to solve this problem? Perhaps install a different version of gcc?
upd: after all, the main target platform is Windows, so I moved the project to Windows, since all the libraries used are cross-platform. There are no problems with lame here.

Answer 1

Show the full source so that it can be compiled.
Only if you compiled lame yourself, and that's unlikely.