This is a bug in the tables - that first line should be a 0 3
instead of 0 2. I have just fixed this, but it should have very
little effect on the output.
And I dont think this could cause any crashes though. Can you
try adding a check in that loop to make sure
b < gfc->npart_s
Sounds to me like the bo_s[] array is probably getting corrupted
somewhere else?
Mark
>
> Ok, I have now tracked down exactly where the bug occurs, abit unsure exactly
> why it completely crashes LAME though...
>
> At line 762 we've got the following loop (the overflow starts here at some
> point (not immediately)):
>
> for ( b = gfc->bu_s[sb]+1; b < gfc->bo_s[sb]; b++ )
> {
> enn += eb[b];
> thmm += thr[b];
> }
>
> I got the following values by a quick check:
>
> bu_s[] bo_s[]
>
> 0 2
> 3 5 <- This one seems strange?!
> 5 8
> 8 11
> 11 15
> 15 20
> 20 23
> 23 27
> 27 30
> 30 33
> 33 36
> 36 38
>
> If I change "b < gfc->bo_s[sb]" to anything else, f.ex. 38 so that it'll go
> through the whole range every time, or manually unroll the loop with those
> values (changing the 3 to 2), LAME works fine...
>
> I'm at a loss what really is going on here, something seems to mess up
> bigtime... :P
>
>
> - CISC
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
