foobar 's bug ?, sound bad for some 8Khz mp3 files Options

[xquake]

When I play some 8Khz mp3 files using foobar 0.82, these mp3 sonud bad .
While play by winamp or nero, they sonud normal. I trid foobar 0.7x , also has this problem.

I know foobar use mpglib. It is said mpglib is derived from mpg123. And I had port mpg123 to DSP before, and now I find my DSP code has the same problem !

so , i guess there must be some bug in it.

I don't know if I can upload the mp3, let somebody to try it.

[Garf]

Uploading is ok, so we can see what's going on.

[xquake]

Could you tell me how to upload?

[Sebastian Mares]

You go to the Upload forum, create a new topic with a descriptive title, type in your message, hit Browse, select the file and finally post the topic.

[The Link]

Untill it is fixed (if it is a bug) you can also try kode54's mad input plugin, perhaps it will work with it.

This post has been edited by The Link: Jul 1 2004, 08:38

[xquake]

thanks.

the post name is "foobar 's bug on 8Khz mp3? " in upload forum.

the file is about 700k.

[The Link]

Do you use a resampler in foobar? For me this made an obviously audible difference with the file you posted, i.e. without resampler it sounded (much) better here.

edit: I didn't abx it because it's obvious to me but normally I cannot hear the impact of a resampler.

This post has been edited by The Link: Jul 1 2004, 09:07

[xquake]

There is still obvious distortion without resample !

using MAD plug_in , sounds ok!

This post has been edited by xquake: Jul 1 2004, 09:16

[The Link]

Seems I'm deaf ... or it's too early in the morning. I compared with a dshow player and I couldn't hear any obvious difference (after disabling the resampler). I'm not of a big help then ...

[Sebastian Mares]

There are some blips in the sound with foobar2000 (with and without resampler), while Winamp sounds OK.

[Garf]

Appears to be a mpglib issue.

[Peter]

Support for very low bitrate MP3s in mpglib is heavily buggy and I don't have time to fix it. Just use foo_mad. And no, foo_mad can't be bundled as default decoder (GPL license / slower than mpglib on most machines / mpglib has no known issues playing high-bitrate MP3s most people listen to).

[xquake]

This problem is relate to bitrate not sample rate, is it right?

[Sebastian Mares]

No, it is related to the sample rate / MPEG version.

MPEG 1.0: 48000, 44100, 32000
MPEG 2.0: 24000, 22050, 16000
MPEG 2.5: 12000, 11025, 8000

Edit: I have just encoded a song at 32 kbps (11025 KHz) and it sounds "good" in both foobar2000 and Winamp. Therefore, I think it's a bitrate related problem.
I also missed zZzZzZz' last post. Sorry.

This post has been edited by Sebastian Mares: Jul 2 2004, 11:01

[xquake]

zZzZzZz said "for very low bitrate " , that is why i ask the above question.
Of course for low sampleRates, the bitrates often are low.

This problem happens in all LSF or just MPEG2.5 or just 8Khz or just some extrem low bitrate ? Has there been a conclusion? (I'm sorry for my poor english )

[xquake]

You encode a wav is ok, that does not mean all (32Kbps 11Khz) is ok.
I also tried some file. It is seemed just 8khz samplerate has problem.

zZzZzZz : do you have any experiments on exactly what condition has this problem ? Or just low bitrate?

[Peter]

I know mpglib has bugs in intensity stereo decoding (which e.g. LAME doesn't support at all, you have to use FhG encoder to reproduce). Perhaps some other issues with MPEG-2 and MPEG-2.5 but no serious research has been done on that.

[xquake]

The file I provide is encoded by lame .

[Peter]

Then there must be other bugs in mpglib than intensity stereo.

I also had FhG decoder working at some point using ACM but it would break gapless playback (doesn't output previous frame before eating next frame header, like MAD did before kode54's changes) and clipped by itself. Perhaps I need to reconsider what's worse or try to hackfix gapless playback with ACM.

[xquake]

I think I have tracked this problem down.

mpglib 's III_get_side_info_2() function :

/*************************************************/
/* check this again! */
if(gr_infos->block_type == 2) {
if (sfreq == 8)
gr_infos->region1start = 36;
else
gr_infos->region1start = 36>>1;
}
else if(sfreq == 8)
/* check this for 2.5 and sfreq=8 */
gr_infos->region1start = 108>>1;
else
gr_infos->region1start = 54>>1;
/*************************************************/



these code are wrong. ISO 13818-3 doc has some bug?

ISO13818-3 say:
----------------------------------------------------------------------
region0_count = 7 (in case of block_type==1 or block_type==3 )
region0_count = 8 (in case of block_type==2 )
----------------------------------------------------------------------



while "MPEG Layer3 Bitstream Syntax andDecoding" say :
----------------------------------------------------------------------
Note: If ID==’0’&&window_switching_flag[gr][ch]==’1’
&&block_type[gr][ch]==’10’&& mixed_block_flag[gr][ch]==’1’,
region0_count is predefined as 7. That means, that the
scalefactor bands of the long block (scalefactor bands 0 to 5)
have to be encoded using the Huffman table that is specified by
table_select[gr][ch][0]. In addition, the scalefactor band 3 of the
first two short blocks are encoded with this table, while
scalefactor band 3 of the third short block is encoded with the
Huffman table specified by table_select[gr][ch][1]. This table is
also used for encoding scalefactor bands 4 to 12 of all three
short blocks.
----------------------------------------------------------------------

So , I follow the above text, change the code.

/*******************************************************/

if((gr_info->block_type != 2))
{
if(sfreq == 8)
gr_info->region1start = 54;
else
gr_info->region1start = 54>>1;
}
else
{
if(gr_info->mixed_block_flag ==0)
{
if(sfreq==8)
gr_info->region1start = 36;
else
gr_info->region1start = 36>>1;
}
else
{
if(sfreq==8)
gr_info->region1start = 48;
else
gr_info->region1start = 48>>1;
}
}

/*******************************************************/

And decode wav file is OK!

This post has been edited by xquake: Jul 3 2004, 15:49

[Peter]

Thank you for your input. The patch has been applied to main source so it's included with next release if no side effects are found (so far all works fine).
foo_input_std.dll build with patched mpglib attached to this post.