Since the latest alpha shows no news on the matter, I wanted to make a sole topic for it. Rendering speeds for a single 24bit 44.1KHz wav without any processing: As we can see, mp3 encoding speeds are terrible. I would render most of my mixes to mp3, but because of the speed I have to render first to wav, and then use an external program to convert to mp3. Workaround like this is not Reaper-like at all. It would ease my mind to atleast hear why is this. Why is the mp3 encoding so slow on OS X? Is it ever going to change?

I take it you downloaded and installed a version of LAME? Which version?

At least 3.98 is available here:

Many thanks, but... Please forgive me for asking a dumb, newbie, non-coder, uninformed user question. As far as I can tell, in order for Reaper OS X to render to mp3, it requires a file called libmp3lame.dylib All I know is what I read. When this file is not present, Reaper gives me an error that says, unsurprisingly, "Error: I need libmp3lame.dylib to encode mp3!" The file "Lame 3.98 for OS X" from Rarewares is a dmg that contains two files. One is the GNU license. The other is a UNIX executable called "lame". It does not contain libmp3lame.dylib. So, maybe the executable is an installer....when I run it, I get this, in the terminal window: ================================================== =================== Last login: Mon Mar 16 10:07:52 on console /Volumes/lame/lame ; exit; Andys-MacBook-Pro-15:~ andy$ /Volumes/lame/lame ; exit; LAME 32bits version 3.98 () usage: /Volumes/lame/lame [options] <infile> [outfile] <infile> and/or <outfile> can be "-", which means stdin/stdout. Try: "/Volumes/lame/lame --help" for general usage information or: "/Volumes/lame/lame --preset help" for information on suggested predefined settings or: "/Volumes/lame/lame --longhelp" or "/Volumes/lame/lame -?" for a complete options list logout [Process completed] ================================================== =================== Not being a UNIX guy (<McCoy>"I'm a musician, not a computer programmer!"</McCoy>), I don't really know what I'm looking at. It actually looks to me as if this is a standalone encoder program, not an installer for the .dylib needed to encode from inside Reaper. I do know that I can find no new file called libmp3lame.dylib anywhere on my system. I've got standalone encoder programs. The objective here is to find the latest version of libmp3lame.dylib so we don't have to first render to WAV first and then convert just to get reasonable speed. What am I doing wrong? I don't know what I don't know..... Many thanks!

By the way... I also downloaded the file "Lame 3.98.2 from the same place and it contains lame_enc.dll, not libmp3lame.dylib.

Never used a Mac :) Maybe the one from has the right file in it?

Ah. That explains it. I assumed since you were posting in the OS X forum you were intimately familiar with the platform and how it differs. I did download that one labeled for Audacity and it gives a file date of December 2008. I tried rendering the Reaper demo project and.... .... the speed still isn't very good. I was getting 1.3 to 1.4 x real time. Better, but certainly not anything to write home about. Oh, well. Just live with it, I guess. Since this is an open-source component, I really don't see how the fault can lie with Reaper OSX itself. All it can do is pass data to LAME for processing. Still, it sucks to have the performance SO much worse than it is on Windows.

I believe my dylib is 3.97, since it is dated March 26. 2007. I wasn't able to find or compile the dylib from the OS X package here: Adouglas, would it be possible for you to share your Dec. 2008 libmp3lame.dylib? Even that tiny speed increase would be very wellcome.

Thanks. I think my max bitrate is set higher than that, so I'll try bringing it down. My projects sound similar to yours. I'm running 10 tracks of plain audio, one take each, no MIDI. I've got a handful of plugins on each track (no more than two or three), plus Ozone on the master. Ozone is doing a lot, and it's doing it in 64-bit, so I'll probably not get your speeds. I'd made the same assumption about VBR vs. CBR and had just never gotten around to trying out VBR. Too many things to tweak...you could spend your life in trial-and-error experiments!