Audiobook Chapters Out of Order: What Actually Decides the Order

The book plays and the chapters have real names — but the order is wrong. Chapter 10 sits between 1 and 2. An hour in, a character who died comes back.

The fast fix: rebuild the book with AudioBo and choose yourself what sets the order — file names, track numbers, titles or dates. The rest of the page explains why this happens and lists every other way out.

The culprit is a sorting routine, and it is worth knowing which one before you rebuild anything. The rest of this page is that machinery: what actually sets the order, how to see for yourself what your own files will do, and which repairs are cheap.

Three cases this page cannot fix

Three situations first, because if you are in one of them, everything below is an evening wasted.

If the book lives inside Audible, Spotify, or Libby and you listen in their app, the order you are hearing is the order the service is serving. There is no file on your Mac to repair, and no local tool reaches into a streaming library. That one goes to their support, and it is a genuinely different problem from the rest of this page.

If the file is protected, the same applies for a different reason. AudioBo does not remove DRM and never will.

And if your file has no chapters at all — one flat scrubber bar, nothing to jump to — the order is not your problem yet. Diagnosing a chapterless M4B is the page you want.

Everything below assumes a file you own, sitting on your disk, with a chapter list in the wrong sequence.

Every answer you have found so far was written for iTunes

If you have been hunting through menus for the setting that fixes this, stop. Every set of instructions on the subject was written for a program that is no longer on your Mac, and the program that inherited audiobooks from it does not have the controls those instructions name. The fix is not hiding somewhere in your player. It is not there at all.

The standard answer, the one every old thread converges on, is to select the tracks in iTunes, open Get Info, set Media Kind to Audiobook, and fix the track numbers. That advice was correct, and it aged out of existence.

There is no iTunes on my Mac. macOS 26.6 ships Books, Music, TV, and Podcasts, and /Applications/iTunes.app does not exist.

The controls those answers name did survive — in Music. Music’s localized strings still carry Media Kind, Audiobook, Remember playback position, and Track Number. Music is also not where your audiobook goes: I asked macOS which application it hands an .m4b to, and the answer was /System/Applications/Books.app.

Books has none of it. I searched every English string table Books ships on macOS 26.6 — all nine of them — for “Media Kind”, “Track Number”, and “Get Info”: zero hits each. Books does edit things. There is a Book Info panel, an Edit Note, an Edit Finished Date. None of them touch order, and the only properties of the book itself you can change are its name and its cover, through Rename and Change Cover. Beyond that there is a Sort By for arranging your shelf and a Chapter list for playback, and that is the surface.

So the fix cannot be a menu item in the player. It has to be in the file — which means understanding what the file thinks order is.

Chapters are positions, not a playlist

An audiobook file is one long recording, and the chapters are notes along its edge saying where each one begins. Rearranging the notes rearranges the notes. It does not touch a second of the recording underneath them.

This is the part that decides which repair you need, and it surprises people who have spent an evening dragging chapter titles around in a tag editor.

A chapter in an M4B is not a container holding audio. It is a mark: a start time, an end time, and a title, pointing at somewhere on one continuous timeline. Move the mark and you move a label. The audio does not follow it.

Worse, a chapter list that is not in ascending order is not really legal, and the tools do not stop you.

Want to see what happens if you try it anyway? I built a three-chapter test file and fed ffmpeg a chapter list whose first entry begins later than its second: Chapter One at start 20000, Chapter Two at start 0, Chapter Three at start 30000. It exited zero, printed no warning at any log level I asked for, and wrote this:

  Chapters:
    Chapter #0:0: start 0.000000, end 0.000000
      Metadata:
        title           : Chapter One
    Chapter #0:1: start 0.000000, end 30.000000
      Metadata:
        title           : Chapter Two
    Chapter #0:2: start 30.000000, end 60.000000
      Metadata:
        title           : Chapter Three

Chapter One is now a zero-length mark at the very beginning, and its ten seconds of audio have been quietly annexed by Chapter Two. That is what “reordering the chapter list” gets you: a file that is more wrong than the one you started with, with no error to warn you.

