Mp3tag alternative?

[Neurrone]

Hi,

I'm wondering if there's any other way of achieving the automatic tagging functionality besides using mp3tag?

For example, I'm wondering if a custom Beets plugin would be able to do this.

[rabelux]

Your topic sounds like more like a discussion, so maybe transfer it to https://github.com/seanap/Plex-Audiobook-Guide/discussions?

[seanap]

There are a few alternatives, but none that I found to be quicker/easier. Here are a few that I know of hopefully if anyone else has any alternatives they can add to this list.

• Puddletag on Linux can use the same .src script
• Bragibooks is a docker and web gui where you feed it an ASIN and it tags/converts/moves
• Readarr similar to radarr/sonarr but for books, audiobooks are still in beta, and the matching wasn't perfect last time I tried
• inAudible/OpenAudible/Libation these 3 programs are very similar they will dl your audible books and tag them

As far as beets.io custom plugin's go, it does looks to be possible. Someone would have to write either a web scraper or audible api hook in python to get the metadata from audible (or whatever source you want to use). The web scraper for mp3tag is not compatible with beets.io, it's not written in python.

The Audnexus plex agent (and upcoming audnexus audiobook database) is very good at matching and pulling metadata from audible. All it needs is a proper ALBUM and ARTIST tags. In previous versions of the old audiobook.bundle agent it needed a lot more help to match and didn't grab all the metadata available. This is why I wrote the mp3tag script like I did to compensate for that by saving all the metadata in the files, but moving forward from a Plex perspective, that isn't required (though I still like my perfectly tagged files).

[Neurrone]

I'm investigating building a Beets plugin. These are just some preliminary ideas, I'd appreciate any advice / suggestions.

I'm trying to read through the source for the plex agent to see how it retrieves info, which seems like a much easier way of getting info than trying to replicate the mp3tag approach.

Mp3tag's audible source seems to use artist with the album name for the search term, I'm hoping that works well enough.

This API call seems to provide almost all the required information:

https://api.audible.com/1.0/catalog/products?response_groups=contributors,product_desc,product_attrs,product_extended_attrs,series,media&num_results=25&products_sort_by=Relevance&keywords=<searchTerm>

The only thing that I don't see is genre which is something I'm ok to live without.

There's another endpoint, https://api.audnex.us/books/{asin} that does return genre, although I'm unsure how they get that information. I couldn't find any documentation on this endpoint though and only saw it in the source of the agent.

[seanap]

I would be very interested to see this integration. The audnexus agent uses a mix of web scraping (for the genres), and audnex.us api (currently in development). Plex surprisingly can't read many id3 tags, which is where the limitation of using the ALBUM and ALBUMARTIST (or ARTIST) comes from. Plex reads those tags and then passes them to the agent.

I would not replicate the mp3tag approach, it is just a basic web scraper and is prone to breaking either when audible changes something on their site or I come across an edgecase book. It's "good enough" but the api is a lot better. That said, mp3tag uses the author+album tags to search audibles site, then it lists the search results. I also have different flavors of scripts that search based on file name, or a custom set up tags. The best search method comes down to the source material and what is available, sometimes the tags are good enough, sometimes they don't exist or are incorrect.

I think the guys over at audiobookshelf were able to integrate the audible api advplyr/audiobookshelf#157 (reply in thread)

I think the genres are scraped from audible and stored in the audnexus db but I could be wrong.

Can beets.io also tag single file m4b chapters? The latest audnexus api calls can also grab chapter info from audible.

API usage documentation can be read here: https://audnex.us/

[Neurrone]

I've started a discussion on Beets requesting for help with some problems I'm having with the process, I have posted a link to my work there.

[Neurrone]

Quick status update. I realize that Beets really really dislikes it if I don't provide chapter info (which I have using the audnex.us API), thanks for that tip.

I managed to get this working extremely well when the book is in the form of a folder with each file being a chapter of the book.

I've opened a new discussion on Beets on enhancing support for audiobooks to see if they would be willing to support other formats such as:

