Audiobook File Naming Convention and Folder Structure That Scans Correctly

The book itself is fine. You checked. Chapters are named, the cover is embedded, the tags are clean, it plays from end to end.

Then a library scans the folder and everything breaks. One book becomes three. The author says “Disc 2”. Every title sorts under T, because they all start with “The”.

AudioBo skips the whole problem: it builds the book as one file with the sort fields filled in. The page below is the rules themselves, for when you want them.

If you want to know which layout, and why a folder that looks perfectly ordered to you hands a scanner the wrong sequence, the rest of this page is the machinery.

The folder decides what a book is. The chapters describe what is inside one.

These are two different layers and they fail independently, which is why fixing one never fixes the other.

A chapter table lives inside a single file. It answers “where are we in this book”. It has nothing to say about which files belong together, what the book is called, who wrote it, or where it sits in a series — those questions get answered before any audio is opened, from the path.

Audiobookshelf states it about as plainly as software documentation ever states anything: “Books are defined as a folder. Single file books can be in the root folder of the library, but otherwise every book must be in its own folder.” Two books sharing a folder are one book with strange chapters. One book split across two sibling folders is two books. Your chapter table has no vote.

Apple Books is the opposite extreme. It copies every import into a container of its own and files it in a folder named after a hash, not after anything you typed. Whatever tree you built outside — author, series, year, all of it — did not come along. For Books, folders are for you and tags are for the app.

So the honest answer to “what is the correct folder structure” is: correct for what. A layout that makes Audiobookshelf happy is invisible to Apple Books, and tags that make Apple Books behave are only half of what a scanner reads.

The layout, concretely

In ordinary words: one folder per author, one folder per book inside it, and a series folder in between when the book belongs to a series. Nothing else is a folder.

Everything else the library wants to know — the year, the narrator, which volume this is — goes into the name of the book folder. The scanner takes that name apart word by word, so where you put a comma or a dash decides whether “Volume 1” becomes a series position or just more letters in the title.

Audiobookshelf’s documented format is {Author}/{Series}/{Book} or {Author}/{Book}, and it is the most fully specified convention in this corner of the world — worth adopting even if you are not running it, because nothing else disagrees with it in a way that costs you.

Terry Goodkind/
  Heart of Black Ice - Sister of Darkness/
    Audio File.m4a
  Sword of Truth/
    Vol 1 - 1994 - Wizards First Rule {Sam Tsoutsouvas}/
      Audio Track 1.mp3
      Audio Track 2.mp3
      Cover.jpg
    Vol 2 - 1995 - Stone of Tears/
      Audiobook.m4b

The book folder name is not decoration; it is parsed. From the documentation:

• Author folder accepts First Last, Last, First, and several authors separated by ,, ;, &, or and.
• Series sequence must sit at the start followed by . or -, or later in the name preceded by - Vol, - Vol., - Volume, or - Book. Decimals work, for the 4.5 novellas.
• Publish year goes first, or directly after the sequence, separated by -.
• Narrator goes in curly braces: {Sam Tsoutsouvas}.
• ASIN goes in square brackets: [B002V0QK4C].
• Discs go in subfolders named Disc, CD, or Disk plus a number.

Which is how 1994 - Volume 1. Wizards First Rule {Sam Tsoutsouvas} parses into four separate fields rather than reading as a cry for help. A subtitle is a fifth, but only after subtitle parsing is switched on in settings — the documentation is explicit that it does not work otherwise.

Tags override where they exist. Audiobookshelf maps artist and album-artist to Author, album and title to Title, composer to Narrator, and series / mvnm and series-part / mvin to the series and its number. A well-tagged single M4B therefore needs much less from its path than a folder of bare MP3s does — which is the strongest practical argument for building one file per book in the first place. Getting that file to behave once it is in place is its own guide.

Plex: a borrowed layout, and a field mapping nobody has settled

Plex is a different story with a shorter chapter, and the short version is that it has no library type for audiobooks at all. So the layout everyone uses is one built for albums, with the book standing in for the album — which works well enough for the folders and leaves one real question open, namely where the author, the narrator and the series are each supposed to go.

