Why do my chapters show up in one app but not another?

Almost always because the chapters are stored only as a Nero chpl list. ffmpeg and mp4v2 both read that list; Apple's AVFoundation does not. I tested a chpl-only file against AVFoundation and it reported zero chapters — the data is in the file, but Apple's framework never looks there. A remux that also writes the QuickTime chapter track fixes it without touching the audio.

Can I add chapters to an M4B without re-encoding it?

Yes. Chapters live in the container's metadata, not in the audio stream, so rewriting them is a remux. I confirmed this by rewriting the chapter list on a test file and comparing the audio stream MD5 before and after — identical. Any tool that copies the audio stream instead of encoding it will finish in seconds and lose nothing.

Does ffprobe showing chapters mean my player will show them?

No, and this is the trap. ffprobe reads both the QuickTime chapter track and the Nero chpl list, and prints them the same way either time. A file can pass the ffprobe test and still look chapterless in an Apple app. To see which kind you actually have, use mp4chaps --list --chapter-any, which names the format it found.

My M4B has exactly one chapter covering the whole book. What happened?

A single chapter spanning the full duration is what you get when a tool creates one chapter per source file and there was only one source file. It is technically valid — AVFoundation reports one chapter — but it gives you nothing to navigate. You need a real chapter list from a timestamp file, an online source, or your original per-chapter files.

My chapters vanished the moment I merged the parts. Why?

Because the merge tool treated the files as audio streams and nothing else. I joined two chaptered M4B files with ffmpeg's concat demuxer and a plain stream copy, and the output had zero chapters — not merged chapters, not the first file's chapters, none. Chapter tables are container metadata, not streams, so a concat-and-copy drops them entirely.

M4B With No Chapters: File or Player?

You have an .m4b. It plays. The audio is fine, the length is right, and there is a scrubber bar with nothing on it — one flat ten-hour line and no way to jump to Chapter 12.

Two different problems look exactly like this: either the file has no chapters at all, or it has them in a form your player does not read. The fix for one does nothing for the other. Ten seconds of testing tells you which.

If the book is one you can rebuild, AudioBo writes both kinds of chapter list into every file it makes — the version of this problem that never starts. For the file you have now: below is how to tell the two kinds apart, how to turn one into the other without touching the audio, and what to do when there is truly nothing there.

The short version

Either the chapters were never put into the book, or they are in there in a form your player does not read. From the outside the two look identical: a flat bar and nothing to jump to. The repairs are opposite, so the first job is telling them apart, and that takes about ten seconds.

The second case is the one that catches people out. There are two different ways of writing a chapter list into an audiobook, and Apple's apps read only one of them. So a book can be complete, correct, and list every chapter it has in one app, while an Apple app shows you nothing at all. Nothing is damaged and nothing is missing — the app is looking in the place your file did not use.

Either way, the sound itself is never the problem and never has to be redone. The chapter list sits beside the audio rather than inside it, so putting it right is seconds of work rather than an evening of re-converting.

Would rather the chapters simply worked? AudioBo writes both kinds of chapter list into every book it makes, so the same file reads correctly whichever app you open it in. It will also write chapters into a book you already have without touching the audio — and if there are none to write, it can go and look a list up, then check it against your actual recording before you keep it.

It builds and repairs the file. It cannot make a player show something that player does not support, and it does not remove DRM — a protected Audible or iTunes Store download is a different problem, and the last section on this page says so plainly.

The ten-second test

All you are doing here is asking whether there is a chapter list inside the file at all. You are not fixing anything yet — you are finding out which of the two problems you have, because they take opposite repairs.

There is a version of this that needs no terminal. Open the file in every player you own: if any one of them lists chapters, the data is in the file and you have the second problem — the player, not the book.

Want the definitive answer? If you have ffmpeg installed, point ffprobe at the file:

ffprobe -hide_banner yourbook.m4b

Somewhere in the output you get either nothing about chapters at all, or a block like this:

  Chapters:
    Chapter #0:0: start 0.000000, end 120.000000
      Metadata:
        title           : Chapter One
    Chapter #0:1: start 120.000000, end 360.000000
      Metadata:
        title           : Chapter Two

No chapter block means the data is not in the file. Skip to when the chapters really aren’t there.

A chapter block means the data is in the file, your player is not showing it, and you have the more interesting problem.

Chapters can be present and still invisible

There are two different ways to write a chapter list into an audiobook, and a program that reads one of them does not necessarily read the other. Neither way is wrong. Both are ordinary, and plenty of perfectly good books carry only one of the two.

