How to Compress an M4B File (And the Best Bitrate for Audiobooks)
The book is 3.8 GB. Your phone has opinions about that, and none of them are generous.
So you searched for a way to compress an M4B, and what came back was a row of web uploaders that would like you to hand over 3.8 gigabytes first, plus a forum thread from 2009 arguing about bitrate in the abstract. The short route is AudioBo: pick a preset, see the estimated output size before you commit, done. The long route — understanding the numbers — is the rest of this page.
The abstract part is short, though. An M4B’s size is its bitrate multiplied by its length. That is the entire mechanism. Everything else is a rounding error wearing a costume.
An audiobook is big because of the sound in it, and nothing else. The cover, the chapter list and the title are noise — even a deliberately oversized cover comes to about a tenth of one percent of a ten-hour book. There is nothing in there to clean out. The only thing that moves the number is re-encoding the audio at a lower setting.
In sizes you can picture: a ten-hour book comes to about 582 MB at the setting some converters still default to, 291 MB at the setting worth keeping, and 147 MB when the megabytes are what hurt. Same book, same chapters, same cover — a recording of one person talking does not need the higher setting.
Re-encoding costs a little quality every time, and asking for a higher setting afterwards does not give any of it back — it only makes the file bigger again. So it is worth getting the choice right once, on the best copy you have.
Would rather see the number before you spend the hour? AudioBo shows an estimated output size on each preset before you commit, and prints what goes in against what comes out — so the size is something you look at first, not something you find out an hour later. A book that has nothing left to give gets the same estimate on every preset, instead of being inflated.
It cannot make audio smaller without re-encoding it, because nothing can, and it does not remove DRM from a book bought and locked to a store's app.
The only lever, and what each setting costs
Re-encode the audio at a lower bitrate. That is the only lever that moves the number.
Here is what a ten-hour book costs at each setting. I encoded the same ten-minute source at each of these and multiplied by sixty — the format scales linearly, so that holds.
| Setting | Per hour | Ten-hour book |
|---|---|---|
| 32 kbps mono, 22.05 kHz | 14.7 MB | 147 MB |
| 48 kbps mono, 22.05 kHz | 21.9 MB | 219 MB |
| 64 kbps mono, 22.05 kHz | 29.1 MB | 291 MB |
| 128 kbps stereo, 44.1 kHz | 58.2 MB | 582 MB |
| 192 kbps stereo, 44.1 kHz | 87.0 MB | 870 MB |
MB here means a million bytes, the way Finder counts.
For narration: 64 kbps mono if you want the book to last, 32 kbps mono if you want it to fit. A book currently sitting at 128 kbps stereo halves when you move it to 64 kbps mono — measured, 9,705,299 bytes down to 4,853,647 on my ten-minute file. Take it to 32 kbps mono and three quarters of it is gone.
Work out what you have before you change it
Two things decide how big your book is: how long it is, and how much sound it carries every second. Nothing can be done about the first one. So the only question worth asking before you touch anything is how much sound is in there already.
That question has a real answer, and sometimes the answer is leave it alone. A book that is already lean has nothing left to take out, and running it through another encode costs quality and returns no megabytes.
Check your own book. One command, no app, no upload:
ffprobe -v error -show_entries format=duration,bit_rate \
-show_entries stream=channels,sample_rate -of default=nw=1 yourbook.m4bThat gives you the four numbers that decide everything: how long the book is, what bitrate it is riding at, and whether it is wasting bits on a second channel and a sample rate speech never reaches.
The arithmetic for predicting the result is a single multiplication. Every kbps costs about 0.45 MB per hour. So 64 kbps for ten hours is roughly 288 MB, and the file I actually encoded came in at 291 MB — the extra one percent is the container, the tags, and the chapter list.
If your book is already at 64 kbps mono, there is nothing here for you. It is as small as an audiobook sensibly gets, and the honest recommendation is to delete something else.
Three knobs, and two of them are not what you think
Every converter shows you bitrate, channels, and sample rate as though they were three separate ways to save space.
They are not. Switching a book to mono looks like it should halve the file — one channel instead of two — and halving the sample rate looks like it should halve it again. Neither one does anything to the size on its own. Only one of the three knobs is attached to the megabytes; the other two decide how far those megabytes stretch.
Want to see it for yourself? I encoded the same ten minutes four ways, all at a requested 64 kbps:
| Encode | Bytes |
|---|---|
| Mono, 22.05 kHz | 4,853,647 |
| Stereo, 22.05 kHz | 4,853,570 |
| Mono, 44.1 kHz | 4,904,994 |
| Stereo, 44.1 kHz | 4,904,686 |
Mono and stereo land 77 bytes apart. Doubling the sample rate costs about one percent. At a constant bitrate, channels and sample rate do not change file size — the encoder was told how many bits per second to spend, and it spends them either way.
What they change is how far those bits go. Sixty-four kilobits spread across one channel is twice the budget per channel as the same sixty-four across two. A 22.05 kHz file has no room above 11 kHz, which speech does not need, so nothing is wasted describing air that is not there.
So the correct way to use mono and a low sample rate is as permission to lower the bitrate, not as a substitute for lowering it. Set them, then cut the bitrate in half, and that is where the gigabyte goes.
None of this is about AAC being cleverer than MP3, either. That comparison is genuinely closer than its reputation suggests, and it lives on M4B vs MP3 for audiobooks.
macOS will not let you overspend on mono
Worth knowing before you type a number into a box: on a Mac, in one particular setup, you can ask for better quality than you actually get. Nothing warns you. The finished file even reports the number you asked for. The sound inside it is the same sound you would have got from the lower setting.
The setup where this happens is the audiobook one — one channel, low sample rate — which is why it belongs on this page rather than in a footnote somewhere.
Want to see it for yourself? I asked macOS’s own AAC encoder — the one in AudioToolbox, reached here through ffmpeg’s aac_at — for 80, 96, 112, 128, and 160 kbps at mono and 22.05 kHz. Every request produced the same 4,853,647-byte file, with an audio stream that hashed identically each time.
What changes is only the number the file claims about itself: the declared bitrate in the header. The file says 128. It delivers 64.
It is a ceiling, not a fixed setting. Below it the encoder does exactly as it is told: 16, 24, 32, 40, 48, 56, and 64 kbps each came back within a kilobit of the request. Above 64 the output stops moving, and it never moves again.
At 44.1 kHz mono, the same encoder honored every request I made up to 192 kbps. And ffmpeg’s own built-in AAC encoder, handed the same 128 kbps mono 22.05 kHz request, does not refuse so much as undershoot — near 100 kbps on broadband test material, lower on simpler signals. Where it lands depends on the audio, which is the point: nothing pins it to one number.
So the ceiling belongs to one encoder in one configuration, not to the format. The practical consequence is the useful part: if you are exporting mono at 22.05 kHz on a Mac, 64 kbps is not a cautious middle choice. It is the top of the range, and asking for more silently gets you the same file.
Where the size is not
Before you go through the book looking for things to throw out: the size is not in any of them. Here are the three things people delete first, and what each is actually worth.
Cover art. I embedded covers of three sizes into the same 4,853,647-byte file. A 600-pixel one added a little over twenty kilobytes, a 1000-pixel one around fifty, and a deliberately oversized 3000-pixel one roughly a quarter of a megabyte. The exact figure moves with the image and the JPEG quality, not with the pixel count alone. Scaled against a ten-hour book, even the worst of them comes to about a tenth of one percent of the file.
Chapters and metadata. A chapter list stored in both of the formats M4B uses costs a few hundred bytes — the exact figure and the reason there are two formats are in what an M4B file actually is. Stripping chapters to save space is the worst trade available at any scale.
Splitting the book into parts. Splitting makes each file smaller and the total identical. It solves “this will not copy onto my player”, not “I am out of storage”; splitting an M4B into chapter files covers the mechanics.
When re-encoding is the wrong move entirely
Sometimes the right thing to do with the audio is nothing at all — either because the audio was never the problem, or because the change you have in mind would make the file worse and larger at the same time. Two situations, and both are common.
You want to change the tags, not the audio. Fixing a title, an author, a cover, or a chapter list is a remux. The audio is copied through untouched. I rewrote the title and artist on a test book with -c copy, and the audio stream hashed identically before and after. It took 0.11 seconds, against 1.11 for re-encoding the same ten minutes. The file did not shrink, either; it grew by a few dozen bytes, because the new title was longer than the old one. That whole path is editing M4B metadata, cover, and chapters.
You are re-encoding upward. I took a 32 kbps file and asked for 128 kbps at 44.1 kHz. It came back at 9,706,163 bytes — almost four times larger, carrying not one bit of information the 2,453,060-byte original lacked.
The emptiest version of that is re-encoding at the bitrate you already have. Sixty-four in, sixty-four out: 4,853,647 bytes became 4,854,022, and the audio measurably changed. On a deliberately unfriendly test signal, the difference between the two generations sat about 26 dB below the audio itself. Speech would fare better than my test signal. It would still be worse than leaving the file alone.
The existing MP3 to M4B walkthrough on this site declines to name a number, on the grounds that the exact bitrate is not the point. Fair enough for a page about building the book at all. This is the page where it is the point, so it gets named: 64 kbps mono, or 32 if the megabytes are what hurt.
Doing it with ffmpeg, for free
If you are willing to paste one line into Terminal, this part is free and it happens on your own Mac — nothing gets uploaded to anybody. The line re-encodes the audio and copies everything else straight through, so the chapters and their titles, the title and the artist all come out the other side.
Run it on your own book: this is one command and it works. No app required:
ffmpeg -i big.m4b -c:v copy -c:a aac -b:a 32k -ac 1 -ar 22050 \
-brand "M4B " small.m4bOn my test book that took 9,749,402 bytes down to 2,507,645 — 74 percent off — with all three chapters and their titles intact, the title and artist preserved, and major_brand reading M4B.
Two traps, both of which I walked into:
Drop -c:v copy and it fails outright. Cover art is a video stream as far as ffmpeg is concerned. Without instructions it tries to re-encode the cover to H.264, the .m4b muxer refuses to carry H.264, and you get Conversion failed! and a zero-byte file. Nothing in the error mentions the cover.
Drop -brand "M4B " and you get an M4A. The output’s major_brand comes back as M4A — a music file wearing an audiobook extension, which is the reason files land in the wrong library.
If you are comfortable in a terminal, that command is the whole answer and you can stop reading — the one thing it will not do is show you the size before you spend the hour. Whether it stays the right answer at volume is its own comparison.
What AudioBo shows you before the encode starts
The encode is not the hard part. The deciding is.
The command above will not tell you the output size until it has finished, which makes bitrate a guess you pay for in wall-clock minutes. Guess low and you have re-encoded a book you now want to redo. Guess high and you have burned an hour for nothing.
AudioBo puts the number in front of the decision. You see what the finished book will weigh before you start it rather than after — pick a setting, look at the size, change your mind, and nothing has been re-encoded yet. A book that is already as small as it sensibly gets is left where it is instead of being inflated into a bigger file that says nothing new.
That is the part that saves the afternoon. If you never want to think about kilobits again, you have everything you need from this page.
If you do want the mechanical version: AudioBo’s Build Settings dialog shows an estimated output size on each preset card before you commit, and its Custom tab prints the input on one line and the output on the next — codec, bitrate, sample rate, channels, size — so you can see the trade rather than infer it. In the version pictured on the product page, a source already at 64 kbps mono produced the same estimate on all three presets, which is the app declining to inflate a file that has nothing more to give.
That refusal is deliberate. It caps the export bitrate to the source and rounds up to the nearest supported value rather than down, so a 125 kbps source exports at 128 instead of dropping to 112. When the source is already AAC with suitable parameters, it copies the stream rather than re-encoding, at zero additional loss, per its own FAQ.
And there is one thing that only bites on exactly the books this page is about. Building a book creates temporary files, and on very long books those used to pile up until the export finished — which could ask for a surprising amount of free space and stop partway through if the disk ran out. Version 1.3.5 made them much smaller and cleans them up as the build runs, so a build now needs about 80 percent less free disk space, and if the disk does fill up the app says so in plain words.
One thing no bitrate setting touches: a book bought from a store and locked to that store’s app. AudioBo does not remove DRM and never will; the full version of that discussion is on converting M4B to MP3 on a Mac.
The setting that matters is the one you pick before the first encode. Everything after that is paying for the same audio twice.
Common questions
What is the best bitrate for audiobooks?
64 kbps mono at 22.05 kHz for a book you intend to keep, 32 kbps mono when size is the actual problem. Measured on a ten-minute test encode and scaled up, a ten-hour book comes to about 291 MB at 64 kbps and about 147 MB at 32 kbps. Stereo at 128 kbps, which some converters still default to, would put the same book at 582 MB.
How do I compress an M4B without losing the chapters?
Re-encode the audio and copy everything else through. On a test book, ffmpeg with -c:v copy -c:a aac -b:a 32k -ac 1 -ar 22050 -brand "M4B " took the file from 9,749,402 to 2,507,645 bytes with all three chapter titles, the title, and the artist intact. Both of those flags matter: without them the command either fails outright or writes an M4A.
Does converting to mono make an M4B smaller?
Not on its own. At a fixed bitrate the encoder spends the bits it was told to spend regardless of channel count — my mono and stereo encodes at 64 kbps came out 77 bytes apart on a ten-minute file. What mono buys you is that the same bitrate now covers one channel instead of two, which is what makes asking for half as much a reasonable trade rather than a sacrifice.
Can I make an M4B smaller without re-encoding?
Barely. Everything that is not audio is rounding error: a deliberately oversized 3000-pixel cover added roughly a quarter of a megabyte to a test file, and a chapter list costs a few hundred bytes. Editing metadata or chapters copies the audio through untouched, which is fast and lossless but does not shrink anything. If the audio has to get smaller, it has to be re-encoded.
Why does my Mac ignore the bitrate I ask for?
Because macOS's own AAC encoder has a ceiling in some configurations. Asking it for 80, 96, 112, 128, or 160 kbps at mono and 22.05 kHz returned the same 64 kbps audio every time, while every request from 16 up to 64 kbps was honored exactly. At 44.1 kHz mono the same encoder honored every request up to 192 kbps, so the limit belongs to that one combination and not to the format.