LibriVox M4B Files: What They Get Right, What They Miss, and How to Fix It

You downloaded a book from LibriVox, dropped the .m4b into Apple Books, and it went in without complaint. It plays. There is a cover.

Then you notice the gaps. No year. No narrator credited. Three chapter marks on a seven-chapter book.

AudioBo fixes all of that in one pass: it looks up the missing year and narrator, rewrites the chapter list, and saves the file properly declared. Below is what LibriVox files actually contain, and why.

Nothing failed, which is exactly why it is hard to fix. A file that refuses to open tells you what to do next. This one does not.

If you want to know why — and to be able to say which part of the file is at fault instead of guessing — the rest of this page is the measurement. I have downloaded a lot of these, and the pattern looked consistent enough to measure rather than assert.

How the measurement was done

Everything below comes from twenty real books, picked by a rule rather than by hand: the first twenty LibriVox hands out, whatever they turned out to be. That matters, because the alternative is one bad download retold as if it were a pattern.

Twenty books in the order LibriVox’s own API hands them out — librivox.org/api/feed/audiobooks with extended=1, the first twenty entries that publish a download. No selection, no hunting for bad examples. For each, the first .m4b its archive.org item publishes — eight of the twenty publish more than one — read over HTTP range requests.

Two tools, deliberately: ffprobe for streams and chapters, and a direct parse of each file’s moov/udta/meta/ilst atoms for the tags — because ffprobe alone got one of these questions badly wrong, which turned out to be the most interesting result of the lot.

Want to check a book of your own against this? One command reproduces every column: ffprobe -show_format -show_chapters yourbook.m4b prints the tags and the chapter list — the same two things every row below reports.

What twenty LibriVox M4B files actually contain

Read the table in two halves. The first rows are the file describing itself, and it describes itself in two contradictory ways. Everything under that is what was actually written down about the book — and the answer is mostly nothing. No year, no description, nobody credited with reading it. The picture made it in; the words did not.

What I checked	Result across the twenty
ftyp brand declares M4B	0 of 20
ftyp brand declares M4A	14 of 20
ftyp brand declares mp42	6 of 20
stik media type set to 2, Audiobook	20 of 20
Year (©day)	missing in 20 of 20
Description (desc)	missing in 20 of 20
Album artist (aART)	missing in 20 of 20
Narrator, in the composer field (©wrt)	missing in 19 of 20 — the twentieth holds the author’s name
Track number (trkn)	missing in 11 of 20
Nero chpl chapter list	missing in 20 of 20
Embedded cover art (covr)	present in 20 of 20

Two rows contradict each other on purpose, and one of them corrects my own first pass.

The contradiction that makes these files half-work

Every file says it is an audiobook. Not one says it is an M4B.

That sounds like pedantry until two apps disagree about the same file in front of you. One puts it on the book shelf and remembers where you stopped listening; the other does not. Neither is malfunctioning. They are asking the file different questions, and the file gives them different answers.

The stik atom — the iTunes media-type flag — is set to 2, Audiobook, in all twenty. That is the declaration that earns a file resume-where-you-left-off behavior and a place on the book shelf rather than in the music library. The ftyp atom at the very start, the four characters naming what kind of MPEG-4 this is, says M4A in fourteen of them and mp42 in the other six. Never M4B.

So the file makes two claims about itself and they disagree. Software that reads the media type shelves it correctly; software that reads the brand does not. Neither is wrong. The file is arguing with itself and different apps believe different halves — which is why these books behave oddly instead of failing cleanly. If the brand question is new, what an M4B file actually is takes the container apart properly.

A smaller detail underneath: thirteen of the fourteen M4A files write the brand as M4A plus a null byte, rather than the trailing space the four-character code calls for. exiftool reports it as Unknown (M4A), and AtomicParsley refuses to open them at all — unsupported MPEG-4 file brand found 'M4A'. A widely used tagging tool will not touch these files.

The cover art row, which I got wrong the first time

If what brought you here is a blank square where the cover should be, start with this: the cover is in the file. All twenty have one. Whether you ever see it depends on which program is drawing the shelf, and that is not something you can fix by re-downloading the book.

My first pass used ffprobe alone and reported that eleven of the twenty carried no cover art. That is reproducible — I ran it again and got the same eleven. It is also wrong: all twenty carry an embedded cover, between 11 KB and 442 KB of JPEG or PNG in the covr atom.

The difference is one flag. The iTunes metadata format tags each value with a type indicator: 13 means JPEG, 14 means PNG, 0 means implicit — work it out yourself. Thirteen of the twenty write the cover with type 0, and ffmpeg goes by that flag, so it reports nothing. That accounts for eleven of them. The other two — The Count of Monte Cristo and The Divine Comedy — carry a second JPEG track beside the cover, one image per chapter, and ffmpeg reports that one instead. A picture comes back and it is not the cover; in Monte Cristo’s case it is a black square.

