Turn a Video File Into an Audiobook on Mac (MP4, MKV, MOV)

You have a video and you only want what is being said in it. A recorded lecture, a conference talk, a course you paid for, a documentary you would rather listen to on a walk.

The picture is the bulk of the file and none of the value. AudioBo takes the video as it is — MKV, MP4, MOV, AVI — pulls the audio out and builds a chaptered audiobook from it; the page below is that route and the by-hand one.

Getting the audio out is genuinely easy, and it is free. Turning that audio into something that behaves like an audiobook — chapters, a cover, and a player that remembers where you stopped — is a separate job, and it is the one that takes the time.

This page does both, in that order.

The short answer

There is nothing here to convert. The sound is already sitting in the video as a finished thing, and all you are doing is lifting it out into a file of its own, which is why it is over before you have taken your hand off the keyboard.

If you want a plain audio file to drop into any player, one command does it and takes under a second:

ffmpeg -i lecture.mp4 -vn -c:a copy lecture.m4a

-vn drops the video. -c:a copy says do not re-encode anything, lift the existing audio out as-is.

That is the whole top of this page. If a loose .m4a is all you needed, you can stop reading — you do not need AudioBo, and you do not need any app with a download button.

Keep going if you want the file to behave like a book.

Extraction does not touch the audio

This is worth being precise about, because the converter sites are vague about it on purpose.

A video file is not one blended thing. The picture and the sound sit side by side inside it, each already compressed and finished, and taking the sound out does not put it through anything. There is no quality setting to get wrong, because nothing is being remade.

The precise version. The audio inside an MP4 is not raw sound. It is already a finished AAC encode, stored in its own track next to the video track. Extracting it is a remux: the container is rebuilt around the same compressed bytes. Nothing is decoded, nothing is re-encoded, nothing degrades.

Want the numbers? I measured it rather than assuming. A one-hour test video — 870 MB, 720p H.264 at 1800 kbps plus AAC stereo at 128 kbps, which is roughly what a recorded lecture looks like:

Operation	Time	Output
Stream copy of the audio track	0.60 s	58.2 MB
Re-encode to 64 kbps mono, 22.05 kHz	12.7 s	29.2 MB

Hold that first row’s output size against the source. The part you wanted was 7 percent of what you were carrying.

And the proof that the copy is lossless: I hashed the audio bitstream in the source video and in the extracted file. Same MD5 both times.

The re-encode row is there for a reason, though. Half the file size, and speech at 64 kbps mono is a normal audiobook bitrate — that trade lives on audiobook bitrate and output settings, which is where the numbers belong.

The paths that do not involve a terminal

You do not have to type anything at all. Your Mac already ships with something that will pull the sound out of most videos, three menu items deep, at no cost. There is one common kind of file it refuses outright, and one myth about it that turns out to be wrong in its favour.

QuickTime Player does this natively. Open the video, then File, Export As, Audio Only. It writes an .m4a next to the original.

Two things to know before you rely on it.

The first limit is not the export, it is the decoding. macOS types an .mkv as a movie and lists QuickTime among the apps that handle it, so the file opens — and then it will not play. AVFoundation, the framework doing the actual work underneath, carries no Matroska support out of the box; I asked it to load the tracks of a test .mkv and got back AVFoundationErrorDomain code -11828, “Cannot Open”, reason “This media format is not supported.” A third-party media extension can teach the framework new formats, so this is not a law of nature. On a Mac with nothing extra installed, and .mkv being a common wrapper for recorded talks, rips, and multi-language releases, it is where the QuickTime route stops.

The second thing cuts in QuickTime’s favor, and it contradicts what most pages will tell you. Audio Only is not automatically a re-encode. The preset behind that export is named AVAssetExportPresetAppleM4A in QuickTime’s own bundle; I ran it directly against an AAC-in-MP4 file and the audio came out with the same MD5 as the source. A passthrough, same as -c:a copy. Hand it something that is not AAC and it does encode. So the difference between this route and the terminal is not quality — it is which files get through the door at all.

Web converters want you to upload a multi-gigabyte video to a stranger’s server to perform an operation your Mac finishes in half a second. There is no version of that trade that makes sense.

