Re-design the book adding process

[PaulWoitaschek]

Right now the whole adding process is severely flawed.

Issues

Users...

• get confused about what the two book adding modes mean
• don't see the sd card selection in the top right
• get confused about the file selection / confirm buttons

Current Solution

Currently there are two kind of folder structures we support:

• In a Folder each folder is recognized as a book:
  • ./book1
  • ./book2
  • ./book3
• A single book
  • ./book

Improvements

Another structure we should support is by author:

• authorA/book1
• authorA/book2
• authorB/book1

I think we need to re-think in a larger picture how we let users add folders.
This should be combined with an onboarding flow. Right now the user is thrown into cold water and I assume that mostly users with a technical background understand how to add folders.

I'm open for ideas! @0rAX0 cc

[0rAX0]

@PaulWoitaschek Do you mind labeling the open issues that need my input/design/ideas as 'Design' or something similar. I feel that we would work a lot more efficiently if we introduce some organization. :)

[PaulWoitaschek]

I added you as collaborator. Feel free to comment / close / tag issues on how you think it's useful. Please don't push directly to master ;)

[0rAX0]

Sweet. And I'll keep that in mind haha 😆

[PaulWoitaschek]

Didn't you just add a label? -- Mit freundlichen Grüßen  Paul Woitaschek  Software Entwicklung  www.paul-woitaschek.de

[0rAX0]

Sorry I'm dumb, forgot to accept the invite. 🤕

[0rAX0]

@PaulWoitaschek I think that a good onboarding flow is the most important piece here, then I suggest giving the user 3 choices: the two current ones with better explanations, and additional 'let me choose' mode when the user points to a directory and he's taken to a screen where he can choose the books by ✅ ing the boxes next to them. Now when a folder that contains a bunch of other folders is ticked it means that it's a book with multiple chapters; when the children folders are ticked then they're the books.

Of course, the best thing in the world is figure a way to be pointed at a directory and intelligently figure everything out, but it probably needs some genius AI or something.

[SierraGuru]

M4B seems to me like it should always be a complete book, although I have seen large files split into two parts. Still, it would be nice to keep all my M4B files in folders like SCIFI, HISTORY, FANTASY, COOKBOOKS, ETC and let the software treat them all as individual books (because of the file extension) and pull titles and authors from metadata. Metadata might work for mp3 too if possible. I'd prefer to let the software take a stab at figuring out things like titles, book files, authors, etc and modify my files as necessary instead of having to organize my files in any particular way. I would put everything under an audiobooks folder and just tell the software where the folder is.

[MagTun]

There is probably something that I don't understand here, but why don't you use a simple folder explorer. I use MortPlayer Audio Books before using your app and the process of having to add audiobook folders to the app really confused me at first.

[PaulWoitaschek]

@0rAX0 Could you do a mockup for the new adding process?

[0rAX0]

@PaulWoitaschek First, sorry for not responding to recent comments, was a bit sick and busy.

How is it going to be, like I suggested?

[PaulWoitaschek]

How is it going to be, like I suggested?

Yes, even though I'm not sure yet if the "Let me chose" is the right way. Maybe the 3rd option will just be the "Author" way.

[digitalec]

Rather than importing based on folder structure, why not import by ID3 tags? I've got a mix of single file audiobooks as well as audiobooks split by chapter into multiple MP3s. It would be beneficial to specify an "Audiobook Directory" that contains all books and import and organize by Album name.

As of now, I have to add each multi-file audiobook separately and then I have to add my single file book directory.

It would also be nice to be able to import books directly from Google Drive/Dropbox/OneDrive etc.

[thw0rted]

I second Shawn's suggestion above. I was confused when adding files the first time I used the app, and just messed around with folder layout until it worked. I think I have several folders with single-file books (m4b), one each, which took some guess work. If this were a music player, I'd just dump all the files in and let the player present them by Artist -> Album based on tags.

[siniux]

