Building an M4B for Audiobookshelf (And Whether You Need One)

Your book sits in Audiobookshelf as forty-one MP3s. It plays fine. But everywhere you read that audiobooks should be one M4B file — so is it worth merging?

Often yes, and AudioBo does the merge in one pass on your Mac: audio in, clean chaptered M4B out. The page below covers when one file really beats forty-one, what the server’s own encoder does, and how to spot a broken merge — they do not announce themselves.

Audiobookshelf does not need M4B

Nothing in Audiobookshelf treats a folder of loose files as a lesser kind of book. It takes whatever audio it finds, in whatever format, and if none of those files brought a chapter list with it, the server writes one — so what you get is navigable whether the book arrived as one file or forty-one.

M4B is the first entry in the server’s own list of supported audio extensions, which currently runs to twenty: m4b, mp3, m4a, flac, opus, ogg, oga, mp4, aac, wma, aiff, aif, wav, webm, webma, mka, awb, caf, mpg, mpeg. Nothing in that list is a second-class citizen.

More to the point: a multi-file book gets chapters anyway. When none of the files carries a chapter table of its own, the scanner walks the audio files in order and makes one chapter per file. The title it uses follows a small, specific rule — the filename with its extension stripped, unless every file in the book has an ID3 title tag, all of those tags are unique, and none of them matches the book title. When all three hold, the ID3 titles win instead.

So 07 - The Sea-chest.mp3 becomes a chapter called 07 - The Sea-chest, and a properly tagged rip becomes a chapter called The Sea-chest. Either way you get a navigable book out of files you never touched.

If Audiobookshelf is where your books live and where they stay, you have your answer — the encoder above is it. Everything below is for the day a book has to leave the server, and for the cases where one file is genuinely better than forty-one.

Four reasons to build one anyway

Three of these are about the book needing to be somewhere the server is not, or about the chapters not falling where the files break. The fourth is a trap you can walk into without noticing.

Offline downloads. Sending a book to your phone as a single file rather than forty-one is the difference you actually feel.

Chapters that are not file boundaries. The scanner can only invent as many chapters as you gave it files, unless they carry OverDrive media markers, which it reads first. A thirty-chapter book that arrived as four two-hour MP3s gets four chapters, and no amount of renaming changes that. Real chapter positions have to be written into the file, from a timestamp list, a CUE sheet, or a lookup.

Somewhere else to be. Apple Books, an iPod, a car stereo, a friend’s laptop. A folder of MP3s is a folder of MP3s everywhere; an M4B is a book. Plex is its own separate problem, and chapters are the part that goes wrong there.

A book whose files each carry one identical chapter. This one is a trap rather than a reason. If the first two files in a book carry chapter lists of the same length, with matching titles and matching start times, the scanner reads that as “every file has the same chapters” and uses the first file’s list alone for the whole book. Files that each embed a single chapter with the same generic name land exactly there. You get a nine-hour book with one chapter in it.

Folder layout is a separate layer that fails on its own schedule — one book per folder, {Author}/{Series}/{Book}, and the rest of it lives in audiobook file naming and folder structure.

The server can build it for you

You do not have to install anything to get the single file. Audiobookshelf will merge the book itself, and for a book whose files were all made the same way it does the job properly and for nothing. What you are choosing on the way through is whether the audio gets re-encoded at all, and how big the result ends up.

Open a book and go to Tools. The panel is headed Audiobook File Management Tools, and one of the cards on it is Make M4B Audiobook File, described honestly as “Generate a .M4B audiobook file with embedded metadata, cover image, and chapters.” The button says Open Manager, not the name of the tool, and it takes you to a page whose tool dropdown is already set to M4B Encoder.

The encoder card has two tabs. Presets gives you three controls and fixed lists of values:

• Codec — Copy, AAC, or OPUS
• Bitrate — 32k, 64k, 128k, or 192k
• Channels — 1 (mono) or 2 (stereo)

