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
That sounds reasonable to me. I'm convinced.