FYI, I’ve just added a class called LAMEEncoderAudioFormat, which lets you use an external lame executable to easily create mp3s via an AudioFormatWriter… Since I’m going to use this code for tracktion’s mp3 exporting, I’d appreciate any feedback about it!

Hi !

Did you finally use it for tracktion ? I've got a problem with that class. The files it generates have a lot of distortion. If I replace LAMEEncoderAudioFormat by WavAudioFormat everything works fine without any other change in my code. 


I traced inside the code of JUCE and the only difference I found is that, in

 bool AudioFormatWriter::writeFromFloatArrays

isFloatingPoint() is true with WavAudioFormat and false with LAMEEncoderAudioFormat

Yes, we do use it in Tracktion, but haven't had any problems. Can you suggest some test code that reproduces the issue?

@jules Why was this route chosen instead of integrating its code like the other formats, or even statically linking LAME?

I’m assuming it’s because of the same risk as mentioned in your MP3AudioFormat's disclaimer, but would rather hear it from you.

Edit: Was curious so looked it up; FL Studio embeds LAME.

@jrlanglois Have you already seen this thread?

An annual minimal royalty of USD 15’000…
if the information on still holds true.

I assume a viable option without adding a burden to the customer would be to use the codec provided by the OS, where the royalties get payed by MS and Apple. Not an option on Linux though.

Absolutely. Did as much research as I could before coming this way…

So, my question was really; why do we have to set up access to an external executable when the LAME library’s source code is available, or when we can statically or dynamically link to LAME?

The nuisance here is having to get the user to provide a proper executable and path. FL Studio appears to not require this at all, and they claim to use LAME for encoding MP3s.

It’s funny because I just found out that the large majority of their patents have expired (relatively easy Google-fu…). This makes me wonder how legally valid any of this really is… (probably too much of a pain in the arse to find out, mind you).

Hi Joël,

I think this is more a question for the lawyers than the devs… How exposed are you to a lawsuit or Cease & Desist from Fraünhoffer if you include the LAME code in your executable or included in your product? I’m sure Jules and ROLI are just playing it safe here. While you may prevail in court against a suite it could tie up your product for years.



1 Like

There are apparently still some valid mp3 patens, but they are about to expire – see


1 Like

Fair enough. I pretty well suspect it’s CYA also. Am mostly prodding to see if the MP3-hell has subsided anymore.

Actually, today appears to be MP3 patent freedom day!

Of course, those of you with lawyers should still talk to them (and they should talk to the licensing group), but this is great news for audio developers worldwide.


I replicated dinaiz’ issue and it appears to be that the LAMEEncoderAudioFormat can’t cope with 32 bit fp output.

To repro this just give LAMEEncoderAudioFormat::createWriterFor a bitDepth of 32 and look at the temp wav.
I’m using writeFromAudioSampleBuffer to put data into the writer.

writeFromAudioSampleBuffer calls writeFromFloatArrays which calls isFloatingPoint() which returns false because that is calling the method on LAMEEncoderAudioFormat::Writer not the internal wav format writer. From there on it’s pushing ints into a float output.

A potential fix would be to add:
usesFloatingPointData = writer->isFloatingPoint ();
at juce_LAMEEncoderAudioFormat.cpp:49

I’ve not tested the other paths into the LAMEEncoderAudioFormat::Writer

Sorry to resurrect a thread after so long, but if I got here needing an answer, I bet others will too. :slight_smile:

1 Like