Can you convert M4A to M4B without losing quality?

Yes, and this is the one conversion where that is literally true. M4A and M4B hold the same AAC audio in the same MPEG-4 container, so the audio stream is copied rather than decoded and re-encoded. I checked a converted file against its source: identical audio stream MD5, identical decoded PCM. Nothing is recompressed, so nothing is lost.

How long does converting M4A to M4B take?

Seconds, because nothing is being encoded. A six-hour, 175 MB M4A took 1.2 seconds to remux into an M4B on my Mac. Re-encoding the same file at the same bitrate took 68 seconds — about 57 times longer — and came back with a different decoded PCM hash, which is a second generation of lossy compression for nothing. If a converter takes minutes on one book, it is transcoding audio that did not need it.

Can I convert M4A to M4B by renaming the file?

Sometimes, and it costs five seconds to find out, so try it before you convert anything. Renaming is a filesystem change, not a file change. Run mdls -name kMDItemKind on both copies and you can watch macOS retype the same bytes: on macOS 26.6 the kind string went from Apple MPEG-4 audio to Protected mpeg 4 audiobook. Whether that is enough depends entirely on which of the two your player asks.

Why does my converted M4B still show up as music?

Because the container never declared itself. ffmpeg copies the audio happily but leaves the brand as M4A unless you pass -brand "M4B ", and it writes the iTunes audiobook flag only if you ask with -metadata media_type=2. Both are one-line additions to the same command, and neither touches the audio.

Does converting M4A to M4B add chapters?

No. Chapters are data that has to exist before it can be written, and most single-file M4As have none. You can supply them in the same pass from an ffmpeg metadata file with timestamps and titles, which costs no extra time because the audio is still only being copied. Without that step you get a chapterless audiobook.

How to Convert M4A to M4B on a Mac Without Re-Encoding

You have an .m4a that is clearly a book. It plays fine. Apple Books files it next to your music, offers no chapters, and forgets where you were the moment you close it.

And the thing everybody assumes at this point is reasonable: it is already AAC, already an MPEG-4 file, so this cannot be a real conversion. It has to be a rename. It is not — and the honest shortcut is AudioBo, which imports the M4A as it is, copies the audio across without re-encoding, and writes out a file that declares itself an audiobook. The rest of the page is what actually changes inside.

Half right. The audio genuinely does not need touching. Something else does.

The short version

The sound in your file is already correct — there is nothing to convert. An M4A and an M4B are the same kind of file holding the same audio. What is missing is the label that tells a player "this is a book, not a song", and usually a list of chapters. Writing those takes about a second and does not touch a note of the audio.

So try renaming it first. Duplicate the file, change the ending from .m4a to .m4b, and open it in whatever you actually listen with. Some players want nothing more than that. Others look inside the file, where nothing has changed, and go on treating it as music — those are the ones you convert for.

Either way it should be over in a moment. If a converter grinds away for minutes on one book, it is re-compressing audio that was already fine, and you get a slightly worse file for the trouble.

More wrong with the book than its label? AudioBo imports M4A as it is, copies the audio across instead of re-encoding it, and writes out a file that declares itself an audiobook and carries its chapters. It is for the case where the label is not the only thing wrong — chapter names that arrived as garbled symbols, a missing cover, an author field that says Audible.

What it will not do: make a player show something that player does not support, or open a book you bought that came encrypted — AudioBo does not remove DRM and never will.

The same audio, a different label

Nothing here is a conversion in the usual sense of the word. Nothing is squeezed, shrunk or re-recorded: the audio comes out of one wrapper and goes straight into an identical one, with different writing on the outside. That is why it is over in about the time it takes to copy the file.

M4A and M4B are the same container holding the same codec. Converting between them does not decode or re-encode anything — it rewrites the index and the labels around audio that stays exactly as it was.

Want to see it for yourself? Time both on the same file. I measured it on a six-hour test book, 175 MB, AAC at 64 kbps mono:

remux    (-c copy)          1.2 s
re-encode (-c:a aac -b:a 64k)  68 s

Fifty-seven times slower, for a file that came out marginally smaller and measurably different — a second generation of lossy compression applied for no reason.

If a converter takes minutes on one M4A, it is transcoding audio that did not ask to be transcoded.

Why this is nothing like MP3 to M4B

If you have made an audiobook out of MP3s before, you will remember it taking a while, and you may be bracing for the same wait. Do not. Those are two different jobs that happen to end at the same kind of file, and only one of them has to put the audio through the mill again.

