In response to Slipstreem's post in another thread, I feel it may be worth considering the establishment of a fairly simple standard and approved logo to signify "safe and sound" settings for LAME encodings.

This logo and/or wording in software and documentation could be used like a trademark to signify a certain assured level of optimum behaviour. An appropriate LAMEsure tag or a flag bit in the LAME header (where used) could also be included (to augment rather than replace the "Unwise settings used").

The idea borrows from logo marks that signify a minimum standard of features. Worldwide, many will be familiar with "Designed for Microsoft Windows XP" logo and in specific countries, standards bodies issue marks like the CE mark (Europe-wide approval, but recognised on products worldwide). Other open standards specify a minimum feature set, such as the UK's "Freeview Playback" minimum feature set for digital terrestrial TV personal video recorders with Electronic Programme Guide, at least 2 hours' pause and rewind of live TV, the ability at least to record one channel while watching any other or record 2 channels, etc.

It's a logo or branding (e.g. "This software offers LAMEsure compliant MP3 encoding and decoding") that people can look for and trust to deliver consistently good quality and features within a given field of operation. A suitable logo with a friendly green tick to denote approval would be desirable, and a monochrome version should be available.

In a way, it extends the idea behind the recommended LAME GUI which appears on few software implementations (foobar2000 and little else, AFAIK!) by providing an incentive to standardise for safe features.

As an outline, I'd suggest for the LAMEsure encoder and its UI (subject to discussion/pruning/extending):

