OK, think I fixed them all, thanks. (to appear in test7...)
On Sat, Feb 07, 2004 at 04:30:47PM +0100, Krzysztof Czaja wrote:
hi,
a few bugs from my gnats db, which all have quick fixes (patched against pd-0.37-1test6)
Krzysztof
BUG #25 soundfiler reads a trailer of a stereo .wav file as part of a sample
Quite often, there is a trailer chunk after data chunk in a .wav file. Soundfiler (correctly) does not read trailers of mono files, but (incorrectly) loads a trailer into an array (or arrays), if the file has additional channels.
Fix: In d_soundfile.c, change lines 1020-1021 to
- if (framesinfile > bytelimit / bytespersamp)
framesinfile = bytelimit / bytespersamp;
- if (framesinfile > bytelimit / (channels * bytespersamp))
framesinfile = bytelimit / (channels * bytespersamp);and change lines 1040-1041 to
- if (finalsize > bytelimit / bytespersamp)
finalsize = bytelimit / bytespersamp;
- if (finalsize > bytelimit / (channels * bytespersamp))
- finalsize = bytelimit / (channels * bytespersamp);
BUG #26 a pop made by reading .wav file trailer as part of a sample
It is quite common for a .wav file to contain a trailer chunk following sample data. Readsf~ correctly excludes it from playback in some cases, but in other cases does not.
Fix: This is one of the two fixes needed: after line 1489 in d_soundfile.c add
else wantbytes = READSIZE;
if (wantbytes > x->x_bytelimit)wantbytes = x->x_bytelimit;The other one, subtracting a skip offset from the `bytelimit' variable in open_soundfile(), is reported separately, because it affects both readsf~, and soundfiler.
BUG #27 readsf~ and soundfiler run over .wav file trailer if skip option used
Yet another case of .wav file trailer chunk causing pops in playback from arrays and from readsf~. The pops occur, if the option 'skip' is used as part of the 'read' message to soundfiler, or as an argument of the 'open' message to readsf~.
Fix: In d_soundfile.c, before line 375, add
- bytelimit -= nchannels * bytespersamp * skipframes;
- if (bytelimit < 0)
- bytelimit = 0; /* copy sample format back to caller */
BUG #28 readsf~ truncates files, if number of samples != multiple of dsp block
If the last dsp block in a stream of sample data to be output by readsf~ is going to be only partially filled from a sound file, readsf~ fills it all with zeros. In effect, the file is truncated on playback.
Fix: In d_soundfile.c, function readsf_perform(), declare a local variable xfersize of type int, and before line 1669 add
xfersize = (x->x_fifohead - x->x_fifotail + 1) /(sfchannels * bytespersample);if (xfersize){soundfile_xferin(sfchannels, noutlets, x->x_outvec, 0,(unsigned char *)(x->x_buf + x->x_fifotail), xfersize,bytespersample, bigendian);vecsize -= xfersize;for (i = 0; i < noutlets; i++)for (j = vecsize, fp = x->x_outvec[i] + xfersize; j--; )*fp++ = 0;return (w+2);} goto idle;BUG #30 endianness bug remains in soundfiler
Endianness bug in soundfiler_writeargparse() remains. Actually, there were two bugs, a typo and an omission -- typo has been corrected, omission has not.
Fix: In d_soudfile.c add the missing clause before line 581:
- else bigendian = endianness; swap = (bigendian != garray_ambigendian());
BUG #31 debugging overhead left in readsf~ and writesf~
In release version, i.e. with debugging printout from readsf~ and writesf~ disabled, the "sprintf(boo..." debugging calls are still performed.
Fix: In d_soundfile.c, comment out the lines 1430-2, 1460-2, 1523-5, 1963-5. For example, change line 1303 to
-#if 0 +//#define DEBUG_SOUNDFILE +#ifdef DEBUG_SOUNDFILE
and add #ifdef DEBUG_SOUNDFILE ... #endif clause around the above lines.
BUG #32 sending 'normalize' to an array of zeros produces an array of nans
Sending 'normalize' to an array of zeros produces an array of nans.
Fix: In g_array.c, line 951, change the condition maxv >= 0 to maxv > 0
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev