Reprinted with permission from Ryan Farmer. Also available in Gemini.

THE Monkey’s Audio Codec Becomes Free and Open Source Software.

Beginning with version 10.18, according to the author, the “Monkey’s Audio License Agreement” has changed its language to match the 3-clause BSD license, and is now Free and Open Source Software. (FOSS)

I’ve never recommended using this format, or even told people about it, and the reasons were (roughly):

1. It wasn’t FOSS.



2. We already had FOSS that did the same thing.



3. If more people knew about Monkey’s Audio, they might use it and share files in it, even though it wasn’t FOSS to deal with it fully (just a reverse-engineered codec), and then we’d have to find ways of dealing with it more often. Then the problem would have rebounded onto the FOSS community.

It would be better if a program were never written at all than to have another one that was proprietary, that makes data storage files that don’t follow any standard that can be easily implemented. (This is similar to the Microsoft Office and OOXML problem.)

By not releasing the software under a FOSS license, Monkey’s Audio was more-or-less condemned to be an unpopular choice, considering that FLAC and WavPack were already under FOSS licenses and more established.

In the case of WavPack, even being able to achieve similar maximum compression ratios and actually having more features than Monkey’s Audio, with faster code.

Even on Windows, whose users install all sorts of garbage and don’t care about security, freedom, elegance, or optimization, it wasn’t so straightforward to get software that could deal with the “.APE” files, which you do come across sometimes.

foobar2000 was not directly compatible with it, without an extension that required the user to agree to yet another proprietary software license. Out of the box, foobar2000 didn’t play them and couldn’t even read them out to be transcoded.

I was always unhappy that I had to agree to a license simply to unpack something and convert it over to WavPack.

It’s like running into the occasional RAR file and needing something to handle it so you can turn it into a standard tarball.

At this point, my usage of APE will be to use the FOSS implementation to convert files out of the format. By being difficult for all these years, the author has destroyed any interest I may have had in standardizing on the format.

Technically, the compression ratio of APE at the highest settings is comparable to WavPack Extra High x6, but the speed of the compressor and decompressor with APE is much slower, to the point where even if Android has a codec at some point, it would make a difference to battery life whereas WavPack does not.

I’m a contrarian when it comes to Xiph.org. I use WavPack and Opus.

WavPack is not the Xiph.org codec for lossless files, FLAC is, but WavPack is also under a BSD license and is a much better piece of software. Especially when you need to archive odd file types like DSF/DSD and don’t want to convert them to PCM and resample, which is what you need to do with FLAC.

(Super Audio CD was never meant to be ripped, but there are rips, and WavPack can handle them directly.)

WavPack also compresses PCM 4-5% better than Flac setting 8, and therefore minimizes space in my archive drive.

Both foobar2000 and ffmpeg can work with WavPack, but ffmpeg can’t handle some types, like DSF/DSD because they didn’t use the upstream WavPack code.

ffmpeg is just weird like this sometimes. They strongly prefer their own code even if they sort of half-finish it and walk away so you have to be careful you’re getting the codec you want if you use it.

foobar2000 comes with the official reference software and the encoder pack too. For the encoding, I just clobber the compressor with the 64-bit upstream binary for x86-64 Windows, in my Wine folder. There are a couple of options.

Sadly, the author of WavPack updated to Microsoft’s recent compiler that generates bad, slow, telemetry infested binaries that (also) don’t work on Windows 2000/XP.

So the binaries cross-compiled from Linux using MinGW are the ones I use.

I benchmarked the MSVC 2019 and the MinGW builds and found that the MinGW ones are about 11% faster, possibly because they contain better (and less) binary code.

If MusePack had an upstream that was active, and better Linux support, I would have standardized on this for the lossy side of things. I think it’s a good format, and it avoids all of the really weird artifacts that are difficult to totally eliminate from MDCT codecs.

It’s open source, so someone could always go back and clean code, fix bugs, and improve it, but it doesn’t look like anyone is interested. Which is a shame. In my opinion, it did prove just how unnecessary the entire foray into the frequency domain codecs really was.

