Need some clarity here, from some folks who've got a little more experience with fastencc than I do, and who know all its ins-outs-quirks.

(FWIW, I already searched the forum and couldn't find a suitable - or even consistent - answer to this.)
fastencc 1.02 is reported to have a stereo collapse bug in the
fast mode, but what about the
-hq mode? So far the only "bug" I've seen described in association with that mode is the slow speed... which would be expected if the libraries being used for that mode were more along the lines of FhG's MP3Enc (i.e., the "professional" libraries).
So out of curiosity I hunted up a copy and ran a few quick tests. Speed-wise here's what I found (the test system was a PIIIM 1.06GHz notebook):
At
-br 128000 -hq, for anything that had a wide stereo separation the speed hovered around 1.1x.
At
-br 128000 -hq, for anything that had a very narrow stereo separation the speed hovered around 8.1x.
For a very low-bitrate mono encode (such as would be used for speech) at
-br 32000 -ds 22050 -dm -hq, the speed soared to 47.9x for the wide-stereo sources, and 48.1x for the sources which were already close to monophonic. (Same sources as above.)
So here is the question: For material which can still be appreciated as a low-bitrate, monophonic stream, and when a CBR stream is required, would there be any compelling
quality-based argument against using fastencc in
-hq mode?
- M.
Edit: Fixed a few stupid spelling errors.