Daniel's been walking in circles carrying Ezra again, and he sent us a whole thing about audiobooks. Here's the situation. He started this podcast because he was building these elaborate AI research pipelines, generating beautiful PDFs he never actually read. New parent, no time, no energy — but plenty of hours pacing the house with a baby. So he turned his research questions into podcast episodes, and that's how all of this started. He's still doing it. He's literally walking Ezra around right now.
He's embarrassed about it. He picked up a couple of books recently and hasn't made progress on any of them. Audio has become his preferred medium so completely that picking up a book feels like a chore. And here's the thing — there are topics we can't do justice to in a single thirty-minute episode. He wants the depth of a book, but he wants it in his ears. Amazon's subscription model has always bugged him. The joy of collecting books is buying something you might pick up in a year, and the idea of paying monthly for the privilege of buying books doesn't make sense to him.
It's a rental model dressed as ownership. You're not buying audiobooks on Audible, you're licensing access to them inside their app. If Amazon decides to pull a title, it vanishes from your library. That's not collecting, that's subscribing to a streaming service with extra steps.
So with TTS quality crossing real thresholds lately, Daniel's asking the technical questions. What does the spec actually expect for chapter metadata and file specs? What Android players are worth using, and are they platform-agnostic? And for someone creating their own audiobooks with TTS, what do you need to know about delivery file specs and playback to actually make this work? He's not asking about the legal side, not the marketing side — just the technical pipeline from generated audio to something that behaves like a real audiobook on a phone.
So today, we're going to build a mental picture of what it actually takes to make an audiobook yourself. The technical side, soup to nuts.
Let's start with the thing that surprised me most when I looked into this. There is no single audiobook format. There's a patchwork.
And the patchwork exists because the dominant player — Amazon — built a walled garden and everyone else had to figure out their own way around it. Audiobooks are the fastest-growing format in publishing, but the ecosystem is still built around a retail model. Audible credits, DRM, proprietary apps. The DIY creation world with TTS is a parallel universe, and it has its own standards, quirks, and gaps.
Why does this matter right now?
Because TTS quality crossed a threshold in the last eighteen months. ElevenLabs, OpenAI's TTS, Coqui, Piper running locally on-device — the bottleneck is no longer voice quality. You can generate narration that most people can't distinguish from a human reader. The bottleneck now is everything around the audio. Metadata, file structure, chapter markers, player support. You can have the most beautiful synthetic voice in the world, but if your file doesn't remember where the listener stopped, it's not an audiobook. It's a very long voice memo.
So the episode breaks into three parts. What the spec expects, what players actually support, and what you need to know to ship a file that works.
Let's get into the weeds on what the spec actually expects, because it's weirder than you'd think.
The first thing to understand is that the closest thing to an official audiobook standard is the Audio Publishers Association specification for dot A A X and dot A A formats. Those are Audible's proprietary containers. Encrypted, locked to Amazon's ecosystem, and completely useless if you're trying to make your own files.
Right. For open DIY creation, the de facto standard is the M4B container. And this is where it gets interesting. An M4B file is an MP4 container with AAC or ALAC audio and embedded chapter markers. Here's the part that most people get wrong — M4B is identical to M4A except for a single flag in the file header. One bit. That flag tells the player this is an audiobook, remember my position. Without it, the player treats the file like a music album. You lose resume-on-close, chapter navigation, sleep timer integration. All of it.
One bit is the difference between an audiobook and a very long song.
One bit. The container itself — I'm going to walk through this because the structure matters when you're debugging why something doesn't work. An M4B file has three main sections. The FTYP box, which identifies the file type. The MOOV box, which contains all the metadata including the chapter track atom — that's where your chapter names and timestamps live. And the MDAT box, which is the actual audio data. If your MOOV box is at the end of the file instead of the beginning, some players won't read the chapters until the whole file downloads. That's called fast-start versus regular MP4, and it's the kind of thing that drives people insane when their chapters work in one player but not another.
So the chapter metadata lives inside the MOOV box. What does it actually look like?
It's a nested structure called the chapter track atom. Each chapter has a name and a start time in nanoseconds. Not milliseconds — nanoseconds. So chapter one starts at zero, chapter two starts at, say, seven hundred and twenty billion nanoseconds. That's twelve minutes. The tools that inject this metadata — mp4chaps, Audiobook Binder, and a really good open-source project by Nic Barker called audiobook-tools — they handle the conversion. You give them start times in a human-readable format, they write the nanosecond timestamps into the container.
Seven hundred and twenty billion. That's the kind of number that makes me want to take a nap.
The tooling abstracts it away. You don't have to count nanoseconds yourself. But if you're writing a script to do this programmatically, you need to know that's what the spec expects. And without chapters, a twelve-hour file is just one giant track. Completely unusable for anything except playing straight through with no navigation.
What about cover art and the rest of the metadata?
The spec expects embedded cover art — JPEG or PNG, ideally twenty-four hundred by twenty-four hundred pixels if you want Audible compatibility, though for personal use anything reasonable works. Plus standard MP4 tags. Title, author, narrator, album which doubles as the series name, genre, and a description field. The sort-as tags matter more than people realize. Most players use them for library organization. If you don't set the sort-as author tag, your book might show up under the narrator's name instead of the writer's.
And codec choices. This is where people waste a lot of bits.
AAC at sixty-four to one hundred twenty-eight kilobits per second is the sweet spot for spoken word. Anything above one twenty-eight is wasted on speech. The human voice has a much narrower frequency range than music. Most listeners cannot distinguish sixty-four kilobit AAC speech from three hundred twenty kilobit. It's just not there. Opus is even more efficient — thirty-two to forty-eight kilobits per second is surprisingly good for TTS voices and produces much smaller files. ALAC, the lossless option, is complete overkill for TTS. You'd use it if you're archiving from CD-ripped audiobooks, but for synthetic speech, you're just storing silence more accurately.
File size. What actually fits on a phone?
Most Android players handle files up to four gigabytes, which is the FAT32 limit on SD cards. Some older players choke at two gigabytes. For a twenty-hour TTS audiobook at sixty-four kilobit AAC, you're looking at about five hundred fifty megabytes. Well within limits. But if you're using high-bitrate stereo — which you shouldn't be for speech — you can hit two gigabytes fast. A forty-hour book at three hundred twenty kilobit stereo is pushing five gigs.
So the spec side boils down to: M4B container, AAC or Opus at modest bitrates, embedded chapters with nanosecond timestamps, cover art, and proper tags. The file itself is straightforward.
The file is straightforward. Getting the chapters right is where people bleed.
Which brings us to the hidden problems. Chapter timing drift.
This one is insidious. TTS engines don't produce consistent timing. A chapter that should be ten minutes based on word count might come out at nine minutes forty-seven seconds with one voice, or ten minutes thirteen seconds with another. The pacing varies by model, by voice, sometimes by the emotional content of the text. If you hardcode chapter boundaries based on source text word count, they'll drift out of sync. By chapter twenty, your chapter marker might be thirty seconds off.
So what's the fix?
Two approaches. The brute-force method is generate the audio first, then detect silence boundaries to split chapters. Most TTS engines insert brief pauses between sentences, and longer pauses between sections. You can use a tool like ffmpeg's silencedetect filter to find those gaps and use them as split points. The more precise method is forced alignment. Tools like Gentle or the Montreal Forced Aligner take your text and your audio and map every word to a timestamp. You get frame-accurate chapter boundaries. It's more work, but if you're producing something for distribution, it's the right way.
The second hidden problem is file naming and sorting.
This one burns everyone exactly once. Most players sort by filename, not by metadata tag. If your chapters are named Chapter One, Chapter Ten, Chapter Eleven, they'll sort as Chapter One, Chapter Eleven, Chapter Ten. Lexicographic order. The fix is zero-padded numbering. Chapter zero one, Chapter zero two, Chapter zero three. Or embed sort-order metadata directly in the M4B chapter track, which is more robust but less universally supported.
So you've got your M4B file with perfect chapters. Now the question is, what can you actually play it on?
This is where the landscape gets fragmented. Let me walk through the Android options first, because that's what Daniel asked about, and then we'll talk about what platform-agnostic actually means.
Smart Audiobook Player.
The gold standard. It supports M4B chapters natively, variable-speed playback from half speed to three and a half times, sleep timer, equalizer, automatic bookmarking. It remembers your position across sessions, it handles large libraries gracefully, and it has a character-based rewind feature — if you miss something, you can jump back by character count, not just by seconds. It's Android only. It is not platform-agnostic. There is no iOS version, no desktop version.
Listen Audiobook Player.
Solid alternative. Cleaner interface, fewer features, but it does the core things well. M4B chapters, speed control, sleep timer. Some people prefer it specifically because it's less feature-dense than Smart. Voice Audiobook Player is the lightweight option. No ads, open-source, supports M4B and Opus. It's the one you install when you want something that just works and doesn't try to be a media center.
What about platform-agnostic?
Platform agnosticism is a myth for audiobooks. iOS has BookPlayer and Bound, but they parse metadata differently than the Android players. There is no single player that works identically across Android, iOS, and desktop. The closest thing is VLC. It plays M4B files, it remembers position, but its chapter navigation is clunky and it lacks sleep timer integration. VLC is a media player that happens to handle audiobook files. It's not an audiobook player.
The self-hosted option.
Audiobookshelf. This is the most interesting solution for someone who wants cross-platform without compromise. It's an open-source server you run yourself. It streams audiobooks to any device via a web app or a dedicated client. It handles M4B chapters properly, tracks progress across devices, and supports TTS-generated files without issues. You start listening on your phone, pick up on your laptop, it syncs. The downside is you need a server. A Raspberry Pi works. An old laptop works. But it's not a zero-infrastructure solution.
So if Daniel wants to generate an audiobook and listen to it on his phone while walking Ezra, the simplest pipeline is what?
TTS engine generates individual chapter MP3s, then mux them into an M4B with audiobook-tools or Audiobook Binder, copy the file to the phone, open in Smart Audiobook Player. That's the whole loop. Piper TTS is the one I'd point people to for local generation. It's fast, it runs on-device with no cloud dependency, and the voice quality is good enough that you stop noticing it's synthetic after about ten minutes. For higher quality, ElevenLabs via API, but then you're paying per character and uploading your text to a cloud service.
Walk me through a real pipeline. Someone has a text file of a book. What do they actually do?
Step one, split the text into chapter files. That's a scripting problem, not an audio problem. Step two, feed each chapter through Piper TTS. You get one MP3 or WAV per chapter. Step three, use audiobook-tools to combine them. The command is essentially audiobook-tools m4b, point it at your chapter files, give it a title and author, and it spits out an M4B with embedded chapters. Step four, copy to your phone. Step five, open in Smart Audiobook Player and verify the chapters navigated correctly. If they did, you're done. If they didn't, you debug the chapter track atom and question your life choices.
The chapter track atom debugging is where the afternoon disappears.
It always does. There's a tool called mp4chaps that lets you dump the chapter information from an M4B file to a text file, edit it, and write it back. If your chapters are off, that's the fix. Dump, check the timestamps, adjust, rewrite.
What about distribution? If someone wants to share their TTS audiobook with friends, or sell it?
Standard M4B files with no encryption. Playable on any player that supports the format. No DRM, no subscription, no platform lock-in. The file is the product. This is the model that the music industry eventually arrived at after years of fighting it, and the audiobook industry is still resisting. Audible's entire business is built on the idea that you shouldn't be able to just have the file.
The irony being that TTS generation makes DRM irrelevant for new content. If I can generate a perfectly listenable version of any public domain book in an afternoon, the walled garden starts looking less like a garden and more like a cage.
And for books still under copyright that you've purchased, the legal question of format-shifting is its own thing — we're not lawyers — but the technical capability exists. You buy the ebook, you generate the audiobook, you listen to it however you want. The publishing industry has spent twenty years trying to prevent exactly this workflow.
Let me ask you something. You've been talking about bitrates and container formats for ten minutes. What's the actual listening experience like? Does a Piper TTS audiobook feel like an audiobook?
It depends on what you're comparing it to. Against a professional narrator like Simon Vance or Robin Miles, no. There's a flatness to synthetic voices, a lack of dramatic range. But against the baseline of just not reading the book at all — which is Daniel's actual alternative — it's transformative. You get the content. You get the ideas. You lose some of the performance, but you gain access to books that don't have audio editions, or that you already own in text form and don't want to buy again.
The performance gap is closing, though.
Fast. ElevenLabs has voices now that do emotional inflection based on context. They can sound excited, somber, curious. Give it two more years and the distinction between synthetic and human narration will be a matter of taste, not quality. At that point, the only thing protecting the Audible model is DRM and habit. And habits change.
The thing I keep coming back to is how much of this is invisible to the listener. You open an app, you press play, it works. You don't think about the M4B flag or the chapter track atom or zero-padded filenames. But every single one of those things is a decision someone made, and getting any of them wrong breaks the experience in ways that are hard to diagnose.
The spec is a collection of decisions that accumulated over twenty years, and none of it was designed with TTS generation in mind. It was designed for studios producing CD rips and Audible commissioning narrators. The DIY creator is working in the gaps between those decisions.
Which is why the tooling matters so much. Nic Barker's audiobook-tools project exists because someone got frustrated enough to build the thing that should have existed already. Piper TTS exists because someone wanted local speech synthesis that didn't phone home to a cloud. The whole ecosystem is held together by people who hit the same wall Daniel's hitting and decided to fix it.
And the walls keep moving. The next frontier — and I think this is where things get really interesting — is dynamic chapter generation. Using LLMs to parse a book's structure and insert chapter markers automatically, without manual splitting. Some tools are already experimenting with this. You feed in the full text, the model identifies section breaks, chapter titles, even sub-chapter navigation points, and writes the chapter track atom for you. No scripting, no silence detection, no forced alignment.
That closes the loop. Text in, M4B out, no human decisions in between.
We're not there yet, but we're close. Give it a year.
Hilbert: I used to do this with a razor blade.
...Go on.
Hilbert: Tape-splicing block. Nineteen ninety-nine, maybe two thousand. Small audiobook production house in Connecticut. My job was fixing narrator flubs. The narrator would cough, or misread a line, or turn two pages at once and skip a paragraph. They'd do a pickup — record the correction — and I'd have to cut the mistake out of the master tape and splice in the fix. With a razor blade and a timing chart.
Physical tape.
Hilbert: Quarter-inch magnetic tape. You mark the cut points with a grease pencil, lay the tape on the splicing block, slice it with a razor, join the ends with adhesive tape. If you cut wrong, you've lost audio. There's no undo. Chapter markers were the worst part. You had to insert a sub-audible tone at each chapter boundary so the duplication machine would know where to put the track splits on the cassette copies. I had a chart with timestamps and a stopwatch.
A stopwatch.
Hilbert: And a prayer that I didn't cut the wrong track. One time I spliced a chapter of a Terry Pratchett audiobook into the wrong order. Death showed up in chapter three instead of chapter seven. Nobody noticed for six months. Six months. The publisher called and said a listener wrote in asking why the plot made less sense than usual for Pratchett. I had to pull the master, find the splice, and redo the whole duplication run.
That's... I mean, that's a perfect Pratchett error. Death showing up early and nobody questioning it.
Hilbert: The listener just assumed it was a stylistic choice.
And now you're listening on Smart Audiobook Player.
Hilbert: Three hundred and twelve books on my phone. M4B files, proper chapters, cover art, the whole thing. I've got the tape-splicing block still. It's on my desk at home. Sometimes I look at it while my phone reads me a book and I think about how that block represents about eleven years of my life, and now a Python script does the same work in eight seconds.
Do you miss it?
Hilbert: I miss being twenty-five and having steady hands. I don't miss the razor blade. The razor blade was stressful.
The thing that strikes me is that the chapter marker problem you were solving with a stopwatch and a grease pencil is the same problem the M4B spec solves with nanosecond timestamps. It's the same information, just encoded differently.
Hilbert: Same problem, different century. The nanosecond thing is ridiculous, by the way. Nobody needs nanosecond precision for a chapter marker. That's engineers being engineers. But it works.
Hilbert, you've got three hundred books on your phone. Are any of them TTS-generated?
Hilbert: About forty. Public domain stuff mostly. Project Gutenberg texts run through Piper. I've got a script that does the whole pipeline — split, generate, mux, tag. Takes about twenty minutes for a full novel on my desktop.
Twenty minutes for something that used to take a production house weeks.
Hilbert: The quality's not the same. I'm not saying it is. But I've got forty books on my phone that I wouldn't have otherwise. For free. Generated on a machine that sits under my desk. That's not nothing.
Alright, let's wrap this up with where I think this is all heading.
The open question I keep coming back to is whether the audiobook industry's DRM-and-subscription model survives what's coming. TTS quality is converging with human narration. The tooling for DIY creation is getting simpler by the month. Once dynamic chapter generation matures, the barrier to creating a perfectly functional audiobook from any text file drops to near zero. At that point, what exactly is Audible selling?
Curation, maybe. Discovery. The performance of a great narrator will still matter — there's an art to it that synthesis hasn't captured yet. But for a huge swath of nonfiction, technical books, backlist titles that never got audio editions — the DIY approach is already better than the alternative, which is not having an audio version at all.
The misconception I want to nail down before we close is this idea that any MP3 player can handle audiobooks. That's the thing people assume, and it's wrong in a very specific way. Without the M4B flag, players treat the file as music. No resume, no chapters, no sleep timer. The container format is what makes it an audiobook, not the audio codec.
And the corollary — higher bitrate does not mean better quality for speech. Sixty-four kilobit AAC is indistinguishable from three hundred twenty for the human voice. You're not storing a symphony, you're storing someone talking.
If you want to try this yourself, start with Piper TTS and audiobook-tools. Generate one chapter, mux it into an M4B, and see if your player picks it up. That's the whole loop, and it's surprisingly satisfying. You go from a text file to something that behaves like a real audiobook in about ten minutes.
The future of audiobooks might not be buying them. It might be generating them.
Thanks to our producer Hilbert Flumingtop for keeping this show running, and for the tape-splicing stories we didn't know we needed.
This has been My Weird Prompts. If you enjoyed this episode, leave us a review wherever you listen — it helps people find the show.
We'll be back soon.