Advanced replaces all three with typed-in values and one line of warning: do not update these unless you are familiar with ffmpeg encoding options. That is a fair description of what they are.

The preselection on the Presets tab is derived from your files, and it explains some surprising defaults. Codec is set to Copy when the first file’s codec is AAC and no other file disagrees; otherwise AAC. Bitrate is the average across every track, rounded up to the next value in that list of four. Channels is the highest channel count found anywhere in the book, clamped to 1 or 2.

That last one has a consequence. One stereo intro track in an otherwise mono book pushes the whole export to stereo, and the whole book pays for it.

If you drive the encode through the API instead and omit the options, the server falls back to aac, 128k, and 2 channels whatever the source looks like. I built three ten-second mono MP3s at 64 kbps — 241,500 bytes together — and ran them through those fallbacks with ffmpeg 8.0. Out came about 486 KB. The same three files asked for 64 kbps mono came out at about 247 KB. Roughly twice the size on my sine waves, for a book that is one voice talking.

Picking that number is its own guide, and the short version is 64 kbps mono.

One more thing before you press Start M4B Encode: your originals move. The first track is copied and the rest are moved into the server’s metadata cache, under /metadata/cache/items/ and the library item’s ID — the page prints the exact path — and the finished .m4b takes their place in the book folder. Nothing is deleted, but nothing stays where you left it either. There is an open request on the tracker to make that backup location configurable.

What comes out

What you get is a real audiobook: one file, the chapters inside it, the cover and the tags attached. It plays, it navigates, and Audiobookshelf is perfectly happy with it. Two small things are missing from the file’s header, and they only start to matter when the file goes somewhere the server is not.

The encoder writes an ffmetadata file holding your chapter list, concatenates the audio, then remuxes cover art and metadata in with a stream copy. I reproduced that chain command for command on my three test files and walked the result:

ftyp
mdat                   — the audio
moov
  trak                 — audio track
    tref
      chap             — points at the chapter track
  trak                 — chapter text track
  udta
    meta/ilst          — ©nam ©ART aART ©alb ©too covr trkn
    chpl               — the chapter list, second format

The chapters are in there twice, which is the correct answer — a QuickTime chapter track and a Nero chpl atom, because players disagree about which one to read. ffprobe -show_chapters came back with all three, titles and boundaries intact.

Two things it does not do.

The ftyp brand comes out as isom, not M4B . Audiobookshelf could not care less — it goes by file extension and tags. Apple Books reads that brand, and it is part of how a file lands in the audiobook shelf rather than the music library. And the ilst block holds title, artist, album artist, album, encoder, cover, and track number, with no audiobook media-type flag beside them.

If the server is the only place the file will ever live, neither matters. If the file is also going to a phone, they do.

The other tool on that panel: Embed Metadata

The M4B encoder gets most of the attention, but the same Audiobook File Management Tools panel carries a second card, Embed Metadata, described in the app as “Embed metadata into audio files including cover image and chapters.” It is the tool to reach for when you are keeping your MP3s and only want the tags in the files to match what you fixed in the web interface.

It has one behaviour worth knowing before you run it, and the app states it plainly on the encoding screen: “Chapters are not embedded in multi-track audiobooks.”

That is not a caveat about edge cases. Want to see the rule itself? In the server’s own source, in server/managers/AudioMetadataManager.js, it is one line:

// Only writing chapters for single file audiobooks
const chapters = audioFiles.length == 1 || forceEmbedChapters ? ... : null

A book that is one file gets its chapter list written in. A book that is twelve MP3s gets title, author, series, cover — and no chapters, because a chapter list spanning twelve separate files has nowhere coherent to go. Audiobookshelf itself does not care: it holds the chapters in its own database and plays them correctly regardless. The gap only opens when the file leaves the server, or when something other than Audiobookshelf has to read it.

