I've been running a SHOUTcast broadcast at 96 kbps for the past year. I keep using an old version of the SHOUTcast DSP for Winamp because I want to use the Radium FhG codec; newer versions only support the LAME DLL, and that DLL's default settings at 96 kbps apparently produce disturbingly bad artifacts in the upper midrange.
Last week I decided to do some comparison between the codecs. I compared live frequency analysis graphs for a particular selection of music (a fairly busy snippet of Duran Duran's "Hold Back The Rain" remix/Night Version) as it went through different encoder settings. I know this isn't the right forum for discussing what's the better encoder, so I won't bother reproducing all my observations here. My main concern is just to see why Radium's true stereo 96 kbps default was producing much less artifact-y sound than the 96 kbps default settings for LAME (even with -q 0) as well as the LAME DLL as invoked by SHOUTcast. Long story not-so-long, you can pretty closely reproduce Radium's performance with LAME on the command line with something like "lame -m s -b 96 -q 0 --lowpass 10.5 --resample 44.1". You can push the lowpass up to 12 for a noticeable improvement beyond this. For reasons I don't understand, the LAME defaults for 96 kbps seem to be to produce 32 kHz output sample rate, with a 12 kHz lowpass, and lower quality settings, and this seems to make all the difference in the world. I don't know how the SHOUTcast folks are setting the DLL, but it seems to produce the same substandard results. So I guess what I'm suggesting is that some improvements be made to the default settings for 96 kbps in the DLL, if not everywhere, so that it is at least on par with Radium, if not better. At least that way, SHOUTcast can use the default and not sound so poor. The equivalent of -m s -b 96 -q 0 --lowpass 12 --resample 44.1, or something close to that, is what I propose. I noticed while browsing CVS that there were some improvements along these lines checked in recently, but they were backed out for the impending release. I'd be interested in hearing the effects of those changes, and vote for putting them back in :) - Mike ____________________________________________________________________________ mike j. brown | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/ _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