exiftool finds the picture. MediaInfo finds the picture. AVFoundation, the media framework Apple ships in macOS, finds it too — I loaded The Canterville Ghost through it and got 23,648 bytes of artwork back from a file ffprobe calls artless.

So “why is my library tile blank” depends on what draws the tile. On Apple’s stack the cover is there; in anything built on ffmpeg, and much self-hosted library software is, it is not. Same shape as the brand: the data is present, the declaration is unusual, half the ecosystem sees it.

One book, in full: The Canterville Ghost

One file taken apart end to end, so the rows above have something solid underneath them. This is a good recording by a real person, and it carries the whole pattern: the wrong label on the outside, empty fields on the inside, and chapter marks that are not chapters.

The LibriVox recording of Oscar Wilde’s The Canterville Ghost, read by David Barnes. A 38 MB .m4b, one hour twenty-three minutes, mono AAC at about 63 kbps. Its first twenty-four bytes:

0000 0018 6674 7970 4d34 4100 0000 0000  ....ftypM4A.....
3367 7035 6973 6f6d                      3gp5isom

The brand is M4A plus a null. The compatible-brands list is 3gp5 and isom — 3gp5 is the 3GPP Release 5 brand, registered to a mobile spec, not to iTunes — and neither M4A nor M4B appears in it. The encoder tag reads Chapter and Verse V 1.4; the creation timestamp is 16 September 2011.

Three chapter marks:

Chapters 1 to 3    0:00:00 — 0:36:46
Chapters 4 to 5    0:36:46 — 1:01:50
Chapters 6 to 7    1:01:50 — 1:23:09

The Canterville Ghost has seven chapters. The marks say so themselves, in their own titles, while giving you three places to jump to.

Here is where they came from. The archive.org item publishes the recording as three MP3 sections next to the M4B — cantervilleghost_1-3_wilde.mp3 at 2206.64 seconds, _4-5_ at 1504.23, _6-7_ at 1278.45. The M4B’s chapter boundaries land at 2206.01, 3710.02, and 4989.27 seconds: within a second of those same three numbers, accumulated. These are section boundaries, not chapter boundaries. The volunteer recorded the book in three sittings, and the assembler turned each sitting into a chapter.

Want to check your own book? The MP3 sections are still on its archive.org page, sitting right next to the M4B. Count them, then count the marks your player offers you.

One more oddity in the same file: the chapter text track declares its language as und. Ask AVFoundation for the chapters best matching English and it returns zero; ask without a language preference and it returns all three.

LibriVox is not the villain in this story

Worth saying plainly, because everything above reads like a complaint and it is not one.

LibriVox is a volunteer project that records public-domain books and gives them away with no account, no payment, and no rights reserved. This item carries a public-domain dedication and credits David Barnes as the reader. Somebody sat down and read Oscar Wilde aloud for free, and the result is on the internet forever.

The M4B is a convenience build layered on top of that work, assembled here by one of two desktop utilities of the era: Chapter and Verse in thirteen books, the Mac app Audiobook Builder in seven. The creation timestamps run from May 2008 to September 2013 — files made while the tagging conventions this page measures them against were still settling, by tools doing precisely what they were told with the material they were given.

Nobody was careless. A volunteer recorded three sections, and a 2011 utility turned three sections into three chapters, which is the only honest thing it could have done with them.

It is also not universal. Where the volunteer recorded one file per chapter, the M4B is genuinely good — The Secret Garden carries 27 marks with the real chapter titles on them, “There Is No-One Left” and “Mistress Mary Quite Contrary” and the rest. Huckleberry Finn has 43. The chapter problem is a property of how a book was recorded, not of LibriVox.

And the raw material for a better build sits right beside the M4B, free: LibriVox publishes the individual MP3 sections for every book. Rebuilding from those sections — real chapters, real titles, one clean file — is exactly the job AudioBo exists for; the MP3-to-M4B walkthrough is the long version.

What each gap actually costs you

None of this stops a book from playing, which is why it is easy to shrug off. It starts to matter once you have more than a handful of them and the shelf tries to put them in some order.

Year and album artist, blank in all twenty. Anything sorting a shelf chronologically or grouping it by author has nothing to read. Not a preference — the bytes are not there.

The narrator, absent. Nineteen of twenty leave the composer field empty and the twentieth puts the author’s name in it. On a project whose defining quality is who read this, David Barnes is credited by LibriVox and anonymous inside the file. The description field is empty in all twenty as well, so the book page has nothing to say about the book.

Chapter marks you cannot navigate by chapter. Three marks for seven chapters means you can reach a 37-minute block, not Chapter 2.

No Nero chpl list. All twenty carry chapters as a QuickTime text track only. Apple’s stack reads that, so Books is fine; tools that read only chpl see a flat file — the subject of M4B with no chapters.

The free fix, which is real and has limits

