Since April 2025, Libation can download many Audible books at higher quality (128 kbps / 44.1 kHz) when the “use widevine DRM” setting is on. Those downloads are still .m4b files, but the audio inside is encoded with xHE-AAC (also called USAC), a newer AAC variant. Drop one into your Audiobookshelf library, run a scan, and the book never appears. No error in the UI, the file just gets skipped.

The scan log shows something like this:

ERROR: [AudioFileScanner] SyntaxError: Expected property name or '}' in JSON at position 2 : "/audiobooks/Author/Book Title/Book Title.m4b"
ERROR: [LibraryItem] Library item not found

And if you run Audiobookshelf’s bundled ffprobe against the file yourself, you get the actual reason:

[aac @ 0x...] Audio object type 42 is not implemented. Update your FFmpeg version to the newest one from Git.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x...] Could not find codec parameters for stream 0 (Audio: aac (mp4a / 0x6134706D), 44100 Hz, 0 channels, fltp, 66 kb/s): unspecified number of channels

“Audio object type 42” is USAC. Audiobookshelf pins its ffmpeg and ffprobe downloads to version 5.1 (hardcoded in BinaryManager.js), and ffmpeg 5.1 predates USAC probing support. When ffprobe can’t parse the stream, it emits garbage instead of the JSON the scanner expects, the JSON parse fails, and the book is silently skipped. This is tracked in issue #4236, and the same failure was reported as far back as issue #1004 in 2022.

Which fix applies depends on how you run the server.

Docker: update your image

If you’re on Docker, you may already be fixed. The official image installs ffmpeg from Alpine’s package repo rather than using the pinned 5.1 binaries (the server skips its binary check entirely when running in Docker), and Alpine now ships ffmpeg 8.0.1. Images built since roughly December 2025 (server v2.32.1 and later) probe xHE-AAC files fine. Users in the issue thread confirmed books scan and direct-play after updating.

docker compose pull && docker compose up -d

If you haven’t set up the server yet, the Docker setup guide covers the full compose file. And if the update itself fails, that’s a different problem.

One caveat: ffmpeg 8 can identify and decode xHE-AAC, but its native USAC decoder isn’t perfect. Direct play (phone apps, most modern devices) is unaffected since the file streams as-is. But playback paths that force the server to transcode, like most desktop browsers, may sound noticeably worse. More on that below.

Bare metal (Windows, Linux, apt/deb): bring your own ffmpeg

Non-Docker installs still hit this on every version, including v2.35.1. Worse, just replacing the ffmpeg binaries doesn’t stick: the server checks for version 5.1 at startup and re-downloads it, overwriting whatever you installed. One user lost a day to exactly this.

The supported way out, documented in the official FAQ, is to point Audiobookshelf at your own binaries and tell it to stop managing them:

# Install a current ffmpeg (8.x) via your package manager or a static build,
# then set these before starting Audiobookshelf:
export FFMPEG_PATH=/usr/bin/ffmpeg
export FFPROBE_PATH=/usr/bin/ffprobe
export SKIP_BINARIES_CHECK=1

For a systemd install, put them in the service override; on Windows, set them as system environment variables before launching the tray app.

Note that SKIP_BINARIES_CHECK=1 makes the paths mandatory. If either FFMPEG_PATH or FFPROBE_PATH is missing, the server logs a fatal error and exits instead of falling back.

If transcoded playback sounds bad: fdk-aac

Stock ffmpeg’s USAC decoder gets you scanning and direct play, but for clean transcoding you need ffmpeg built with the Fraunhofer fdk-aac library, currently the only mature USAC decoder ffmpeg can use. Nobody can ship this prebuilt: fdk-aac’s license is incompatible with ffmpeg’s GPL, so every prebuilt ffmpeg on the internet excludes it. You have to compile it yourself.

Two community recipes from the issue thread:

• dymk’s Dockerfile builds ffmpeg with fdk-aac from source on top of the official Audiobookshelf image. Vito0912’s variant parameterizes the ABS version tag so you can keep updating.
• justcallmelarry’s approach builds the binaries once, then volume-mounts them into the stock image. You keep normal docker compose pull updates, at the cost of rebuilding the binaries if the image’s expected ffmpeg changes.

Both are community workarounds, not official builds. Read the Dockerfiles before running them.

Or sidestep it: turn off Widevine in Libation

If none of that appeals, Libation’s settings have a “use widevine DRM” toggle. Turn it off and Libation downloads plain AAC-LC files that every Audiobookshelf version scans without issues. The tradeoff is quality: books that only offer the high bitrate through the Widevine path fall back to the older 64 kbps encode.

A few users also reported that chapter markers can differ between the Widevine and non-Widevine downloads of the same book. That turned out to be a Libation/Audible quirk, not an Audiobookshelf bug; if your chapters look wrong, use Edit > Chapters > Lookup > Apply Chapters in Audiobookshelf to pull correct ones.

Client playback varies

Once the server scans the files, whether they actually play depends on the client’s decoder. iOS has supported xHE-AAC natively since iOS 13 and Android since 9, so phone apps that direct-play the file (SoundLeaf included, via the system decoder) handle these books fine. Desktop browsers mostly don’t decode xHE-AAC, which is why the browser player falls back to server transcoding and inherits the quality caveat above. In the issue thread, results varied by app: Plappa threw EPIPE errors with these files, ShelfPlayer worked, and the official app had intermittent play/pause issues. If a book scans fine but won’t play in one specific app, the codec is the first thing to suspect.

Affected versions

Every server version that manages its own ffmpeg binaries is affected, since they all pin 5.1. Docker installs are effectively fixed from v2.32.1 onward via the Alpine ffmpeg 8.0.1 base image. Bare-metal installs (Windows tray app, apt/deb, manual Linux) still need the FFMPEG_PATH / FFPROBE_PATH / SKIP_BINARIES_CHECK workaround as of v2.35.1. The maintainers have said they should look at updating the pinned version to ffmpeg 8, but no release does yet.