Skip to content

M4B Audiobooks on an iPod Classic: The 12-Hour Wall

Updated August 10, 2026 • 12 min read

You drag the book into the sync list, the Mac thinks about it for a moment, and then declines. The message people report says the file could not be converted, which tells you nothing about what is wrong, because nothing is wrong with the file. It plays in Books. It plays on the phone.

It is too long. AudioBo has a mode built for exactly this device; the page below is what the iPod actually accepts, and why.

If you want the reasoning — and the numbers that let you cut a book without tearing a chapter in half — the rest of this page is the machinery.

Length really is most of it. An iPod Classic will play an M4B — the compatibility list AudioBo publishes for its own demo book names Classic, Nano, and Touch — and on that hardware M4B is what buys you the audiobook treatment rather than a track in the music library. What the device will not take is one continuous file for a very long book. AudioBo’s FAQ puts the ceiling at twelve hours and calls it a requirement of old iPod Classic and Nano hardware.

So the fix is not a conversion. It is a cut.

The short version

Nothing is wrong with your book — it is simply longer than the iPod will take in one piece. Twelve hours is the working ceiling for a single audiobook file on this hardware — the number the tooling for legacy iPods is built around — and the device reports it in the least useful way available — the message people report says the file could not be converted. The format is not the problem. An iPod Classic plays these books quite happily.

So the answer is not to convert the book, and not to drop its quality to make it smaller. It is to cut it into parts of twelve hours or less. Cutting costs nothing in sound quality — the audio moves across untouched — and even a twelve-hour book takes a few seconds to split.

Cut in the right place, though. Split the book where a chapter starts, not at a round number on the clock, or one chapter ends up half in each part and the device loses your place in the middle of it.

Would rather not do the arithmetic? AudioBo has a mode built for this device. It splits a long book into parts of twelve hours or less, puts every cut on a chapter start instead of a clock reading, and picks settings aimed at hardware this old — and each part keeps its chapter list rather than arriving as one undifferentiated block.

What it cannot do is unlock a book you bought from a store. If the file is locked to that store's app, it stays locked, and no amount of cutting changes that.

The ceiling is duration, not size

The first instinct is to make the file smaller. Lower the quality, shrink the megabytes, squeeze in under whatever the limit is. It does not work, and it is worth knowing why before you spend an evening on it.

The device is not counting megabytes. It is counting hours. A lower quality setting hands you a smaller file and a book that runs exactly as long as it did before, so the second attempt is refused for the same reason as the first, only now it sounds worse. Worth separating the two, because people reach for a lower bitrate first and it does not help.

Want the measured numbers? I built a real twelve-hour M4B to check: mono AAC at 64 kbps and 44.1 kHz, the kind of setting AudioBo’s own FAQ describes as often sounding identical to the original for speech. The finished file was 354,820,830 bytes. Roughly 355 MB for the full twelve hours, and a shade less at 22.05 kHz, which is where a good deal of mono narration ends up.

The product page’s own demo book agrees from the other direction: 6 hours 20 minutes of AAC-LC at 64 kbps CBR, mono, 22,050 Hz, weighing 185,043,557 bytes. About 29 MB an hour either way.

Which means a thirty-hour book, whole, would come in under a gigabyte. Nowhere near a size ceiling worth worrying about — and so dropping the bitrate does not move you under the limit, because the limit was never about bytes. Twelve hours at 32 kbps is still twelve hours.

If you want to argue about bitrates for their own sake, that belongs to output settings for audiobooks. For this problem, leave the bitrate where it is and cut the book.

Split at chapter boundaries, not on the clock

Where you put the cut decides whether the parts feel like a book or like a mistake.

Cut at a round number on the clock — five hours in, twelve hours in — and the cut lands wherever the book happens to be at that moment, which is almost always the middle of a chapter. Half of that chapter ends up at the end of one part and half at the start of the next, both halves carrying the same chapter name. The device sees two separate files and keeps your place in each of them separately, so you finish part one mid-sentence and open part two somewhere inside a chapter that already began.

Cut where a chapter starts and none of that happens. Every chapter stays whole, in one file, and each part opens at the beginning of something.

This is what separates a usable set of parts from an annoying one, and it is easy to demonstrate.

Want to see the difference measured? I built a ten-minute test book with four chapters starting at 0:00, 2:00, 4:15, and 6:30, then cut it two ways.

Cut on the clock, at the five-minute mark. What ffprobe reported back:

part 1  …  Chapter Two    120.000 → 255.000
           Chapter Three  255.000 → 300.000

part 2  …  Chapter Three    0.000 →  90.000
           Chapter Four     90.000 → 300.000

