The problem here seems to be that sfront is reaching end of file
unexpectedly, while still trying to read a MIDI chunk (variable-length
number). So either there is indeed a fault in elpelele.mid, which
players can overcome, or there is an arithmetic anomaly in sfront
somewhere in the MIDI parsing.
I have to say, it dos not help that there are no tests of return values
from fread() anywhere, which makes it much harder to trap an error with
breakpoints.
Anyway, my short-term workaround is to add a feof() call to the main
while loop in the function readmidi():
while (len > 0 && !feof(midifile))
{
nextmidicommand(&len,&command,&d0);
[etc....]
AND
change the error message in getmidibytes() to a warning:
if(midifile){
if (fread(c, sizeof(char), numbytes, midifile) != numbytes){
//printf("Error: Corrupt MIDI file.\n");
printf("Warning: may be corrupt MIDI file.\n");
//noerrorplace();
//return;
}
midifsize += numbytes;
return;
}
With this, sfront executes, and generates sa.c, which in turn compiles
and eventually crunches out elpelele.wav. Except that there ~is~ a
problem, because the music comes to an abrupt halt (notes linger for a
few seconds and fade) around 110 seconds in - the rest is silence.
Without totally rigorous midi verification programs I really can't tell
where the problem lies - but error checks of fread() are, IMHO, a very
useful thing in MIDI parsers!
Richard Dobson
>
> The elpelele example would not compile to C source on my PC, with an error
> about the MIDI file being corrupt (although it played fine in WinAmp).
>
-- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 23rd August 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 14th June 1999)
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:27 EDT