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