freeamp uses a Xing decoder, table entry is 332.
Robert
Mark Taylor schrieb am Fre, 24 Mär 2000:
> 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/ )