If the audio inside your single-file book is genuinely in the wrong sequence, the repair is to move the audio: cut the book at its chapter boundaries and reassemble the pieces in the right order. That cut costs nothing in quality, because it copies AAC frames rather than decoding them — the mechanics, the commands, and the millisecond-level accuracy are all in splitting an M4B into chapters.

But before you cut anything, check whether you still have the files the book was built from. Rebuilding from the sources is faster, and it fixes the cause rather than the symptom.

What sorted your files, and why it disagreed with you

Most out-of-order books were never scrambled. They were sorted, correctly, by a rule you did not know was being applied.

There are two ways to put a list of names in order. One of them notices that a run of digits is a number and treats it as one, so nine comes before ten. The other reads a name as a row of characters and never sees a number at all, so it compares the first character, then the second, and stops as soon as they differ. Both are perfectly sensible. They agree with each other right up to chapter nine and part company at chapter ten.

macOS has a numeric-aware name comparison that understands a run of digits as a number. Plenty of software does not use it, and compares names one character at a time instead. I sorted the same seven filenames both ways:

numeric-aware:  Chapter 1, Chapter 2, Chapter 3, Chapter 9, Chapter 10, Chapter 11, Chapter 12
character-wise: Chapter 1, Chapter 10, Chapter 11, Chapter 12, Chapter 2, Chapter 3, Chapter 9

A character-wise comparison never sees a number. It walks the two names position by position and stops at the first difference, so Chapter 1… and Chapter 2… are decided at the first digit, where 1 beats 2 — and everything beginning Chapter 1 therefore arrives before anything beginning Chapter 2, including all of 10, 11, and 12. Nothing is malfunctioning. The two rules disagree from chapter ten onward, which is exactly where people report their books going strange.

Check your own folder. You can see the unflattering version of the list in one command. In Terminal, cd to the folder and run:

ls -1

That is the order a name-comparing tool hands you. If it matches the order you want, no converter can get your book wrong.

Do not run this check in Finder. Apple documents its numeric-aware comparison as the one to use wherever names are “presented in lists and tables where Finder-like sorting is appropriate” — so the list Finder shows you is the flattering one, not the one your converter walks. That is exactly how a folder can look correct to you and reach a converter in a different sequence; audiobook file naming and folder structure puts the two lists next to each other.

The fix is zero-padding, and it removes the ambiguity permanently: with 01 through 12, both rules produce the same list. I verified that too — padded names sort identically either way.

Want to do the padding in bulk? This loop shows you the renames before it does anything:

for f in *.mp3; do
  base="${f%.mp3}"
  new="$(printf '%s' "$base" | perl -pe 's/(\d+)/sprintf("%02d",$1)/e').mp3"
  echo "$f -> $new"
done

Read the output, and read it properly, because the loop pads the first number in each name and nothing else. On Chapter 1.mp3 that is the chapter number, and on Disc 1 - Track 01.mp3 it is the disc number, which is what you want in both cases. On The 3 Musketeers - Chapter 1.mp3 it pads the 3 and leaves the chapter alone. The preview exists for that. A name with no digits at all — Intro.mp3, Prologue.mp3 — passes through unchanged, because the extension is peeled off before the padding and stitched back on after.

If it is right, run it again with the echo line replaced by [ "$f" = "$new" ] || mv -n "$f" "$new". Two digits covers a book under a hundred chapters; use %03d above that.

Multi-disc rips break in the same place, twice

A boxed set is numbered twice over: once for the disc, once for the track inside it. That is two places for the same mistake to happen, and a rip usually gets one of them right and forgets the other. Get the tracks right and the discs wrong and the book sounds fine until the first disc runs out.

A twelve-disc audiobook gives the character-wise sort two chances to embarrass you, and it takes both.

Disc 1 - Track 01.mp3
Disc 10 - Track 01.mp3
Disc 11 - Track 01.mp3
Disc 2 - Track 01.mp3

The tracks inside each disc were padded, so they behave. The disc number was not, so disc 10 and 11 barge in ahead of disc 2 and the book plays in an order that is coherent for about forty minutes. Pad the disc number as well — Disc 01, Disc 02 — and both levels sort together.