I think the process should be streamlined but without giving the user too much options; what if the app created an "Audiobook" folder on first opening and the user only had to use a file manager to copy the audiobooks there.

[thw0rted]

@siniux how would that behavior work with external storage (sd card)? I like the idea of having a default. Maybe make an Audiobooks folder on both devices and show any books in either one?

[SierraGuru]

A default would force you to move folders if you already have a structure you like. I keep a few audiobooks I don't mind listening to again, some nonfiction in a seperate folder rthat's interesting but will get deleted if I run out of space, and newer books I haven't read or listened to yet that just get dropped into the file system where I can find them. .

[siniux]

Could be, I think it would to be better to have the two options just there when the user tries to copy its first book.

[MagTun]

I agree with @thw0rted, it would be nice to be able to put the audiobooks inside theme/author folders and to only add one folder in Voice [as a "folder with multiple books"]: the parent folder of those "theme/author folders"

[audiamus]

What is the current state here if I may ask? If no new design has been implemented yet - at least that's my guess trying the current version - my suggestion would be:

Let the user select a root folder. Recursively iterate the folder hierarchy below that root as a tree of nodes and leafs. If the search discovers a match - either a recognized audio file or a playlist - treat this folder and anything below (sub-folders may contain playlist tracks) as a single audiobook, i.e a "leaf" in the tree, and continue searching with the next "node" folder.

This way you are independent of the user's folder organizing scheme. He/she can use any scheme, with or without extra levels for genre or author.

That's also the method other players like VLC are using.

[thw0rted]

I do like the idea of looking at folders recursively so I can organize by author but if you don't look at the file metadata at all, you still can't put more than one book in a folder. All my books are in single M4A files, so I'd love to just have a folder per author or series, with all the books in it, without having to make superfluous folders per book (with a single file in each), which is what I do now.

[newhinton]

@thw0rted I think your structure is one of the hardest to implement, without major changes. I have build a 'smart' scan, that properly scans recursive folders to add everything it finds, however: differentiating audiobooks only by filename/directory basically excludes multiple audiobooks in a single folder. For that, the scanner would need to also look at the id3tags, which it does not do afaik.

However, my 'smart' implementation (and i use the term smart here very loosely) is able to cover most cases that occur. The downside is that it relies on a list of keywords that indicate a group of books, eg. CD or PART

So for your case: as long as the filenames are in order, you end up with a single book for the whole series, and each book would be a 'chapter'

[thw0rted]

How about this: when you encounter a folder full of files,

