On codecsLooking at graphics is not the most efficient mean to evaluate codecs. Info from king is interesting but most points out to non-updated and controversial r3mix-related analysis (
http://www.r3mix.net/). For another point of view:
http://www.hydrogenaudio.org/index.php?act=ST&f=1&t=4298&hl= (originated by one of chicoself's first post on hydrogenaudio
) and
http://www.hydrogenaudio.org/index.php?act=ST&f=1&t=4015&hl=r3mix&s=2d24894f78db0618326dea22d5f4e0a1 (check Flloyd's answer particularly and later Dibrom's)
It is normally accepted to say that LAME and Fraunhofer's FastEnc (used since MMJB 6.1) have similar quality at 128 kbits/s; some background:
http://www.ff123.net/cbr128.html and
http://www.ff123.net/index.htmlAnything at a higher bit rate with Fraunhofer's FastEnc is inefficient. FH was optimised for speed (and its development stopped years ago) while LAME is optimised for quality (and still in development, making use of the latest psychoacoustic models). If you want better sound quality with mp3, a slower encoding process shouldn't be too much of a high price to pay. Other types of lossy codecs will provide for more quality and speed (mpc, ogg, aac, but definitely not wmv), but at the price of hardware compatibility (at least now).
Also, according to the LAME development team, the next release of LAME (3.94, - curently in late alpha stage-) is going to have noticeable speed increases.
If you want to learn more about audio-related stuff, a good and up to date place to start is here:
http://www.hydrogenaudio.org/index.php?act=ST&f=1&t=4917&and after reading the FAQ the fine people at hydrogenaudio will be happy to help you out.
On MJ/MCA way of easily improving speed in MJ/MC would be to allow for parallelized ripping/encoding, as previously discussed and many times requested:
http://www.musicex.com/cgi-bin/yabb/YaBB.cgi?board=beta;action=display;num=1038804011and
http://peakin.com/music/rip_comparison.html (RemyJ's test?)
This is especially true for older CPU (like my PIII-700), as ripping is much faster in my case (6x in secure mode) than the encoding process (1,5x on average using alt-preset standard). At the fastest setting (rip and encode) my drive makes very long pauses waiting for the CPU to encode after a song is ripped, and in turn my CPU will then wait for the drive to rip before encoding. If MC/MJ could have the encoding and the ripping work simultaneously, the overall speed would be faster by just eliminating delays. The lack of such feature is the only thing that prevents me from abandoning Exact Audio Copy for most of my ripping needs.