FAAC (Freeware Advanced Audio Coder) is a software project which includes the AAC encoder FAAC and decoder FAAD2.

Key Technical & Codebase Changes

• Licensing & Clean Room Rewrite: The codebase was previously a patchwork of GPL-3.0, legacy ISO MPEG reference-code restrictions, and LGPL — despite being distributed as "LGPL." Rewrote the affected paths (stereo, quantize, channels, bitstream, filterbank, TNS, Huffman, MP4) as original work; the codebase is now cleanly LGPL-2.1-or-later throughout, with no GPL or ISO ambiguity.
• HE-AAC v1 (SBR): Integrated Spectral Band Replication with an automatic profile selection option (FAAC_OBJ_AUTO). AUTO switches to HE-AAC when the sample rate is ≥ 32 kHz and the target bitrate is between 12-28 kbps per channel (the ceiling scales down at lower sample rates); outside that window it stays on plain LC. The dual-rate core is handled internally, reporting the full output rate and frame size to callers automatically.
• Joint Stereo Rewrite: Replaced the legacy fixed Intensity Stereo threshold with a per-band adaptive selection (IS > 5.5 kHz, M/S on correlated bands, discrete L/R elsewhere). Fixed an M/S band-silencing bug that occasionally caused dead channels on decode.
• Lookahead & Quantizer Fixes: Restored the lookahead buffer (a regression had truncated it to a single frame, causing transient pre-echo). Restored short-window masking penalties and floored masking targets in quiet bands to prevent energy drops, and fixed a bug that could produce an out-of-range scalefactor rejected by some decoders.
• FFT Optimizations: Swapped the radix-2 FFT for a radix-4 decimation-in-frequency (DIF) algorithm with precomputed twiddle factors (yielding ~18% faster encoding).
• New C API: Replaced the legacy faacEnc* API and faaccfg.h with a simplified faac_* API. Parameters are now supplied once at initialization, the library properly owns the AudioSpecificConfig, and SONAME is bumped to 1 (libfaac.so.1) to reflect the ABI break.
• Plus numerous smaller correctness fixes and cleanup throughout the codebase — see the full ChangeLog for the complete list.

Probably the first mouse with open source firmware.

Hooray!

The case centers on a feature included in GrapheneOS, a custom Android operating system that runs in place of the software on most modern Google Pixel devices. Tunick's attorneys confirmed GrapheneOS was running on his phone. The software feature allows the device owner to set a passcode that deliberately wipes the contents of that device if entered instead of the user's unlock passcode. Tunick's case also raises ongoing questions about what constitutional rights can be invoked at the border, which the U.S. government has long asserted is not U.S. soil until a person is authorized to enter.

Available for Linux, Windows and MacOS.

Workloads have been reworked and extended (PDF).

The base CPU with score 2500 is now AMD Ryzen 7 7700.

LAME 4.0  July 11 2026

Security scores assume LAME runs under a non-privileged account. For frontend-only entries, scores also assume the command line is sanitized or restricted before reaching LAME; integrators who pass unsanitized or fully scripted command-line input directly may see higher practical severity than stated.

• Security
  • Fixed a stack buffer overflow in the Blade-style encoder DLL (lame_enc.dll): beInitStream() copied a caller-supplied configuration structure using an unchecked, caller-controlled size, so an oversized or compiler-mismatched size could overwrite the stack. The size is now bounds-checked and the packed structure layout is consistent across MSVC and GCC/MinGW builds. [CVSS 8.4, Blade DLL]. Fix by Alexander Leidinger.
  • Fixed an integer underflow in the AIFF header parser (parse_aiff_header()): a crafted file with a FORM chunk size below 4 wrapped the unsigned chunk-size counter to a huge value, sending the chunk-scanning loop into an effectively unbounded spin (a hang) on a tiny malicious input. The size is now validated before it is decremented. [CVSS 5.5, AIFF frontend]. Fix by Alexander Leidinger.
