Whenever new versions of audio codec libraries are released, such as FFmpeg or libFLAC, the updates get picked up by audio player project quickly, usually without much work needed on audio player side. More quickly so if the updates fix CVEs.

There's also the other kind of file format libraries used in foobar2000, that gets much less attention: archive readers.
It's a feature that fewer users care about, also optional on Windows.
However, relevant libraries get more CVE reports as of lately.
Let's look into how it's been handled in foobar2000 so far.

The criteria

A well behaved archive reader should:

• Use unmodified library provided by makers of the format, for easy updating.
• Read from supplied virtual file callback object, not only from physical file.
• Extract to a virtual file callback object, or to a memory buffer (callback preferred to extract large files something else than contiguous memory block).
• Allow unwanted archive records to be skipped - when we want a single music file from an archive, the rest should be untouched if possible (not possible with solid compression).
• Bonus: allow store mode records to be read transparently, as byte range of whole archive, to open contents of Bandcamp zips with no delay.

ZIP

zlib/minizip was once used. Eventually minizip part was rewritten in C++.

• Use unmodified library: NO
• Read from virtual file: YES
• Extract to memory buffer: YES
• Extract to virtual file: YES
• Extract only parts we want: YES
• Transparent store-mode records: YES

All good because file manipulation is done by own C++ code written specifically to fit requirements.

RAR

This is where the real fun starts. foobar2000 uses modified version of UnRAR code. The essential changes are:

• Only extract to memory / virtual file, never write any files (actual file write functions removed or changed to no-op).
• Added transparent store-mode reads.

Because of these changes, UnRAR code can't be updated automatically, needs manual applying of changes each time.

Additionally, UnRAR can't read from file callbacks, only from plain files. RAR archives on network shares using foobar2000's own readers must be downloaded entirely before they can be handed to UnRAR.

The score:

• Use unmodified library: NO
• Read from virtual file: NO
• Extract to memory buffer: YES
• Extract to virtual file: YES
• Extract only parts we want: YES
• Transparent store-mode records: YES

What if unmodified UnRAR.dll was used instead?

foobar2000 can use unmodified UnRAR.dll with a compile-time switch, but it drops the score a lot:

• Use unmodified library: YES
• Read from virtual file: NO
• Extract to memory buffer: NO
• Extract to virtual file: NO
• Extract only parts we want: YES
• Transparent store-mode records: NO

Going this route would cause all your archives to be extracted to temporary files while looking for music / adding to playlist / indexing library, which is not really an option.
Edit 2026-06-29
Technically, UnRAR's PROCESSDATAPROC does allow extraction to memory, but it lacks mechanism to pass instance data. I chose to mod UnRAR code to do this properly (turned PROCESSDATAPROC definition into std::function<>) over hacking my code to go around this limitation.

7-Zip

Built-in support was added late (2020).
Multiple interfaces exist (C, C++) with different limitations. C++ interface isn't stable - frontend written in 2020 required various changes to build against current library.
Original 7-Zip code didn't compile for non-Windows at the time foobar2000 support was introduced, "p7zip" with C interface had to be used instead.
By now (2026) it looks like mainline 7-Zip source can be used on all platforms.
7-Zip C++ code uses static C++ objects to register optional functionality such as handlers for different compression schemes. It's a very interesting technique, also used heavily in foobar2000 itself. A downside of this is that relevant code can't be linked as a static library - must be included directly in EXE/DLL that uses it.

The score:

• Use unmodified library: YES (yay!)
• Read from virtual file: YES
• Extract to memory buffer: YES
• Extract to virtual file: YES (C++ frontend), NO (C frontend)
• Extract only parts we want: YES
• Transparent store-mode records: NO

As of latest foobar2000, C++ frontend is used on Windows, C frontend on other platforms. Lack of virtual file extraction bothered mainly 32-bit Windows foobar2000 users, I haven't received any complaints about this on other platforms.

Why no libarchive?

Libarchive wasn't yet available when ZIP and RAR support was originally implemented (mid 2000s); after that there wasn't enough of a reason to switch libraries.
At least the interface looks like it handles our checklist well, except for transparent store-mode handling.