Combining audiobook chapters into one file
They have 30 or 40 chapter files and a player that loses its place between them, or a phone that shows them as 40 separate tracks. The existing answers are an ffmpeg command line or a paid Mac utility.
Put the chapters end to end into one file, and choose the container by what your player does with it. If you listen in Apple Books, in a car head unit, or in any app that looks for audiobooks rather than music, you want an .m4b: it is an ordinary MPEG-4 file with an extension that tells players to remember your place. If you listen in a player that already bookmarks MP3s, join the chapters into one MP3 instead and skip the re-encode entirely, because MP3 chapters can be stitched together without any encoder running. The audio joiner does both, in this tab, with no file-count cap — which matters more here than on any other job, since forty chapters is usually the better part of a gigabyte.
What M4B actually is
An .m4b is not a format. It is the same MPEG-4 container as .m4a, .m4r and .mp4, carrying the same AAC audio, wearing a different extension. Nothing inside the file changes when you rename it. What changes is how software treats it.
Three behaviours hang off that extension:
- Position memory. Audiobook players save where you stopped and return there, per book, instead of restarting the track.
- Shelving. Apple Books shows M4B files as books. Drop an MP3 on the same device and it lands in the Music app as a track, next to your albums.
- Chapters. The MPEG-4 container has a proper chapter track, so a player can offer a chapter list and skip between them. MP3 has no equivalent that players agree on.
Because the rename is only a label, the reverse is also true: renaming an MP3 to .m4b produces a broken file. The bytes inside are MP3 frames, not MPEG-4 boxes, and nothing will open it. The extension has to match what is actually in the file — the same trap covered in renaming an M4A to MP3.
MP3 or M4B: the one real trade-off
Your chapters are MP3. Joining them into one MP3 means the compressed frames are carried across untouched. Joining them into an M4A or M4B means every frame is decoded back to samples and re-compressed as AAC — a second generation of lossy encoding, on audio the first encoder has already thinned. For spoken word at a sensible bitrate that is a small cost, but it is not nothing, and it is worth knowing you are paying it. The what a re-encode actually costs guide has the detail.
| One joined MP3 | One M4B | |
|---|---|---|
| Second lossy encode | None — the frames are copied | Yes, MP3 decoded then AAC encoded |
| Remembers your place | Only if the player chooses to | Yes, in any audiobook player |
| Chapter list | No | Yes, if chapters are written in |
| Apple Books | Goes to Music instead | Shelved as a book |
| Old car stereos, cheap MP3 players | Plays | Often refuses |
| Size at the same perceived quality | Slightly larger | Slightly smaller |
If you use Smart AudioBook Player, Voice, BookPlayer, VLC or a self-hosted library like Audiobookshelf, all of them bookmark a plain MP3 quite happily, and the joined-MP3 route is the better answer. If your listening ends up in Apple Books, take the re-encode.
Get the order right before you join
Almost every ruined audiobook merge is a sorting problem, not an audio problem. Computers sort names as text, so Chapter 10.mp3 comes before Chapter 2.mp3, and a forty-chapter book ends up in the order 1, 10, 11, 12, … 2, 20, 21. You will not notice until chapter three.
Two fixes:
- Zero-pad the numbers so every name is the same length:
02, not2;007if the book runs past ninety-nine. Then text order and number order are the same order. On Windows, select all and press F2 to rename in bulk; on macOS, right-click the selection and choose Rename Items. - Check the list before you run it. The joiner shows the queue in order and lets you drag items around, so the last thing to do before pressing the button is read the list from top to bottom.
Do not trust the track numbers in the ID3 tags. Rips from different sources number themselves per-disc, so you get three files claiming to be track 1.
Joining without a second encode
A join can skip the encoder when every file already agrees: same codec, same sample rate, same channel count. Chapters ripped from one source almost always do. When they match, the tool concatenates the compressed streams and writes a new index, so the work is reading bytes and writing bytes rather than decoding several hours of audio. That path finishes quickly even on a long book, because no per-sample work happens at all. A re-encode of the same material does not, since it is a single-threaded WebAssembly build pushing every sample through a decoder and an encoder.
MP3 encoders add a short chunk of padding at the start and end of each file — the decoder's warm-up frames. Stitch fifty MP3s together without re-encoding and that padding survives, so there is a few tens of milliseconds of silence at each seam. Between chapters, where a pause belongs anyway, nobody hears it. If you are joining a piece of continuous music where the seam falls mid-bar, that is the one case where the re-encode route actually sounds better, because decoding first removes the padding.
When a re-encode is forced
The tool checks each file and tells you which path it took. It has to decode and re-encode when any of these is true:
- Mixed bitrates or sample rates. A 22.05 kHz interview spliced onto 44.1 kHz chapters cannot be concatenated as-is.
- Mixed channel counts. One stereo chapter among thirty-nine mono ones forces the whole job.
- Mixed formats. Thirty MP3s and four M4As have nothing in common to copy.
- You asked for a different output. MP3 in, M4B out, is a re-encode by definition.
- You asked for a crossfade. Overlapping two files means computing new samples where they overlap.
When it is forced anyway, choose the bitrate deliberately. Spoken word is cheap: 64 kbps mono is transparent enough for narration and is what most commercial audiobooks sit near. Asking for 192 kbps stereo on a mono narration triples the size and adds nothing, because a higher bitrate cannot put back what the source encoder already discarded. The file-size tool shows the predicted output before you commit.
Chapters, cover art and tags
Here is the honest boundary. The joiner produces one continuous file. It does not write a chapter track, and it does not write cover art or title and author tags — expect the metadata from your source files not to survive the merge, and plan to set it afterwards.
For tags and artwork, use a tagger: Mp3tag on Windows, Kid3 on Windows, macOS and Linux, or Apple Books' own Get Info panel once the book is imported. Ten seconds of typing, and the file shows the right title and cover on the shelf.
For real chapter marks you need a tool that writes the chapter track. On a desktop with FFmpeg installed, a plain text metadata file plus ffmpeg -i joined.m4a -i chapters.txt -map_metadata 1 -c copy book.m4b attaches chapters without touching the audio. m4b-tool automates the whole thing from a folder of files, and Audiobook Builder on macOS does it with a mouse if you would rather pay than type. None of that runs in a browser tab, and pretending otherwise would waste your afternoon.
One thing no tool on this page or any other will do: a purchased Audible or Apple Books download is encrypted, and it cannot be joined, converted or renamed into anything. It will not open here and it will not open in FFmpeg either.
Why a server-based joiner struggles here
Audiobooks are the file class where the mechanics decide the argument rather than the privacy principle. A twelve-hour book at 64 kbps mono is roughly 350 MB. At 128 kbps stereo it is closer to 700 MB. A server-based joiner has to receive every one of those forty files across your connection before the first byte of work happens, then send the merged result back, and the free tiers of those services are shaped exactly to prevent it — a cap on how big one file may be, and a cap on how many jobs you may run in a day. Forty chapters is forty files against that count.
Here the files are read straight off your disk, so the connection is not involved. The real ceiling is the browser tab, which has about 2 GB of address space and needs roughly three times a file's size in working memory. The converter warns above 300 MB and refuses near the limit, so a long book at a music bitrate may need joining in two halves and then joining the halves. That is a genuine limit and it is ours to state plainly rather than discover halfway through.
The phone app is the wrong shape for this particular job, and it is worth saying so: its merge tool takes two files at a time and writes an uncompressed WAV, which for a twelve-hour book would be several gigabytes before you converted it back. Use it for stitching two voice memos together. For forty chapters, use the converter here on a desktop, where the disk is fast and the memory is real.
The converter on the home page handles this. Free, no upload, no sign-up.