mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-03-02 22:46:56 -05:00
[Enhancement]:Option to still show m4b "tool" even when book only has single m4b #1506
Labels
No labels
authentication
awaiting release
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/audiobookshelf#1506
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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 @ceramicwhite on GitHub (Oct 7, 2023).
Describe the feature/enhancement
I store most books at 64k in single-channel format, unless they feature a soundscape, full cast, etc. I think that storing books at 128k and in dual-channel is a waste of space, the fact that a narrator records with a single channel microphone and especially if one uses libfdk-aac for encoding, the loss of fidelity is minimal and is worth it for size being cut in half. Well anyways that's my preference not here to debate it.
If I'm uploading just one book to the server, I'd rather not SSH in to encode it manually; I'd prefer to configure these settings through the UI.
I'd like to see a more advanced automation feature that allows for preset encoding settings to be applied upon import. For example, if an audiobook is 128k, dual-channel, and has a single narrator, it should be re-encoded to 64k and single-channel. If an audiobook is 320k, has two or more channels, and more than one narrator, then it should be re-encoded to 128k, dual-channel.
@advplyr commented on GitHub (Oct 7, 2023):
I think you can combine this with your previous issue #1257, some of it is the same
@advplyr commented on GitHub (Oct 7, 2023):
Duplicate of #1257