When the copy will not work

Sometimes the free copy is not on offer. The sound inside a video can be stored in a form an audiobook file is not allowed to hold, and then it has to be re-made rather than moved — a real conversion instead of a copy. That is mostly an .mkv problem; MP4 and MOV files almost always behave.

Mechanically, stream copy has one hard constraint: the destination container has to be willing to carry the source codec.

MP4 and MOV files usually hold AAC, which is what an M4B wants anyway, so the copy is free. Matroska is the promiscuous one — an .mkv may hold AC-3, E-AC-3, DTS, FLAC, Opus, or TrueHD, and most of those the MPEG-4 container refuses to carry at all.

Check your own file before you guess:

ffprobe -v error -select_streams a \
  -show_entries stream=index,codec_name,channels:stream_tags=language,title \
  -of compact lecture.mkv

If codec_name comes back aac, copy it and you are done.

If it comes back dts, truehd, flac, opus, or eac3, the copy is not available to you. I tried each one into an .m4a and every one failed the same way — Could not find tag for codec … in stream #0, codec not currently supported in container. Those need a real conversion.

ac3 sits between the two. It does mux into an MP4 container without complaint, and macOS reads the result back as a playable audio file. The reason to convert it anyway is not the container, it is the content. That is what the channels field in the probe is for: if it reads 6, you are looking at a surround film mix, and a multichannel film mix is an absurd thing to carry around for spoken word. So while you are converting, go mono and drop the bitrate.

ffmpeg -i lecture.mkv -vn -c:a aac -b:a 64k -ac 1 -ar 22050 lecture.m4a

Picking the right track when there are several

Multi-language releases carry one audio track per language, and the default is not always the one you want. Take whatever the file offers first and you can find out an hour into a walk that you committed to the wrong one.

There is a worse version of the same mistake, further down this section: two tracks can claim the same language, and one of them has somebody describing the scenery over the top of it.

See what your own file holds. The probe above lists the tracks. Here is what a three-track file actually reports:

stream|index=1|codec_name=ac3|channels=6|tag:language=eng|tag:title=English
stream|index=2|codec_name=ac3|channels=6|tag:language=eng|tag:title=English Audio Description
stream|index=3|codec_name=ac3|channels=6|tag:language=deu|tag:title=Deutsch

Select one by language rather than by counting positions:

ffmpeg -i lecture.mkv -map 0:a:m:language:deu -vn -c:a copy de.m4a

Now the part nobody warns you about, which I ran into while building that test file.

Two tracks can carry the same language code. An audio-description track — the one with a narrator describing the visuals for blind viewers — is tagged eng, exactly like the ordinary English track. The only things separating them are a visual_impaired disposition flag and a human-written title, and titles are frequently missing. Ask for language:eng on that file and you get both tracks, not a choice.

So in any interface that lists tracks by language, an audio-description track shows up as a second “English” with no explanation. If you see two of the same language, that is usually what the second one is. Play a few seconds before you commit an hour of listening to a stranger narrating camera angles.

The bridge: from an audio file to an audiobook

Here is where the top of this page ends and the actual goal starts.

You now have an .m4a. It plays. It has no chapters, it lands in your music library, and no player will remember where you stopped in it — which for a nine-minute clip is irrelevant and for a six-hour lecture series is the entire problem.

The difference between an audio file and an audiobook is not the sound. It is a few small notes written inside the file saying what it is and where the chapters fall — the audio itself is identical either side of that line.

In full: an audiobook file is not a different kind of audio. It is the same AAC with three declarations added: the four-character brand M4B in the file header, a media-type flag that says audiobook, and chapter markers. The full anatomy is on what an M4B file actually is.

Renaming does not do this. Check it yourself if you like — I extracted a track, copied it to .m4b, and probed it, and the header still read major_brand=M4A. The bytes did not change, because changing a filename never changes bytes. Converting M4A to M4B properly covers that specific hop.

With ffmpeg you can go straight from the video to a correctly declared M4B in one pass, still without re-encoding:

ffmpeg -i lecture.mp4 -vn -map 0:a:0 -c:a copy \
  -brand "M4B " -metadata media_type=2 lecture.m4b

