Audiobook Converter: Ebook to M4B on Mac

Direct answer: an audiobook converter turns an ebook's text into spoken audio and bundles it as one file whose chapters a listener can jump between. In that workflow, M4B is the container: it is the audiobook flavor of MPEG-4 audio, and players read chapter names, a cover, and the playback position from metadata inside the file. On a Mac the job breaks into three steps you can run yourself: pull the ebook into clean chapter scripts, generate the narration, then package the audio with chapter markers and book metadata.

This guide is about the packaging half of that job, the part most converters gloss over. It explains what an audiobook converter actually does, why M4B is a container rather than an audio codec, where chapter information comes from in an ebook, which metadata fields a store or player expects, and how to check the finished file before you ship it. The examples use Murmur, a local-first macOS voice studio, but the chapter and metadata rules hold no matter which tool writes the audio.

What an audiobook converter actually does

Strip away the branding on any tool called an audiobook converter and you find three separate jobs stacked together. First, text extraction: reading the source document and getting the words out in reading order, without page numbers, running headers, or markup. Second, speech synthesis: turning that text into audio in a chosen voice. Third, packaging: joining the audio, writing chapter markers, and storing book metadata so a player can show a title, a cover, and a chapter list. A tool that does the first two and skips the third produces audio that plays, but not an audiobook people can navigate.

It helps to know which job is failing when a conversion disappoints. The wrong words mean extraction or text cleanup. A flat or drifting read means voice choice. Audio that plays as one anonymous two-hour block, with no chapters and no title, means packaging. If you plan to sell or distribute the result, do not skip the third job; a buyer who cannot see chapters will treat the file as an unfinished recording.

M4B is a container, not an audio format

People say convert to M4B as if M4B were a codec. It is not. M4B is an MPEG-4 audio file that uses the .m4b extension to signal audiobook. The FFmpeg project lists m4b among the registered extensions of its MOV, MP4, and 3GP demuxer, alongside m4a and mp4, which reflects the reality that these are the same family of container. The audio inside is usually AAC, the same codec an M4A uses. The difference is convention and metadata: the .m4b extension tells players and stores to treat the file as a book, with chapters and a remembered position.

That has a practical consequence. You rarely make an M4B by encoding the audio again. You change the packaging: remux or rename the file so its extension is .m4b, with the chapters and cover written into it. Re-encoding lossy audio a second time only risks quality, so prefer a tool that rewrites the container and leaves the encoded audio untouched.

Chapters are the payload that makes an M4B worth having. Apple's developer documentation describes AVTimedMetadataGroup as a collection of metadata items valid for a time range, and states that these groups are used to represent chapters, optionally containing metadata items for chapter titles and chapter images. That is the mechanism: each chapter is a time range plus a title, stored inside the file, and a player reads that list to build its chapter menu.

Choosing a container for your audio

Before you package anything, decide which container the destination actually wants. This table is the quick version; the rest of the article assumes you have settled on M4B for one-file delivery.

The useful split is between an editing master and a delivery copy. Keep a lossless chapter per chapter so you can fix a line without rebuilding the book, and treat the M4B as the shipping artifact you generate from those chapters.

Where the chapter markers come from

An ebook already knows its own structure. The EPUB 3.3 specification defines a spine, the ordered list of content documents that represents the default reading order, and a navigation document that carries the table of contents. When you convert an EPUB, that spine is your chapter list almost for free: one spine document is usually one chapter. A PDF gives you no such gift, so you build the list yourself from its headings or bookmarks, and a plain text file gives you only the headings you typed.

Turn that structure into named markers. Take a book with a title page, a contents page, an introduction, twelve numbered chapters, and an afterword. You would drop the title and contents pages, then create fourteen markers: Introduction, Chapter 1 through Chapter 12, and Afterword. The names should match what a listener hears and sees, because those exact strings become the chapter titles in the player.

Order and timing matter more than the labels. A marker starts a chapter at the moment its first word is spoken, and the next marker closes it. If your tool writes markers from a timeline, place each one exactly at the start of its chapter's audio. The full audiobook workflow covers generating and reviewing chapters one at a time, which is what keeps those boundaries clean.

