mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Very large M4B file not able to have metadata embedded #2891
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#2891
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @anakinsleftleg on GitHub (Jul 14, 2025).
What happened?
I wanted to update the chapters on this massive multi-work collection. It comes as one file. I'm able to set the chapters in ABS but when I want to embed the metadata, it fails with the following debug output. I admit that i've tried using
tonemanually and it produced the same problem. I've also tried ffmpeg directly and wasn't able to get it to work. also tried MP4box and same. nothing seems to be able to write to this file without either corrupting it as below, or simply not applying the chapter data. Logs are below.I was thinking, for files like this, which there are numerous COLLECTED WORKS audiobooks, it would be nice to have a decent gui to have all the chapters there (which you already have) and then allow to split the file into multiple smaller files at specific chapter positions while retaining the bookmarks. basically the reverse of the "combine into a single m4b file" function.
This doesn't have anything to do with this request, and is out of scope, but I would like to be able to split these collected works files into their separate books and use each of those with their correct chapters as individual entries in the library.
What did you expect to happen?
Metadata to be embedded without error.
Steps to reproduce the issue
Audiobookshelf version
2.25.1
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Windows
If the issue is being seen in the UI, what browsers are you seeing the problem on?
None
Logs
Additional Notes
No response
@advplyr commented on GitHub (Jul 14, 2025):
I don't think this has to do with the file size. If every other tool has failed to work with this file then my guess is it is corrupt.
I just tested this with an 8GB audiobook (4 copies of War and Peace merged) and it had no issue embedding.
The logs show that ffmpeg can't open the file, so Abs wouldn't be able to split the file even if that feature were added.
There is an open feature request for that though: https://github.com/advplyr/audiobookshelf/issues/1356
@anakinsleftleg commented on GitHub (Jul 17, 2025):
@advplyr I wanted to give you an update. I have no idea what changed, other than filename but there was nothing wrong with that to begin with (length or anything). Applying the Quick Embed or Full backup embed both work now but with a significant caveat!!
Your command to apply metadata will apply chapters in both standards (Nero (Menu#2) and QuickTime (Menu#1)). The problem is that Nero only supports 255 maximum chapters. QuickTime as far as I know has no limit. But most players will default to the Nero listing if it exists (like VLC). If it doesn't exist, it will use the QT chapters. A tool like MediaInfo (available as console app or gui) will show both types or one or the other. It only shows up to 512 of QT chapters even if there are more, which can be confirmed by
ffprobe -i input.m4b -show_chapters.My point in all this is the following. If the chapter count exceeds 255, I would recommend that audiobookshelf uses a slightly modified version of the metadata command which disables the Nero chapters. Insert
-movflags disable_chplinto the command args to do this. So numChapters > 255 then use that, if 255 or less, no change needed to the command. It will populate both types of chapters.Current command:
Modified command for >255 chapters:
Also, one of the things I noticed and didn't see anywhere as to why that is is the fact that you have
-map_metadata 1 -map_metadata 0which would populate the metadata with info from ABS first then overwrite it and fill in any missing fields with the original file values. To me, it seems like if anything it should be 0 first then 1 last so that the ABS metadata overwrites anything from the file that is common. Or even just the ABS data only, but I understand there might be reasons for safety to have both. Still, I would want the ABS stuff to always take precedent which means coming last, for any common fields.