Chapter Three now exists twice. Forty-five seconds of it at the tail of part one, ninety seconds at the head of part two, with the same title on both. On the device those are two separate files, so whatever position it remembers, it remembers per file. You finish part one in the middle of a sentence, open part two, and land in a chapter that already started somewhere else.

Cut on the chapter boundary, at 4:15. Same command, different number:

part 1  …  Chapter One    0.000 → 120.000
           Chapter Two  120.000 → 255.000

part 2  …  Chapter Three   0.000 → 135.000
           Chapter Four  135.000 → 345.000

Every chapter lives in exactly one file, whole. Part one ends where a chapter ends. Part two opens on a chapter start. Nothing is torn.

Two artifacts survived even the clean cut, and they are worth recognizing. Part one picked up a 1.5-millisecond stub of Chapter Three at its very end, and part two picked up a zero-length Chapter Two at its very start. Harmless in practice — a millisecond and a half is not audible, and a zero-length chapter has nothing to play — but if a strict player shows you a ghost entry in the chapter list, that is what it is.

Doing the cut by hand

Three steps, and the commands for them are short. Find out where the chapters start. Pick the last chapter start that falls under twelve hours. Cut the book there into two files — and if the book is long enough to need a third part, do the same thing again to the second half.

The thing to get right is that the cut copies the audio across rather than rebuilding it. Nothing is decoded, nothing is re-encoded, nothing is lost, and that is also why splitting a very long book takes seconds rather than an evening.

Check your own book first: read its chapter table.

ffprobe -v error -show_chapters -of compact book.m4b

Pick a boundary near the twelve-hour mark — the last chapter start that comes in under it — and cut on that number, twice:

ffmpeg -i book.m4b -ss 0 -to 42180 -c copy -brand "M4B " "Book, Part 1.m4b"
ffmpeg -ss 42180 -i book.m4b -c copy -brand "M4B " "Book, Part 2.m4b"

-c copy does the important work. It moves the compressed audio across without decoding it, so nothing is re-encoded and nothing is lost. Both outputs from my test came back AAC-LC, 44.1 kHz, mono, matching the source stream, and the piece I asked to end at 255 seconds ended at 255.0015. Cutting is cheap in time as well: splitting the twelve-hour file took under four seconds on an Apple silicon Mac. Note the -ss position in the second command — before -i it is an input option, which is the faster of the two and was accurate to the millisecond here.

-brand "M4B " is the flag people leave off, and it decides what the file says it is. My split came out ftypM4A without it and ftypM4B with it, chapter list identical either way — the .m4b on the filename changes nothing. The trailing space is part of the value, not typographical slack. On a device whose whole appeal is the audiobook treatment, that is not a detail to shrug at. The general mechanics of cutting M4B files, including the traps that have nothing to do with iPods, are in splitting an M4B into chapters.

Codec settings for a 2007–2010 device

Two more things decide whether a part that looked perfect on the Mac behaves once it is on the iPod, and each takes a moment to check before you sync.

The first is which flavour of audio sits inside the file. There is a plain, ordinary kind that hardware this old is safe with, and there are cleverer variants — HE-AAC, xHE-AAC — that it may not handle. The second is the cover picture, which is usually far larger than anything a screen that size could ever use.

Both are habits that keep you out of trouble, and both are checkable rather than trusted.

Check it before you sync: run ffprobe on whatever you are about to copy across and read the profile line.

ffprobe -v error -show_entries stream=codec_name,profile,sample_rate,channels \
  -of default=noprint_wrappers=1 book.m4b

You want profile=LC. That is what ffmpeg’s stock AAC encoder produced in every test file I made without being asked, and it is what AudioBo’s own spec sheet lists for its demo book — plain AAC-LC is the conservative assumption for hardware this old. Exotic profiles are where hand-rolled encodes go wrong, and the failure shows up on the device rather than on the Mac, which is the worst place to find it.

The second habit is cover art. Enormous embedded artwork is a known way to make some players behave strangely, and nothing on a screen this small is going to use a 3000-pixel cover.

AudioBo’s “Vintage devices (iPod)” preset handles both without asking: it picks export settings for legacy players, applies an appropriate cover size, and splits long books into parts when the length calls for it.

What AudioBo does about the twelve-hour split

Everything above is doable by hand, and for one book I would not talk you out of it.

The part that wears thin is the arithmetic. Read the chapter table, convert chapter start times into seconds, find the last boundary under twelve hours, run the cut, then do it again for part two, and again for part three if the book is long enough — and every one of those boundaries has to be a real chapter start or you get the torn-chapter mess from earlier. Then check the profile. Then check the brand. Then sync and find out. The free demo’s 60-minute export limit is enough to watch the parts come out cut on chapter starts before paying for anything.