Two smaller things, both verified in the same file. Regular embedding can back your files up first — the originals are copied into the item’s cache folder before ffmpeg touches anything. Quick Embed skips that, and says so: “Warning! Quick embed will not backup your audio files. Make sure that you have a backup of your audio files.” Quick is genuinely quicker. It is also the one that leaves you nothing to go back to.

Chapters live in the database, not in your files

This is the part that surprises people, and it explains a whole family of confusing symptoms.

Audiobookshelf has a real chapter editor. You can Edit Chapters, Add Multiple Chapters on a numbering pattern, Set chapters from tracks, Map Chapter Titles, run Find Chapters against a lookup, and even Remove Audible intro and outro from chapters. It validates as you go — edit a chapter past the end of the book and it tells you the chapter end is after the end of your audiobook.

All of that edits the library item. None of it, on a multi-file book, reaches the audio.

So chapters that are wrong or out of order inside Audiobookshelf are fixed in Audiobookshelf, and the fix holds for as long as you play the book there. Copy that same folder to a phone, hand it to another app, or rebuild the library from scratch on a new server, and you are back to whatever the files themselves say — which for a folder of MP3s is usually nothing at all.

Two consequences worth planning around:

• The order you see is not always the order that is stored. If the scanner put the files in the wrong sequence, fixing the chapter list does not fix the track order underneath it — what actually decides audiobook chapter order covers where that gets decided.
• Embedding is what makes the work permanent, and for a multi-file book embedding will not carry the chapters. Which leaves exactly two durable options: merge the book into a single file first, or build the chaptered file somewhere else and let the scanner read it.

The failure that is real and current: files that do not match each other

Here is the one to actually worry about, and it is less a bug than a physics problem.

If the files in your book were not all made the same way — one in stereo and one in mono, one recorded at a different quality — the merge can hand you a file of the wrong length and never say a word about it. Half the book gone, or twice the running time for the same amount of audio. The task goes green either way, and you find out when you play it.

The merge feeds every file into ffmpeg’s concat demuxer, which reuses the first file’s stream parameters for everything that follows. When the files agree, that is efficient and correct. When they do not, the results are quiet and wrong.

I made two ten-second files — one 22.05 kHz mono, one 44.1 kHz stereo — and ran the encoder’s exact command over them.

With the Copy codec: a file reporting 40.05 seconds for twenty seconds of audio. The second file’s frames are read at the first file’s rate, so its ten seconds stretch to twenty, and the packet ahead of them is declared ten seconds long to cover the gap.

With AAC: a stream of decoder errors and a finished file of 10.08 seconds. Half the book is gone.

Neither surfaces as a failed task. You get a green checkmark and a broken book — the same fault line joining M4A files by hand runs into, whichever tool invoked the demuxer.

Mixed parameters are not exotic. An open issue on the tracker, filed in March 2026 against v2.33.1, describes M4B files whose chapters change sample rate or channel count going silent after the first chapter in the app and in the browser while playing correctly in VLC. Its author puts the rate at about two percent of that library, and traces the bad files to a batch MP3-to-AAC converter. Same fault line, seen from the playback side.

Check your own files before you merge — and check with the right tool. The Audio Tracks table at the bottom of the manage page (Audiobookshelf v2.33.x as I write this), below the encoder, lists channels, codec, bitrate, and size for every file — which catches the channel mismatch and nothing else. Sample rate is not a column there. For that you need a terminal:

for f in *.mp3; do
  echo "$f: $(ffprobe -v error -show_entries stream=sample_rate,channels \
    -of csv=p=0 "$f")"
done

If they do not all match, do not use the concat demuxer. Use the concat filter, which resamples everything to a common target on the way through:

ffmpeg -i part1.m4a -i part2.m4a \
  -filter_complex "[0:a][1:a]concat=n=2:v=0:a=1[out]" \
  -map "[out]" -ar 44100 -ac 1 -c:a aac -b:a 64k -brand "M4B " out.m4b