The MP3 route has to re-encode, and the muxer will tell you so if you try to skip it. Copying an MP3 stream into a .m4b fails outright: Could not find tag for codec mp3 in stream #0, codec not currently supported in container. So every MP3-to-M4B conversion decodes and compresses again — AudioBo’s own FAQ says the same thing about MP3 sources, plainly. That is a real cost, and the MP3 workflow is a genuinely different job.

M4A is already at the destination. The audio has nowhere to go.

What you are actually changing is three small things: a four-character brand in the file header, one iTunes flag, and a chapter list that may not exist yet. All of it is bookkeeping, and it costs about a kilobyte.

Can you get away with renaming it?

Try it. It takes five seconds and it is completely reversible.

Duplicate the file, change .m4a to .m4b, drop it into whatever you actually listen with. If it behaves, you are done, you did not need a converter, and you did not need this page.

The bytes do not move — the byte-level account of a renamed M4B hashes both copies and works through the two declarations a real M4B carries that a renamed one does not.

What changes is entirely outside the file. macOS types by extension, so on macOS 26.6 the same bytes went from kMDItemKind = "Apple MPEG-4 audio" to "Protected mpeg 4 audiobook", protection or no protection.

Check it on your own Mac: run mdls -name kMDItemKind on both copies and the switch is one line of output.

That relabeling is the whole trick, and also its limit: a player that decides from the extension, or from what macOS says the type is, now puts the file on the audiobook shelf. A player that reads the header sees an M4A with a misleading name. Filesystem change, not a file change.

So: rename first. Convert when the rename is not enough.

The command that actually converts it

One line, and it finishes before you have read to the end of it. In plain terms it does two things: carries the sound across without touching it, then writes the small declarations that make the file announce itself as a book rather than a song. That announcement is the entire conversion — the part a rename cannot do, because a rename never changes anything inside the file.

ffmpeg -i book.m4a -c copy -brand "M4B " -metadata media_type=2 book.m4b

Three flags, each doing one specific thing:

-c copy copies the audio stream instead of encoding it. This is the flag that makes the whole operation lossless and instant.
-brand "M4B " writes the audiobook brand into the ftyp atom. Four characters, trailing space included, and the quotes matter.
-metadata media_type=2 sets the iTunes stik flag to Audiobook. AtomicParsley reads it back as Atom "stik" contains: Audiobook.

Leave the last two out and you get something worth knowing about. I ran ffmpeg -i book.m4a -c copy book.m4b on a file ffmpeg had written itself, and the output was byte-for-byte identical to the input — same MD5, same size, different extension. A rename with extra steps. On an M4A produced by a different encoder the container did get rewritten and came out slightly smaller, but the brand still came out as M4A.

ffmpeg names the output file .m4b because you told it to. It does not infer what you meant by that.

The audio really is untouched. Comparing source and output:

audio stream MD5   5292d831c60bcba63c87d5c7427a9459   (both files)
decoded PCM MD5    a3ee58240e27c44780fff51e76cde4c7   (both files)

Same samples in, same samples out. The re-encoded version of the same file came back with a different PCM hash, which is what a lost generation looks like when you can measure it instead of arguing about it.

Chapters, in the same pass

Most single-file M4As have no chapters, and converting the container does not invent any. If you want them, supply them here — it costs nothing extra, because the audio is still only being copied.

Write a metadata file with your timestamps:

;FFMETADATA1
title=The Book
artist=A Narrator

[CHAPTER]
TIMEBASE=1/1000
START=0
END=40000
title=Chapter One

[CHAPTER]
TIMEBASE=1/1000
START=40000
END=80000
title=Chapter Two

Then fold it into the same conversion:

ffmpeg -i book.m4a -i chapters.txt \
  -map_metadata 1 -map_chapters 1 \
  -c copy -brand "M4B " -metadata media_type=2 \
  book.m4b

The audio stream MD5 came out identical to the source again, chapters and all. Three chapters plus the brand plus the audiobook flag added 799 bytes to the file.

ffmpeg writes chapters in both of the formats players look for — I found the QuickTime chapter text track with its tref/chap reference and a 79-byte Nero chpl atom in the same output. That matters more than it sounds, and why chapters vanish between players is the page for it.

One trap before you run that: -map_metadata 1 replaces the file’s whole tag set rather than merging into it — a source tagged with six fields came back holding only the two the metadata file listed, cover intact, which is what makes it easy to miss. If you want to keep the tags the M4A already has, take the chapters from the second input and nothing else:

ffmpeg -i book.m4a -i chapters.txt \
  -map_metadata 0 -map_chapters 1 \
  -c copy -brand "M4B " -metadata media_type=2 \
  book.m4b

Verify rather than assume

A converted file looks no different in Finder, and a player that still files it under music does not tell you which of the two declarations went missing. Rather than guess, ask the file what it says about itself.

