I Just Want to Own My Audiobooks

· Medium ·

6 min read Original article ↗

Andrew T. Marcus

I paid the library’s replacement fee. I should own that book.

Press enter or click to view image in full size

Wanted in six states for audiobookjacking. The Spring Public Library has my number.

Sometime in the early nineties, I checked out Dune on cassette from my local library — a box of tapes, the kind of object that implies commitment. This was before Dune was a thing, before the films, before it was culturally legible outside of science fiction circles. I listened to it so many times I couldn’t bring myself to return it, and eventually I just paid the library’s replacement fee and considered us square.

In 1999, I wanted to rip those cassettes to MP3. I could see which way the wind was blowing with physical media. I didn’t have a sophisticated theory about it — I just wanted to own my stuff. My actual stuff, on a drive I controlled, in a format that would still work in ten years regardless of what any company decided to do with its subscription model or its licensing agreements or its app redesign.

That instinct has aged well. I have no interest in the Audible ecosystem. I don’t want to rent books I’ve already paid for. I don’t want my library to live inside someone else’s app, subject to removal or region-locking or whatever comes next. I want files. My files.

Those 1999 MP3s still exist somewhere. Getting them into a form I can actually use — properly chaptered, correctly tagged, playable on any device without babysitting — is where the story gets complicated.

Why MP3 folders aren’t enough

For music, folders work fine. A ripped CD becomes a folder of tracks, your player reads them, done. Audiobooks are different, and the difference is chapters.

An audiobook isn’t a playlist of discrete things. It’s one continuous thing that needs internal structure — named chapters, timestamps, a way for your player to say “you’re in Chapter 14: The Trial” and let you jump around without scrubbing through hours of audio. That structure has to be embedded in the file itself, not just implied by filenames.

The format that handles this properly is M4B — basically AAC audio inside an MPEG-4 container with real embedded chapter markers and bookmarking. Apple Books, Overcast, Audiobookshelf, BookPlayer — they all read it natively. One file, correctly structured, plays right everywhere.

The problem is that getting from a folder of MP3s to a clean M4B is genuinely annoying, and the tooling situation has been a graveyard for years.

The tools I tried

iTunes actually handled this well. The audiobook management was solid — you could organize, tag, and play local files without fighting the software. I liked it enough that when Apple replaced it with Music, I kept running an old version of iTunes through increasingly convoluted workarounds just to hold onto that functionality. For a while I was doing legitimately weird things to keep a deprecated app alive on a current OS, because the replacement was so much worse. Apple took one of iTunes’ best features, moved audiobooks to the Books app, and made local file management actively hostile in the process. It’s genuinely bad, and I think it deserves to be said plainly.

AudioBook Binder was for years the Mac answer for actually building M4B files. You dragged in a folder, set some metadata, hit go. The problem: it still technically runs, but it will silently fail at the end of a long encode — you wait 45 minutes, get nothing, no explanation. And even when it works, chapter editing is barbaric. You type titles into fields with no way to hear what’s at that timestamp. If your files are named Track 01 through Track 93 from a 1999 rip, you’re guessing. There’s no queue either — encoding is CPU-intensive, running multiple windows simultaneously doesn’t really work, so you end up babysitting it one book at a time.

ffmpeg scripts are the power-user fallback, and I wrote several. They work until they don’t — a corrupted MP3 header, mixed sample rates in the same folder, a filename with an unexpected character — and when they fail, they fail with a wall of output you have to read carefully to find the actual error. No chapter preview. No queue. Fine for one book occasionally. A tax you pay every time for a collection.

The specific things I kept wanting that nothing gave me:

  • The ability to hear what’s at a chapter boundary before naming it
  • Cover art from a URL, without having to download an image file manually
  • A queue so I could stage 20 books and let them run overnight
  • The ability to fix chapters on an existing M4B without re-encoding the whole file
  • Automatic repair of damaged MP3s before the encode starts, rather than mysterious failures after

What I built

Press enter or click to view image in full size

Eventually I stopped trying to patch together other tools and just built one.
I called it m4Bookmaker.

It’s a desktop app for Mac and Windows with a proper GUI — drag in a folder, set your metadata, edit chapters with a built-in audio player that lets you click any chapter row and hear exactly what’s there, then hit Convert. For existing M4B files, Edit mode lets you rename chapters and adjust timestamps without touching the audio stream. There’s a batch queue. Cover art accepts a URL. Every input file gets analyzed before encoding, damaged MP3s are repaired automatically, and output settings are matched to your source — no silent upconversion. It’s built on ffmpeg — the standard for audio encoding — so the pipeline is the same battle-tested tooling everyone else relies on — the difference is that you don’t have to fight with it.

Everything the GUI does is also available on the command line, for scripts and automation:

for dir in ~/Audiobooks/*/; do
m4bmaker "$dir" --output ~/Output/
done

It’s open source under GPL-3.0 and free on GitHub. The pre-built download — Mac and Windows, ffmpeg bundled, no Python, no setup, just open and run — is $4.99. Part of that covers the Apple developer account required to sign and notarize the Mac app so it doesn’t get flagged by Gatekeeper. The rest supports continued development. Functionally it’s identical to building from source.

I built it because I was tired of working around tools that were almost right, and because I think the ability to manage your own media without depending on a platform is worth maintaining. If you’ve been living with the same problem, I hope it saves you some time.

m4bookmaker.sageframe.net