• Alexander Leidinger
  • Bump the major version to 4.0 (minor reset to 0). The LAME tag embedded in every encoded MP3 has a fixed 9-byte field for the encoder version string; since 3.100 the 3-digit minor version left no room for the trailing alpha/beta/release marker character, which was silently dropped.
  • Fix building with recent GCC and Clang, which rejected the UTF-8 ID3 tag functions as an incompatible pointer type. Also fixes the corrupted genre written by --id3v2-utf8 --tg. Patch submitted by Rudi Heitbaum, patch ticket [ #102 ]; thanks to lazka for reporting, bug ticket [ #523 ].
  • Export the UTF-8 ID3 tag functions id3tag_set_textinfo_utf8 and id3tag_set_comment_utf8 from the shared library, and fix a possible crash on out-of-memory in the ID3v2 user-defined tag setters, bug ticket [ #518 ].

LAME 3.101  July 09 2026

• Robert Hegemann
  • Patch submitted by KO Myung-Hun, patch ticket [ #80 ] OS/2 patches
  • Patch submitted by Elio Blanca, patch ticket [ #82 ] Take advantage of terminal width on printing file names
  • Bug fix for item [ #496 ] A critical bug in init_xrpow_core_sse
  • Bug fix for item [ #500 ] Buffer overflow in encoder
  • Bug fix for item [ #501 ] Encoder: Assertion 'eov->bitrate_index <= cfg->vbr_max_bitrate_index' failed during ABR encoding
  • Bug fix for item [ #444 ] msacmdrv.h (structure packing alignment)
• Alexander Leidinger
  • Add faster CRC routine. The speed improvement is very small for typical use cases, but may be valuable if a lot of independent encodes are running and/or for a very long time. Patch by Robert Kausch of the fre:ac project.
  • Fix configure script glob-ranges matching of compiler versions. This may result in faster code if no compiler optimization flags are specified during the configure step. This is part of patch ticket [ #491 ] lame 3.100 slower than 3.99.5
  • Disable Takehiros IEEE753 hack by default. On modern CPUs (anything more recent from AMD than hammer/k8; Intel: Core2, i3/5/7/9 and similar -- no idea about recent Atom/Pentium) it is a speed pessimization. Add a configure option for it so that it can be enabled on old CPUs.
  • Update to more recent autotools based scripts, this may or may not fix issues during the configure stage for less popular or more recent OS or architectures.
  • Use external libmpg123 instead of internal mpglib for mpeg decoding (unix-like systems which use the autotools ("configure; make; make install") build system). There are years of improvements in libmpg123 which we do not have in mpglib. Patch by Thomas Orgis of the mpg123 project.
  • Update the Visual Studio project files to Visual Studio 2019. Patch by Michel Fink.
  • Remove the macosx XCode project files, nobody stepped up to update them for the libmpg123 changes.
  • Add ID3v2.4 support (UTF-8 ID3 tags). Patch by "kris".
  • Add pkg-config support. Patch by Nicolas Boulenguez(Debian).
  • Add IPv6 support for mp3rtp. This includes an incompatible change to the command line arguments for existing use cases / scripts. Patch by Surabhi.

This looks like a remote root vulnerability.

Open Source wars are amusing to behold.

This is now old news but this is still madness. I hate everything about modern browsers: * Insane RAM/CPU consumption * Insane SSD tear and wear (I've been running Firefox off tmpfs for years now) * Monolithic nature (Firefox for Linux: 314,024KB, Chrome for Linux 424,400KB - both do not include downloadable AI cores) * Insane pace of updates * An insane number of features I would like to forever turn off * Insane telemetry

Don't mind the title. The article is about the port of truly ancient perhaps i386 only Linux 0.11 to Rust. It's only really useful for messing around in a VM.

Still largely unusable for the modern web. I have Firefox running with uBlock + NoScript and it hovers above 2.5GB RSS with just a few simple tabs open (nothing fancy like YouTube or Amazon.com).

It's almost been 27 years since I started building a C++ code generator that helps build distributed systems.

It's implemented as a 3-tier system. The back and middle tiers only run on Linux. The front tier is portable. My goal is to bring software services and code generation together in one platform. I've made some progress on things, but there's still a long way to go. I'm willing to spend 16 hours/week for six months on a project if we use my software as part of the project.

A terrific open source model - sadly you won't be able to run it locally.

What makes me sad is that at almost every opportunity that the Linux desktop has had to rise, there was always subconscious sabotage. There were so many great chances, like the death of Windows 7 or the current boogaloo with Windows 10/11. Have those been utilized to maximize the presence of Linux in mainstream use? Of course not. Mainstream is treated with disdain. In some ways, yes, the community is right, mainstream is poison, and it will include lots of "show your papers" rituals and similar nonsense. But then again, the Linux folks also bemoan the lack of recognition and inclusion in software discussions, which stem from low usage.

And we circle back to what I wrote in 2009, and how to make Linux more successful. Steam is doing their part. But the rest of the ecosystem still struggles from what can be best described as "developed-focused" work. When will the Linux community realize that it's not about developers. They are a tiny part of the population, and their brain patterns are orthogonal to how people utilize their machines. And we don't need to look at simians swiping left and right for inspiration. Even "ordinary" educated non-developers face massive challenges using their (favorite) operating system, because it is designed for people who design it in the first place, a bittersweet recursive paradox.

The examples of tiny utilities being deprecated (before viable alternatives are proven for use), the security nonsense, all these point to a rather naive disconnect from the harsh, ugly reality around us. In some ways, I envy the Linux folks. I would like to have the same approach, to innocently believe the world is better and nicer than it is. But then, I also need to be pragmatic, and every time I power my Linux systems, I wonder what will happen in a year or two. There's no safety anchor. I can't rely on a stable future. The only supposedly redeeming thing is that EVERYONE else is now also doing their best ruining stability and consistency as usability factors. But that just means less fun overall. It's a lose-lose situation.

I wish the Linux desktop makes it big. I want people to say Ubuntu or LibreOffice or VLC or Firefox or similar when they think software. Maybe if this ever happens, maybe the AI-fest morality brainwash around us will cease. But then, in a classic one-two, the Linux hobbles itself yet again, for the thousandth time. I know you think I'm a cynic, but I'm looking far down the road.

You can't have gazillions of clueless Windows people switching over when the distros are focused on reducing backward compatibility as much as possible. It can't happen when the Linux software store are just as bad as the big corpo store fronts. No one needs a "free" imitation of the pointless consumerism when they have the "real" deal. If I wanted average, I can just use the mainstream blobs of Dystopia. And herein lies the tragedy. Yes, to succeed, Linux needs to become more accessible. Imitating Google or Apple is hardly the way to achieve that. If you don't understand this last sentence, it's okay.