The root of the problem is a divide-by-0 error when calculating the speed
of the rip or encode for the progress bar, when no time has yet elapsed.
On Alpha (and some other architectures), this causes a floating point
exception; on x86 (and on Alpha with the -mieee flag) this computation
returns a NaN number instead and the program continues. The enclosed
patch avoids this divide-by-0 error by applying the same basic change in
two places.
--- grip.c-orig Sat Jan 5 10:21:39 2002
+++ grip.c Sat Jan 5 10:32:57 2002
@@ -4114,9 +4114,12 @@
{
time_t now = time(NULL);
gfloat elapsed = (gfloat)now - (gfloat)rip_started;
-
+ gfloat speed;
/* 1x is 44100*2*2 = 176400 bytes/sec */
- gfloat speed = (gfloat)(mystat.st_size)/(176400.0f*elapsed);
+ if (elapsed < 0.1f) /* 1/10 sec. */
+ speed = 0.0f; /* Avoid divide-by-0 at start */
+ else
+ speed = (gfloat)(mystat.st_size)/(176400.0f*elapsed);
/* startup */
if (speed >= 50.0f) {
@@ -4207,8 +4210,12 @@
{
time_t now = time(NULL);
gfloat elapsed = (gfloat)now - (gfloat)mp3_started[mycpu];
+ gfloat speed;
- gfloat speed = (gfloat)mystat.st_size/((gfloat)kbits_per_sec *
128.0f * elapsed);
+ if (elapsed < 0.1f) /* 1/10 sec. */
+ speed = 0.0f;
+ else
+ speed = (gfloat)mystat.st_size/((gfloat)kbits_per_sec * 128.0f *
elapsed);
sprintf(buf,"MP3: Trk %d
(%3.1fx)",mp3_enc_track[mycpu]+1,speed);
gtk_label_set(GTK_LABEL(mp3_prog_label[mycpu]),buf);