Check your own file: three commands, and they take a second:

exiftool -MajorBrand book.m4b
ffprobe -v error -show_chapters -of compact book.m4b
AtomicParsley book.m4b -t | grep stik

You want Apple iTunes AAC-LC (.M4B) Audio Book, one line per chapter, and Atom "stik" contains: Audiobook. If the first one still says .M4A, the brand flag did not make it into your command.

Two things that quietly go wrong

Both of these hand you a file that looks finished and is not, with nothing on screen to say so.

The brand does not survive the next remux. I took a correctly branded M4B and ran it through ffmpeg -c copy once more — the stik flag came through fine, the brand dropped back to M4A . Every remux needs -brand "M4B " restated. Editing metadata later is the same operation with the same trap, covered in editing an M4B’s tags, cover, and chapters.

The M4A might not be AAC. M4A is a container, and Apple Lossless lives in it too. It remuxes into a .m4b without complaint, and a lossless M4B is perfectly constructible — it is just a strange thing to build for speech. One minute of my test signal came to 487 KB as 64 kbps mono AAC and several times that as ALAC; the exact multiple depends on the material, and lossless loses that comparison on any real speech recording.

Check before you assume:

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

If it says alac, this is one of the rare cases where re-encoding is the right call.

If it is a store purchase

Audio bought from a store can be encrypted, and no stream copy reaches encrypted audio — ffmpeg never sees usable samples. AudioBo does not remove DRM and never will. Converting M4B to MP3 lays out how to tell where you stand, including the one-line decode test that answers it.

More than one M4A

If your book arrived as a folder rather than as one file, joining is quick for the same reason converting is: nothing gets re-recorded on the way through. The trouble is what joining does not do for you, and what it will do without warning you.

If the book arrived as a folder of M4A files, joining them is also a copy operation — ffmpeg’s concat demuxer turned three 30-second parts into a 90-second M4B in under a tenth of a second with -c copy — but it comes with two catches, and the second is nasty: concatenation produces no chapter marks at all, and the parts have to share sample rate and channel count, or nothing warns you. I joined a 22.05 kHz mono file to a 44.1 kHz stereo one and got a 120-second file out of 60 seconds of audio, exit code 0, not a single warning. The multi-file case is properly covered in the MP3 to M4B workflow, where merging and chaptering are the whole point.

When re-encoding is the right answer anyway

Copying is correct by default, not always. Re-encode when the file is too big for the device it is going to, when a stereo narration would be fine in mono at half the size, or when the source bitrate is extravagant for speech. That is a size decision rather than a format one, and audiobook bitrate and output settings works through the numbers.

Re-encoding to “make it an audiobook” is the version to avoid. The container change never required it.

What AudioBo is for — and when ffmpeg is all you need

For one file you already have the command, and it is faster than downloading anything. ffmpeg is the correct tool for this job and it is free.

It stops being the correct tool at the point where the M4A is not the only thing wrong. Chapter titles that came in as garbled symbols, a cover that is missing, an author field that says Audible, twelve files whose sort order is not the reading order — none of that is fixed by a container change, and hand-authoring an FFMETADATA file with timestamps you have to find by scrubbing is an evening.

AudioBo is that evening done differently. You bring the file in as it is, put the chapter names, the cover and the fields right where you can see them, and get out an audiobook that says what it is. The audio is copied rather than re-encoded, so the export is as quick and as lossless as the command above — and a book you already made can be corrected without being rebuilt, which is the part that saves the evening.

If you do want the mechanical version: AudioBo takes M4A as a native import format alongside MP3, M4B, AAC, FLAC, AIFF and the rest, and it makes the same call this page argues for: when the source is already AAC with suitable parameters, it copies the stream rather than re-encoding it, at zero additional loss, per its own FAQ. Exports carry the real M4B brand and chapters in both formats. Since 1.2.2, ⌘U writes edited tags, covers, and chapter names straight back into an existing file with no re-encoding — M4B, M4A, MP3, FLAC, OGG, or AIFF. Since 1.2.9 it imports xHE-AAC books and edits them in place, though exports there convert to standard AAC, because xHE-AAC encoding is licensed exclusively by Fraunhofer.

What it does not do, and it is the line that matters here: AudioBo does not remove DRM and never will, so a store purchase that came encrypted stays encrypted — no stream copy reaches encrypted audio. It builds and repairs the file, not the player: it cannot make a player show something that player does not support, which is why the five-second rename at the top of this page is worth doing before any of it.

The audio in your M4A was already right. Everything this conversion changes is paperwork — which is exactly why it should take a second and cost nothing.