The standing advice on Plex’s own forum is that audiobooks go into a Music library for want of a library type built for them — one reply in the best-practices thread puts it as “Plex isn’t very well suited for audiobooks.” That layout Plex does document: Music/ArtistName/AlbumName/TrackNumber - TrackName.ext, an artist folder, an album subfolder inside it, numbered tracks inside that.

What nobody documents is which of author, narrator, or series belongs in Artist rather than Album Artist once the album is a book. The best-practices thread on the Plex forum asks that question in its first post and gets three replies, none of which answer it; the one concrete layout posted is the token string %artist%\%album%\%artist% - %album% - %track% of %totaltracks%, where the album is the book title. Treat the field mapping as unsettled, because it is. The larger Plex problem is not naming at all — Plex plays an M4B and does not read the chapters inside it, which no folder layout can fix.

Why the folder looked fine to you and wrong to the scanner

Numbers inside names are the one place where your eyes and your software genuinely see different lists, and it is worth knowing which of the two you have been looking at.

Chapter 10 comes after Chapter 9 to you, because you are reading numbers. Most software is not reading numbers. It is comparing the names as text, one character at a time, and in that comparison “1” comes before “2” — so Chapter 10 sorts ahead of Chapter 2 and the book plays out of order. Finder quietly does it your way instead, which is the whole reason the trap is invisible: the folder you inspected and the list the scanner built were never the same list.

Want to see the two orderings side by side? I made a folder of nine files — Chapter 1.mp3, 2, 3, 9, 10, 11, 12, 20, 21 — and asked Finder, through AppleScript, for its own ordering of it. Finder handed them back in exactly that order, because it reads runs of digits as numbers. A shell listing the same folder gave Chapter 1, 10, 11, 12, 2, 20, 21, 3, 9, because a plain text comparison never sees a number at all.

So the folder passes inspection while feeding a scanner the wrong sequence, and you have no reason to suspect the names. Zero-padding to a fixed width makes both comparisons agree permanently, and the chapters in the wrong order guide has the renaming loop and the disc-number version of the same trap.

Sort tags: the part the path cannot carry

A library alphabetizes by the exact text of the title, and the exact text of most titles begins with “The”. Nobody goes looking for The Hobbit under T, but that is where it goes, along with everything else you own.

No folder name fixes this, because by the time a book is on the shelf the folder has done its job and the title is coming from inside the file. What fixes it is a second title that nobody ever sees: the book keeps the name you gave it, and files itself under a different one.

Alphabetize a real library by title and you get a wall of T:

A Wizard of Earthsea
An Ember in the Ashes
Dune
Neuromancer
The Dispossessed
The Hobbit
The Left Hand of Darkness
The Silmarillion

MPEG-4 has a fix for this. Four sort atoms matter here, sitting in the container alongside the ordinary tags and holding nothing but the text a library should alphabetize by: sonm for the title, soar for the artist, soaa for the album artist, soal for the album. The schema carries a couple more — composer, TV show — but these four are the audiobook set. Tools name them Sort Name, Sort Artist, Sort Album Artist, Sort Album. This is a fix for the Apple side of your library specifically — Audiobookshelf’s published tag mapping has rows for artist, album, composer, series and a dozen others, and no row for a sort field at all. The shelf still reads The Hobbit; the index reads Hobbit, The:

Dispossessed, The
Dune
Ember in the Ashes, An
Hobbit, The
Left Hand of Darkness, The
Neuromancer
Silmarillion, The
Wizard of Earthsea, A

Same for people. Tolkien, J. R. R. files where you would look for him instead of under J. AudioBo’s own demo book ships this way on the author side — its published tag dump lists Sort Artist and Sort Album Artist as Stevenson, Robert Louis against an Author of Robert Louis Stevenson.

Want to set them on a book of your own? It is one command, using mp4tags from mp4v2:

mp4tags -sortname "Hobbit, The" -sortartist "Tolkien, J. R. R." \
        -sortalbumartist "Tolkien, J. R. R." -sortalbum "Hobbit, The" \
        -type 2 book.m4b

-type 2 is the audiobook media type while you are in there. For one book this is the right tool and you do not need anything else — brew install mp4v2, run the line, done.

The trap before you build a pipeline: a remux throws sort tags away

