How to Convert M4B to MP3 on Mac (Keeping Chapters and Cover Art)

Your M4B plays fine in Apple Books. Then you try it in the car, or on an Android phone, or on the twelve-year-old player that lives in a kitchen drawer, and the file does not appear. Not an error. It is not on the list at all.

The file is fine. The device is just old, or not Apple’s. MP3 is the format everything still reads.

AudioBo exports the same book as MP3, fixing the titles and cover on the way out. Below: that route first, then the by-hand ones.

Converting is straightforward, and on a Mac you already have most of what you need. But there is one question to settle before any of it matters.

Is the file protected? That decides everything

Audiobooks come in two kinds: the ones a shop locked, and the ones nobody locked. Which one you have decides whether there is anything to do here at all.

If the audiobook is encrypted, nothing on this page will work, and AudioBo does not remove DRM. It never will.

Three quick ways to tell where you stand.

It came from Audible. Then it is not an M4B in the first place. Audible downloads arrive as .aa, .aax, or .aaxc. Only .aa is a container of its own — ffmpeg lists it as a demuxer in its own right. The other two are MPEG-4 files underneath, the same family as your M4B, with the audio itself encrypted, which is why an ordinary conversion refuses them. Audible’s own apps are the path there.

It came from the Apple Books store. Apple’s own software will tell you when you try. Music.app on macOS ships this exact error string: “could not be converted because protected files cannot be converted to other formats.” That is the answer, from the vendor, in advance.

You built it, or downloaded it from LibriVox, or ripped it from your own CDs. Then it is almost certainly unprotected and everything below applies.

One thing that panics people and should not. On macOS, the .m4b extension resolves to the content type com.apple.protected-mpeg-4-audio-b. Run mdls on a file you built yourself thirty seconds ago with no encryption anywhere in it and macOS still reports that type, because the type is assigned by extension and that name is a leftover from when audiobooks and DRM arrived together. The word “protected” there describes a type declaration, not your file — what an M4B file is prints the full mdls output if you want to see it.

Want to settle it for certain? The real test is whether a decoder can read the audio from end to end:

ffmpeg -v error -i book.m4b -f null -

Nothing printed, exit code 0 — the audio decoded cleanly, there is no encryption in the way, and you can convert it.

What the conversion actually costs you

Converting costs you one thing you cannot avoid and several things you can. They get mourned together, which is why people go in expecting to lose the chapters and the cover as well — and then, with the short command, do.

The audio is re-encoded. There is no way around it. M4B is a container holding AAC; MP3 is a different codec. You cannot copy the stream across — the MP3 muxer refuses outright, with Invalid audio stream. Exactly one MP3 audio stream is required. So the audio gets decoded and compressed again: a second lossy generation on top of the first. On narration at a sane bitrate this is barely audible, but it is real, and it is the price of the format change.

Chapters do not have to be lost. MP3 carries them natively: ID3v2’s chapter addendum gives you a CHAP frame per chapter and a CTOC frame for the table of contents, and ffmpeg writes both from the source with no extra flags. My three-chapter test M4B converted straight through, titles and timings intact. What you cannot control is whether the player draws them, and plenty of hardware ignores ID3 chapters entirely. That is a player limitation rather than a format one — M4B versus MP3 for audiobooks shows the frames sitting in the ID3 header where the spec says they belong.

Cover art survives as an ID3 APIC frame, if you tell ffmpeg not to mangle it, and there is a flag for that in a moment. Title, author, and album come across as ordinary TIT2, TPE1, and TALB tags.

Audiobook behavior in Apple’s ecosystem does not survive, because that behavior comes from the M4B container itself, and it is why Apple Books accepts one and shrugs at the other. Converting to MP3 is a deliberate trade of Apple-side niceties for universal playback.

One file, or one file per chapter

These are different jobs and people conflate them constantly.

One MP3 keeps the book as a single timeline. Choose it when the target reads ID3 chapters, or remembers position on its own, or when you want the library to stay tidy.

One file per chapter turns the chapter list into a track list. Choose it for car stereos, old hardware players, and anything with a next-track button and no concept of a bookmark. That is a split, not a conversion, and it is a separate operation with its own rules — splitting an M4B by chapter covers it, including the part where you can do it without re-encoding anything.

The rest of this page is the single-file case.

The free path: one ffmpeg command

The tool for this job is free and it has no window. You paste one line into Terminal, it reads your M4B, and it writes the MP3 for you. There is nothing to click and nothing to configure — the whole of the job is in that one line, and every part of it is explained underneath so you are not taking any of it on trust.

If you have Homebrew, brew install ffmpeg is the whole setup. If you do not do this often, the honest answer is that you do not need an app for it — one command, done, close the tab:

ffmpeg -i book.m4b \
  -map 0:a -map 0:v \
  -c:a libmp3lame -b:a 64k \
  -c:v copy \
  -id3v2_version 3 \
  book.mp3

Every flag in there is doing work:

• -map 0:a -map 0:v names the audio and the cover image explicitly. On a plain book with one of each, ffmpeg picks those two on its own; the maps are there for the file that carries more than that.
• -c:a libmp3lame -b:a 64k sets the encoder and the bitrate. Match your source; see below.
• -c:v copy passes the cover art through untouched instead of re-encoding it.
• -id3v2_version 3 writes ID3v2.3 tags. ffmpeg defaults to 2.4 — the header on the output reads ID3 then 04, and with the flag it reads 03. 2.3 has the reputation of being the version old players parse, which is reputation rather than something I can test on a drawer full of hardware, but the flag is free.

