Project of the Month, May 2010

LAME is an open source audio encoder designed to create MPEG-1/2 Layer III files (casually known as “MP3 files”)

The LAME name was originally an acronym for “Lame Ain’t an MP3 Encoder,” as it used to be a set of patches that were applied on top of the ISO reference/demonstration encoder. With the release of version 3.82beta, LAME became a full blown encoder that is not a set of patches anymore, but the name was kept.

Its two main strengths are high audio quality, being able to compete with commercial encoders, and portability, as it it able to run over a wide range of operating systems.

Why and how did you get started?

Some of us are involved in the project since 1999. Mark Taylor, which was then the maintainer, created the foundations of LAME v3.xx, allowing us to work together within a community of people who wanted to work together to create a useful piece of software and learn about audio coding. Some of use joined at a latter stage, helping on the audio coding front but also on packaging, autoconf/automake wizardry and on the website, which are also an important part of a successful project.

Rogério Brito’s: I am a late comer to the project. Around 2003, I was interested in encoding a large amount of music files into the MP3 format, but I only knew about some closed-source, binary only programs that were not able to run under PowerPC.

I had been playing with a PowerPC (which is a big-endian architecture and somewhat different from a common x86 chip), then for some time — in particular with Linux on PowerPC running Debian. But then I found that packaging of the project could be improved and, in 2005, I contacted Mark Taylor, offered my patch and he granted me CVS commit access. I also have the rights to post announcements about LAME’s releases to Freshmeat’s system.

Who is the software’s intended audience?

MP3 technology is covered by several patents, which legally restricts us to only release source code of our encoder (but no precompiled, directly usable binaries). Thus, our intended audience is either advanced users able to compile LAME themselves, or third-party developers who need to add MP3 encoding functionality to their own software.

Alexander Leidinger: Ideally the audience are people which are interested to create an MP3 file. Legally (due to software patents), this is restricted to people which additionally are able to use a compiler to build LAME, except people take precompiled LAME binaries from other sites which are not affiliated with the LAME project.

Gabriel Bouvigne: MP3 technology is covered by several patents, as a consequence we only release source code of our encoder. Thus, our intended audience is either advanced users able to compile LAME themselves, or third-party developers who need to add MP3 encoding functionality to their own software.

What are a couple of notable examples of how people are using your software?

Apart from the obvious task of converting music from CD’s to MP3 files so that they can work with MP3 players, LAME is frequently used jointly with some video conversion software to generate files that can be played on many stock, set top boxes for dealing with video, especially when used with MPEG 4 Part-2 (“DivX”) encoders.

What are the system requirements for your software, and what do people need to know about getting it set up and running?

Alexander Leidinger and Rogério Brito: LAME runs on any Unix-like system or on Windows with a floating-point co-processor (= on any normal PC).

Due to a peculiar characteristic of the software that LAME implements (regarding legal matters), the project is not allowed to provide binaries (without paying some money to some companies). As a consequence, people need to know how to use a supported compiler on the OS they use, or in the case of an Unix-like OS they need to know how to use the OS-package-management to install LAME if it is provided by the OS-vendor there. We would like to make it easier for users (providing binaries via SourceForge), but, unfortunately, this would mean to spend potentially large amounts of money per compiled download of LAME to some companies which have some IP regarding MP3, which is not an option.

On Windows, it often comes bundled with some other software which provides a GUI to the features of LAME, or uses LAME implicitly to write MP3 files. On Unix-like systems people use it either from the command line to convert audio files into MP3, or LAME is integrated into some other software similar to Windows. Some systems like Amigas are still supported in our latest release. OS/2 is, perhaps, also still being used.

Gabriel Bouvigne: LAME can be used on any regular computer sold within the last 10 years, running under most Unixes, Windows or OS X (and even older, more exotic operating systems like AmigaOS or OS/2). The only requirement is to have a floating point computation unit, so LAME is not suitable to embedded platforms without any floating point unit.

What gave you an indication that your project was becoming successful?

The amount of other projects using the lame encoder (as a command line program or as a library, since both modes of use are provided).

What has been your biggest surprise?