• Pick only the ones we might add (ignore thumbnail / NFO / whatever)
• Remove any trailing numbers and punctuation from the file name with a simple regex matching "1 of 20", "1/20", "pt20", etc something like /(\s|[.])+(\d+)?\s*([a-zA-Z]{0,4}\s*\d+$/ -- required whitespace, maybe number, maybe space, maybe short word like "part" or "of" or "disc", maybe space, required number
• Lowercase and remove spacing from all trimmed names, score for similarity (number of characters different or something)
• Pick a reasonable threshhold, if all the numbers are below, it's a folder with one book. If the filenames differ from each other significantly, they're probably different books.

ETA: I'm not sure how to handle multipart books with spelled out chapter names, because the differences between Harry Potter and the Sorcerer's Stone - Chapter 1 The Beginning.mp3 vs Harry Potter and the Sorcerer's Stone - Chapter 2 A Hairy Biker Arrives.mp3, look a lot like those between JK Rowling - Harry Potter 1 The Sorcerer's Stone.m4a and JK Rowling - Harry Potter 2 The One With The Big Effing Snake.m4a.

[newhinton]

I already do the part with regex for folders (okay, i dont use regex at the moment, just contains()) and it works pretty good.
So, detection of a single book is not an issue, but as you mentioned, multipart books that are not stored in seperate folders break still wont work.

This breaks:

JK Rowling/Harry Potter and the Sorcerer's Stone Part 1.mp3
JK Rowling/Harry Potter and the Sorcerer's Stone Part 2.mp3
...
JK Rowling/Harry Potter and the Sorcerer's Stone Part 33.mp3
JK Rowling/Harry Potter The One With The Big Effing Snake.mp3

Since they are all in the same folder, it assumes JK Rowling is a single audiobook, and therefore we mix those two books.

JK Rowling/Harry Potter 1/The Sorcerer's Stone Part 1.mp3
JK Rowling/Harry Potter 1/The Sorcerer's Stone Part 2.mp3
...
JK Rowling/Harry Potter 1/The Sorcerer's Stone Part 33.mp3
JK Rowling/Harry Potter X/The One With The Big Effing Snake.mp3

This i can detect properly, we get two different books. However, this does not require any smarts. So what does? This:

JK Rowling/Harry Potter 1/CD 1/The Sorcerer's Stone Part 1.mp3
JK Rowling/Harry Potter 1/CD 1/The Sorcerer's Stone Part 2.mp3
...
JK Rowling/Harry Potter 1/CD 4/The Sorcerer's Stone Part 33.mp3

If we do it naively, we end up with 4 audiobooks, one for each CD. This is not optimal. But with a little regex and a list of keywords, we can add them together.

I think we can completely remove the old "single book" and "collection" types, since my pr can actually handle both, without the user needing to know how or what those types mean.

Even if we dont find a solution for "multiple books in same folder", this would improve the app anyway if we can make the CD stuff work.

The PR: #1072. The last commit has a working version that can only detect CD's, but it is easily extended to different keywords in different languages.

Edit: sorry, i think i went a bit offtopic and summarized what i did, but maybe it is helpful to anyone anyway

Edit2: If anyone has additional, very strange patterns that are maybe not working, please provide examples so that we can think about them

Edit3: After reading the thread again, the only thing that i think is nearly impossible is the podcast/recurring format detection, since that relies again on the displayed name in the app, not the scanning. I don't think voice was designed to support that kind of content

Edit4: Another example on what wont work, but this is far off:

JK Rowling/Harry Potter 1/CD 1/The Sorcerer's Stone Part 1.mp3
JK Rowling/Harry Potter 1 - CD 1/The Sorcerer's Stone Part 2.mp3

That will create two audiobooks.

[thw0rted]

Sounds like you've thought this through. I'd still like some option for

Harry Potter/
  1. The Sorcerer's Stone.m4a
  2. The Big Snake.m4a
  3. Uncle Werewolf.m4a
  ...

because it's a lot easier to manage in my phone's file manager than making a bunch of extraneous folders, but I understand if the need to reduce the number of user-facing buttons / options wins out.

[newhinton]

I don't think it will be possible to archieve your goal with folderbased detection, at least not to my knowledge. That probably requires switching to metadata-based detection.

One possibility would be to apply the "part" detection from your post, but as you said, it breaks as soon as the filename does not contain any "chapter"-identifier like a tracknumber or similar.

[PaulWoitaschek]

I'm still in the thought process on this. With the switch to SAF, the process is even more complicated.
You must tell the system what you want now in advance.

The current version (6.0.x, rolled out with about 10%) has only a single option: You can only select a root audiobook folder. But from reviews I can see that people are actually missing the other options.

This is my current draft, but I have doubts that users will understand the distinction between the three types.
Has someone suggestions how we could communicate, what each option means? Or do you think this is self explanatory enough?

[newhinton]

SAF

Why is the SAF getting in your way? I build&ran the latest version, and to me it seems sensible since every "new" step added is by android and should already be known to the user. I find it to be a good implementation, you cant really make it better with the current restrictions.

Three Icons

Maybe we can try to "guess" which type the folder is and dont expose the three options? That would probably take a bit of work though.

Unrelated Comment

Three sidenotes: I think your main website is down, and something seems wrong with the git-repository, i get a 404 on some git-lfs files:

Error downloading object: app/src/androidTest/assets/covers/Dream in a boat/cover.jpg (3088821): Smudge error: Error downloading app/src/androidTest/assets/covers/Dream in a boat/cover.jpg (30888217cfb15f6f07fd6462948969afc72ac6c5fdc27a70136cf25ccc575626): [30888217cfb15f6f07fd6462948969afc72ac6c5fdc27a70136cf25ccc575626] Object does not exist on the server: [404] Object does not exist on the server

The third thing: your Project is not really easy to build&run, especially since there are some dependencies that are not supported by Android Studio 2021.2.1 (agp = "7.3.0-beta05", latest supported is 7.2.1 (At least on my system)). Maybe you want to add some build-instructions how this project should be build and with what tools

[thw0rted]

Would it be possible to have one "add a folder" button, then present the user with a dialog with both folder options after they have picked? You could parse the selected folder according to "single" rules and show a preview of how it will be treated. If that isn't what they wanted, they can try the other option. I would suggest a pair of radio buttons at the top with the "preview" (list of books that would be added) below, Save / Cancel buttons at the bottom.

[PaulWoitaschek]

About SAF:
It's not possible to let the user select a folder or a file. It always has to be one.

On the three icons topic:
What do you have in mind? How could that possibly work?

On LFS: the missing assets are related to the screenshots and shouldn't affect the development.

On the project setup:
Isn't it that android Studio tells you that you need a newer version and that's it?
I'm hesitant against adding setup steps as it's not really a special setup, but requires maintenance.

[PaulWoitaschek]

Would it be possible to have one "add a folder" button, then present the user with a dialog with both folder options after they have picked? You could parse the selected folder according to "single" rules and show a preview of how it will be treated. If that isn't what they wanted, they can try the other option. I would suggest a pair of radio buttons at the top with the "preview" (list of books that would be added) below, Save / Cancel buttons at the bottom.

That's interesting. If we want to let the user select a single file though we'd still need multiple buttons.
But that idea us really clever.

[newhinton]

What do you have in mind? How could that possibly work?

The most reliable and probably complicated would be to use metadata. But i guess that will probably require massive changes to the database and backend.
There could be simple rules, that decides that, eg. Keywords in foldernames, or if we only find loose files in that folder, or if we have mixed content and then decide what model would fit best. I have no such ruleset ready, but it could be done. Drawback is that we will probably have false results that require the user to change his or her folderstructure.

On LFS: the missing assets are related to the screenshots and shouldn't affect the development.

No, building worked. But after cloning from fresh, the repository is in an unusable state. Lots of delteded and untracked files that shouldn't be either. It could be my own fault, but i dont see how since i have a fresh install and didnt make any wild changes to git.

Isn't it that android Studio tells you that you need a newer version and that's it?

Okay you were right, i am not entirely on the latest version (2021.2.1 Patch 1 vs 2021.2.1 Patch 2), but imho it would be better to use a version that is a little bit more widespread supported, so that newcomers aren't put off by such "issues"

Would it be possible to have one "add a folder" button

To chime in on that, we could do something like those intro libraries do, and add iconography on how each option expects the audiobooks to be ordered. It would take up screen-realestate, but i dont think that would be an issue

[PaulWoitaschek]

I made a first draft on how the UI could look like that allows to select both folder modes.

https://drive.google.com/file/d/14xFhQ_ykYfqxM20Jd9eT2umK27CD-PgZ/view?usp=sharing
I'm looking forward to feedback!

[PaulWoitaschek]

PR and motivation:
#1471

[thw0rted]

I haven't had a chance to test this yet but the screenshot in the PR looks awesome. Thanks!

[newhinton]

I made a first draft on how the UI could look like that allows to select both folder modes.

I think this comes from a misunderstanding on how voice should deal with this properly. The whole problem with differences between single files, folders with single files and all the other combinations stem from the fact that voice actually moves the "burden" of management to the user, instead of actually managing it itself.

Mostly we should assume that all the files have metadata, and we should use those primarily to identify books etc.

Using the parent folder (name) (or filename) should only be the case if and only if the file has no id3tag, otherwise the tag should be the source of truth.

This completely removes the nesessity for the user to differentiate their folder-types. All types, all sorting would automatically be supported because voice does not rely on them at all.

This has huge benefits because the user is no longer confused (and in fact, cannot be confused) and on a side bonus, there is no maintenance overhead from additional views and ux-flows.

[thw0rted]

If you look back at earlier discussion (or maybe the issue that preceded this?) there was some mention of the fact that a lot of ID3 tags have bad or mis-matched information. I'm really not sure who to side with here. The stated goal of the software is to Just Work for most people -- minimal controls and settings to fiddle with. So you have to pick whether you are trusting the structure that the user created for the files, or the metadata in those files.

I make a point of cleaning up my metadata (using MP3Tag), but some people are just going to leave whatever their ripping software does as-is, so you wind up with situations where Genius / CDDB / whatever had CD 1 of your book with all Artist tags filled using author's name plus narrator, while CD 2 has the same tag as just the author name, or one has the author as "First Last" while the other uses a middle initial, etc etc. You wind up with a bunch of slightly mismatched MP3s that reassemble into 5 different "albums". The alternative is to guess what the user "intended" by putting a bunch of files in one directory. If you can make that work, it saves them having to do the hard work to keep all their tags correct (even though some of us were going to fix them anyway).

[newhinton]

True, there are downsides to that approach. If a user has only "titleX.mp3" named files, that obviously will work very poorly.
However, in those cases the foldername fallback is the only option anyway (as it is currently)

If the metadata is broken, that is, simply put, not our problem. To an extend we need to support some fallback because mistakes happen, but if the support of such users is to the detriment to the de-facto-standard and the users who do manage their files properly, i am not really in favor of such a solution. (Also your example does actually work correctly (to some extend), all chapters/cd's are correctly grouped together, even if the intent was a bigger set of all cd's into a correct audiobook. In fact, if the metadata is messed up, it will also be probable that it cant be ordered properly even if it ignores metadata)

I see that there is a small group of users that does benefit from the current state, but i see quite a lot of issues for everyone else because of that.

[thw0rted]

I'm coming back to this discussion quite some time later, because #1893 was just converted to a discussion. I still use Voice the same way as before -- all my audiobooks are single-file M4A/M4B, I still store them on OneDrive, and when I want to listen to one I manually make a subfolder under /Audiobooks on my phone to hold that one file, then save it there.

If I could have a button to add a single folder, with a checkbox that says "this folder will only ever have one book per file, I promise", it would make that workflow a lot easier for me. I could just bulk download a dozen files from OneDrive and save them all in one place. If that's just not going to happen, I understand, but I thought it wouldn't hurt to check.

[PaulWoitaschek]

I'm coming back to this discussion quite some time later, because #1893 was just converted to a discussion. I still use Voice the same way as before -- all my audiobooks are single-file M4A/M4B, I still store them on OneDrive, and when I want to listen to one I manually make a subfolder under /Audiobooks on my phone to hold that one file, then save it there.

If I could have a button to add a single folder, with a checkbox that says "this folder will only ever have one book per file, I promise", it would make that workflow a lot easier for me. I could just bulk download a dozen files from OneDrive and save them all in one place. If that's just not going to happen, I understand, but I thought it wouldn't hurt to check.

Why don't you just add the onedrive files directly to voice?

[thw0rted]

When you say "add to Voice", what do you mean? #1893 was about being able to "add to Voice" via Android sharing intent, which is not currently supported.

In Onedrive, I can "download" or "share". (Download is the workflow I described above.)

In Google's "Files" app, there's Onedrive integration, so I can browse cloud storage. That gives me the same "share", "copy to..." (basically the same as "download" above), or "open with...". I can "open with" VLC or Pocket Casts, but not Voice. I guess that's a different Intent from "share"?

Regardless, the only way I've figured out to "add directly to voice" is to put the files into a folder that has been added as an audiobook folder in Voice, but that still carries the restriction that each book (file) has to go in a subdirectory.

[PaulWoitaschek]

Like this:

voice.mp4

Disclaimer: I would never listen to christian stuff, that's just a test file 😁

[thw0rted]

That's really neat, I didn't realize it was possible. When you do that, does it copy the file to the local device or stream it from Drive? (If it's copied, where does it wind up?)

[PaulWoitaschek]

It's streaming

[ghost]

I realize this is an old thread, but this seemed like the right place to discuss this.

I have a LOT of audiobooks which I keep organized with a single .m4b file per book in folders and sub-folders, which usually denote the genre or subject. I'd really like to use Voice, however the folder modes make it borderline unusable for finding books as they get imported into a huge flat listing. It would be very helpful if you added support for a mode that's just a simple file-system view with navigable folders and sub-folders, and displaying file names in addition to title/author metadata.

For reference, the Android version of VLC (which I also tried using for audiobooks) does something similar to this; in particular, I really like how it indexes metadata so that I can list files by, eg, artist or album, in addition to browsing the filesystem directly

Thanks!

[sandreas]

@halcyonseeker

I get your point and I use the same format (m4b), but are you really sure that it would be better to have a Filesystem structure? I really don't like moving my files around to update the structure of my database, especially on Android where moving files is not keyboard or mouse based but touch based...

@PaulWoitaschek
In my opinion a system with tags (Genre:Fantasy, Year:2024, Author:J.K. Rowling etc.) would be better to filter and categorize books. Easier to implement and very powerful in terms of presentation (Virtual Folders, Filter-Buttons, Tabs or whatever).

The book adding process should work automatically (no selection on how the folder structure might be). In my opinion this could be done very easily by grouping the files by:

• Author
• Album / Title (Name of the book)
• Narrator
• Movement (Series)
• Part (Series-Part)

If all these are the same for multiple files in the same folder, the folder is an audio book - otherwise the folder contains separate audio books per file.

The artist, album, composer, movement and movement-index are part of most audio formats. Unfortunately, movement is not supported by voice - this would be a great benefit in general because audio-book-series could be grouped by this tag. Another problem is movement-index, which is an integer value and cannot represent special part numbers (like 2.1 or V). Therefore I invented ----:com.pilabor.tone:PART (see https://github.com/sandreas/tone?tab=readme-ov-file#reserved-metadata-fields) for m4b to store part numbers that are not simple numbers.

After the scanning process there could be a UI Element of selecting or entering data of elements that are not or incompletely tagged to choose, what this is.

An example:
Downloading files with audiobookshelf-app results in a pretty simple folder structure, but having multiple m4b files in the same folder:

• /J.K. Rowling/Harry Potter/
  • 1 - Harry Potter and the philosopher's stone
  • 2 - Harry Potter and the chamber of secrets
  • ...

There is NO available option to scan this structure and have ONE BOOK PER FILE - the Folder method results in having ONE Harry Potter book with 7 parts and the books have to be added manually.

[sabi0]

Do I get it right that we are trying to find a solution that would correctly recognize all the books below?

Audiobooks/
├─ Harry Potter/
│   ├─ Philosopher's Stone/
│   │   ├─ chapter1.mp3
│   │   └─ chapter2.mp3
│   ├─ Chamber of Secrets/
│   │   ├─ chapter1.mp3
│   │   └─ chapter2.mp3
│   └─ Prisoner of Azkaban.m4b
├─ Woolf/
│   ├─ MrsDalloway.mp3
│   └─ ToTheLighthouse.mp3
├─ The Hobbit/
│   ├─ scans/
│   ├─ chapter1.mp3
│   └─ chapter2.mp3
└─ LittlePrince.mp3

I think this cannot be done without resorting to some heuristics. Like checking the audio files play time (chapters are shorter than whole books) or inferring the "chapters mode" from the files names differing by just digits or using files tags to guess the grouping.

It is possible to improve the current solution with the following simple rule:

• if a directory (A) contains audio files and other directory(-ies) with audio files, then files in directory A must be separate books
  (The "with audio files" part is important as we do not want some "scans" sub-directory turning chapters into books.)
• if a directory contains only files, they could be either chapters or books
  Treating them as chapters would keep the current behavior. At the cost of not supporting the "directory with book per file" case ("Woolf/" above). Supporting this scenario could be added later once the heuristics is settled and implemented.

P.S. This essentially merges the current options "book per directory" and "organized by author". So the user's choice could be simplified to just "single book" or "multiple books". Once the heuristics to tell chapters from books is in place asking the user about this would not be needed at all.

[sandreas]

if a directory (A) contains audio files and other directory(-ies) with audio files, then files in directory A must be separate books

Not necessarily.

There are books that may contain subdirectories for parts, then chapters and on the upper level some intro or author comment stuff...

• Intro.mp3
  • Part1/chapter1.mp3
  • ...

A duration based approach also won't work reliably because there are short audio books that have durations < 10mins and chapters with more than 10 mins. So a check for 90min or more may be a good start.

The most reliable way is to use m4a /m4b files along with the media type metadata tag 2 (stik).

Mp3 is just not as good for books. However # Voice does focus on easy usage and forcing users into using m4b is also not the right way.

As already stated above: in my opinion an auto approach with optional exclusions / adjustments should be the best approach while i still think EVERY scan option of the 3 available ones should detect m4b files as single books.
And as long as we do not want to analyse the audio itself for spoken word or music, it'll be hard to find a >90% accurate heuristic.

I think it might be nice to integrate a feature, where you can select a file and choose mark as full book where internally it creates a file beneath the audio to advice voice to handle it different... Like

• a-book.mp3
  • a-book.mp3.voice (with some json to have adittional info)

But this would slow down the scan significantly. A custom tag would also be possible, like TXXX:VOICE-MEDIATYPE=audiobook, but i prefer not to alter the files.

[thw0rted]

The way Plex handles this is using file naming conventions. If you have books that are split into many separate files, the file names use the same base/root and end with a suffix like "ch1" / "chapter 1" / "part 1" etc etc. It should be pretty straightforward to build a regex that groups together batches of files where the names are the same except for a "part" suffix. Single files with no similarly-named siblings would be treated as their own book.

ETA: This approach should allow you to support mix and match:

Audiobooks/
├─ Harry Potter/
│   ├─ Philosopher's Stone/
│   │   ├─ chapter1.mp3
│   │   └─ chapter2.mp3
│   ├─ Chamber of Secrets/
│   │   ├─ Chamber of Secrets - pt1.mp3
│   │   └─ Chamber of Secrets - pt2.mp3
│   ├─ Prisoner of Azkaban ch1.mp3
│   └─ Prisoner of Azkaban ch2.mp3

Users whose files don't already match the convention could either select a mode when adding a folder that says "every subdirectory is a single book with multiple files" (i.e. disable matching based on the naming convention), or they could use a batch processing tool like https://www.mp3tag.de/ to rename the files to match the convention.

[sandreas]

@thw0rted
@sabi0

Thank you very much for your input. However, I think that the most important thing of a "new" solution would be not breaking existing libraries or filesystem scans and additionally not irritating the users even more. Therefore a shiny new filename convention would only work by having ANOTHER option to choose from and kind of legacy the other options out.

That would basically mean irritating the users even more with a 4th option to choose from, which, in my opinion, would not help at all. We should start by fixing the most annoying problems of the most used option or maybe finding a way to merge all options into one while not breaking the behavioral pattern. I think the most inflexible is the /Author/Book one, which basically only allows a fixed structure with very little room for structure deviations...

We'll see. Probably the m4b thing is the only thing that really is a problem - mp3 already works pretty decent atm.