Is M4B better quality than MP3?

Not inherently. Both are lossy, and at the bitrates people use for narration both are transparent enough that the argument is academic. AAC does hold up better in one specific corner: at 32 kbps mono and 44.1 kHz on a deliberately hard test signal, the AAC encode kept about 6 dB more energy above 8 kHz than the MP3 encode of the same source. At 22.05 kHz, the sample rate mono narration is normally encoded at, even the MP3's own loss above 5 kHz is only about a decibel — no meaningful gap is left. At 64 kbps mono you will not hear a difference.

Does converting to M4B make the file smaller?

Not by itself. File size is bitrate times duration, and the container barely registers. Ten minutes of mono audio at 64 kbps came out to 4,800,722 bytes as MP3 and about 4,864,000 bytes as AAC in an MP4 — the M4B was slightly larger. You save space by choosing a lower bitrate or mono, not by changing the extension the file ends in.

Can MP3 audiobooks have chapters?

Yes. ID3v2 defines a chapter frame, and MP3 files can carry a full chapter list with titles. I wrote three chapters into an MP3 and read them back with ffprobe intact. The catch is not the format — it is that Apple's audiobook handling is built around M4B, so an MP3 with perfect chapter frames still lands in the wrong library.

Should I convert my whole MP3 library to M4B?

Usually not. Converting re-encodes lossy audio into another lossy format, which only subtracts. Convert the books that actually annoy you — the ones you listen to in Books, on an iPhone, or in a car — and leave everything you already play happily in a third-party app alone. Format churn for its own sake costs quality and time.

Why does my MP3 audiobook show up in Music instead of Books?

Because an MP3 has no way to declare itself an audiobook. An MPEG-4 file leads with a four-character brand and carries a media-type flag, and those are what Apple Books goes on when it routes the file; the MP3 container has no equivalent slot. Books does the only thing it can with an unlabeled audio file and files it as music. That routing, not sound quality, is the real difference between the two formats.

M4B vs MP3 for Audiobooks: What Actually Changes

You have a book in MP3 and someone told you it should be M4B. Or you have an M4B and your car stereo will not touch it.

Either way the question is the same one: does the format actually matter, or is this audiophile theater. If you end up on the M4B side, AudioBo is the short route — a pile of MP3s in, one chaptered book out. The actual answer to the question is the page below.

It matters, but almost none of the reason is sound.

The short version

At the quality audiobooks are actually made at, the two sound the same. The difference is that an M4B can tell your device it is holding a book, and an MP3 has no way to say it. Everything else follows from that. A file that announces itself lands on the audiobook shelf, keeps your place between sittings, and shows a list of chapters. A file that cannot announce itself gets filed in with your music, and whether it remembers where you stopped is anybody's guess.

So: if you listen on Apple devices, M4B. If you listen anywhere else and your player is already happy with what you have, leave it alone. Converting between the two costs a little quality every time and hands you nothing you did not already have.

It will not save space either. How big a book is comes from how good you asked the sound to be and how many hours it runs — not from which of the two it is stored in.

Decided you want the M4B and would rather not assemble it by hand? AudioBo takes a pile of MP3s and gives back one book — real chapters, the title and the cover filled in, and the label that puts it on the audiobook shelf instead of in with your music. If the audio is already fine and only the title is wrong, it can fix that without converting anything.

It builds and repairs the file, and that is the whole of it. It cannot make a player show a chapter list that player does not read, and it does not unlock a book you bought from a shop that locked it.

Which one to use

Use M4B if you listen on Apple devices — Apple Books, an iPhone, CarPlay, an iPod that survived. That is the ecosystem the format was built for, and everything works there without negotiation.

Use MP3 if you listen anywhere else and the player already handles your files fine. Old car head units, cheap MP3 players, Android apps with opinions, a Sonos setup you are not going to renegotiate with.