Alexander Leidinger: That LAME is the project of the month on SF now, after it is already used a lot in 3rd party programs for many years and the interest in the standalone LAME program is in decline.

Gabriel Bouvigne: That some of us are still there pursuing the development for more than 10 years.

What has been your biggest challenge?

Having continued input from the community during all the years is a challenge. Thankfully, some projects (like the listening experiments lead by Hydrogenaudio.org’s regular posters) have helped in many aspects, like the development of the preset-based encodings and fine-tuning.

Rogério Brito It would be really appreciated if some of the external developments could find their way back to our repository (even if in an external branch), like the multithreaded version of the encoder. I tried to contact the people from Technion‘s institute, but my e-mails apparently did not reach them. Also, Sometimes, people have cool projects that even long-time developers don’t know about

Gabriel Bouvigne: Finding some time to work on LAME, and trying to find new people willing
to contribute to our encoder.

Why do you think your project has been so well received?

Because the focus was/is on high quality results from the program and it supports a wide range of platforms.

What advice would you give to a project that’s just starting out?

If you write a library, focus on the main feature, that is, do one thing and one thing well. Let other people,in other projects, build upon it to add bells and whistles over there. As an example, we provide an MP3 encoder library and other people in other projects write GUIs and even decoders.

Where do you see your project going?

With the possibility of the patents on the MP3 technology expiring in a few years, LAME should be usable by many more people (without any royalty concern) as a standard MP3 encoder. This is despite the fact that some more flexible/efficient formats exist, but which may be encumbered by patents and other legal matters.

What’s on your project wish list?

We don’t have one. If we would have to make up one, it would probably be:

· Unit tests

· Code cleanup

· Separation/abstraction of some parts of LAME, so that they are easily pluggable on encoders for other formats of audio, including (whenever applicable) the psychoacoustic parts of LAME and the successful system of presets

· Documentation about the source code

· Documentation about the development, test, and release process

What are you most proud of?

That LAME is now recognized as an high quality MP3 encoder, while all of us are only working on it on our (scarce) spare time.

If you could change something about the project, what would it be?

Perhaps the release management process could be refined.

Rogério Brito: As a more ambitious goal, having documentation (read: “text-book like, accessible to some advanced undergraduates”) of the background technologies and techniques in LAME would be highly desired, since some people view the project as impenetrable from a contributor’s point-of-view.

Gabriel Bouvigne: We initially made the mistake to provide access to developer-centric options within LAME’s interface, and many people choose to use those in all kind of strange and suboptimal ways. Now, we need to keep those available in order to keep backward compatibility of LAME’s interface. I would wish we never provided those options to end users, keeping those only available within debug or beta versions.

How do you coordinate the project?

In general, we coordinate on the LAME mailing list: lame-dev@lists.sf.net.

How many hours a month do you and/or your team devote to the project?

Not enough. 😉

What is your development environment like?

The dev environment is mostly (alphabetic order) FreeBSD, Linux and Windows. The compilers and debuggers are the default compilers/debuggers of the corresponding OS (or Visual C/C++ for Windows).

Regarding the machines, there is no practical special requirement anymore for quite some years, as any cheap PC is powerful enough to handle the compile and test runs of LAME.

Milestones:

How can others contribute?

We don’t have any formality for people willing to join. Just find a place where the code can be improved, and send a comment/patch. If your interests are generic, it would be nice to contact the mailing list instead of a single developer.

Rogério Brito: It would also be nice if some companies that provide static analysis could screen our code(and stop ignoring my e-mails sent over the last two or three years. 🙂 )

We do not have a list of open tasks or a wish list. Right now, the code is being changed to use a different internal representation (in floating point) of the data to be encoded. We need a cleanup of the source code. People doing this would just need to come over to lame-dev@lists.sf.net and provide comments and patches. Knowledge about good (and portable) C code are required here.

This month and for the rest of 2010, we’re highlighting some of our most venerable projects. This month’s Project of the Month is one of about 1,000 that began hosting on SourceForge.net in the site’s first year of existence, beginning in November 1999.

---

More projects of the month