This is also the point where the mistake stops being fixable by looking at it. Twelve discs of sixteen tracks is nearly two hundred files, and no one eyeballs that list successfully. Fix the names, then verify by sorting, not by squinting — which is exactly the check AudioBo runs when you hold Option: every chapter title becomes its source filename, one list instead of two windows. Ripping the discs in the first place has its own set of traps, covered in ripping an audiobook CD to M4B, and where the finished books should live afterwards belongs to audiobook file naming and folder structure.

Filenames or track numbers: which one actually wins

Your files carry two different pieces of ordering information. One is what they are called. The other is a number written inside each file, put there by whoever ripped or tagged it. They can disagree with each other, and they often do.

Both are real inputs, and the honest answer is that it depends on the tool, which usually does not tell you which it chose.

Check your own files before you pick a lever. This prints the ordering tags for every file in a folder:

for f in *.mp3; do
  echo "== $f"
  ffprobe -v error -show_entries format_tags=track,disc,title -of default=nw=1 "$f"
done

On a properly tagged file you get all three:

== 07 - Chapter Seven.mp3
TAG:track=7/12
TAG:disc=2/3
TAG:title=Chapter Seven

On a file with no track number, the TAG:track line is absent — which is the answer to your question. If half your files have no track number, sorting by track number cannot work, and the filename is the only ordering information you have.

There is a second trap in that output worth naming. Track numbers usually restart at 1 on every disc, and the disc number lives in a separate tag — you can see both in the dump above, track=7/12 alongside disc=2/3. A tool that sorts on track number alone will interleave your discs perfectly: all the track 1s, then all the track 2s. If your book plays chapter 1, then chapter 17, then chapter 33, that is what happened.

What AudioBo does about chapter order

The free path above is real, and for one broken book it is the right amount of work. ffprobe tells you the truth about your tags, ls tells you the truth about your names, and a rebuild from correctly named sources is the whole fix. That workflow is written out in full in converting MP3 files to a chaptered M4B on a Mac.

What none of it gives you is a look at the running order before you commit to a two-hour export.

That is the specific tedium AudioBo removes. You drop your files in and the order they will be built in is right there as a list, which you can drag into shape by hand. You decide what sets that order in the first place — the file names, the track numbers, the titles, or the dates — instead of finding out afterwards which one the program picked. Hold a key and every chapter title turns into the name of the file it came from, so you can confirm that chapter 12 really is the twelfth file without opening Finder and comparing two lists by eye. You can also turn off the automatic re-sort, so that adding more files later leaves the ones you have already arranged where you put them. And you can listen across a chapter boundary before you export, rather than discovering the problem after.

Once the order is right, the titles usually still say the wrong numbers. Renumbering a whole selection is one pass, and a find-and-replace across forty chapter titles shows you a live before-and-after, so it is something you read rather than something you risk. Cleaning up how those titles are actually written is a different job with its own page: editing M4B metadata, covers, and chapter names.

If you do want the mechanical version: the relevant parts are small features rather than headline ones. The import sort is an explicit choice instead of a hidden default — since 1.3.1, a setting picks whether added tracks are ordered by file name, track number, title, or date modified. Since 1.3.0, a second toggle stops the automatic re-sort from firing every time you add files, and the half of that worth caring about is what happens to the tracks already in the list: they stay where you put them, manual reordering included. That is the difference between disc 7 arriving after the first six and disc 7 rearranging them. Since 1.3.0, holding Option replaces every chapter title with its source filename; 1.3.2 fixed the arrow keys jumping to the top or bottom of the list while you held it. Batch Rename renumbers a selection in one pass, and its Regex tab, added in 1.3.2, shows a live before-and-after preview.

And the part it cannot do. It works on files you have on your disk. A book you are streaming from Audible, Spotify or Libby has nothing on your Mac to repair, and a protected file is out of reach for a different reason: AudioBo does not remove DRM and never will. Nor does any of this change what a finished book is: if the audio inside an M4B you already built is genuinely in the wrong sequence, the repair is still the one above, cutting it at the chapter boundaries and reassembling the pieces in order.

The habit that prevents the next one

Check the order at import, not at export. Every fix on this page is cheap before the build and expensive after it — after the build, correcting a running order means cutting a finished file apart and putting it back together, and the chapter list you can see is the one thing that cannot move the audio.

Zero-pad the numbers, look at the sorted list once, and the problem stops recurring.