AudioBo collapses that into a preset. You hand it the book, choose the iPod option, and get back parts that are already short enough for the device, already cut where chapters begin, and already set to the kind of audio that hardware this old expects. No stopwatch, no turning timestamps into seconds, no finding out later that part two starts halfway through a sentence. When it finishes it tells you how long the book is, how many chapters it found, and how many parts it made.

If you do want the mechanical version: its iPod Compatibility mode does the boundary arithmetic for you — parts of twelve hours or less, every cut placed on a chapter start rather than a clock reading, and codec settings aimed at 2007–2010 hardware. Splitting by plain duration or by file size instead is a separate option, added in version 1.2.6 on April 14, 2026, and the export summary reports length, chapters, and parts.

It also writes chapters in both of the formats players look for — the QuickTime chap track and the Nero chpl atom — which is the difference between a part that shows a chapter list and one that shows a single undifferentiated block. If your source is already AAC with suitable parameters, it copies the stream instead of re-encoding, so the split costs nothing in quality.

One thing it does not do, and never will: remove DRM. A book bought from a store and locked to that store’s app stays locked.

Getting the parts onto the device

Name the parts so they sort in reading order — Book, Part 1, Book, Part 2, with the number somewhere an alphabetical sort will handle correctly. Beyond that, the parts behave like any other audiobook files, and when a sync claims to succeed and the book still is not there, the diagnosis lives on audiobooks not syncing from Mac.

If a part lands in the music library instead of the book section, that is the file’s audiobook declaration missing rather than the sync failing — the ftyp brand and the media-type flag are what buy a place in the book library, and what an M4B file actually is covers both.

Where MP3 is the better answer

There are cases where all of the above is the wrong effort, and it is worth being straight about them.

Your source is already MP3. Converting MP3 to AAC is one lossy format into another. It subtracts, and for a book you are going to hear once and delete, it subtracts for no return. Keep the MP3s.

The click wheel is your navigation anyway. If you skip with the wheel rather than open a chapter menu, per-chapter MP3s sidestep the twelve-hour ceiling by construction — no single chapter is ever twelve hours long, so there is nothing to split and no boundary arithmetic to get wrong.

The same files need to work somewhere else. Anything older than the iPod, or cheaper, or built by a company that never had a reason to care what Apple’s audiobook flag means. AudioBo’s release notes said this out loud when MP3 export arrived in version 1.2.1: MP3 is the best choice for older non-Apple players.

What you give up is the entire reason to use M4B on an iPod. An MP3 has no slot for a flag that marks the thing as a book, so the files land in the music library, the device does not hold your place, and a chapter list is not on offer. That trade is the actual decision, and M4B versus MP3 for audiobooks works through it in more detail than belongs here.

My own default, for what it is worth: books I am actually reading get built as M4B parts, because losing my place in a thirty-hour book is a genuinely bad afternoon. Everything else stays as whatever it already was.

Common questions

Why won't my M4B sync to my iPod Classic?

Length is the usual reason. AudioBo's FAQ puts the ceiling at twelve hours per file and calls it a requirement of old iPod Classic and Nano hardware, and one long continuous M4B walks straight into it. Splitting the book into parts of twelve hours or less is what clears it. The app's iPod Compatibility mode does that split automatically and aligns every cut to a chapter boundary.

Does the iPod Classic play M4B files at all?

Yes. The compatibility list AudioBo publishes for its own demo M4B names iPod Classic, Nano, and Touch, and M4B is what gets you the audiobook treatment on a device that old — the book in the book section, the position remembered. What the hardware will not take is a single file for a very long book, which is a length limit rather than a format problem.

Should I split by time or by chapter?

By chapter. I measured what a clock cut does: the same chapter title ends up in both files, forty-five seconds of it at the end of one and ninety at the start of the next. The parts are separate files, so position is tracked per file, and you finish part one mid-sentence. Cutting on a chapter start came out clean, with every chapter whole and in exactly one file.

Will splitting re-encode my audio?

It does not have to. A stream copy cuts the file without touching the samples. I split a 64 kbps mono AAC book at a chapter boundary and both parts came back as AAC-LC, 44.1 kHz, mono, unchanged — and cutting a full twelve-hour file took under four seconds. Cutting is free in quality terms. Converting the pieces to another format afterwards is not.

Is MP3 a better choice for an old iPod?

Sometimes, honestly. If your source is already MP3, converting to AAC is one lossy format into another and subtracts for nothing. If you browse by track rather than by chapter, or you want the same files to work in an old car stereo, per-chapter MP3s are the simpler object. What you give up is the audiobook treatment: position memory and a chapter list.