Two details in there cost me a while to pin down, and neither is documented anywhere obvious:

• The brand is four characters, including a trailing space. It is a fixed-width field, not a name, and a string shorter than four characters is discarded without a word. -brand M4B leaves you with the muxer’s default. -brand "M4B " writes M4B .
• The default you fall back to is M4A . A .m4b extension makes ffmpeg pick its ipod muxer, and that muxer’s own brand is M4A . Omit -brand and you get a perfect audiobook that declares itself a music file — which is why so many hand-built M4Bs land in the music library.

That command costs the same half-second as the plain copy in the table above — it is the same stream copy, with two extra lines written into the header — and the audio bitstream came out hash-identical to the source. What I verified is what the file declares about itself, not how any particular player reacts to it — Apple Books has opinions of its own.

Where chapters come from when the source is a video

Chapters are the reason this stops being a one-liner.

Either the video came with them or it did not. If it did, they come across for nothing and you are finished. If it did not, someone has to write them, and for a video that someone is usually you — though the timings are often already sitting in text somewhere you can copy from.

If the video already has chapter markers, you are lucky, and they survive extraction. I put three named chapters into a test .mkv, copied the audio out, and probed the result — all three came through with titles and timings intact, written into both chapter formats an M4B uses. Chapters only exist if something wrote them, so a disc rip or a carefully authored MKV may have them and a screen recording will not.

If it does not, you write them. For a video the timings usually already exist somewhere in text: the timestamps under a talk, a syllabus, the slide list. Save them as a plain text file, one line each, and a converter can apply them:

0:00 Introduction
14:32 The first argument
41:05 Objections
1:12:40 Q and A

That sidecar format, and every variant of it that works, is covered in adding chapters from a timestamp file. AudioBo reads those files directly — drop the text file on the book and the chapters land on it, and a CUE sheet from a rip works the same way.

If a file comes out flat despite your best efforts, chapters written in only one of the two competing formats is the usual culprit — see why an M4B shows no chapters.

What AudioBo does with a video file

Everything above works. It is also five commands, a probe you have to read, a brand string with a load-bearing space, and a chapter file you write by hand — per book.

That is where AudioBo comes in, and it is the same operations rather than a different trick.

In practice: you drop the video in and the audio comes out of it without you ripping anything first. If the file carries more than one language, it asks which one you meant instead of guessing. The chapters sit in front of you to edit and rearrange, you put a cover on it, and what you save is one file that declares itself an audiobook rather than a music track. Several videos at once behave the same way — each one stays together as a block you can move around.

If what you are converting is a film or a series, the cover and the description can come down for you automatically, from The Movie Database — the one place that actually keeps them for video.

If you do want the mechanical version: since version 1.3.1, you drop video files straight into it — MKV, MP4, MOV, AVI and more — and it extracts the audio itself, with no manual ripping step. When a video carries several language tracks, you pick which one to use, which is the picker the section above explains the trap in. 1.3.3 made multi-video imports behave sanely: each file’s chapters stay together as a single draggable chapter you can edit and rearrange, the way joining audio files already worked. The metadata problem is different for video than for a folder of MP3s, and 1.3.1 addressed that too: a TMDB source pulls titles, descriptions, and cover art from The Movie Database, which is where a film or series soundtrack has its cover, since no book database is going to have it.

One plain sentence, because this page attracts the question: AudioBo does not remove DRM, and it does not download the video or the audio. It works on files you already have on your Mac; what it pulls over the network is metadata and cover art, never media. A purchased or streamed file that is protected stays protected, and that is not going to change.

When to stay with ffmpeg

If you are extracting audio once, or once a quarter, use the command at the top of this page. It is free, it is faster than launching anything, and it does not degrade a single sample.

ffmpeg also wins outright on anything scripted — a folder of forty conference recordings, a nightly job, any case where the answer is a loop rather than a window. The honest comparison of the two approaches is ffmpeg and m4b-tool versus a Mac app.

The app earns its place at the other end: when the source is one long video that needs to become a book with twenty named chapters, a cover, and metadata that does not look like a broken import — and when you are going to do that again next week.