Notes by ff123
NOTE: Also see the List of Recommended Lame settings on the hydrogenaudio.org forum.
Also see Roberto Amorim's Public Listening Test of MP3 at 128 kbit/s
Revision: Added --ns-bass -8 to the Lame command line, which improves low frequency noise when using --nspsytune. Thanks to Hans Heijden for testing this switch. In fact the lion's share of the Lame command line is due to Hans Heijden. Also Wombat, Dibrom, and I have also contributed to tuning the Lame command line.
Revision: Added a command line for files which aren't restricted to CBR.
Revision Nov 4, 2001: Now make a much stronger recommendation for --scale, and have lowered the value from 0.98 to 0.93. Also, now recommend a second setting which sets the lowpass filter higher than 16 kHz.
Revision Dec 21, 2001: In Lame 3.90 stable, the primary recommended settings are now encapsulated into the presets: --alt-preset cbr 128 and --alt-preset 128.
For musicians who wish to upload files to music services such as mp3.com, 128 (CBR) is a requirement. So which mp3 encoder would I recommend at this bitrate, and what would the settings be? My only consideration is sound quality, not speed or convenience or cost. I have tried to synthesize the opinions of many different sources to come up with recommendations, but they are swayed by my own biases.
Jan 10, 2002: I am almost equally divided between the lame command lines and FastEnc. They both produce objectionable artifacts at times at this bitrate, but it's a matter of preference which one you will object to more.
For CBR 128, I currently use the following codec(s) and command line.
Lame 3.92 stable (Apr 14, 2002) with the
settings:
Fraunhofer's FastEnc (CBR 128, as found in MusicMatch Jukebox 6.1 or later, "normal" setting) |
For files which average about 128 kbit/s, I use the following:
Lame 3.92 stable (Apr 14, 2002) with the
settings:
Fraunhofer's FastEnc (CBR 128, as found in MusicMatch Jukebox 6.1 or later, "normal" setting) |
Please note that opinions concerning sound quality at this bitrate are varied. There are advocates for MP3Enc31, Lame, FastEnc, and Producer Pro. See my page "Test for Ringing" to see what I'm talking about. The following lists reasonable candidates for "best" encoder at 128 (Xing is not included as a reasonable candidate at this bitrate!).
Fraunhofer MP3Enc31: This is the encoder which many people with good high frequency hearing would choose as the one to beat at CBR 128. Biggest shortcomings: 1) the default lowpass filter is set lower than other encoders (transition starts at about 14.5 kHz), such that people complain of a "muffled" sound. 2) There are occasional obvious dropouts/glitches in certain types of music (see my page "Dropouts in MP3/Alternate Codecs"). On the other hand, this codec does not "ring," meaning it does not produce artifacts caused by switching of high-frequency subbands (see my page, "What does ringing look like?"). And one can override the default lowpass filter. The switch settings I might try are:
-qual 9 -bw 16500
which will actually only extend the lowpass cutoff to about 16 kHz. Or, one can use the Alternate codec, which is a close relative of MP3Enc31, but which defaults to higher cutoff. Be sure not to use the bad version of the Alternate codec (see my page "Bug in older FhG Alternate Codec"). NOTE for NT (SP4 or later) or Win2K users: Using high values of -bw (greater than 16000) may cause a screeching high-pitched noise to be produced. It's a known bug in mp3enc31 when using those operating systems.
David Robinson has some information about what Fraunhofer themselves would recommend (see his post on r3mix's forum):
FhG suggest using FastEnc over MP3enc at bitrates up to 80kbps. I don't have a reference for this - I asked one of the FhG guys directly at the AES - they keep sending "reference" DOS mp3 encoders out to magazines, and I wondered which codecs they included - the answer FastEnc and mp3enc 3.1.1, the former up to 80kbps, the latter above it.
I believe mp3enc 3.1.1 to be what I term (actually what Cool Edit terms) "Alternate."
Fraunhofer FastEnc: In many cases, this encoder produces better (to my ears) sounding files at CBR 128 than MP3Enc31 and in some cases it beats Lame with --nspsytune (in my opinion) On some songs with a lot of cymbals, lame has more of a tendency to flange than FastEnc. Be sure to use programs which don't use the bad version of this codec (see my page "Bug in Latest FhG FastEnc"). Some people with good hearing report hearing slight ringing, or a "steely" sound, as if the music had been placed in a metal room. This codec produces consistent quality, without the occasional obvious dropouts/glitches of MP3Enc31. Fraunhofer's VBR is based on FastEnc, and produces average bitrates near 128 kbit/s at the 50% quality level. See my page "MP3 codecs not recommended" for programs which properly implement Fraunhofer's VBR (there aren't many).
Fraunhofer (Opticom) Producer Pro, AudioActive, or Radium hack of this codec: Some people swear by this codec, but I think that at CBR 128 it pays too much attention to frequencies greater than 16 kHz at the expense of more critical lower frequencies. In addition, on certain musical selections which contain lots of out-of-phase information (I don't know how rare this is), this codec may produce unlistenable results (see my page "Out of Phase Quirk in FhG 1.0/1.2 build 63i Codec"). In addition, bAdDuDeX has heard pre-echo problems with this codec on castanets.wav (see his comment on my listening test of castanets.wav).
Lame: Just as it doesn't make sense to talk about "the Fraunhofer codec," (there are more than one), one can't talk about Lame without mentioning the version and settings. There have been complaints about ringing in Lame (see my page "Ringing Artifacts in Lame"), caused by on-off switching of high-frequency subbands. This has been largely taken care of in version 3.88 and later with Naoki Shibata's nspsytune. This codec using --nspsytune is consistently good (see caveats about --nspsytune in the section below), and was rated at or near the top by most listeners in the "Test for Ringing." on the one sample tested. Contrast this to MP3Enc31, which received almost equal number of best and worst votes.
Rationale for settings:
In Lame 3.90 stable, the presets encapsulate what used to be experimental switches. Alternate command lines are offered for those who may prefer that a bit more attention be paid to reducing rumbling or blurring at low frequencies, but at the expense of high frequencies.
joint stereo (default stereo mode): at higher bitrates, normal stereo might be preferred to joint-stereo, but at CBR 128, all of the codecs listed here, including Lame, default to joint-stereo.
--nspsytune: appears to cure the ringing problem noted by some people. On the other hand, others (including me) have noted a slight blurring of the sound or addition of low-frequency noise or rumble (for example, see my page "Test for Echo by Rush" and Test using the Eagles's Lyin' Eyes). Also see bAdDuDeX's comments about not being as "clean" when compared with MP3Enc31 in the Test for Ringing, and TLO's comments about "slight upper midrange smearing or blurriness." The --ns-bass -8 switch was added (7/17/01) to take care of this low frequency noise.
Another thing that is slightly worse with this setting is temporal accuracy, or pre-echo handling. David Robinson writes: "Castanets (the SQAM version) is audibly worse at 128kbps than the lame default (both are obviously smeared, but the recommended settings give poorer results). I also heard slightly more smearing on the tapped hi-hat in a track I was listening to but the difference between the lame default and recommended settings was very small, and neither was too bad. The watery sound on many notes, which I now realise is due to those high (9-12kHz+) frequency drop-outs that are visible in spectral view, is dramatically reduced with the recommended settings. I guess this is what others call "ringing" when it's at a higher frequency (as it is with higher bitrate mp3s), and nspsytune certainly reduces it dramatically. I think the temporal trade-off is worth it, at least for the tracks I've tried."
Finally, on some samples such as charlies.wav (available from my samples page) or Daughter.wav (available from Speek's page), this setting starts to flange, with metallic background sounds (it is very obvious if the bitrate is reduced to 112 kbit/s). FastEnc, while it has its own problems, flanges a bit less on such samples at 128, and a lot less at 112 kbit/s.
-q2: defaulted by using the -h (high quality) switch. In Lame 3.90 stable, an experimental mode is now enabled with -q0. This experimental mode is Takehiro Tominaga's new noise-shaping mode, which performs "pseudo half-step quantization." The -q1 mode was noted by Hans Heijden in previous versions of Lame to sound different from -q2, but not improved. (see original post on the archived r3mix.net forum).
--athtype 2: Absolute Threshold of Hearing curve. Defaults to athtype 0 (in Lame 3.87) when using nspsytune (defaults are as shown in the following table:
default without nspsytune default with nspsytune cbr athtype 2 athtype 0 abr athtype 2 athtype 0 vbr athtype 2 athtype 0 According to bAdDuDeX, athtype 0 falsely masked the background hiss in the sample used for the Test for Ringing. Hans Heijden also notices that athtype 0 alters the sound of background hiss in testsample1.wav. EarGuy's Digital Ear rates files encoded with athtype 0 slightly better than those encoded with athtype 2 (see this thread on r3mix's archived forum). However, for the time being, I am choosing the listening opinions of live people over the simulation in recommending an ATH type.
--lowpass 16: when used with CBR 128, raises the lowpass cutoff about 700 Hz from its default transition band of 15.1 to 15.6 kHz. Hans Heijden notices a definite improvement in bandwidth with no apparent loss in quality. Wombat prefers a higher lowpass value, and doesn't notice a quality degradation if --lowpass 17.5 is used.
--ns-bass -8: improves the low frequency rumble I and others hear in certain samples. The improvement in ringing for higher frequencies is not degraded too much. Hans Heijden performed a listening test for this setting using lyin.wav and main_theme.wav, two samples which have opposite encoding requirements. I verified that low frequency rumble is much improved. Make sure you use --ns-bass -8 and not --ns-bass 8. The latter will make the rumble worse! Dibrom notices a slight degradation of high frequency quality in test_4_artifacts.wav (which can be downloaded from r3mix's server) using --ns-bass -8, and prefers to make the tradeoff more in favor of high frequencies using a value of --ns-bass -6. This value would probably be the best one to use if the lowpass is increased to 17.5 kHz.
--scale .xx: This switch is used to scale the amplitude down to prevent clipping caused by the encoding/decoding process. Dibrom noticed that with bitrates below 128 kbit/s, clipping was causing very frequent and audible artifacting (ticking noises) in bloodline.wav (which can be found on my samples page). This problem gets less and less severe as the average bitrate increases, but there are still some audible ticks in this sample caused by clipping even when using --abr 134. These are reduced by using --scale 0.98. Using --scale 0.95, I don't hear the ticking noises in this sample anymore. However, Dibrom said he heard something even using 0.95, so I'd recommend something slightly less to be safe (0.93). The audible problem is less severe when using CBR128. However, I recommend using the same value of scale with CBR as well just to be safe. Note: I personally don't normalize before encoding or use the --scale switch to prevent clipping. To prevent clipping (which only occurs upon decoding), I use mp3trim or mp3gain to reduce the gain in the mp3 file directly (without decoding to WAV and re-encoding). However, currently this is a two step process and using --scale is a more practical solution.
--abr 128 (for files which average about 128 kbit/s): add this to the command line if you aren't restricted by constant bitrate considerations. I tested ABR against plain CBR using peaceful.wav and the ABR-encoded file sounded better (ABX results 15/16).