It looks like this MPEG2 table bug has finally showed up as a real glitch.
There seems to be a problem with the 19'th number in Table B.2.c (24kHz):
{ /* Table B.2.c: 24 kHz */ /* ISO docs: 332. mpg123: 330 */
{0,6,12,18,24,30,36,44,54,66,80,96,114,136,162,194,232,278, 332, 394,464,540,576},
{0,4,8,12,18,26,36,48,62,80,104,136,180,192}
},
ISO docs: 332
ISO demonstration code: 330
mpg123 330
Robert recently found that if you use "lame -v --resample 24",
you can trigger some errors related to this problem.
I tested the following, with the above options.
LAME: 332 mpg123: 330 mpg123 reports errors, some frames corrupt
LAME: 330 mpg123: 330 no problems
LAME: 330 mpg123: 332 no problems
LAME: 332 mpg123: 332 no problems
If any of you have access or know people who have access to mp3
decoder source, could you try and find out what value they use? If
all the decoders are using 330, we should probably switch LAME to 330
also.
Mark
>
> A comparison between LAME's tables and MPGLIB's (mpg123)
> tables show a different value in Table B.2.c (24kHz)
> for long blocks
>
> LAME: ... 332 ...
> MPGLIB: ... 330 ...
>
> Robert
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
