I tend to use LAME but it seems to change dynamics a little. The problem is that it uses 0 dB, too, which gives me the creeps because it might distort the sound a bit. 
Cool edit pro’s encoder doesn’t use 0 dB, but it seems to change the dynamics even more than lame. If the wave is brickwall limited then the mp3 signal has peaks over the limit quite much. Anyone knows a good mp3 encoder that won’t change the dynamics that much?
LAME is the best there is and you will not got better results from anything else in my opinion.
If you are not getting good enough results then perhaps you are using some weird settings? Could you mention which settings you are using?
160 kbits cbr with joint stereo and high quality switch.
It might be the joint stereo which is affecting your music. It’s usually ok but due to the way it works it can sometimes degrade the sound, especially the perceived stereo positioning of certain things.
I would recommend encoding in true stereo and using at least 192kbps. I would also recommend using VBR instead of CBR since it tends to give a better overall result in my experience, though you will probably end up with a slightly larger file. It just depends on the balance you want to achieve between quality and filesize I guess.
Here are the flags I use, for whatever it’s worth:
-b 192 -m s -h -V 0 -B 320
.
i thought fraunhoffer was supposed to be better than lame?
It is different… LAME still stands for “Lame Ain’t an MP3 Encoder”
But i believe Frauhenhofer offers a time limited evaluation version of their surround encoder:
http://www.iis.fraunhofer.de/amm/download/…ound/index.html
It is offered time limited because it still seems beta.
At low bitrates such as 128kbps Fraunhofer performs better than LAME and other encoders. In fact LAME and several others will roll off everything above 16khz in an attempt to give extra encoding bandwidth to the more audible frequencies below 16khz, compared to Fraunhofer which will attempt to encode all the way up to 20khz.
But at 192kbps and above LAME is practically identical in performance (it does not roll off at 16khz either). I honestly doubt you would ever be able to hear any difference between Fraunhofer and LAME at higher bitrates. The extra icing on the cake for me is that LAME is free and fast, so it has become my encoder of choice.
There’s an interesting comparison here:
http://arstechnica.com/wankerdesk/1q00/mp3/mp3-1.html
.
I personally use BladeENC… it’s based off lame… don’t ask me how it deals with sound dynamics though… all I know is it sounds good enough for me 
I’m using the Audition encoder, which I believe is a hack of Fraunhofer. Best results I’ve ever heard, but you have to have Audition to run it.
Regarding the CBR vs VBR thing: I’m moving back to CRB especially as the songs I’m encoding with good vocal performances get really mashed with VBR. 192k CBR for sure. VBR screws up in some players too, still.
Hmm, that doesn’t make sense - the whole point with Variable Bit Rate is that the material should reach a given quality at all times and then the encoder estimates what bitrate is sufficient to encode each mp3-frame to reach that quality. What could be the problem is that your mp3-encoder doesn’t do this estimation well enough, to put it easily. It’s kinda awkard that there are players out there that don’t handle VBR, it’s quite an old standard by computer terms. 
Personally: I also recommend, using LAME and the alt_preset_standard / alt_preset_extreme / alt_preset_insane commandlines. Well, when it comes to mp3 anyway. Ogg is technically and audibly a better format imho.
Interesting. I found VBR much better are single-source audio, like a speech or single instrument. But when you have complex dynamic stuff it just didn’t cut it. With CBR I felt I had explicit control on where I could ‘let go’ on the quality.
But you may be right, maybe the encoder I have isn’t that great at that particular aspect.
OGG is the best for sure, but unfortunately mp3 still has the deepest format acceptibility.
EDIT (8th of November 2007):
URLs changed and also made 3 different ZIPs for everyone.
First a complete working pack with Razorlame, a rather new or perhaps even the latest LAME and noclipping v.1.0. You may have to tweak Razorlame’s preferences. See noclipping.txt in /lame/ directory.
http://kotisivu.dnainternet.net/ollijuss/n…_noclipping.zip
Only noclipping.exe and noclipping.txt:
http://kotisivu.dnainternet.net/ollijuss/n…pping_v.1.0.zip
And the source code:
http://kotisivu.dnainternet.net/ollijuss/n…1.0_source.zip
Noclipping v.1.0
Author: tenda / TyypiZ
This program is made to aid LAME compress non-clipping audio files. You probably have noticed that the wave file doesn’t clip and is perhaps brickwall limited to -0.1 dB, but when you encode it into mp3 the signal has some peaks which clip. This program hopefully removes the clipping. At least it works for me.
Install & use:
Copy noclipping.exe into same directory where lame.exe is. It works at least with Razorlame if you change lame.exe from edit->options to noclipping.exe. It naturally works from the command line like: noclipping -q 0 -V 2 -m s c:\song.wav c:\music\mystuff\song.mp3
Known issues:
- Currently mp3 to mp3 encoding is not possible because LAME doesn’t support it with --clipdetection switch set.
- When aborting encoding in Razorlame, lame.exe process is left running in memory causing input and output file undeleteable. Kill the process. It happens because Razorlame shuts down only noclipping.exe.
How it works:
Noclipping starts LAME with --clipdetect parameter + the parameters you give. LAME encodes the input file and noclipping writes --clipdetect parameter output into noclipping.dat. After that noclipping reads the approximated new scale for the output file from noclipping.dat and LAME re-encodes the mp3 from input file with new scale so that the signal won’t clip. The new scale value is determined by LAME. So, basically noclipping commands LAME to encode the input file twice if the output file clips after first encoding. If there’s no clipping, the file is encoded only once.
Results:
Sometimes LAME can give a message that clipping occurs after 2nd encoding. But in cooledit I noticed no clipping. Maybe some files will clip after 2nd encoding, but then you can do the scaling manually by giving LAME “–scale 0.xx” factor. First give “–scale 1” and “–clipdetect” for options. Then you’ll see what scale factor LAME suggests for non-clipping result. Decrease the factor so that LAME gives no whining about clipping.
Contact:
(see noclipping.txt)
Feel free to mess with the source code. Hope that was all… Have fun!
Great stuff… you should post this to the LAME coder (well i don’t mean anything with this other than… erm… never mind).