The half of this that is fixable is fixable for nothing, and that is worth knowing before any app is mentioned. What changes is the label on the file, not the audio inside it — nothing is re-compressed, so nothing sounds worse afterwards.

Want to do it yourself? If all you want is a file that declares itself honestly, ffmpeg does it in about a second with a stream copy. Nothing is re-encoded.

ffmpeg -i CantervilleGhost_librivox.m4b -map 0:a -c copy \
       -brand "M4B " fixed.m4b

I ran that on the file above. The output’s brand is M4B , exiftool now names it “Apple iTunes AAC-LC (.M4B) Audio Book”, all three chapters survive, stik stays at 2, and ffmpeg throws in a Nero chpl list for free.

Three traps I hit getting there:

The trailing space is not optional. -brand M4B is silently ignored — the output still said M4A . Brands are four characters. -brand "M4B " works.

Do not map everything. -map 0 fails with Tag text incompatible with output codec id, because the ipod muxer refuses the file’s existing chapter text track as a stream. Map the audio only and let -map_chapters, on by default, carry the chapters across.

The cover disappears. On the eleven files ffmpeg cannot see a cover in, it writes none out — AVFoundation reports 23,648 bytes of artwork on the source and nothing on the output. Extract it first:

exiftool -b -CoverArt CantervilleGhost_librivox.m4b > cover.jpg

ffmpeg -i CantervilleGhost_librivox.m4b -i cover.jpg \
       -map 0:a -map 1:v -c copy -disposition:v attached_pic \
       -brand "M4B " \
       -metadata date=1906 \
       -metadata album_artist="Oscar Wilde" \
       -metadata composer="David Barnes" fixed.m4b

That output carries the M4B brand, artwork AVFoundation can read, the three chapters, and the fields typed on the command line. The 1906 is the year LibriVox’s own catalog record carries for this edition — the date tag describes the recording you have, not the author’s first printing, so copy it from the catalog page of your own book.

Which is the honest boundary of the free path. It fixes declarations, and it writes fields you already know. It will not tell you the narrator, find a description, or turn three section marks into seven chapters — and for a shelf of forty LibriVox books, it is forty rounds of the same typing.

What AudioBo does with a LibriVox book

AudioBo is the version of that command line you do not have to remember. The sample audiobook on its product page is itself built from a LibriVox recording, which is not a coincidence.

In ordinary terms: you open the book, and the fields LibriVox left blank get looked up for you — the year, the description, the person who read it, the series it belongs to. Nothing is written until you have seen what it proposes and picked what you want, so you can take the year and the narrator and keep LibriVox’s own title.

Chapter titles get rewritten as a whole list rather than one mark at a time, and the ones that arrived as gibberish — Spanish accents turned into code, Czech and Russian and Ukrainian titles scrambled — come back readable. What you save is a file that says plainly what it is, so both halves of the ecosystem shelve it the same way. And a shelf of forty of these stops being forty rounds of the same typing.

It still cannot rescue chapters the recording never had. Three sittings stay three marks, here as anywhere else.

If you do want the mechanical version — the parts that map onto the table above:

The container. Exports carry the M4B brand in ftyp, with chapters written in both the QuickTime and Nero formats, so both halves of the ecosystem read them.

The empty fields. Fetch Metadata (1.2.3) searches Audible, Apple Books, MusicBrainz, and Google Books for the year, description, narrator, series, and cover these files leave blank. Since 1.2.8 you pick which fields to apply, with a color-coded diff — useful here, since you usually want the year and narrator while keeping LibriVox’s own title. The walkthrough of that feature covers each source’s strengths.

The chapter titles. The Regex tab in Batch Rename (1.3.2) rewrites a whole list with a live before-and-after preview. It cannot split three marks into seven — nothing can, the audio was recorded in three pieces — but it turns 43 entries reading Ch. 1 into something worth looking at.

The mangled characters. Fábulas de Esopo ships chapter titles like 001 El águila, el cuervo y el pastor — HTML entities written straight into the tag. AudioBo 1.2.9 translates those back on import, and 1.3.4 does the same for the scrambled Czech, Russian, and Ukrainian titles common in older files.

The shelf. Sort As (1.3.4, read-back fixed in 1.3.5) sets the sort text by hand when the automatic rule is not what you want — which matters once you have forty of these.

Getting back out. Export to M4A or MP3 (1.2.1), for players that want nothing to do with Apple’s container. If MP3 is the destination, converting an M4B to MP3 on a Mac walks that path, including what gets lost.

One thing it does not do: remove DRM, and it never will. That will not bite you here — LibriVox recordings are public domain and unprotected — but it is worth saying where the subject comes up.

If your book’s chapter marks are section marks, rebuild from the MP3 sections rather than repair the M4B — converting MP3 to M4B on a Mac is that workflow end to end. If the container is fine and only the tags are wrong, editing M4B metadata, cover, and chapters is the shorter road.