Ron,
I have been doing some digging in the svn database and on Internet and I have 2 remarks.
First, I think you are making your life much too complicated regarding the transcoder. An uncompressed stream (PCM) can be fully characterized by 4 parameters: the sample size, the sample rate, the number of samples (with song duration = number of sample / sample rate) and the number of channels. Let’s ignore the pedantic case of surround sound for which it makes theoritical sense to have a different sample rate for the different channels (bass).
The number of channels is 1 or 2. There is no point in transforming a mono signal into a stereo signal (you cannot create information). Transforming a stereo signal into a mono signal is possible but masochistic. You wrote somewhere that you want to keep Firefly simple so I guess you do not want to support this case.
The number of samples is not a problem for transcoding. The transcoding process will not change the song duration.
The sample rate can have an important number of values. In practice, it is CD quality or 44100 Hz. There is no point in increasing the sample rate during the transcoding (you cannot create information). Reducing the sample rate is also masochistic and as a consequence is also not a feature.
The sample size is the most problematic parameter from a transcoding point of view. There are 2 reasons for that. With lossy codecs, it is usually not possible to know what the original sample size was. Moreover, you do not know the quality of the DAC on your rendering device (20 bits on a M1000). However the loss due to the compression is such that it does not make sense to transcode to 24 bits. Also transcoding to 8 bits audio is masochistic. To conclude, when transcoding lossy codecs the resulting sample size should be 16 bits when transcoding lossless codecs the resulting sample size should be either whatever is indicated in the file or the maximum sample size in PCM format supported by the renderer (16 bits for a M1000).
So quite a big rant to say that the number of type of wav files created by transcoding is quite limited.
The second remark concerns the “scan-*.c” files: wow! I am must say that I am impressed by the amount of work you did. Getting it right and maintaining it must be a major pain. Would you consider rewriting or having someone rewrite most of the “scan-*.c” to use taglib? After all, the library is already used for Musepack. I understand this is not a priority for you so I can offer my help if you wish.
As far as I can see, it should be possible to use taglib for scan-aac, scan-flac, scan-mp3, scan-mp4, scan-mpc and scan-ogg. Moreover if the developer of taglib import some code from Amarok, it could also be possible to use it for scan-aif and scan-wav.
The net result would be a single hard dependency on taglib instead of id3tag (hard), vorbis (soft), taglib (soft) and flac (soft).
Let me know what you think about it.