(This is a cross between a bug and a feature request)
Great product, its the only command line mp3 decode I could find with good error-tolerating of mp3
files (mpg123 bombs 20% of the time).
One of the things I use it for (OK the only thing) is to convert mp3's and pipe them to cdrecord.
However, I pipe them through sox where I add a pre-figured out Volume adjustment and force
Stereo 16-Bit 44,100 raw output to cdrecord.
I have to use sox because I need to force output to CD size raw output, so the only way I can do
that programmaticaly is to output it to sox as a .wav file, then force the output in sox to the
correct raw format.
The problem is that madplay, for .wav files, starts with a "LENGTH" in the header of 0, then later
corrects it. This causes sox to read 0 bytes of data and quit. Other programs write a "LENGTH" of
FFFFFFFF , then correct it. This works better for piping to STDOUT (I just ignore the premature
So, Can I request:
1) Change all occurences of \0\0\0\0 in lib_wav.c to \255\255\255\255
2) Add options to force 44,100 Stereo 16-bit raw output
I did option #1 myself with no problem.
BTW, the intended use I'm talking about is something like:
madplay -o "WAV:-" \ | sox -t wav - -v $VOLADJ -c 2 -r 44100 -s -t raw - \ | cdrecord -audio -pad -nofix