You start an audiobook in Audiobookshelf. Chapter 1 plays fine. At the Chapter 2 boundary the audio just stops. No error in the server logs, no skipped track, the timeline keeps moving. Seek back into Chapter 1 and sound returns. Seek forward and it’s silence again.

This affects a small fraction of M4B files, usually ones that were assembled from mixed source files. The Audiobookshelf logs keep showing [SessionController] Serving audio track 1 for session... because the server thinks everything is fine. It is, from the server’s point of view. The file plays back in VLC without issues, which makes the whole thing look like an ABS bug at first.

It isn’t. The root cause is that the M4B file contains chapters with different channel counts (e.g. Chapter 1 is mono, Chapter 2 onward is stereo) or different sample rates. Browsers and most simple audio players use a single audio decoder initialized with the first chapter’s parameters. When the file switches to a different channel layout or sample rate mid-stream, the decoder keeps running but emits silence. VLC sidesteps this by reinitializing its audio output, which is why it looks fine there.

This reproduces on direct play in the ABS web client (Firefox, Chrome, Chromium-based browsers) and on the Android app. It’s also been reproduced with the Android system media player and Open Source Music Player, which confirms it’s a file-level problem, not an ABS-specific one.

Confirm you’re hitting this bug

Run ffprobe against the file and check if channels or sample rate change between chapters. The easiest way is to list every audio stream segment:

ffprobe -v error -show_entries stream=index,codec_name,channels,sample_rate \
  -of default=noprint_wrappers=1 "yourbook.m4b"

For a properly-built M4B you’ll see one audio stream. To see if the chapters internally vary, probe the packets:

ffprobe -v error -select_streams a -show_packets -show_entries packet=pts_time \
  -of csv "yourbook.m4b" | head

If the file was assembled from inconsistent sources, you’ll see it in the logs when ABS merges or when you look at the source files:

ffprobe -v error -show_entries stream=channels,sample_rate \
  -of default=noprint_wrappers=1 "Chapter 01.mp3"
ffprobe -v error -show_entries stream=channels,sample_rate \
  -of default=noprint_wrappers=1 "Chapter 02.mp3"

If Chapter 1 reports channels=1, sample_rate=22050 and Chapter 2 reports channels=2, sample_rate=44100, you’ve found it.

Fix 1: Re-encode the M4B with uniform parameters

The reliable fix is to re-encode the file so every chapter has matching channels and sample rate. Stereo at 44.1 kHz works everywhere:

ffmpeg -i "bad.m4b" \
  -map 0:a -map 0:v? -map_metadata 0 -map_chapters 0 \
  -ac 2 -ar 44100 \
  -c:a aac -b:a 64k \
  -c:v copy \
  "fixed.m4b"

The -ac 2 -ar 44100 flags force stereo output at 44.1 kHz across the whole file. -map_chapters 0 preserves the chapter markers so Audiobookshelf still sees the chapter structure. -c:v copy keeps the embedded cover art without re-encoding it.

Replace the old file in your library folder, then run a manual scan from the library menu. Playback should work end to end after that.

If you prefer to stay mono (smaller file), use -ac 1 instead of -ac 2. The important thing is that every chapter ends up with the same channel count.

Fix 2: Re-merge the source files with matching parameters

If you still have the original per-chapter MP3s or AACs (from auto-m4b, LibbyRip, or a manual rip), normalize them first, then merge. This avoids a lossy re-encode of an already-encoded M4B.

Normalize every source file to mono at a consistent sample rate:

for f in *.mp3; do
  ffmpeg -i "$f" -ac 1 -ar 44100 -c:a libmp3lame -b:a 64k "normalized/$f"
done

Then merge with m4b-tool or re-run auto-m4b against the normalized folder. The resulting M4B will have a single audio profile across all chapters and will play fine.

Fix 3: Audiobookshelf’s built-in M4B converter

Audiobookshelf has a Tools > Convert to M4B option that merges multiple source files. In testing, users reported it handles channel mismatches correctly (it produces a consistent mono or stereo output), but it fails on sample-rate mismatches. Specifically, if the source files have different sample rates, the converter deletes all but the first file and produces no M4B.

So this works only if your source files differ in channels but share a sample rate. Safer to normalize with ffmpeg first (Fix 2) and then use the ABS converter or m4b-tool on the normalized set.

Fix 4: Keep it as multi-file MP3

If you still have the original per-chapter files and don’t need the single-file format, just point Audiobookshelf at the folder of MP3s instead of the M4B. Each chapter is its own file, each file has its own decoder init, and the browser plays them sequentially without trying to cross a channel boundary mid-stream. Users confirmed this works when the same content as M4B was broken.

The tradeoff is that multi-file audiobooks have their own issue on iOS Safari (background playback stops between tracks). If you’re listening on iPhone, a properly-encoded single M4B is still the better format.

On iPhone, this often plays fine

SoundLeaf uses the iOS AVPlayer stack, which handles mid-stream audio format changes better than browser MediaSource does. In most cases a file that goes silent in the ABS web player will still play correctly in SoundLeaf. That said, some of the weirder mixed-format M4Bs can still trip up AVPlayer on older iOS versions, so if you see the same silence on iPhone, apply one of the fixes above at the source file. The file is the problem, not any particular player.

Affected versions

The issue has been observed on Audiobookshelf v2.33.1. It’s not a regression introduced by any specific version. The bug lives in the browser and mobile OS media stacks, and ABS direct-plays the file without rewriting it. Any version of ABS will surface the same problem because the server is doing the right thing (serving the file exactly as stored). The fix has to happen at the file level.