The same two files that produced 40 seconds and 10 seconds above came out of this at 20.04 seconds, mono, correct. ffmpeg is not the problem here and never was; the demuxer was the wrong tool for a job nobody told it about.

What AudioBo does that the built-in encoder does not

The built-in encoder is a good tool for a narrow job: uniform source files, a server that is the final destination, chapters that already match file boundaries. It is installed, it costs nothing, and for that job it is the right answer. Use it.

It stops helping at the point where the chapters are not the files. AudioBo is built around that gap. You give it the audio and tell it where the chapters actually fall — from a CUE sheet, a timestamp list, or a metadata lookup — rather than letting however many pieces the book happened to arrive in decide for you. Out comes one file with the chapters, the cover and the description in it, named the way your library expects, and labelled as an audiobook — which is part of how a file lands in an audiobook shelf rather than in a music library.

If you do want the mechanical version: export filename presets, six of them in Settings → Export since 1.2.3 and narrator-based patterns since 1.3.1, mean the exported file lands with the name your scanner expects instead of the name the merge picked. Version 1.2.4 changed how book descriptions are written, for better compatibility with Subler, Mp3tag, and Audiobookshelf. And the export declares the M4B brand in its header, which matters the day the file leaves the server.

The other honest comparison is ffmpeg and m4b-tool against a Mac app, which is the same decision with different tradeoffs. If you already have a working shell script, you already have your answer.

The boundaries from the top of the page hold here too: it builds and repairs the file, cannot make any player draw what it does not support, and does not remove DRM.

Checking the file you got

Whatever built the file — the server, a Mac app, a script of your own — you check it the same way. You want chapters that run from the start of the book to the end, a running time that matches the audio you fed in, and sound at the quality you asked for. The running time is the important one, because that is where a merge of mismatched files gives itself away.

Three commands, and they take longer to read about than to run:

ffprobe -v error -show_chapters -of default=nw=1 book.m4b | head
ffprobe -v error -show_entries format=duration:format_tags=major_brand \
  -of default=nw=1 book.m4b
ffprobe -v error -show_entries stream=codec_name,sample_rate,channels \
  -of default=nw=1 book.m4b

The colon in the second one matters. -show_entries separates sections with colons and entries with commas, so the plausible-looking format=duration,tags=major_brand asks for an entry called tags, finds nothing, and prints the duration alone — no error, no warning. I ran both forms on the same file to be sure. Only the colon form prints the brand.

You are looking for: a chapter list whose first entry starts at zero and whose last ends at the file duration; a duration matching the sum of what you fed in, because that is where the mixed-parameter failure shows itself; an audio stream at the sample rate and channel count you asked for; and, if the file is going anywhere near Apple, major_brand=M4B.

The third command prints the audio stream first, then one or two blocks that look wrong on purpose: codec_name=bin_data, with no sample rate and no channels, is the chapter text track, and codec_name=mjpeg is the cover art. Read the first block and ignore the rest.

xHE-AAC, briefly

One codec is worth naming, because it explains a specific and confusing symptom: a file that plays perfectly well in one app and refuses to make a sound in another.

If a file plays in VLC and not in the web player, the codec is a reasonable suspect, and xHE-AAC is the newest one you are likely to meet. It is an AAC profile, it is very good at low bitrates, and nothing in the usual free toolchain will produce it — ffmpeg 8.0 on my Mac lists two AAC encoders, the built-in one and the macOS AudioToolbox one, and neither exposes that profile as an option. Encoding it is licensed exclusively by Fraunhofer, which AudioBo’s changelog states plainly in the 1.2.9 entry that added xHE-AAC import: such files can have their metadata, chapters, and cover edited in place with no re-encode, but exports come out as standard AAC.

Plain AAC-LC is the safe target, and it is what the server’s own encoder produces whenever you pick AAC. I have not put an xHE-AAC file through the Audiobookshelf web player myself, so treat the codec as the first place to look rather than the answer.