Metadata to set before you package

A player shows more than chapters. The Apple Books Asset Guide states that a package document must include at least a title, an identifier, a language, and the date the book was last modified, and those same fields are the floor for an audiobook's metadata. Stores add their own expectations for narrator, publisher, and cover, so read the target store's requirements page before you finalize; exact limits differ by platform.

• Title and subtitle, spelled the way you want them displayed.
• Author and, separately, narrator, so the credits are not blurred.
• Language, using a standard code such as en for English.
• A unique identifier, so an updated version is not mistaken for a new book.
• Series name and book number, if the title belongs to one.
• A square cover image at the size the target store asks for.
• Chapter titles, written exactly as the markers will carry them.
• The date the book was last modified, which stores use to detect updates.

A repeatable ebook to M4B workflow

1. Extract the text. Import the ebook and read the preview. Follow the EPUB spine, or confirm a PDF actually has a text layer before you invest time.
2. Clean the text for speech: fix hyphen joins, decide how numbers read, expand abbreviations you do not want spoken, and strip running headers and page numbers.
3. Split the text into one script per chapter and name each script after its chapter.
4. Choose one narrator voice and reuse it for every chapter, so the book sounds continuous.
5. Generate the chapter audio in order.
6. Export the timeline with markers. Murmur exports WAV and M4A and writes timeline markers into M4A as chapter metadata; this chaptered M4A is the file to build from.
7. Package to M4B. Remux the chaptered audio into an .m4b container with your metadata and cover, without re-encoding the audio.
8. Verify. Open the M4B in a player and check the chapter list, the title, the cover, and that the reading position is remembered.

Murmur is a local-first voice studio for Apple Silicon Macs running macOS 15 or later, so the extraction and generation steps happen on your own machine, with no per-character fees and nothing uploaded to a cloud service. It imports PDF, EPUB, and plain text, exports WAV and M4A, and can write chapter markers, a transcript, and a chapter list. It does not export M4B, so the final packaging step is a separate tool; keep the chaptered M4A as the source you remux from. The WAV, M4A, and MP3 export guide explains the difference between a master and a delivery copy, and the text normalization guide handles the number and symbol cleanup that trips up a reader.

One file or many: choosing a packaging profile

Once the chapters exist, the packaging decision is mostly about your distribution. Use the profile that matches where the book is going.

How to verify the M4B before you ship

Do not trust the tool that wrote the file to be the tool that proves it. Open the finished M4B in a player that supports chapters and check four things: the chapter list is present and in order, each chapter name matches the book, the title and author read correctly, and the cover appears. Then jump to the last chapter and confirm the audio is complete rather than clipped. If any chapter is missing, the markers were likely not written, or the container does not carry them the way that player expects.

A short spot-check of the spoken audio is worth the minutes. Listen to the opening of the first chapter, a name-heavy passage, and the start of the final chapter. If a chapter sounds wrong, fix that chapter's script and regenerate only that chapter, then repackage. Because the chapters are independent, a single fix does not force you to rebuild the whole book.

Where Murmur fits, and where it does not

Murmur is the right tool when the job is private, repeatable narration you want to regenerate chapter by chapter on your own Mac. It is the wrong tool if you work on Windows, want several people editing one project in the cloud at once, or need live, real-time streaming speech; a cloud service with those features fits better. Murmur runs only on Apple Silicon Macs with macOS 15 or later and does not provide Windows, iPhone, Android, or browser apps, live streaming, or speech to text. It also does not write M4B itself. And if the source ebook is DRM-protected and you cannot get a DRM-free copy, no converter helps, because the text is what is locked. When a publisher requires a signed, mastering-grade M4B, a dedicated audiobook production suite will do more of that packaging than a voice studio.

For the writer who owns the text, wants one narrator, and needs a chaptered file with correct metadata, the local route is enough. Pair it with the audiobook narration guide for choosing that single voice and the workflow guide above for pacing across many chapters.

Frequently asked questions