Most decoders now report total sample play time, now. Technically, this breaks binary compatibility with the 1.0 branch, since it extends the Sound_Sample struct, but most (all?) programs are just passing pointers allocated by SDL_sound around, and might be okay. Source-level compatibility is not broken...yet! :) --ryan. -------- Original Message -------- Subject: SDL_sound patch: Finding total length of time of sound file. Date: Sun, 26 Jan 2003 09:31:17 -0800 (PST) Hi Ryan, I am working with Eric Wing and helping him modify SDL_sound. AS part of our efforts in improving and enhancing SDL_sound, we like to submit this patch. We modified the codecs to find the total time of a sound file. Below is the explanation of the patch. The patch is appended as an attachment to this email. * MOTIVATION: We needed the ability to get the total play time of a sample (And we noticed that we're not the only ones). Since SDL_sound blocks direct access to the specific decoders, there is no way for a user to know this information short of decoding the whole thing. Because of this, we believe this will be a useful addition, even though the accuracy may not be perfect (subject to each decoder) or the information may not always be available. * CONTRIBUTORS: Wesley Leong (modified the majority of the codecs and verified the results) Eric Wing (showed everyone how to do modify codec, modified mikmod) Wang Lam (modified a handful of codecs, researched into specs and int overflow) Ahilan Anantha (modified a few codecs and helped with integer math) * GENERAL ISSUES: We chose the value to be milliseconds as an Sint32. Milliseconds because that's what Sound_Seek takes as a parameter and -1 to allow for instances/codecs where the value could not be determined. We are not sure if this is the final convention you want, so we are willing to work with you on this. We also expect the total_time field to be set on open and never again modified by SDL_sound. Users may access it directly much like the sample buffer and buffer_size. We thought about recomputing the time on DecodeAll, but since users may seek or decode small chunks first, not all the data may be there. So this is better done by the user. This may be good information to document. Currently, all the main codecs are implemented except for QuickTime.

--- a/decoders/voc.c	Sat May 08 03:14:42 2004 +0000
+++ b/decoders/voc.c	Sat May 08 08:19:50 2004 +0000
@@ -196,6 +196,7 @@
     Uint32 new_rate_long;
     Uint8 trash[6];
     Uint16 period;
+    Uint32 bytes_per_second;
     int i;
 
     v->silent = 0;
@@ -241,6 +242,12 @@
                 v->extended = 0;
                 v->rest = sblen - 2;
                 v->size = ST_SIZE_BYTE;
+
+                bytes_per_second = sample->actual.rate
+                    * sample->actual.channels;
+                sample->total_time += ( v->rest ) / bytes_per_second * 1000;
+		sample->total_time += (v->rest % bytes_per_second) * 1000
+		    / bytes_per_second;
                 return 1;
 
             case VOC_DATA_16:
@@ -272,8 +279,13 @@
 
                 if (!voc_readbytes(src, v, trash, sizeof (Uint8) * 6))
                     return 0;
+                v->rest = sblen - 12;
 
-                v->rest = sblen - 12;
+		bytes_per_second = ((v->size == ST_SIZE_WORD) ? (2) : (1)) *
+		    sample->actual.rate * v->channels;
+                sample->total_time += v->rest / bytes_per_second * 1000;
+                sample->total_time += ( v->rest % bytes_per_second ) * 1000
+		    / bytes_per_second;
                 return 1;
 
             case VOC_CONT:
@@ -302,6 +314,9 @@
                     v->rate = uc;
                 v->rest = period;
                 v->silent = 1;
+
+		sample->total_time += (period) / (v->rate) * 1000;
+		sample->total_time += (period % v->rate) * 1000 / v->rate; 
                 return 1;
 
             case VOC_LOOP: