Robert,
Can you be more specific with which file this error occurs, and what
options/settings are you using? So I can try to reproduce this problem on my
system.
Albert
----- Original Message -----
From: Robert Hegemann <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 15, 2000 6:16 PM
Subject: RE: [MP3 ENCODER] using lame363 for shuttle transmission
Mathew Hendry schrieb am Die, 15 Feb 2000:
> >
> > 0x805e2cc <calc_xmin+460>: fldl 0xfffffff0(%ebp)
>
> It loads a floating point value from memory into a floating point
register.
> The value in memory is presumably invalid, so the CPU traps when it loads
> it.
So we have to figure out which variable it is. Then it would be interesting
to
to see the memory usage in its neighbourhood. Either the calculation of the
variable itself goes wrong, or there is an index overflow by the calculation
of its neighbours.
here is the C-code, lame throws the SIGFPE at marked position:
int calc_xmin( FLOAT8 xr[576], III_psy_ratio *ratio,
gr_info *cod_info, III_psy_xmin *l3_xmin)
{
:
--> for ( sfb = 0; sfb < cod_info->sfb_lmax; sfb++ ){
start = scalefac_band.l[ sfb ];
end = scalefac_band.l[ sfb+1 ];
bw = end - start;
for (en0 = 0.0, l = start; l < end; l++ ) {
ener = xr[l] * xr[l];
en0 += ener;
}
en0 /= bw;
xmin = ratio->en.l[sfb];
if (xmin != 0.0)
xmin = en0 * ratio->thm.l[sfb] * masking_lower / xmin;
Robert
PS: yesterday I checked Mathew Hendry's quantize_xrqpow update into CVS
and fixed a problem with ms_convert: it was going wrong when the
source and destination array are identical, now ms_convert is
robust to handle this. It can convert in place now
today I got rid of some extra quantizations in VBR_iteration_loop
L earning
A bout
M p3
E ncoding
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
