Hi, Todd.  I really appreciate your message.  

    >> A WAV file (or more generally, any RIFF file) has a chunk
    >> _size_ at bytes 4-7, which you can see above.  When madplay
    >> writes a WAV file, it's probably expecting to calculate the
    >> size of the file and lseek() back to the beginning to overwrite
    >> those 4 bytes with the actual size.  Since a pipe is not
    >> seekable, it's not able to do such writing.


   I had the same idea when I found the problem, but then
I rejected it because I thought it is impossible to lseek() back
the standard output.   But the fact seems to tell me that I am wrong.

  I would appreciate if someone gives me a confirmation that it is
possible to lseek() back the standard output when it is redirected
to a (trivial) file.   It may be more valuable for me to learn it than
to solve the madplay problem. :)

-
Koh Sato
k-sato@ks-s.otaru-uc.ac.jp