starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: embedded chapters are not properly extracted from multiple m4b #2061

New Issue
Closed
opened 2026-04-25 00:03:03 +02:00 by adam · 5 comments
adam commented 2026-04-25 00:03:03 +02:00
Owner
Copy Link
Copy Source

Originally created by @random-human-being on GitHub (Jun 17, 2024).

What happened?

Most m4b audiobooks are composed of a single file with embedded chapters, or of several file each corresponding to one chapter. Both are properly scanned.

Some instances exist where a long-ish m4b is split into two or three smaller m4b, each with its embedded chapter list. This happens, for instance, with some Japanese audiobooks, which are split into a 上 (up/first) and 下 (down/second) volume.

When this happens, the chapters of the first volume are properly extracted, while those of the second (and further) volume(s) are ignored. This leads to the latter half (or more) of the audiobook being devoid of chapters.

What did you expect to happen?

Chapters and timestamps should be extracted from all files.

Timestamps for files after the first one should be shifted as needed.

Steps to reproduce the issue

Add an audiobook divided into two or more parts, each with its embedded chapter metadata. Here is an example:
Mediainfo file 1
Mediainfo file 2

After it has been imported into the library, check its chapters and verify that only those from the first file have been imported.

Audiobookshelf version

v2.10.1

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

No response

Additional Notes

No response

Originally created by @random-human-being on GitHub (Jun 17, 2024). ### What happened? Most m4b audiobooks are composed of a single file with embedded chapters, or of several file each corresponding to one chapter. Both are properly scanned. Some instances exist where a long-ish m4b is split into two or three smaller m4b, each with its embedded chapter list. This happens, for instance, with some Japanese audiobooks, which are split into a 上 (up/first) and 下 (down/second) volume. When this happens, the chapters of the first volume are properly extracted, while those of the second (and further) volume(s) are ignored. This leads to the latter half (or more) of the audiobook being devoid of chapters. ### What did you expect to happen? Chapters and timestamps should be extracted from all files. Timestamps for files after the first one should be shifted as needed. ### Steps to reproduce the issue Add an audiobook divided into two or more parts, each with its embedded chapter metadata. Here is an example: [Mediainfo file 1](https://pastebin.com/mutBnSAg) [Mediainfo file 2](https://pastebin.com/P4iCupx7) After it has been imported into the library, check its chapters and verify that only those from the first file have been imported. ### Audiobookshelf version v2.10.1 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs _No response_ ### Additional Notes _No response_
adam added the bugwaitingunable to reproduce labels 2026-04-25 00:03:03 +02:00
adam closed this issue 2026-04-25 00:03:03 +02:00
adam commented 2026-04-25 00:03:03 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jun 17, 2024):

The reason is because the chapter titles are the same. Sometimes audiobooks have multiple files and have all of the chapters embedded into each file so if we can't always merge the files, we need to check that they are different.
https://github.com/advplyr/audiobookshelf/blob/a75ad5d6594274a6ea048e246a1cedbd2dc72cd1/server/scanner/AudioFileScanner.js#L464-L474

Update: copied the wrong code snippet

@advplyr commented on GitHub (Jun 17, 2024): The reason is because the chapter titles are the same. Sometimes audiobooks have multiple files and have all of the chapters embedded into each file so if we can't always merge the files, we need to check that they are different. https://github.com/advplyr/audiobookshelf/blob/a75ad5d6594274a6ea048e246a1cedbd2dc72cd1/server/scanner/AudioFileScanner.js#L464-L474 Update: copied the wrong code snippet
adam commented 2026-04-25 00:03:03 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jun 18, 2024):

I'm looking at this again and since the timestamps are different the chapters should have still been merged. I was incorrect in saying it only checks the chapter titles (as shown in the code snippet). It checks the start time and titles to check if it should merge the chapters.

Since Abs uses ffprobe to get the chapter information, can you share the ffprobe output of those same 2 files?
You can do this using Abs: https://www.audiobookshelf.org/guides/ffprobe#inspecting-an-audio-file

@advplyr commented on GitHub (Jun 18, 2024): I'm looking at this again and since the timestamps are different the chapters should have still been merged. I was incorrect in saying it only checks the chapter titles (as shown in the code snippet). It checks the start time and titles to check if it should merge the chapters. Since Abs uses ffprobe to get the chapter information, can you share the ffprobe output of those same 2 files? You can do this using Abs: https://www.audiobookshelf.org/guides/ffprobe#inspecting-an-audio-file
adam commented 2026-04-25 00:03:04 +02:00
Author
Owner
Copy Link
Copy Source

@random-human-being commented on GitHub (Jun 19, 2024):

I'm wondering if the issue is not with the files themselves. Unless I am doing something wrong, ffprobe gives the following errors:
ffprobe file 1
ffprobe file 2

Both play fine via VLC and MPC though.

@random-human-being commented on GitHub (Jun 19, 2024): I'm wondering if the issue is not with the files themselves. Unless I am doing something wrong, ffprobe gives the following errors: [ffprobe file 1](https://pastebin.com/2NHCKPS0) [ffprobe file 2](https://pastebin.com/VmE11bkn) Both play fine via VLC and MPC though.
adam commented 2026-04-25 00:03:04 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jun 19, 2024):

If you are referring to the message Unsupported codec at the bottom then this can be ignored. I see this from ffprobe also for m4b files with embedded chapters.

Is it possible you added the second file after the first file had already been scanned in?

Abs does not update chapters after the initial scan. To pull in chapters again fresh after you add audio files you can press "Edit chapters" and delete the existing chapters. Then press edit on the book and "Re-Scan".

From what I can see the ffprobe outputs look fine. It would be better to check within Abs like it shows in the guide that I linked because then we would be sure that Abs is pulling the chapters in.

@advplyr commented on GitHub (Jun 19, 2024): If you are referring to the message `Unsupported codec` at the bottom then this can be ignored. I see this from ffprobe also for m4b files with embedded chapters. Is it possible you added the second file after the first file had already been scanned in? Abs does not update chapters after the initial scan. To pull in chapters again fresh after you add audio files you can press "Edit chapters" and delete the existing chapters. Then press edit on the book and "Re-Scan". From what I can see the ffprobe outputs look fine. It would be better to check within Abs like it shows in the guide that I linked because then we would be sure that Abs is pulling the chapters in.
adam commented 2026-04-25 00:03:04 +02:00
Author
Owner
Copy Link
Copy Source

@random-human-being commented on GitHub (Jun 21, 2024):

I have removed both m4b from the filesystem, then and re-added them. Now they indeed show up as expected.

I guess when I first transferred them to my server one, of them finished being copied slightly before the other did, by just enough time that abs was able to complete a scan of the former.

Well, that being the case, apologies for my oversight.

@random-human-being commented on GitHub (Jun 21, 2024): I have removed both m4b from the filesystem, then and re-added them. Now they indeed show up as expected. I guess when I first transferred them to my server one, of them finished being copied slightly before the other did, by just enough time that abs was able to complete a scan of the former. Well, that being the case, apologies for my oversight.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug unable to reproduce waiting
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2061
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?