Chapters need no flag. ffmpeg carries them over on its own.

Want to see whether the chapters made it? Ask the file rather than the player:

ffprobe -v error -show_chapters -of compact book.mp3

You should get one line per chapter, with start times and titles.

If you would rather stay in a window and install nothing at all, Music.app ships an MP3 encoder and an Import Settings panel that picks the output format, so a conversion is possible there without the command line. What it does with chapters I have not tested — run ffprobe -show_chapters on whatever comes out before you trust it with a book.

What the short version silently does to your file

There is a much shorter way to type this, and it does work. The catch is that leaving the options off does not leave the decisions unmade — it hands them to the program, and you find out what it chose afterwards, on a finished file.

ffmpeg -i book.m4b book.mp3 works. It also makes two decisions on your behalf that are worth knowing about.

It picks a bitrate, and the pick can be lower than your source. A 64 kbps mono 22.05 kHz chapter — a completely normal audiobook encode — came out of the default at 32 kbps. Half. Nothing warned me. At 44.1 kHz the same source came out at 64 kbps, so the default tracks the sample rate and channel count rather than the source bitrate.

It re-encodes your cover art to PNG. Photographs do not belong in PNG, and the numbers get ugly fast: a 159 KB JPEG cover came back as a 648 KB tag block, four times the size, in a file whose audio was 90 seconds long. With -c:v copy, the same cover took 159 KB. How bad the multiplier gets depends on the artwork, and on a real book the difference is dwarfed by the audio — but it is pure waste, and it costs one flag to avoid.

Picking a bitrate

Bitrate is how much data per second the encoder is allowed to spend on the sound. Higher is not better here, it is only bigger: the rule is to match what the book already has.

Want your own book’s number? Read it straight off the file:

ffprobe -v error -select_streams a:0 \
  -show_entries stream=bit_rate,sample_rate,channels \
  -of csv=p=0 book.m4b

Match the source, or come close to it. Encoding above the source rate is wasted space — the audio the first encoder discarded is gone, and a bigger MP3 does not bring it back. Encoding well below it is where narration starts sounding gritty. Mono spoken word is comfortable in a range that would be miserable for music, which is why 64 kbps mono is not the insult it looks like.

What AudioBo does here: repair the book first, then export the MP3

For one book, ffmpeg is faster than downloading anything. That stays true no matter what else is on this page.

It stops being true around the third or fourth book, and specifically at the moment when the M4B you are converting is itself a mess — chapter titles that came in as garbled symbols, no cover, a book title that says “Audible”. Then you are not converting, you are repairing first and converting second, and doing that by hand means writing a metadata file, matching timestamps, and re-running the command until the tags look right.

That repair is the part AudioBo is built around, and the conversion falls out of it. You fix the chapters, the cover and the title once — in the app, rather than in a hand-written text file of timestamps — and then send the same book out as M4B, M4A or MP3 depending on where it is going. Nothing to memorise, nothing to retype for the next book.

The workflow that holds up: keep one clean M4B as the master, export MP3 copies for the places that need them, and never re-do the metadata work.

If you do want the mechanical version: MP3 export arrived in 1.2.1. Since 1.2.2 the app can also write metadata straight back into an existing file — M4B, M4A, MP3, FLAC, OGG, or AIFF — with no re-encoding at all, which is the right tool when the audio is already correct and only the tags are wrong.

Two things it will not do, and they decide whether it is any use to you. AudioBo does not remove DRM and never will, so a locked Audible or Apple Books purchase stays locked whatever you point at it. And no app can make a player draw chapters that the player ignores — AudioBo writes them into the file, and after that it is the player’s decision, exactly as it is with the command above.

The failures people actually hit

The same handful come up every time, and in each case the first move is to look at the file rather than to convert it again.

“I renamed it to .mp3 and nothing plays it.” Renaming changes the label on the box, not the contents. The bytes inside are still AAC in an MPEG-4 container. I copied an M4B to renamed.mp3 and asked macOS’s own audio framework about it: afinfo renamed.mp3 answered Fail: AudioFileOpenURL failed, while ffprobe on the same file still reported the format as mov,mp4,m4a. A conversion has to actually re-encode the audio.

“The chapters disappeared.” Check the file before blaming the conversion — ffprobe -show_chapters on the MP3 will tell you in one line whether they are there. If they are, the player is ignoring ID3 chapters, and no re-conversion will change that. Splitting into per-chapter files is the fix for players like that.

“The MP3 is bigger than the M4B.” Either the bitrate went up, or the cover art got re-encoded to PNG, or both. At the same bitrate the two land within a percent or two of each other, because size is bitrate times duration and the container is rounding error.

“It sounds worse than I expected.” Look at the actual output bitrate rather than the one you assumed. If you left -b:a off, ffmpeg chose, and its choice may have been half your source.

Going the other direction

If you landed here while actually trying to solve the reverse problem — a pile of MP3s that should be one audiobook — that is the MP3 to M4B workflow, and it is a genuinely different job, because merging and chaptering are harder than transcoding.

MP3 asks nothing of the player. That is the entire reason to convert, and the only thing you hand over in exchange is the part Apple built for itself.