LAME (Lame Ain't an MP3 Encoder) is the recommended 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 for using LAME:
- Highly optimised presets
- Fast encoding
- CBR, ABR and VBR encoding methods
- Gapless playback with LAME-header compliant decoders
- Exact Audio Copy and CDex support
- 1 History
- 2 Recommended Encoder Settings
- 2.1 History
- 2.2 Recommended encoder compiles and source code
- 2.3 Recommended encoder settings
- 2.3.1 Maximum quality and archiving
- 2.3.2 [VBR] Very high quality: HiFi, home, or quiet listening, with best file size
- 2.3.3 [CBR] Very high quality: HiFi, home, or quiet listening, with maximum file size
- 2.3.4 Portable: listening in noisy conditions, lower bitrate, smaller file size
- 2.3.5 Very low bitrate, small sizes: eg. for voice, radio, mono encoding etc.
- 2.4 Understanding the bitrate settings
- 2.5 Technical information
- 2.6 See also
- 2.7 Notes and references
- 2.8 External links
- 3 Additional reading
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. That branch (a patch against the reference sources) became LAME 2.0, and only on LAME 3.81 they got rid of all dist10 code, making LAME a completely new program-not a mere patch of an existing encoder.
The project quickly became a team project. 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 like Takehiro Tominaga, Naoki Shibata, Darin Morrison, Gabriel Bouvigne, Robert Hegemann, etc. And development is still going on...
Recommended Encoder Settings
|Developer(s)||The LAME project|
|Operating system||Windows, Mac OS/X, Linux/BSD|
|Website||LAME website, Download site: Rarewares LAME-bundle|
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:
- Highly optimised presets
- Fast encoding
- CBR, ABR and quality-optimized VBR encoding methods
- Gapless playback with LAME-header compliant decoders
- Supported by recommended CD rippers Exact Audio Copy and CDex
- Highly tunable
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. 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
Unless noted otherwise, the recommended LAME compile for optimal quality is always the latest stable version.
Download the latest LAME from these links:
- RareWares MP3 Page - Compiles for Win32, Mac OS X universal binary, Linux etc.
- LAME source code on SourceForge
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
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).
Understanding the bitrate settings
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
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.
-V <number> where <number> is between 0 and 9, 0 being highest quality, 9 being the lowest. (Note: The "V" has to be a capital letter.)
Fractional values out to three decimal places are also accepted, with 9.999 being the absolute lowest quality.
Note: The switch
--vbr-new, which enabled a superior VBR mode in LAME 3.97 and some previous versions, is no longer needed with LAME 3.98 and higher, as it is now the default VBR mode. However, if you're still using LAME 3.97 or older, you have to add
--vbr-new to your command line to use that mode.
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
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.
--preset <bitrate> where <bitrate> (desired averaged bitrate in kbit/s) is a value between 8 and 320.
Important: ABR setting is tuned from 320 kbit/s down to 80 kbit/s.
CBR (constant bitrate) settings
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.
-b <bitrate> where <bitrate> (bitrate in kbit/s) must be chosen from the following values: 8, 16, 24, 32, 40, 48, 64, 80, 96, 112, 128, 160, 192, 224, 256, or 320.
Important: CBR setting is tuned from 320 kbit/s down to 80 kbit/s.
- The rule of thumb when considering encoding options: at a given bitrate, VBR is higher quality than ABR, which is higher quality than CBR (VBR > ABR > CBR in terms of quality). However, ABX tests demonstrate that as bitrate increases, the perceptual differences diminish, with all modes generally reaching transparency well before their maximum settings; when you can't tell the difference, the modes are qualitatively the same.
- In terms of filesize VBR tends to produce the smallest files down to -V7. For lower quality (e.g. for non-music audio such as speech) ABR will produce smaller files than VBR, starting from --abr 115.
- All modes and settings mentioned in this topic belong to the specifications of the MP3 standard, and the resulting MP3s should be playable by every MP3 decoder that conforms with the standard. If your decoder or device does not play MP3s produced by LAME, blame the manufacturer or developer, not LAME.
- Prior to LAME 3.98, the
--vbr-newswitch enabled the new VBR mode. This is now the default VBR mode, with the old mode being available via
--vbr-old. In terms of quality, the new mode appears to be better than the old, but reports of artifacts when using the new mode do exist. Despite these possible issues, the new mode is currently recommended due to both the speed and quality increases afforded by the new algorithm.
Recommended settings details
|Switch||Preset||Target Kbps||Typical Kbps||Y Switch enabled by default||Lowpass||Resample||Formerly Known As|
||320||320||Y||20094 Hz – 20627 Hz||api|
||~240||220–260||none||ape or apx|
||~220||190–250||19383 Hz – 19916 Hz|
||~190||170–210||18671 Hz – 19205 Hz||aps|
||~170||150–195||Y||17960 Hz – 18494 Hz|
||~160||140–185||Y||17249 Hz – 17782 Hz||apm|
||~130||120–150||Y||16538 Hz – 17071 Hz|
||~120||100–130||Y||16538 Hz – 17071 Hz|
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.
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. 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.
Fraunhofer decoder incompatibility
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
l3codecx.ax version 1.5.0 or lower, as used by Windows Media Player on versions of Windows prior to Windows Vista. An August 2010 security update for Windows XP and Server 2003 upgraded this filter to version 1.6.0, which can play the problematic MP3s. Windows Vista shipped with the older version but Windows Media Player uses a different filter, and later versions of Windows don't have the old filter at all.
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
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:
- a short version string (9 ASCII bytes; see LAME version string)
- audio and info tag CRCs (since LAME 3.90)
- separate delay & padding values for gapless playback (since LAME 3.90)
- various encoder settings (since LAME 3.90, expanded in 3.94 to include presets)
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.
Hey! What happened to "--alt-preset"?
--alt-preset system was introduced in LAME 3.90. It was replaced by the
--preset flags in later versions.
Starting with version 3.94, the
-Vx quality system was introduced, allowing finer control over the desired quality level and bitrate. The
--preset switches were made into aliases to the corresponding
-V flags for the sake of backward compatibility. There is no difference between the output you get if you use
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:
--preset cbr 320
Notes and references
- dist10 is the rudimentary "demonstration" MP3 encoder described in the MPEG-2 standard, ISO/IEC 13818.
- Prior to version 3.99, CBR and VBR modes were encoded differently by LAME. In some unusual problem samples, these differences were sometimes audible, even at very high bitrates. Current versions of LAME encode CBR and VBR with the same psychoacoustic model, so such differences shouldn't arise from normal use.
- Typical bitrates are mostly based on the results of testing with LAME 3.98.2.
- This range is the transition band of the lowpass filter, as of LAME 3.99.5 with 44100 Hz input. Signal components are at full intensity at the lower frequency. Higher frequencies are attenuated on a slope which reaches zero at (and beyond) the high end of the given range. Further info can be found in the HA forum.
- CBR mode uses
-Yin effect; see the LAME Y switch article.