One warning, and it is the kind that costs an afternoon rather than a minute. Sort tags are unusually easy to lose. Send the book through a converter — even one that copies the audio across untouched and takes two seconds — and the sort fields can simply not arrive at the other end, with no error and nothing to notice. The check most people make afterwards will still show them, because it is being made on the wrong file.

ffmpeg will quietly throw sort tags away. I wrote all four atoms into a test M4B, confirmed them with exiftool and mp4info, then remuxed the file with a plain stream copy: sonm, soar, soaa and soal were all gone from the output, while the media type, track number and disc number came through untouched. Passing them in on the command line as -metadata sort_name=… does not write them either.

The one flag that looks like the answer solves the wrong half of the problem: -movflags use_metadata_tags does carry every value through — all four sort fields, the media type, the track and disc numbers — but it writes them into the mdta key box instead of the iTunes atoms. ffprobe and exiftool still read them there. mp4info prints no tags at all, and nothing that expects the iTunes atoms, Apple Books included, sees a media type or a disc number. The values are not lost; they are in a box the audiobook world does not look in.

ffprobe reads the sort tags and prints them as sort_name, sort_artist and friends, which is exactly what makes the loss easy to miss — you check the source file, see them listed, and assume they survived. They did not. This is not a knock on ffmpeg, which is doing the thing it always does: precisely what it was asked and nothing more. The practical consequence is that sort tags go on last, after any remux, or they go on again afterwards. An export from AudioBo simply arrives with them written — it fills the sort fields automatically on every book it makes, so there is nothing to lose in the first place.

What AudioBo does about the naming and the sort fields

None of the above is difficult. It is that there is so much of it, and every piece of it is per-book: name the folder in the grammar the scanner parses, name the file so it survives being moved out of that folder, then set four sort fields by hand for a book you will never think about again.

That is the seam AudioBo sits in. You build the book, and the two fiddly parts are already done when it comes out. It shelves The Hobbit under H and authors by last name without being asked. The finished file arrives with a name whose shape you chose once, rather than one you type again for every book — and that name is the half of the convention that survives the file being moved somewhere else.

When the automatic answer is wrong — which is mostly non-English titles, and names no rule handles — there are two fields to type the right one into, and what you type stays typed.

If you do want the mechanical version: sort tags are written for you, and the release notes describe that default behavior as filing The Hobbit under H and authors by last name. Since 1.3.4 the Sort Title As and Sort Author As fields sit directly under Title and Author in Edit Book, for the cases the automatic answer gets wrong. 1.3.5 fixed the follow-on bug: those manual entries were being written into the file correctly but not read back on re-import, so the next metadata update could overwrite what you typed. They now come back with the book and stay.

The output filename is a preset rather than a typing exercise. The pattern worth knowing here is the one added in 1.3.2 — Author - Title [Series #], which drops the bracket cleanly on a standalone book instead of leaving an empty pair of them behind. Set it once and every book you build lands with a name the scanner can parse.

What it does not touch is the tree above the file. The author folder, the series folder, the book folder and the grammar their names are written in are still yours to arrange — AudioBo builds and repairs the file itself, and a file cannot name the folder it is put into.

Multi-disc rips and the boring recommendation

A boxed set rips as ten folders of twelve tracks, and every naming problem on this page arrives at once.

The layout that works: one book folder, disc subfolders named Disc 1, CD 2, or Disk 3, and the disc-number tag set as well as the track-number tag. Audiobookshelf orders such a book by disc number first and track number second. Setting the tags does not retire the filenames, though — the scanner reads a disc and track number out of the filename too, and picks whichever of the two sources looks more accurate. What the tags buy you is that a bad filename is no longer the only vote.

The better answer is to stop having discs. A rip is a stack of arbitrary disc-length slices of a book, and the boundaries mean nothing to a listener; merging them into one M4B with real chapters removes the disc question rather than solving it. That is the CD ripping workflow, and it ends with a single file whose path has almost nothing left to carry.

What naming cannot fix

If the file came from Audible or the iTunes Store and still refuses to play outside one app, the problem is protection, not organization. AudioBo does not remove DRM and will not; that discussion belongs to converting M4B to MP3, where it comes up first.

And if the tags themselves are wrong rather than the layout — the author reading “Audible”, a cover from a different book — no filename fixes that either. Editing an M4B’s metadata is the repair, and it is a remux measured in seconds.