1.1.0 development branch begins.

Ryan C. Gordon icculus at clutteredmind.org
Sat Oct 25 22:23:33 EDT 2003

Welcome, ladies and gentlemen, to the 1.1 SDL_sound development branch. 
New development goes here. Bugfixes (like the VOC one from the last 
post) and other things that don't alter the API (like a new decoder or a 
port to a new platform) can still be applied to a stable branch, which 
will eventually result in a 1.0.2 release.

I'm not going to screw around with CVS branches. If you're in CVS, 
you're on the bleeding edge, so a fresh checkout will get you the 1.1 
branch. If you want to work with 1.0, sync to the "version-1-1-0-start" 
tag and work from there.

To start off new development, I'm committing a patch that's been in the 
queue for damned near a year...it adds functionality to report a given 
sample's total playing time. I've forwarded the (thoroughly explained) 
details below. Please note that this patch, as it exists in CVS, breaks 
binary compatibility with SDL_sound 1.0. While that is always a 
possibility in the 1.1 branch, I will be changing this behaviour soon, 
since it's not really necessary to do so at this point. In short, please 
feel free to play with it, but don't ship any products that rely on it yet.

Discussion involving requests (and patches!) for new features should 
begin now. Rock on.


-------- 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.

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.

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)

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.


-Mikmod total_time and seek notes:
The Mikmod decoder now has support for both seeking
and total time. However, both require the assumption
that the file actually be seekable because every Mod
pattern and position must be analyzed for speed
changes.  For module/tracker files in general, this is
a normal
assumption as most files would never be able to play
if this were not true due to the nature of the format
(it's ability to dynamically jump anywhere in a song).
  And the total_time and seek code used is
fundamentally the same method used by ModPlug

The computed total_time can be extremely wrong
depending on the file. If the file has jumps, loops,
short tracks, or exploits other funky
features, the total_time could easily be wrong.  Use
Modplug, rewrite the algorithm, or demand that Mikmod
compute it if you need better accuracy.

Due to the Pattern (block) based nature of the format,
seek-to-a-specific-millisecond is impossible. You can
only seek to a beginning of a pattern.  This is also
typical of Module other module players you find.  The
current seek code computes what the closest pattern is
to the specified milliseconds and goes there
(accounting for speed changes, but not

-Ogg Vorbis notes:
We just call the their total_time function and leave
it at that.

-SMPEG notes:
We just queried the total time.

-MPGLIB notes:
We modified the custom mpglib files to give us access
to the bit rate of the mp3 file.  From there, we
calculated length in the same fashion as SMPEG did,
but we also scan for the TAG frame and ignored the
128 bytes if it existed at the end of the file.

-FLAC notes:
We scan the STREAMINFO block and grabbed the bit rate
and total number of frames before calculating the
total length of the song.  If either headers have the
value of 0, we return -1.

-VOC notes:
We can calculate the length of an 8 bit and 16 bit voc
block. Extension blocks ruins the accuracy of the
calculation.  Silent blocks have some calculations,
but it was never tested because its hard to find a voc
file with silence.

-AIFF notes:
Calculated the time with bit rate and number of

-SHN notes:
Same as FLAC, except we always assumed that the header
has the correct data.

-AU notes:
Depending on the type of AU file, we calculated the
total length with the information from the AU header.
The header information include the size of the data
block, frequency, and sample size.

-ModPlug notes:
We used the default ModPlug functions to determine

-Experimental QuickTime notes:
We return -1 for now until we can actually figure out
how to test QuickTime on a the Mac and find more
documentation about their source code from the
QuickTime development kit.  We prefer that someone
with previous knowledge of Quick Time, like the author
of the codec, to modify it.

-RAW notes:
Found the length of the file with seek and used the
sample size and frequency to determine the length.

-WAV notes:
Calculated the total time with the length of the file
and the average bytes per second.  Both pieces of data
are readily available in the wav.c file.

-timidity notes:
Timidity finds the total length by itself, but throws
the value away.  We had to modify the code to keep
that value.


Wesley, Eric, Wang, and Ahilan

More information about the sdlsound mailing list