• A folder of a few mp3s, e.g, part 1, part 2 for when the book is too long to download as a single book and Audible breaks it up
• A folder of many mp3s where the files are not split by chapters, and there could be many files per chapter
• A folder of folders (disk 1, disk 2 etc)
• A single mp3
• A single m4b with embedded chapter metadata

The main issue is the assumption that one file = one track / chapter.

In the case where adding this support isn't possible, I'm wondering how useful it would be for me to continue developing this plugin even with such a restriction.

I'm also wondering how hard it would be to work around this problem, e.g chapterizing a book to be 1 file per chapter, to then be fed into Beets. This seems like the most practical solution.

[Neurrone]

I've uploaded a preliminary version of an Audible plugin, you're welcome to give it a try.

I'll probably only have time to work on this or extending Beets to better support this use case in a few weeks.

Would welcome any help from anyone else interested in making Beets for audiobook management happen.

[Neurrone]

I have made a massive breakthrough and have gotten Beets to work even for m4b files as well as books in the form of multiple mp3s even when they're not chapterized.

As I mentioned before, the case for properly chapterized books (meaning that the number of audio files is the number of chapters returned by the Audible API) is straightforward because that is what Beets is already optimized for.

The problems were when the number of files is not the same as the number of chapters.

The key insight is to manipulate the book / album data being returned to Beets, depending on whether the number of files present matches the number of chapters.

For example, lets say there are 27 chapters but only 1 file. Instead of notifying Beets that this book has 27 tracks, I "lie" and say that this book only has 1 track, i.e the number of files. Then the matching works very well.

I'll work on polishing the code a bit more to add description.txt, reader.txt and writing of cover art.

The dark days of using Mp3tag will soon be behind us!

[Neurrone]

@seanap its ready for use, see https://github.com/Neurrone/beets-audible

Let me know if the instructions are unclear. I need to create a mod for the linuxserver Beets container to make setting it up with Docker easier.

I've tested this on a variety of books and so far, it has worked on all of them.

Note that the comment tag and text in description.txt is in markdown format.

[Neurrone]

I've gotten most of the tags that Beets writes out to match what you suggest, except for the following which I have some questions about

• For tit1 (contentgroup), what is the value when the book is not part of a series?
• For pgap (ITUNESGAPLESS), what is the value when it is not an m4b? Is it just not set?
• For shwm (SHOWMOVEMENT), does it only apply to a m4b files for books that are part of a series?
• For TCOP (copyright), I'm not going to bother setting it in Beets because that is harder for me to extract out, that would be a lower priority item
• I noticed that Mp3tag writes TDRC and TDRL for the year, while in Beets it writes it as TDRC=2021-05-11. I'll probably just leave this as it is.

[seanap]

• From ID3 "The 'Content group description' frame is used if the sound belongs to a larger category of sounds/music." I would take that to mean that if the book isn't part of a series then we leave it blank.
• ITUNESGAPLESS is only a mp4/m4b tag, and I think itunes is the only program that uses it.
• Correct shwm is mp4/m4b only tag. There is no standard for which tag the series info belongs, I personally like using the MOVEMENT tag because there are built in tags for movement title, movement #, and SHOWMOVEMENT to designate that it's part of a series. However, there's not a single audiobook player that looks for the series in the movement tag.
• TCOP isn't used for anything I wouldn't worry too much about it, but what I do like to parse is the copyright year and I set in the TDRC (personal preference).
• Many times there are multiple dates associated with an audiobook. There is the date the book was originally published, there is the date when a particular release was audio recorded, and sometimes another date when the same book was re-recored with another narrator or a 20th anniversary, etc. Because of that I like to use the standard YEAR (TDRC) as the original publication year/date, then use the date this particular edition was released as RELEASETIME (TDRL). The hard part is getting the original pub date, I found that the copyright date is often very close so I use that as a substitute. All said, nothing wrong with keeping the release date in TDRC like beets defaults, maybe put the original publication year in ORIGYEAR?

[Neurrone]

I'm not able to get the copyright date. I think the Audnex API strips that out when it returns the book description.