So a file can be complete and full of chapters and still open as one flat line, because the app you opened it in only knows how to look in the other place. That is not damage, and there is nothing in it to repair. What it needs is a second copy of the same list, written where that app looks.

MPEG-4 files can store chapters two different ways, and the two are not interchangeable.

QuickTime chapters are an actual second track in the file — a text track carrying the titles, with the audio track pointing at it through a tref/chap reference. This is Apple’s own mechanism, and it is structural: the chapters are part of the file’s track layout.

Nero chapters are a flat list in a single chpl atom tucked inside udta, next to the tags. No track, no reference. A table of start times and titles, and that is all.

Both are legal. Both are common. They behave completely differently.

I built one M4B carrying only QuickTime chapters and one carrying only the Nero list — same audio, same three chapters — and read both with AVFoundation, the media framework macOS gives apps for reading audio files. On macOS 26.6:

File	ffprobe	mp4v2	AVFoundation
QuickTime `chap` only	3 chapters	3 chapters	3 chapters
Nero `chpl` only	3 chapters	3 chapters	no chapters at all

Not “chapters with missing titles”. Not “chapters in the wrong place”. availableChapterLocales came back as an empty list — as far as Apple’s framework is concerned, that file has no chapter data whatsoever.

So when someone tells you their audiobook shows chapters in one app and nothing in another, that is not a bug and not a cache. That is a chpl-only file meeting a reader that only looks for the QuickTime track. Anything reading the file through AVFoundation lands in the second group — that is the framework result above, not a guess. The bytes are right there. Nobody is reading them.

The practical consequence, and the reason the ten-second test needs a footnote: ffprobe agreeing that chapters exist does not mean your player will find them. ffprobe reads both formats and prints them identically. It cannot distinguish the working case from the broken one.

Want to know which kind your own file carries? mp4chaps from mp4v2 will name the format:

mp4chaps --list --chapter-any yourbook.m4b

It prints either QuickTime Chapters of "yourbook.m4b" or Nero Chapters of "yourbook.m4b" before the list. That one word is your diagnosis.

Fixing a file that carries the wrong kind

Nothing in this repair goes near your audio. The sound is copied across exactly as it is, and only the chapter list is rewritten — into the form the app you are using does look for. On a full-length book that is seconds of work, and what comes out is the same recording that went in.

If you have Nero-only chapters, you need a copy of the file that also carries the QuickTime track. The audio does not need to be touched, because chapters live in the container, not in the audio stream.

Want to do it yourself, for free? It is a single remux:

ffmpeg -i yourbook.m4b -c copy -map_chapters 0 -brand "M4B " -metadata media_type=2 -f mp4 fixed.m4b

ffmpeg reads the Nero list on the way in and writes both formats on the way out. I ran this on the chpl-only test file and re-read the result with AVFoundation: three chapters, correct titles, correct timings. Hashing the audio stream before and after gave the same MD5 — nothing was re-encoded, nothing was lost. It is a stream copy, so on a full-length book the ceiling is your disk rather than your CPU.

mp4chaps does the same job in place:

mp4chaps --convert --chapter-qt yourbook.m4b

Both work. ffmpeg gets the respect here — it is doing real work, correctly, for free, and if this is your only broken file you should use it and stop reading.

The -brand "M4B " in the ffmpeg line is not decoration. Leave it off and the output declares itself isom even with the .m4b extension on the filename; I checked the header both ways, ftypisom without the flag and ftypM4B with it, chapters intact either way. The -metadata media_type=2 beside it sets the audiobook flag — the thing that keeps a freshly fixed file on the book shelf instead of in the music library. mp4chaps works in place and leaves whatever brand and flags the file already had. Whether the brand matters to you depends on the app you are feeding it to — that is the subject of what an M4B file actually is, not this page.

When the chapters really aren’t there

This is the other half of the split, and it is a different kind of job. There is nothing in the file to convert, so no amount of rewriting the container will produce chapters — something has to author a list that has never existed, using information from outside the file.

If ffprobe printed nothing, no amount of remuxing will help. Something has to write chapters that do not yet exist. Three causes account for nearly all of these.

It is an M4A wearing a different extension. I copied a plain .m4a to .m4b and checked it: brand still M4A, zero chapters, invisible to AVFoundation. Renaming changes the filename and nothing else. Books also has opinions about this that go beyond chapters — that failure mode has its own page.

It was merged with a tool that drops chapters. This one is worth demonstrating because it bites people who did everything else right. Take two chaptered M4B files, join them with ffmpeg’s concat demuxer and a straight stream copy, and the output has zero chapters. Not merged chapters. Not the first file’s chapters. None. The concat demuxer is stitching audio streams; chapter tables are not streams, so they fall on the floor. If your book lost its chapters at the moment you combined the parts, this is why.