Do not convert a library that already works. Every conversion between lossy formats subtracts. If the file plays, resumes, and shows the right title in the app you actually use, the format argument does not apply to you.

That is the decision. The rest of this page is why, with the numbers.

What is under the hood, briefly

Both files are the same two things: a recording, and a box around it with labels on the outside. In both cases the recording has been squeezed to save space, and some of it is gone for good. What differs is the box — and how much that box is allowed to say about what is inside it.

An M4B is AAC audio in an MPEG-4 container, carrying chapter markers and a flag that declares it an audiobook. An MP3 is MPEG Layer III audio with ID3 tags stapled to the front. Different containers, different codecs, both lossy.

The full anatomy — the ftyp brand, the chapter atoms, why chapters vanish between players — lives on what an M4B file actually is. This page is about which one to put your library in.

What changes is where the file lands

Here is the part that gets lost in every forum thread about this.

Nothing about MP3 makes it a bad audiobook format on technical merit. It stores speech competently. It can hold a title, an author, and cover art. It can even hold chapters, which we will get to.

What it cannot do is tell an Apple device what it is.

An MPEG-4 file leads with a four-character brand and a media-type flag. Apple Books reads those and routes the file into Audiobooks, turns on resume, and draws a chapter list. An MP3 has no equivalent declaration — the container has no slot for one. So Books does the only thing it can do with an unlabeled audio file: it treats it as music.

That cascade is the entire practical difference:

	MP3	M4B
Lands in Apple Books’ Audiobooks shelf	No	Yes
Resume position remembered across sessions	Unreliable	Yes
Chapter navigation in Apple Books	No	Yes
One book, one item in the library	Only if one file	Yes
Playback on older non-Apple hardware	The safer bet	Device-dependent

The AudioBo product page puts the same thing more bluntly: wrap MP3s without real chapter data or correct atoms and you get flaky playback, lost progress, and files drifting into the Music app instead of the Audiobooks section. The full catalogue of ways that goes wrong is in adding M4B audiobooks to Apple Books on Mac.

The villain here is not MP3 and it is not Apple, exactly. It is that Apple built audiobook handling around one container and never retrofitted the other.

MP3 can carry chapters. It still does not help.

MP3 cannot do chapters: that is the thing everybody knows, and it is not true. An MP3 can hold a proper chapter list — names and times, the same as any audiobook — and hand it to any player that bothers to look for one.

This one is worth showing rather than asserting, because it is the assumption most of the format argument rests on.

ID3v2 has a chapter frame. MP3 files can hold a real chapter list with titles and timestamps, and the tooling supports it.

Want to see it for yourself? I wrote three chapters into a 10-minute MP3 and read them straight back:

$ ffprobe -v error -show_chapters -of compact chaptered.mp3
chapter|id=0|time_base=1/1000|start=0|start_time=0.000000|end=200000|end_time=200.000000|tag:title=Chapter One
chapter|id=1|time_base=1/1000|start=200000|start_time=200.000000|end=400000|end_time=400.000000|tag:title=Chapter Two
chapter|id=2|time_base=1/1000|start=400000|start_time=400.000000|end=600000|end_time=600.000000|tag:title=Chapter Three

The raw bytes show CHAP frames sitting in the ID3 header exactly where the spec says they should be. The format is not the limitation.

The limitation is that a chaptered MP3 arrives in Apple Books as a song with an unusual tag it does not read. Perfect chapter data, wrong room.

So chaptered MP3 is a genuinely reasonable way to store a book — as long as the player you actually listen in is one that reads ID3 chapter frames.

File size, with actual numbers

“AAC is more efficient, so M4B files are smaller” is the most repeated claim in this comparison and it is wrong as stated.

How big an audiobook is comes down to two things: how many hours it runs, and how good you asked the sound to be. Nothing else moves the number much, least of all which of the two boxes you put it in.

File size is bitrate times duration. The container contributes rounding error.

