I am the before mentioned Debian user who reported this bug. On Tue, Jul 08, 2003 at 17:17:50 -0400, Steven Richman wrote: > > > - file_info->length_in_msec = file_info->total_samples * 10 / > > > (file_info->sample_rate / 100); > > > + file_info->length_in_msec = (FLAC__uint64)file_info->total_samples * > > > 10 / (file_info->sample_rate / 100); > ... > > It seems like would be simpler to do something like: > > > > (file_info->total_samples / file_info->sample_rate) * 1000; > > Without a float cast, this truncates the length so it's always a multiple > of 1000ms. That's cool now, but it wouldn't be if the xmms gui changed to > display track lengths with, say, tenth-of-a-second precision.
Here is a suggestion to avoid this:
length_in_msec = total_samples / sample_rate * 1000 +
total_samples % sample_rate / ( sample_rate / 1000 );
This should be exact to the msec. No more parentheses than above are
needed since * / % are left-associative, although more parentheses wouldn't
hurt of course. :-)
While looking at this, I also noticed that in include/FLAC/format.h,
total_samples is defined as FLAC__uint64, which is used in
src/plugin_xmms/plugin.c line 304, while in the latter file, line 57,
total_samples is defined as unsigned (used in line 538), which is only a
32 bit value in most cases. Wouldn't it be better to make it FLAC__uint64,
too?
Thanks,
- Stephan.
pgp00000.pgp
Description: PGP signature
