LAME (Lame Ain't an MP3 Encoder) is the Hydrogenaudio recommended MP3 encoder. It has been developed by the open-source community since 1998, and has become the highest quality MP3 encoder for most purposes. Some benefits of using LAME:
Contents[hide]
History[edit]LAME development began around mid-1998. Mike Cheng started it as a patch against the 8hz-MP3 encoder sources. After some quality concerns raised by others, he decided to start from scratch based on the dist10 sources.[1] That branch (a patch against the reference sources) became LAME 2.0. By the release of LAME 3.81, all dist10 code was removed, making LAME a completely new program, not a mere patch of an existing encoder. The project quickly became a team effort. Mike Cheng eventually left leadership and started working on tooLAME, an MP2 encoder. Mark Taylor became leader and released version 3.0 featuring gpsycho, a new psychoacoustic model developed by him. Nowadays LAME is considered the best MP3 encoder at mid & high bitrates, and features the best VBR model among MP3 implementations, mostly thanks to the dedicated work of talented developers Takehiro Tominaga, Naoki Shibata, Darin Morrison, Gabriel Bouvigne, Robert Hegemann, and others. Development is ongoing. Although LAME is generally considered to be an encoder, according to the LAME technical FAQ, it's technically not an encoder, but rather is officially just "a development project which uses the open source model to improve MP3 technology." This improved technology is only released in source code form in order to minimize the risk of violating patents. When the source code is compiled and distributed, it may require a license from Thomson, depending on where and how it's to be used. The LAME project's position is "Source code is considered as speech, which may contain descriptions of patented technology. Descriptions of patents are in the public domain." LAME source code is maintained in a CVS repository, and the only official codebase for public use is the trunk code tagged "MAIN". There are also numerous experimental branches of this code in which the developers test new ideas. One of these branches was started after the release of LAME 3.92 in 2002. To keep it from being confused with LAME 3.93 alpha versions, the code was made to self-identify as LAME 4.0 alpha 1 (in late 2002) through 4.0 alpha 14 (since 2005). This code is mainly for the developers to test optimizations and architectural changes in LAME's foundational code, ideas that may eventually be used in the main branch if and when development actually begins on LAME 4.0. However, some members of the public used this code to build working copies of "LAME 4.0" alpha versions in 2003-2005. These should not be considered actual LAME 4.0 releases and the developers do not want public feedback on them, nor do they want any more public builds to be made from this branch. Recommended encoder compiles and source code[edit]Unless noted otherwise, the recommended LAME compile for optimal quality is always the latest stable version. Download the latest LAME from these links:
Avoid using alpha versions of LAME. These versions have "a" in their version string and are usually only for testing changes and new features, and may result in lower quality MP3s. Use them only if you want to help the developers and provide feedback. Recommended encoder settings[edit]This section describes the Hydrogenaudio recommended settings to be used with LAME for highest quality MP3 encoding. These settings require LAME 3.98 or later (the latest stable version is recommended). Maximum quality and archiving[edit]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. For archiving, only lossless formats like WavPack, FLAC, etc. are ideal; they will preserve the audio with no changes, sample-for-sample, regardless of encoder settings. In contrast, lossy formats like MP3 are designed to save space by changing the audio in subtle, often imperceptible ways, even at the encoder's maximum settings. Very high quality: HiFi, home, or quiet listening, with best file size[edit]
These VBR settings will normally produce transparent results. Audible differences between these presets may exist, but are rare. Very high quality: HiFi, home, or quiet listening, with maximum file size[edit]
This CBR mode will maximize the MP3's bitrate and overall file size. The extra space may allow for some parts of the audio to be compressed with fewer sacrifices, but to date, no one has produced ABX test results demonstrating that perceived quality is ever better than the highest VBR profiles described above.[2] Portable: listening in noisy conditions, lower bitrate, smaller file size[edit]
Very low bitrate, small sizes: eg. for voice, radio, mono encoding etc.[edit]For very low bitrates, up to 100kbps, ABR is most often the best solution.
Use --preset voice is only available in the command line front-end, and is there for compatibility. It is currently mapped to --abr 56 -mm, so that means that the recommendation would be to encode in mono, and use ABR. Understanding the bitrate settings[edit]MP3s are divided into frames, each frame being a particular size, expressed as a bitrate. If the bitrate of every frame is the same throughout the file, then the file is considered to be constant bit rate (CBR). Otherwise, it is variable bit rate (VBR). LAME offers CBR and VBR encoding modes, as well as a special VBR encoding mode called ABR (average bit rate). VBR (variable bitrate) settings[edit]VBR: variable bitrate mode. Use variable bitrate modes when the goal is to achieve a fixed level of quality using the lowest possible bitrate. VBR is best used to target a specific quality level, instead of a specific bitrate. The final file size of a VBR encode is less predictable than with ABR, but the quality is usually better. Unlike other MP3 encoders which do VBR encoding based on predictions of output quality, LAME's default VBR method tests the actual output quality to ensure the desired quality level is always achieved. Usage: Example: Fractional values are also accepted, with 9.999 being the absolute lowest quality. Example: Note: The switch The target bitrate and actual typical bitrate for each VBR quality level is shown in the Technical details for recommended LAME settings section below. If you need a predictable bitrate (in a streaming application, for example), use ABR or CBR modes, described below. ABR (average bitrate) settings[edit]ABR: average bitrate mode. A compromise between VBR and CBR modes, ABR encoding varies bits around a specified target bitrate. Use ABR when you need to know the final size of the file but still want to allow the encoder some flexibility to decide which passages need more bits. The output is an ordinary VBR file compatible with all MP3 players that support VBR; ABR is not a special type of file, just a LAME-specific strategy for producing VBR. Usage: Example: Important: ABR setting is tuned from 320 kbit/s down to 80 kbit/s. CBR (constant bitrate) settings[edit]CBR: constant bitrate mode. CBR encoding is not efficient. Whereas VBR and ABR modes can supply more bits to complex music passages and save bits on simpler ones, CBR encodes every frame at the same bitrate. CBR is only recommended for usage in streaming situations where the upper bitrate must be strictly enforced. There is still some variability in bitrate behind the scenes, through LAME's use of the bit reservoir feature of the MP3 format, but it is much less flexible than actual VBR. Usage: Example: Important: CBR setting is tuned from 320 kbit/s down to 80 kbit/s. Remarks[edit]
Technical information[edit]Recommended settings details[edit]
The default lowpass settings were not chosen at random; for general use, they are as high as they can be without putting quality at risk. Raising the the cutoff via command-line options is not recommended. See the high-frequency content in MP3s article for more info. Fraunhofer decoder incompatibility[edit]Differing interpretations of an unclear portion of the MP3 spec led to a Windows-specific version of the Fraunhofer IIS MP3 decoder being unable to properly play certain MP3s created with certain versions of LAME. In order to demonstrate the problem, the problematic MP3 must have been created with LAME 3.97 or earlier, and must contain a frame with certain parameters and a very large amount of data, such as a 320-kbps frame which makes heavy use of the bit reservoir. The decoder must be the DirectShow filter A workaround was implemented in LAME 3.98.0 beta 1 through LAME 3.98.2, and in LAME 3.99 alpha 1, whereby 320-kbps frames were limited in how much of the bit reservoir they could use. This resulted in wasted space when the bit reservoir would grow beyond the limit. In LAME 3.98.3 and beyond, and in LAME 3.99 alpha 2 and beyond, the method was changed such that the bit reservoir can't grow beyond the limit. Related discussion threads: VBR header and LAME tag[edit]LAME supports the de facto standard of adding an extra frame of silence to the beginning of MP3 files. This "VBR header" or "Info tag" provides a home for precise info about the audio duration and a table of seek points. It is mainly for the benefit of players working with VBR files. Decoders usually treat the frame as informational, rather than playing the audio. LAME uses the Xing format for this header, and extends it by embedding a 20-byte "LAME tag" with additional info:
Prior to LAME 3.94, the VBR header was only written in VBR files. Since 3.94, it is written to CBR files, too, with "Info" instead of "XING" at the beginning. Details are in this wiki's MP3 article and LAME version string article, and in LAME developer Gabriel Bouvigne's MP3 Info Tag documentation. Hey! What happened to "--alt-preset"?[edit]The revolutionary Starting with version 3.94, the Recent LAME versions feature more streamlined command-line options, and it's recommended to stick to one of the values described in the text or shown in the table above. For example, the following command-line options will all produce the same output:
See also[edit]Notes and references[edit]
External links[edit] |
|