I asked for the latest release, SV8 (which enhanced coding efficiency with more efficient Huffman coding and brought faster and more accurate seeking), to be included in Fedora, years ago.

I think SV7 came out in the 2000s and Fedora Linux is bumping it for no change rebuilds every time a release goes out.

With many packages, Fedora not only no longer maintains them, but hasn’t in 5-10 years. If you want to install Netsurf (a Web browser) via RPMs for whatever reason (it’s small), then you’ll be a version behind because of the no change rebuild problems that were already going on before they orphaned parts of GNOME, Bluetooth, the library to manage iPhones, and LibreOffice.

Fedora is collapsing because there’s nobody to invest time in it. IBM won’t pay people to do desktop work now, and they’ve banished the community packagers.

I’m not saying IBM “owes” me software. They don’t. But I wish they could lead, follow, or get out of my way. Since they won’t, I moved to openSUSE.

The Opus codec is what I’ve been using on my phone because it performs quite well at low (~128k) bitrates.

Even Windows 95 has an Opus codec now because a former Nullsoft employee backported one to Winamp 2, which runs on Windows 9x.

Android has one. Windows 10 and 11 come with one, Linux supports it. Maybe it even runs in OS/2 (or at least through Odin with Winamp?).

That covers everything that’s even kind of important and some platforms that aren’t. It’s mainstream.

But AAC is broadly compatible and not a terrible codec either. It’s been around since 1997, it’s just been patent-encumbered and never had a decent FOSS project behind it.

Sure there were a few encoders you could use if you were in a pinch, but they were all terrible. The only ones that had any effort put into them at all were proprietary .

And even among the proprietary ones, there’s widely varying quality. I only plucked fhgaac dlls out of Winamp to put in foobar2000 in Wine (as I blogged about before) to experiment with it. I’d never used it. I would say that it’s worse than Nero but not as bad as FAAC or the ffmpeg “Native” AAC.

FhG worked with Google more recently. Google demanded an “open source” encoder to get it into AOSP, so the result is we have an open source Linux-native encoder now, if your distribution or package source for ffmpeg builds fdkaac. RPM Fusion for Fedora did not.

Turns out, “Packman” for openSUSE does. Also, if you just want to drop something into foobar2000, it has the settings for you and you just need to find an fdkaacenc.exe somewhere, like the “x64” binary for Windows at RareWares.org and drop it into the encoders folder.

Alternatively you could just “anything to anything” it using multiple encoders, using GNU Parallel and ffmpeg.

parallel ffmpeg -i {} -map 0:a -c:a libfdk_aac -vbr 5 {.}.m4a ::: *.flac

In this example, you want the highest Variable Bitrate quality setting of 5. For smaller, lower quality files, you can set it as low as 1. 5 being “about” 192 kbps on average.

It’s not hard to adapt this command for other codecs if you look at the command line and figure out which codecs and filename extensions you want, and what the valid settings are for the target codec.

FLAC to ~128k Opus could be:

parallel ffmpeg -i {} -map 0:a -c:a libopus -b:a 128000 {.}.opus ::: *.flac

After experimenting with both fhgaac and fdkaac, it’s obvious they put more work into the fdkaac and that it has multi-pass encoding which is called “afterburner”, on by default in ffmpeg, which fhgaacenc doesn’t. On a fast PC, multi-pass encoding is desirable. It’s a couple seconds slower over a full album to make sure the encoder is making the optimal decisions along the way.

I really like the results from fdkaac. It’s honestly not THAT much worse than Opus 1.4 at comparable file size settings, and AAC is more widely supported in hardware, like the car stereo, or Apple devices, or the cheap Sandisk players that they don’t put much effort in, that can’t even play Ogg Vorbis anymore.

The main profile that people actually use, Low Complexity AAC, is actually patent-free now and therefore public domain. FhG is a patent troll and you have to watch what you use if they have a claim on it.

Most people are neither using the bitrates withere HE-AAC (High Efficiency) is desirable (at higher bitrates you just destroy the sound quality and reduce compatibility with the files).

