OK, I just committed that patch to CVS. Makes code read much nicer having HAVE_LAME_398 type #defines.
I have only one minor concern. For mad precision, we may want to keep it at 16-bits even though we read in higher. The reason is pretty simple. Users expect the following command line:
sox infile.mp3 outfile.wav
to create a 16-bit WAV file instead of a 24-bit... Similar to how:
madplay -o outfile.wav infile.mp3