[PD] Wav file corruption with writesf~

[thewade]

> You don\'t actually describe the failure: noise?  silence? error generation?

I did in a previous email, sorry I left it out this time:
Lame gives me a segmentation fault. aplay cant read non-pcm coded files (I was using 32bit float files as sugguested by another lister).

> Debugging steps: Do aplay and lame play: Audacity-generated Tone wav files?

lame -h -b 192 audacity-test.wav audacity-test.mp3
LAME version 3.95  (http://www.mp3dev.org/)
Using polyphase lowpass  filter, transition band: 20323 Hz - 20903 Hz
Encoding audacity-test.wav to audacity-test.mp3
Encoding as 48 kHz 192 kbps single-ch MPEG-1 Layer III (4x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
     0/1252   ( 0%)|    0:00/    0:00|    0:00/    0:00|   0.0000x|    0:00
Segmentation fault

aplay -D hdsp_analog audacity-test.wav
Playing WAVE \'audacity-test.wav\' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
(ok, so I was wrong about aplay)

> Debugging steps: Do aplay and lame play: Windows Sound Recorder-generated
> wav files?
lame sndrec32-test.wav sndrec32-test.mp3
LAME version 3.95  (http://www.mp3dev.org/)
Using polyphase lowpass  filter, transition band:  8269 Hz -  8535 Hz
Encoding sndrec32-test.wav to sndrec32-test.mp3
Encoding as 22.05 kHz  32 kbps single-ch MPEG-2 Layer III (11x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
    76/78     (97%)|    0:00/    0:00|    0:00/    0:00|   19.853x|    0:00
average:  32.0 kbps

ReplayGain: +29.4dB
aplay -d hdsp_analog sndrec32-test.wav
Playing WAVE \'sndrec32-test.wav\' : Unsigned 8 bit, Rate 22050 Hz, Mono

So, lame only works with windows generated files. I was wrong about aplay. Aplay
only needs 16bit signed files...(sorry)

I have also tried recording something in linux:pd:writesf using 32bit float
files. Then I use audacity to convert to signed 16bit, as soundforge and sox
cant open IEEE standard float files. Soundforge on widows is used to open, and 
then save as the soundfile. That doesnt even fix the file! The only thing that 
has worked for me in the past is using the default writesf:signed 16bit format,
then copying to windows, using soundforge to save-as, then copying back to
linux, and doing lame and cdrdao.

I also seem to remember that when writing files, using writesf~, in windows, then opening in soundforge and saving, soundforge prompts me that there was some extra data in the file...

Is there some way to test this theory of the fact chunk, some tool in linux to
view binary data headers like these?

Is there some way to repair the file by inserting this chunk (should this be
the case:linux fix)?

Has anyone else had this problem?

All I want to do is to be able to write a soundfile to disk in a loseless
format, rip it to mp3 and/or burn it to cd. I can record a file to disk using
writesf~, but cdrdao and lame cant open it.

Is there some modification to writesf in d_soundfile.c that I can make to add
this fact chunk, to see if this is the problem?

Thanks for the help!
-thewade