Fedora does have an fdkaac package that only makes LC-AAC, but it’s not at all straightforward to use. Given that LC-AAC is harmless now (like MP3, the patents are gone), and there’s an open source coding program, finally, I think this format is now safe to use if you need it.

Years ago I was playing around with Nero AAC for Linux and was not that impressed.

I tried to install iTunes in Wine to grab qaac (QuickTime AAC) and make it work in foobar2000 without iTunes running, but that failed spectacularly, so I’ve never actually been able to encode “Apple” AAC to see if it’s as good as some people say.

Apple’s software is written by a bunch of quacks (which makes it ironic that their AAC is pronounced this way). After all this time, their MP3 decoder still has a more than 20 year old bug where it can’t seek VBR accurately. They’re not actually a software company. They’re a cult.

I doubt I would do anything with AAC at this point.

Although fdkaac was surprisingly good at what it does, and you should use it if you need to encode bitstream compliant AAC without resorting to anything truly weird on your Linux machines, the format was frozen in 1997 and “there have been some improvements”. Opus is still more efficient and I already have a large library of Opus files.

For fdkaac, you simply need more data for it to be competitive with Opus, which defeats the point of trying to save space.

fdkaac is better than using MP3 for sure. Instead of nearly triple the data to be on par with Opus, you only need about 33% more.

Android phones are ditching the SD cards, so instead of “who cares what bitrate it is just use mp3 lulz”, I’m back to trying to squeeze files to the sorts of bitrates we had to use in the 90s to deal with PC hard drives.

(But for the master copies, I use WavPack Extra High x6 because I think David Bryant is just a raging perfectionist who wrote great code and added a lot of features FLAC just doesn’t have.)

I’ve determined that for a given “quality” that sounds really good, indistinguishable from CD audio to me, Opus manages this at 128k vbr, whereas fdkaac needs 192k vbr (setting 5), and LAME MP3’s latest releases tend to need -V0, which can effectively end up around ~224-260 kbps.

All of this just goes to show the evolution of the lossy audio codec, and in the case of MPEG formats, the fact that technology designed by patent trolls will do things that hamper efficiency to get more patents.

In closing, while our resident troll seems to enjoy making fun of my “experiments” in Techrights, and mocked me for mentioning that Monkey’s Audio is Free Software…

It’s always better to have more Free Software than less.

While APE files are rare, you do find them sometimes. APEs in the wild, you know. 🙂

I’d much rather be in a place where instead of using reverse engineered codecs where you read out to FLAC or WavPack and then it doesn’t match AccurateRip’s database anymore, which implies that the Rockbox people didn’t get things right, we can use the upstream code that the author actually poured a lot of effort into.

This argument over whether upstream Monkey’s Audio could even be included raged for a while and then died after no distribution would touch it. I know that the issue came up on at least Gentoo, Ubuntu, Debian, and Fedora, and they all shot it down, and Fedora even put it through legal review and said the old license was unacceptable.

But that was Red Hat before IBM. Now they toss a ton of garbage in there.

Repositories with Microsoft Edge and Google Chrome, non-Free Steam binaries, a proprietary MP4 AVC codec from Cisco. Just all sorts of junk. They selectively care it it’s Free Software.

For distributions who care about the legality and the ethics of what they ship, the new Monkey’s Audio license is fine.

I’m not sure what finally got the author to budge. He spent nearly twenty years with a license that said you could have the source code but it was illegal to distribute your modifications.

The same license also said you had to notify him if you made patches and send them to him.

Then it said that this was “fine to link to” this from a license like the GPL, when it most certainly WAS NOT. So it also encouraged people to violate the GPL license of other software.

The BSD license, you can link to that from anything. I guess he finally must have figured that out.

It’s always so fun to run into people who have no understanding of copyright law but they did sleep at a Holiday Inn Express last night. Isn’t it?

While home users can (somewhat) probably be a little looser with things like copyright law on their bedroom computer if they want to get something that’s under a messy license like the old Monkey’s Audio one, people who ship software can find themselves in a lot of trouble very quickly. It’s a matter of “You don’t go out with an elephant gun to hunt squirrel.” ⬆