[vorbis] Various Ogg Vorbis largefile notes and/or patches

[Barry Bouwsma]

[this address is IPv6-only, and usually doesn't work, so don't
reply directly to me.  I'll catch the archives next time online]

I drooled the following all over my keyboard:

> Anyway, I've been working with ogg123/oggenc and large files as
> both source and destination.  (Large files being those several GB
> in size, for which 64-bits are needed.)  This has exposed some
> weaknesses that I've tried to hack around.  I'll explain in messages
> to follow, each problem that I'm addressing along with brutish hacks


Hello.  For my next trick, I'll try to submit an alleged patch (more
like a hack) for a problem I've noticed when playing long-running ogg
vorbis files.

It appears that when playing via ogg123 a lengthy audio file (say, ten
hours at CD-sampling-rate stereo), with FreeBSD I get choppy static
mixed in the audio after several hours.  I don't know if other OSen
suffer the same.  This static is not in the encoded file, as I can
successfully seek within the file to the position where I'm hearing
the static and the playback is clean -- for a few hours.

My guess is that something is counting the amount of raw data output
(the static starts after what would be raw PCM data of 2 or 4GB, can't
remember precisely) and overflows.  Or something.  Nevertheless, I've
added a hack to my ogg123 source, and for more than the past 14 hours
I've been playing an encoded file and so far I've not encountered this
static, which usually should have happened long before now.  (Update:
I ran the playback for more than two days at which point I tripped
over the power cord, but if it could get that far without experiencing
the problems, I suspect they aren't likely to recur.  Sometimes I hate
my clumsiness.)

I believe the hack is in this comparison of 3 or 4 values, some of
which are ints, some long, and some 64-bit values.  When the value of
the PCM data size exceeds that which can be stored in a long, this
comparison probably bombs, explaining the static I used to hear.
I'm no programmer, so if someone wants to do this properly, I won't
be offended.



--- /stand/work/vorbis/vorbis-tools/ogg123/buffer.c-DIST	Thu Sep  4 03:53:02 2003
+++ /stand/work/vorbis/vorbis-tools/ogg123/buffer.c	Fri May  7 00:41:15 2004
@@ -165,7 +165,7 @@

int compute_dequeue_size (buf_t *buf, int request_size)
{
-  int next_action_pos;
+  ogg_int64_t next_action_pos;

/*
For simplicity, the number of bytes played must satisfy the following
@@ -180,10 +180,11 @@

next_action_pos = buf->actions->position;

-    return MIN4(buf->curfill, request_size,
-		buf->size - buf->start, next_action_pos - buf->position);
+    return MIN4((ogg_int64_t)buf->curfill, (ogg_int64_t)request_size,
+		(ogg_int64_t)(buf->size - buf->start),
+		next_action_pos - buf->position);
} else
-    return MIN3(buf->curfill, request_size, buf->size - buf->start);
+    return MIN3(buf->curfill, (long)request_size, buf->size - buf->start);

}



(apologies, I'm not sure if this is a complete patch.  my source
tree is a mess.  by the time I post everything, I hope it will
all apply cleanly and that I exterminate my pointless debuggery.)

thanks
barry bouwsma