• Common terms like MP3, VBR, and transparency are no longer linked every single time they're mentioned; once per section is enough.
• The warning to avoid using alpha versions is now in the appropriate section (Recommended encoder compiles and source code).
• The recommended settings section is now in a grey box with a border, for emphasis.
• The recommended settings section now begins with a brief explanation relating quality to transparency, informing the reader that once transparency is achieved, higher-bitrate settings won't result in improvement. This could probably use some adjustment in phrasing.
• As per recent remarks by greynol, MP3 is no longer acknowledged as being useful for "archiving" and some phrasing changes were made to where archiving is mentioned, in order to emphasize that lossless is lossless and lossy is lossy, regardless of encoder settings.
• As per recent remarks by greynol, -b 320 is no longer characterized as "best quality", or as superior in quality to -V0 through -V3, or as superior to VBR and ABR in general. It is now characterized as "very high quality [...] with maximum file size", and -V0 through -V3 are "very high quality [...] with best file size". Additionally, the -b 320 info now mentions that no one has provided ABX test results to support the theory that it's any better than -V0 through -V3.
• The heading "background noise and low bitrate requirement, small sizes" has been changed to "listening in noisy conditions, lower bitrate, smaller file size", in order to avoid the implication that using these settings generates background noise.
• The heading "Quick start (short answer)" has been removed. There was no question being answered.
• The "Detailed explanation (long answer)" section was covering a different topic, not explaining a previous topic in more detail, nor recommending anything, nor answering a question, so it is now its own section, renamed "Understanding the bitrate settings", because that's what it's about.
• I removed a note I had previously added about the -F flag; as was pointed out to me a while back, I was confused about when this flag is needed. It's for when -b is used with -V to enforce a minimum VBR bitrate, not for when creating CBR files.
• The explanation that VBR > ABR > CBR was amended to point out that these differences diminish as bitrate increases, and once transparency is reached, the modes are qualitatively the same. This probably could use some adjustment.
• Mention of -mm (mono mode) was removed, since joint stereo is the default and is quite efficient. If we want to have a section where we talk about random useful options, we can re-add it.
• I made a few other minor phrasing and formatting edits.

Is it worth revisiting whether it should be mentioned that the -V setting accepts fractional values?

Usage: -V<number> where <number> is 0-9, 0 being highest quality, 9 being the lowest.

Maximum quality is achieved when, regardless of listening conditions, you are unable to detect a difference between the MP3 and the original. As demonstrated by blind ABX tests, LAME-encoded MP3s typically achieve this level of transparency when encoded with the default settings, at bitrates well below maximum. Encoding with other settings will have no effect on the quality.

Maximum quality is achieved when, under optimal listening conditions (e.g. headphones in a quiet environment), you are unable to detect a difference between the MP3 and the original. As demonstrated by blind ABX tests, LAME-encoded MP3s typically achieve this level of transparency when encoded with the standard settings, producing typical bitrates well below maximum (for example -V2 to -V3, since LAME was historically tuned for transparency and to address problem samples at -V2). Once transparency is achieved, higher settings (lower -V values) will not produce meaningfully higher quality.

The VBR scale has been carefully optimized, and permits the use of fractional values (-V9.999 being its lowest quality/bitrate setting), though some graphical user interfaces to LAME VBR restrict selection to the commonly-used integer values only. A change in the -V value (down or up) will respecitively raise or lower the average bitrate, and will also raise or lower the quality unless the threshold of transparency has been exceeded. As a very mature, well tuned, quality-oriented encoder, LAME already has the best 'commandline tweaks' and internal optimizations already built in to its VBR scale. Any further commandline switches are likely to degrade quality, to waste bits or to provide less bang for you bitrate than simply adjusting the -V value for the equivalent bitrate change. The lure of 'secret expert settings' can be strong, but the advantage of 'commandline tweaks' usually tends to vanish when subjected to ABX testing.

Regarding 320 vs VBR, IIRC there simply isn't an abundance of evididence showing one to be better than the other, rather depending on the sample and listener, either may show superiority when a difference can be demonstrated.

"-b 320 vs. -V 0" is more generally "CBR 320 vs. highest-quality VBR"

That said, we are still suggesting that -V 0 is potentially better than -V 1, and that's potentially better than -V 2, and so on.

I heard a DJ last week who should have used lossless. He was DJing for a kids dancing competition. His CD player failed to read one of the kid's CDs. No problem - he had the same track on his laptop. Problem was, the kid was using the version without vocals (for reasons that will become apparent), and he only had the vocal version. Ah, no problem again - the vocal cut feature in the software would sort that. If only it hadn't been an mp3. Vocal cut only works (sometimes) on the highest quality mp3s, and this one wasn't. The vocal bled through as horrible mp3 artefacts. It was so bad that he gave up and switched the vocal cut off. Just at the point where the lyrics said something like "...and you're no fucking use to me..." - as the five year old girl continued through her dancing routine. I doubt they'll be using that DJ again.

The higher the bitrate, the more you can do with MP3...

Thus, the recommendation would be to encode using the settings that provide transparency under optimal conditions (and you know everyone's going to go one higher out of paranoia). But we shouldn't say that transparency/"maximum quality" is only achieved under those conditions.

The fact that some of the settings are indistinguishable doesn't really matter to the user who wants maximum quality. They're going to pick the potentially best settings, and they're not interested in a lecture about how, technically, they could just as well choose lesser settings and be completely unable to tell the difference. *sigh*

isolated test samples by individuals

• To dissuade people from thinking that new must mean improved, the warning to avoid using alpha versions now adds that using them "may result in lower quality MP3s".
• At the suggestion of lvqcl (2 years ago), the info about the -V option now mentions that fractional values can be used, with 9.999 being the lowest possible quality.
• The table showing what settings map to what bitrates was almost exactly the same as the "Technical details of the recommended settings" table, so I merged them by adding one column (Typical Kbps) and one row (-b 320) to the latter table.
• I added a note to the technical details table, advising people that using lowpass settings higher than the defaults will put quality at risk.
• I added a footnote to explain why the lowpass is given as a range; someone was asking about it.
• I clarified that the FhG decoder incompatibility was an issue specific to Windows, mostly pre-Vista.
• I moved the version string formatting details to a separate article, and replaced that section with a more general section about the VBR header and LAME tag, pointing to the relevant docs.
• I removed the acknowledgements which were for recommendations from a decade ago, and I moved all the links to the discussion of those older recommendations into the talk page.

• The table with the technical details of the recommended settings now has the actual lowpass values from LAME 3.99.5 when used with 44.1 kHz input.
• The table no longer has resampling info about old versions of LAME (this had been recently added by another user).
• The table no longer has lines for -V7, -V8, or -V9, because those are not recommended settings in the preceding section; ABR is! I did not add lines for ABR.
• I mentioned the number of decimal places you can specify a fractional -V values to (three places, e.g. 9.999).
• I added a small section on resampling, which reads as follows:

When the input sample rate is greater than 48 kHz, LAME will resample it to a maximum of 48 kHz (the maximum supported by MP3). In VBR modes 7 to 9.999, and at CBR bitrates below 104 kbps, the input is resampled to 32000, 24000, 22050, 16000, 12000, 11025, or 8000, depending on the target quality level or bitrate.

Since it is required when resampling, a filter is always applied to remove frequencies above one-half the sample rate. The lowpass info above is indicating whether any additional filtering is done.

LAME's internal resampler is not ideal.[6] If resampling is needed, better results (especially when targeting low bitrates) can be obtained by using a high-quality sample rate converter, such as SoX or SSRC.