• LAME 3.98 release version or above excluding alpha and beta versions (hence excluding the LAME 4.0 alpha fork)
• Lossy-to-lossy transcoding warnings (over-rideable by user)
• Encoder aims for... [x]Consistent quality target (suggested tooltip: "VBR, recommended, minimum filesize for given quality"); [ ]Bitrate target (ABR, quality variable but file size fairly predictable); [ ]Bitrate fixed (CBR, quality more variable, file size exactly predictable). Could add support for additional "standards" like Podcast mode, typically CBR 128 kbps, Joint Stereo, 44.1 kHz.
• Option of slider (preferred), drop-down-list, radio-button or numerical entry limited to valid ranges (or any combination). Descriptions for each mode along with estimated typical bitrate (and filesize, or megabytes per minute or per 4-minute song, or hours-per-gigabyte) should be from an approved list (interpolated for fractional -V settings) for each version of LAME. This could indicate near-transparent, transparent etc. No requirement to permit all available modes (e.g. forcing -V3 would be allowable, as would allowing -V5 to -V2 (preferably showing -V9 to -V5.01 and -V1.99 to -V0 greyed-out), if your software targets a particular niche only, though allowing at least all integer settings between your upper and lower bounds is preferred. Option to disallow fractional quality settings for ease of using sliders etc. if fractionally settings are permitted by your UI.
• [x]Stereo or [ ]Mono radio button. (Stereo means Safe Joint Stereo - full stereo is not permitted in LAMEsure as it tends to impede quality, inflate bitrate or both). Could add a "same mode as source audio" button and allow the stereo button to force stereo mode on mono files (upmix), which would still be encoded pretty efficiently using MS mode.
• Don't allow a choice of VBR mode: Use the default, which from 3.98 is both fastest and recommended for the best psymodel quality and current tuning. Don't allow a choice of "quality -q switch", nor "-h" or any other developer switches like -k and similar nasties.
• Must include gapless info (both delay and padding where possible - unless we choose to impose a LAME header even on CBR files.
• Can allow pre-processing for gain (e.g. Replay Gain hard-coded before encoding or via --scale) and Dynamic Range Compression (e.g. foo_dsp_vlevel) but prefer a flag in the LAME header to indicate each of the major items used.
• Could incorporate further ideas, such as an embedded loudness profile in the header (or hidden in padding within an MP3 compliant bitstream, if that's possible) to allow on-the-fly DRC that is optional at decode time (e.g. when listening in a noisy environment or as background music).
• Optionally, a link to a fixed web resource containing further information about LAMEsure and the reasons why the settings are optimal as demonstrated ultimately by fairly extensive double-blind testing on a wide selection of music.

The list is incomplete and not fully thought through, but it needs to be fairly brief and reduce the confusion and propensity to end up with suboptimal settings.

Anyway, I hope to spark some discussion and see what might be worthwhile, if you think any of it is!

For LAMEsure decoders, we should ensure full MP3 compliance (obviously including VBR) with correct track duration reporting and at least reasonably accurate VBR seeking and at least the option of gapless decoding using LAME gapless info where present. Playback of mono MP3 files through both L & R speakers is a requirement unless the output device is mono or has a single centre channel that is used instead.
Optionally, support for Replay Gain should be encouraged, though probably not insisting on using the gain stored in the LAME header as this has little support to date (e.g. foobar2000).

I'm interested to know what you all think.

I might suggest that 3.97 also be an approved version. I know there are likely a number of users here who have yet to make the leap to 3.97 to 3.98 for whatever reason(s), and I don't believe their hesitancy is necessarily unjustified given how 3.98 has not been a contender in as many listening tests, and has therefore not been as well "established" (in my own opinion). From an encoder settings perspective, 3.97 would need only a few considerations.


I don't agree with the use of the term "transparency" to describe a potential result of any particular setting or mix of settings unless it's made incredibly clear that transparency or near-transparency is merely a potential outcome to a majority or large majority of users. I would say that V0 would be described as "Potentially resulting in transparency for most types of music to a large majority of users" or something to that effect.


I like this. A lot

The bottom line: I generally approve with everything you've suggested. Nice job!

tl;dr

I don't see the point of a "standard". If people can't follow the recommendation for encoding, it's their own problem. I'm not going to listen to their files, and I know how to encode my own stuff properly.

I think the point Dynamic is making is that the vast majority of end-users are unaware as to what the recommended settings are, and the situation is further muddied by many front-ends either allowing, defaulting, or even forcing the output of suboptimal files with non-recommended switches. I fail to see how taking a "them and us" attitude helps anyone to be honest. An analogy that springs to mind is that, in most countries, there is no requirement to know anything about how a car works at the mechanical level in order to pass a driving test. Why should encoding with LAME be any different?

I've now had to stop replying to threads regarding LAME settings and switches on any other forums besides HA due to the abuse I nearly always receive in return. According to many of the people I've attempted to have reasoned debate with, all of us here are totally wrong and a bunch of complete thickies, and everybody else is right to use/recommend whatever settings/switches they decide bring more "warmth", "brightness", "fluffy bunny wabbits", etc, to encodings regardless of the damage they may be doing to their own and other people's encodings. To repeat the car analogy, it's frighteningly common to see people gladly recommend that others put diesel in their petrol cars with assurances that it's "the right thing to do".

In short, neither the LAME developers nor anyone who has any understanding of LAME has the authority to even voice an opinion according to most of these "audiophile" LAME abusers. Apart from the code inside LAME itself, there currently is no standard regardless how much many of us would like to think there is. It's a crap-shoot for the uninformed with the result frequently being... well... crap quite frankly.

Wouldn't it be a massive help to everyone if we could just point people to a "LAMEsure" WIKI page carrying an explanation as to what it is and why it exists, and include a list of "LAMEsure-approved" front-ends in that WIKI? Isn't that better than the current situation of Chinese whispers promoted on almost every other forum on the planet by those who, in all honesty, really have no idea what they're talking about?

Many front-ends are already in existence that, with minor modification, could easily carry a "LAMEsure" logo or have a "LAMEsure" version released alongside the current incarnation with very little work involved in the process. LamedropXPd springs to mind, and I'd value John Edwards' opinion on this if he's about. I'd also like to hear Robert Hegemann's opinion as LAME is more his baby than anyone else's at the moment.

Dynamic must be psychic, because I already had most of his suggestions written down as part of a list I've been compiling since the beginning of the year in the hopes of making my own front-end with the intention of starting a new semi-locked standard eliminating any deliberate or accidental abuse of LAME when complying with that standard. Although I hadn't decided upon a new name yet, "LAMEsure" sounds like a mighty fine name to me.

I don't have the necessary programming skills and am suffering from a long-term illness that's completely wrecked my concentration (hence nearly all of my posts here requiring multiple-edits of late), so I'm really struggling here trying to learn a programming language to achieve this goal. Hopefully, someone else will pick up the ball and run with it.

Much respect to Dynamic for broaching this subject (again) on behalf of those of us who just want the best for everyone.

Cheers, Slipstreem.

Do it as simple as you want as long as there is an override in the form of advanced option checkbox that will let me enter any parameter I want. The foobar one is already pretty KISS to the point where I have to choose custom option.

Absolutely. I think one of the greatest advantages to having and promoting a compliance program like LAMEsure is that it sends a signal to those who use the encoder personally and those who use it commercially (Amazon, for instance). The message is simple and clear: this is LAME, and this is the best way to utilize LAME. Additionally, it should help to both simplify and demystify LAME settings, since LAMEsure GUIs won't present options to users that are typically undesirable. It should minimize user experimentation that will, more often than not, lead to substandard encodes.

If it's backed both by LAME developers and app developers who work in LAME-capable conversion functions in their products, it seems much more authoritative than a list of recommended settings at the LAME website (which don't currently exist, at least not in any straightforward manner) or on the HA wiki. It would end any debates about which settings are beneficial and which are unnecessary and/or detrimental.


I'm just surprised that there seems to be so little interest so far.

I've been thinking about this on-and-off all day, and the only part I'm not in agreement with is allowing lossy-to-lossy MP3 transcoding to take place unless this removes the LAMEsure flag after giving a warning that it will do so. After all, anyone could take an MP3 file that didn't comply and transcode it with a LAMEsure-compliant front-end and have an MP3 file produced at the output with a LAMEsure flag, thus defeating the object of having a compliancy standard in the first place.

The rest, I like.

Cheers, Slipstreem.

Slipstreem: I agree.

Dynamic, thanks for sharing the recommended LAME GUI link. I had never seen this before.

LAME first time users wanting to know the best settings, if they have any sense, would use Google to find out the best settings to use. Searching for "best recommended lame settings" would bring them here to HA. If they choose to use non-recommended settings after reading the wealth of information here, then they deserve their crappy encodes.

Others would go directly to the LAME website to look for answers. They'll have a tough time looking for answers there.

Just a comment from a user who can still remember what it was like starting.

LAMEsure would be good for new users who want to know where to start. If you just Google, how do you, at first, tell the difference between the sound advice of HA (which you've never heard of) and the people who insist on the -wtf -bbq switches? LAMEsure could be made official-looking, and if widely-enough adopted could become a standard.

OTOH, it won't stop the compulsive tweakers. "Oh, LAMEsure's just for beginners/part of a conspiracy to keep down the quality of rippings/the product of those dipsticks on HA who know NOTHING."

I guess the effort (which would be other people's effort, so easy for me to commit) would be worth it for the first group; as for the second, well, there is such a thing as invincible ignorance, so it won't stop there being suboptimal encodings in the wild. But then, that is of little interest to anyone except pirates, yes?

It seems to me that LAME devs want users to have access to only the options/switches in this GUI. Why don't they just disable all the other options/switches in the code itself? That sure is a lot easier than requesting all frontends/rippers to follow their recommendation.

Roberto Amorim and Sebastian Mares should be able to explain where this gui came from.

edit: btw, i do actually think that os is about promoting variety (not to be confused with the apparent lame goals, which are really cool imho).

I wanted to echo these thoughts. I'm very tech-savvy and my google-fu is strong, however it took me quite a while to figure out how to properly encode my collection so that i was happy with it. Ultimately my information came from here, but it took time to figure out you were the folks who actually knew what you were talking about and could be trusted. Finding a true authority on a subject on the www is a tough job sometimes. There's a lot of noise and outdated information out there.

Putting a developer endorsed stamp of approval on a front end is an almost fool-proof way of getting decent encodings onto the dap's of the not-so-informed. A brief writeup on how to choose a bitrate would be all that's needed to get folks started.

There is a very minor "stamp of approval" for HA at the LAME website. You'd have to have pretty sharp eyes to find it.

Thanks for the input, folks. I like Slipstreem's idea of removing any LAMEsure flag from the MP3 if it's a lossy transcode, though that will obviously never catch lossy-PCM-lossy conversions.

When starting out again after using MP2 and Cool Edit 96 and l3enc.exe, I seem to recall searching for "best MP3 encoder" and "Variable Bitrate MP3", which I thought was a smart idea and learned about via MusicMatch Jukebox (FhG-based). This was quite some time ago, and at the time the top link was "r3mix" - partially good, but partially the worst example of tweakmanship and tuning-by-graph.

I think I then came across digital-inn.de regarding Exact Audio Copy and the Winamp forums, and finally Dibrom's Project Mayhem - now known as Hydrogen Audio. In the meantime, I'm sure I'd looked at the LAME website too.

If I'd seen a number of software apps all claiming LAMEsure compliance, I'd have suspected something desirable and googled LAMEsure to find out more and become educated.

@shadowking: I envisage LAMEsure being one of many encoder settings dialogues in an app. Ideally it should be limited to the foolproof usually-optimal settings described above. Custom or Command-line encoder could be another dialogue, and a LAME dialogue box with any settings one wishes could be another, but it may not set the LAMEsure flag unless the settings used happen to be allowed by the LAMEsure standard.

LAME could be modified to include a LAMEsure switch (or a LAMEsure special compile) that will either refuse to encode or ignore unwise settings whenever "unwise" settings are chosen or will simply omit unwise options.

I believe I may be able to get hold of a compiler in the coming weeks, try to get my head around it and have a go, though I suggest you don't hold your breath waiting!

(P.S. Another name might be LAMEcert, though it sounds more like something to do with secure encryption)

I think it is a great idea! One simple setting for 99% of people to use. Sort of like the old -V2 before a recommendation stopped being made.
Hope it comes to fruition!