HydrogenAudio

Another round of updates (http://wiki.hydrogenaudio.org/index.php?title=LAME&action=historysubmit&diff=23217&oldid=23120) to the article on LAME (click for current version) (http://wiki.hydrogenaudio.org/index.php?title=LAME):

• 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.

Please note your concerns or fix whatever I broke...

Well done!

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.

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

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

...and -V 9.999 is the lowest quality VBR setting (LAME 3.98+):

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

Also, lowpass values in "Technical information" section are valid for 3.98 (and for 44.1kHz input), but not for 3.99.

Hello.

Do you want me to update the lame documentation in some way? Since I used back then part of the wiki , I guess it might need an update too.

Yes, please.  The discussion that led to these changes included the lame documentation.

Good work, mjb

I noticed that the Bit Reservoir (http://wiki.hydrogenaudio.org/index.php?title=Bit_reservoir) article needed a bit of work in the example section to avoid confusion of bits per frame with kbps, so I believe that's now fixed and essentially correct within rounding error.

Returning to LAME:

Regarding this bit of wording within section 'Recommended encoder settings':
CURRENT

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.

That last sentence isn't completely clear to me, as you intimated, mjb. I'm tempted to modify as follows. Any comments on accuracy/clarity/length?

I suspect my second paragraph should appear near the end of the grey box or outside it.

My PROPOSED

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.

BTW, the Y-switch is mentioned, linked to the definition page. That's probably the one commandline switch which is the exception to commandline switches wasting bits and providing less bang-for-your-bitrate than changing the -V value and the one commandline tweak with any merit.

Should we also address Joint Stereo myths, stating that LAME uses only safe Joint Stereo, not Intensity Stereo, with a link to the Joint Stereo page. The myth of unsafe Joint Stereo seems to stem from earlier Fraunhofer encoders using IS.

Another myth we could debunk is that of re-encoding and already lossy source to a higher quality setting (i.e. we know this as transcoding, but a newbie won't).

It might be worth including a section on Myths and Misinformation Explained, as the LAME page is a very useful resource for newcomers or a search result for getting into the HydrogenAudio site. Another myth is that MP3 is always or frequently audibly distinguishable from the original CD or WAV. As we know, at Lame -V2 or -V3 it's actually rare to tell them apart in proper level-matched double-blind tests (e.g. ABX), even for expert listeners.

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.

Very well stated. Since it's a recurring topic, I would like to see this addressed. However, I am also wondering if anything not specifically related to LAME really belongs in the LAME article. "-b 320 vs. -V 0" is more generally "CBR 320 vs. highest-quality VBR", which could be in its own article, and we can link to it.

As for Dynamic's proposed text, I would tighten up the second paragraph a bit, but I totally support the idea behind the additional text: steering people away from "advanced settings" that they think can be used to coax higher quality out of the encoder.

Our recommended settings are addressing the users' #1 concern—what settings will give them "maximum quality"—so I do feel we're obligated to define maximum quality in terms of transparency. One thing I'm unsure of re: transparency is whether it depends on the listening conditions being 'optimal'.

Transparency is simply achieved when you can't tell the difference, right? So if the landscaping crew outside is making it such that you can't tell the difference between a -V 8 MP3 and a CD, then -V 0 through -V 8 are effectively all the same; they're all "maximum quality". But naturally, if you're going to also be listening to these same MP3s in your man-cave in the wee hours, headphones on, no noise but your computer's fans and hard drives, then the threshold of transparency is probably a bit higher. 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.

In other words, by making transparency contingent on listening conditions being optimal, we imply that only "-V 0 to -V 3" is transparent. It follows that "-V4 to (whatever)" is not transparent. This undermines our recommendations to use those lower settings for portable players/noisy environments. For portable/noisy, the lower settings are highly likely to be transparent.

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. 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*

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

I'm not sure. Rather, it is "one high-bitrate setting vs. another high-bitrate setting".

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.

The higher the bitrate, the more you can do with MP3... I mean cases like this:

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...

You have an excellent point, though that specific case may have just as easily benefited from having all frames encoded as stereo if they weren't already.

My $0.02...
This should be considered a truism by our community: given any specific circumstance, if two mp3s deliver transparent results then they are of equal quality regardless of how they were encoded.  So long as this point gets across, it doesn't matter to me whether 320 CBR vs. highest bitrate VBR is addressed specifically.

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.

I agree completely.

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*

So long as the reader is knowingly discarding sane advice rather than being misled or feeling proselytized to then we've done our part.

A suggestion to help people like me not completely conversant on how all of settings of previous versions of LAME relate to the latest version of LAME:

I understand from posts 9 and 10 at http://www.hydrogenaudio.org/forums/index....showtopic=49380 (http://www.hydrogenaudio.org/forums/index.php?showtopic=49380) that the need for -q settings for VBR have changed since 3.97 or thereabouts.  Clarifying the meaning (if any) of -q settings with VBR before and after whatever version breakpoint of any difference would be insightful.  If such clarification belongs on a different page, that seems OK as long as there is a reference and link to that page.  Alternatively, if all settings from versions before 3.99.5 are irrelevant and the existing wiki page is comprehensive in everything one must know to understand all the optional settings of the latest version, then stating that would be helpful.  Thanks for updating the wiki!

Firstly thank you mjb for your time and effort!

The only suggestion I'll make is to keep in mention of the mono switch, which can be quite handy in keeping the bitrate down when encoding spoken content & audiobooks (e.g., using the unofficial preset voice: --abr 56 -mm).  I know other codecs do low bitrates more efficiently but for compatibility this performs to quite acceptable levels.

I think just get rid of any mention to -b320 . I am sure users who desire it know what to do.

I say also that the only thing we know for sure scientificaly is that V5 is perfect or close to for most people in listening tests. Everything else is conjecture, speculation or isolated test samples by individuals. We also know below 120k VBR is no good.  So : V6 - V0 are useable and V5 is a good starting point. Then it is up to the user to decide the level. I see way too many 320 cbr encodes all over the net for no good reason even in legit sites selling mp3 and the anything less than 256k must be no good.

isolated test samples by individuals

Which is exactly what a listening test is.

I could ABX -V5 just about every time I tried, thank you very much.

Allright, this is how it is now: http://lame.cvs.sourceforge.net/viewvc/lam...ml?revision=1.4 (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/usage.html?revision=1.4)

Great job, thanks!

BTW, how does one actually navigate to that page without a direct link?

lame.sf.net (http://lame.sf.net) -> Using LAME (http://lame.sourceforge.net/using.php) -> Program documentation (in CVS) (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/index.html)

If you mean the CVS, the root is:

http://lame.cvs.sourceforge.net/viewvc/lame/ (http://lame.cvs.sourceforge.net/viewvc/lame/) . Opening the document is done by clicking on the version number instead of the name, and then clicking download.

And to know how to go to the cvs root, that's found going to the sourceforge page of lame, and then in the horizontal menu bar, to "Code" and "CVS Browse".

Edit: From a user point of view, robert's answer is much better..

It was pointed out to me that we're inconsistent in whether we put a space between the "-V" and the number which follows. I know conversationally we like to omit the space, but in the docs and recommendations maybe we shouldn't, just for consistency with the other options.

In conversation it seems like using the space only adds confusion, but maybe this impression directly stems from the two people who confused flac settings with lame settings just last week.

With respect to higher bitrate when you are already beyond transparency, I believe another case in addition to DJ removing vocals is changing of the beats per minute.
Apparently, and I can't back this up with a test but apparently software that detects BPM so that it can be altered is sometimes fooled by lossy source and is more likely to be accurate at higher bitrate encodings even if the human ear can't tell the difference.

I personally have no need to ever do that but I have seen that discussed by people who at least sounded like they had actual experience with it.

That sounds reasonable; higher-bitrate MP3s are more likely to preserve high-frequency content, and tempo detection is likely easier if the high-frequency content is preserved; all that's normally up there, aside from noise, is the upper harmonics of percussion instruments. But as far as recommending bitrate settings in LAME, I don't know if we should mention it. Telling people to take into consideration content that's only "audible" to BPM detection software, when MP3 and LAME are designed with human hearing in mind, seems counterproductive.

I made more edits to the LAME article today. Aside from minor copy edits and table formatting improvements, there are some substantive changes:

• 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.

Thank you very much. Nice work!

More edits made today (diff (http://wiki.hydrogenaud.io/index.php?title=LAME&diff=27042&oldid=26650)):

• 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] (https://hydrogenaud.io/index.php/topic,97479.0.html) 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.

Suggestions for improvements welcome.