Want the numbers? I encoded the same 10-minute mono source both ways at 64 kbps, 22.05 kHz:

Encode	Bytes	Effective bitrate
MP3, 64 kbps mono	4,800,722	64.0 kbps
AAC in MP4, 64 kbps mono	~4,864,000	64.9 kbps

The AAC file came out about 64 KB larger. Scale that to a ten-hour book and you get roughly 288 MB versus 292 MB. Converting a 64 kbps MP3 library to 64 kbps M4B saves you nothing and costs you a generation of lossy re-encoding.

The AAC figure is approximate on purpose: the encoder is not byte-deterministic, so a rebuild of the same source lands within a kilobyte or so rather than on the same number. The MP3 reproduces exactly.

There is a second version of the size argument, and it is worth taking apart too: that MP3 hits a wall on the way down, that it will not go below a certain size while AAC keeps going. That one is half true, and the true half is narrower than it sounds.

The famous MP3 floor turns out to be a sample-rate artifact, not a property of the format.

At 44.1 kHz the floor is real. I asked for 24 kbps mono and got back a 32 kbps file — 2,400,357 bytes for ten minutes. So did 16 kbps. So did 8 kbps. All three requests produced byte-identical file sizes, because MPEG-1 Layer III has a fixed bitrate table and 32 kbps is the bottom of it at that sample rate.

Encode at 22.05 kHz instead — which is what the table above uses, and what mono narration is normally encoded at — and the floor is gone. MPEG-2 Layer III has its own bitrate table reaching down to 8 kbps, and lame handed back every rate I asked for: 1,800,402 bytes at 24 kbps, 600,285 at 8 kbps. At that sample rate MP3 is the smaller of the two, not the larger — the same 24 kbps request produced 1,862,486 bytes as AAC, about 3 percent more. The efficiency advantage AAC is famous for does not show up in the configuration audiobooks are actually encoded in.

Quality at the bottom is where AAC has the better reputation, and the sample rate governs that too. On a pink-noise test signal — a deliberately hard case, not speech — at 32 kbps mono and 44.1 kHz, the MP3 gave up 9.4 dB of energy above 8 kHz against the source while the AAC gave up 2.9 dB. Six and a half decibels apart. Run the same test at 22.05 kHz, where the ceiling is 11 kHz to begin with, and the MP3 gives up about one decibel above 5 kHz. The gap belongs to that one 44.1 kHz combination, not to the format.

None of which matters at 64 kbps mono, where both formats are transparent for narration and AudioBo’s own FAQ notes that 64 kbps mono often sounds identical to the original.

So: size is a real concern, but it is a question of bitrate, not of containers. If your problem is that a book is too large for your phone, the fix is a lower bitrate or mono, not a different extension.

When MP3 is the right answer

Not a consolation prize. There are cases where MP3 is the correct choice and M4B is the mistake.

Older car head units. The ones that read a USB stick and offer no clue what they support. Whether a given dashboard will touch an M4B is a coin flip you find out about on the highway.

Cheap standalone players. Gym-clip players, kids’ audio players, anything with a two-line display.

Neither of those two bullets is something I put on a bench. No car head unit and no clip player was in reach; they rest on AudioBo’s own 1.2.1 release note and on what that generation of hardware was built to read, not on a device test.

If your habit is browsing by file. A folder of one-chapter-per-file MP3s gives you next-track and previous-track navigation natively, on anything. A single M4B gives you a chapter list your player may or may not choose to expose — and whether it does depends on which of the two chapter formats it reads.

Non-Apple software you already like. If Audiobookshelf or Plex is your library and it is behaving, changing formats buys you nothing.

AudioBo’s release notes for version 1.2.1 say this out loud when they added MP3 export: MP3 is the best choice for older non-Apple players. A tool that only ever recommends its own preferred output is not being straight with you.