It never had any. A single-file download, a rip exported as one long track, a YouTube grab. There is nothing to recover; there is only something to author.

Getting chapters into a file that has none

A chapter list is not a clever thing. It is a set of titles and the times they begin at, and that information is not in your file — if it were, you would not be here. So it has to come from somewhere else, and for most books it already exists somewhere: in something you already have, in the published record of the book, or in the files you built it from.

You need three things: a list of titles, a list of start times, and a tool that writes both into the container. There are three realistic sources for the first two.

Timestamps you already have. A YouTube description, a CUE sheet from a CD rip, notes you took while listening. A plain text file of 0:00 Introduction lines is enough — the sidecar timestamp format is covered here, and AudioBo has read those files since version 1.2.1, along with CUE sheets.

The internet’s copy of the book. If the book was published commercially, someone already has its chapter list. AudioBo’s Fetch Metadata, added in 1.2.3, searches Audible, Apple Books, MusicBrainz, and Google Books; Audible is the one that carries chapter titles and timing. The full walkthrough is on the blog.

Fetched chapter data is the part worth being suspicious of, because a chapter list from a different edition will line up with nothing. Since 1.3.2, AudioBo checks how well the found chapters match your actual audio and tells you specifically what is off — same length but split differently, a different edition, extra audio at the start — then lets you preview them by ear and apply anyway if they sound right. That check is the difference between recovering chapters and decorating a file with plausible nonsense.

Your original files. If you still have the per-chapter MP3s, the file boundaries are the chapter boundaries, and rebuilding from them is more reliable than repairing the merged result. That is the conversion workflow, not a repair job.

One chapter, and it is the whole book

This is the version that looks like success from a distance. There is a chapter list — it just has one entry in it, running from the first second to the last, which gives you nothing to jump to.

A file with a single chapter spanning the full duration is technically valid — I built one, and AVFoundation dutifully reported one chapter titled Track 01. It is also useless, and it almost always means the same thing: the tool wrote one chapter per source file, and you gave it one source file.

That leaves you in the no-chapters case with a decorative marker at 0:00 for company. You need a real chapter list, from one of the three sources above.

What AudioBo does about chapters that do not show up

Everything above works, and for one broken book it is the right amount of effort. What none of it can do is tell you whether the chapter list you are writing actually belongs to your audio — timestamps from a different edition decorate a file with plausible nonsense, and no probe hears that.

Where a dedicated app earns its place is that check, and the boring middle: getting it right on every book, so you never have to know which of the two chapter formats the app on the other end is going to look for.

AudioBo writes both of them into every book it makes, so the file reads correctly whichever way the app you hand it to looks. It will also write chapters into a book you already have, in place, with the audio left alone — and it puts the list in front of you first, so you fix the titles and hear where a chapter actually lands before you commit to anything. When the list came from the internet rather than from the file, it checks how well those chapters fit your actual audio — same length but split differently, a different edition, extra audio at the start — and tells you what is off before you apply.

If you do want the mechanical version: every export carries both the QuickTime chapter track and the Nero chpl list, by default. Rewriting chapters and metadata straight into an existing file is the same remux the ffmpeg command above performs — no re-encoding, with a chapter list you can edit and hear before you commit. For the step-by-step of editing an existing book, see editing M4B metadata, covers, and chapters on Mac.

And the part it cannot do. AudioBo builds and repairs the file. It cannot make a player show something that player does not support, and it does not remove DRM, so a protected download stays out of reach whatever is done to its chapters — which is the next section.

What this page will not fix

Some of this is simply out of reach, and it is cheaper to hear that now than after an evening of trying.

Protected files sit outside every test on this page. An old iTunes Store purchase is a genuine M4B with FairPlay wrapped around it, and no remux will reach its chapters. An Audible download is not an M4B at all — those arrive as .aa, .aax, or .aaxc, in Audible’s own container, so if that is what you are holding, the chapter question is not the one you have. AudioBo does not remove DRM. Converting M4B to MP3 on a Mac is where that argument is laid out in full.

If your chapters exist, are readable, and are in the wrong order or badly named, that is a separate repair — the diagnosis on this page ends once the chapter table is present and Apple’s frameworks can see it. And if what you actually want is one file per chapter rather than one file with chapter marks, splitting an M4B into chapters is the other direction entirely.

M4B With No Chapters: How to Tell If It's the File or the Player