MP3 "gain loss bug" for sample rates 8k, 11.025k, and 12k

MP3 "gain loss bug" for sample rates 8k, 11.025k, and 12k

There exists a "gain loss bug" in the IPP Samples floating-point MP3 encoder code which affects the IPP Samples toolkit at least as far back as v5.3 and appears to still exist in v7.1.  For the three supported sample rates less than 16k (8k, 11.025k, and 12k), the output .mp3 is upsampled by 2 but has 1/2 the amplitude.  The bug is independent of bitrate, MP3 layer (for layers 1, 2, or 3), and MPEG format (for MPEG-1 or MPEG-2).

I have confirmed the bug affects both versions v5.3 and v7.0, and it appears to affect the current v7.1 version as well but I haven't actually tested that.

The bug is related to the 'upsample' parameter of the '_MP3Enc' structure. Here are three one-line changes (one for each MP3 layer) that can be used to fix the bug:

mp3encGetFrame() in mp3enc_api_fp.c:

layer 1:
  old code:
    ippsConvert_16s32f(buff[ch], tbuf, 384 >> upsample);
  new code:
    ippsConvert_16s32f_Sfs(buff[ch], tbuf, 384 >> upsample, -upsample);

layer 2:
  old code:
    ippsConvert_16s32f(buff[ch], tbuf, 1152 >> upsample);
  new code:
    ippsConvert_16s32f_Sfs(buff[ch], tbuf, 1152 >> upsample, -upsample);

layer 3:
  old code:
    ippsConvert_16s32f(buff[ch], tbuf, frame_size);
  new code:
    ippsConvert_16s32f_Sfs(buff[ch], tbuf, frame_size, -upsample);

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Great find. Is the integer version of the encoder affected similarly?

Can anyone from Intel or anyone with the proper insights confirm/review the findings and the suggested changes?

Leave a Comment

Please sign in to add a comment. Not a member? Join today