And if you would rather build the M4B by hand, you can. ffmpeg deserves respect here. It will build a properly branded M4B with chapters written in both the QuickTime and Nero formats — I checked the output of a hand-rolled build and both atoms were present, with the brand correctly stamped as M4B . The iTunes stik flag is the same deal as the brand: ask for it with -metadata media_type=2 and it is written; forget, and it is simply not there — my first build came out without it. It is free, it is scriptable, and if you enjoy that, you do not need an app. The catch is that it does exactly and only what you tell it: encode straight to a .m4b filename and the header still says M4A , because you never asked for the brand.

What to do with the MP3 library you already have

The honest answer for most people: much less than you think.

Sort your books into three piles.

Plays fine where you listen. Leave it. Converting is a downgrade in quality and an upgrade in nothing.

Right content, wrong tags. The book is one sane file, the audio is fine, but the title says “Audible” and the cover is missing. This does not need a conversion at all — it needs the tags rewritten, which is a metadata operation, not a re-encode.

Structurally wrong. Twenty-eight MP3s that are one book, no chapters, resume that resets every time you open the app. This is the pile that justifies rebuilding, and only this one.

That third pile is where the tedium lives, and it is not one hard step — it is six small ones in sequence: order the files, merge to a single timeline, encode to AAC, author chapters, fill in metadata, embed a cover, export with the right container brand. Miss any one and the file plays while behaving wrong.

What AudioBo does with the books that need rebuilding

AudioBo collapses that into one pass. You hand it the twenty-eight files and you get back one book: one item in the library instead of twenty-eight, chapters you can move between, the title and the cover filled in, and a file Apple Books shelves as a book rather than as a song. The small steps still happen — you are simply not the one keeping track of which one you are on.

For the second pile it does something more useful, because it does not convert anything at all. It writes the corrected title, author and cover straight back into the file you already have. Nothing is re-encoded, no second copy appears, and it works on an MP3 as happily as on an M4B — so a badly labelled MP3 can stay an MP3.

And if the destination is a vintage iPod, AudioBo has a compatibility mode that splits long books into parts of 12 hours or less at chapter boundaries, which is a hardware constraint no format choice makes go away.

If you do want the mechanical version: it writes chapters in both the QuickTime and Nero formats so they survive the trip between players, stamps a real M4B container rather than an M4A wearing the extension, and copies AAC streams without re-encoding when the source already qualifies — zero additional loss, per its own FAQ. The in-place metadata edit is ⌘U, added in version 1.2.2, writing straight back to the original file with no re-encoding, and it works on MP3 as well as M4B, M4A, FLAC, OGG, and AIFF. Fixing a broken title on an MP3 does not require converting it to anything.

Two things it will not do, and between them they decide whether it is any use to you. One thing no tool on this site does: remove DRM. A book bought from a store and locked to that store’s app stays locked, and AudioBo will not change that. The other is the player at the far end — AudioBo writes the chapters into the file, and after that whether a chapter list appears is the player’s decision, exactly as it is for an M4B built by hand.

How to tell what you actually have

All of the above turns on one question: is the file you have actually the thing its name says it is. A file can end in .m4b and still be an ordinary music file wearing the extension — that is what a rename gives you — which is how a book that looks correct in Finder still lands in the wrong place in Books. So before you decide anything, check what is in the file.

Check your own file — one command, no app:

ffprobe -v error -show_entries format_tags=major_brand -show_chapters yourfile.m4b

If major_brand comes back M4B and chapters are listed, the file is what it claims to be. If it says M4A — which is what you get from a rename, or from a converter that took the lazy path — you have a music file with an audiobook’s extension, and that explains everything Books has been doing to you. It is also a five-minute repair rather than a rebuild: the container is rewritten and the audio copied untouched — converting M4A to M4B is the walkthrough, and AudioBo makes the same repair in one pass.

Going the other direction, from a working M4B down to MP3 files for a car or an Android player, is its own guide. Going up from a folder of MP3s to a proper chaptered book is the MP3 to M4B walkthrough.