Can you please make a git repo so we can contribute I think I found a solution to the copyright issue and I have a fuel modifications I'd like to contribute as well
You can just upload your modifications here for now and I'll see if I want to incorporate them.
I know you wanted me to just upload my changes to here, but I had so many of them that it was more feasible for me to put them all in a git repository so that I could see what I had changed over time so these are the changes I made I updated your script to allow searching by file name as well as a couple of other things, including fixing the copyright the rating I made a beta script as well, which I have not done a lot of testing on to centralize the ASIN Seach so that it’s all in a single file instead of having to update every file whenever there’s a change, I’d be happy to give you the repository license it under whatever you want a license it my code is MIT licensed so do whatever the heck you want with it
I also added in some feature specifically for using Plex with audiobooks because Plex has an issue having multiple album artists so because that’s what I use I put in some fixes for that
I'm not a big fan of multiple versions of the same script. I've moved your version to a separate topic for now.
I currently don't have time to review in detail. However, I've noticed that you're just using json_select "copyright" to get the copyright data. Do you have an example audiobook that contains this field?
I adjusted the query URL’s to include it
The reasoning behind the multiple versions for the same script is one of them queries based upon the file name the other one does author and title as far as the ASIN one I’m still debugging it a little bit so I didn’t want to overwrite The working one with the beta one the beta one works, but I’m just doing checks on it to make sure I’m not breaking anything
You can see all the changes I made by comparing version five which is in the history, to the head of the repository
First of all, many thanks for all the changes!
I'm mostly incorporating them into the official version of the tag source and noticed some things I'd do differently and which I wanted to discuss before releasing a new version.
-
Field
ABRIDGED: I did some research and it seems that theformat_typeproperty can haveabridged,unabridged, ororiginal_recording, so I'd rather name this fieldFORMAT(assuming the field name is of your own invention). -
Field
EXPLICIT: I'd only write this ifis_adult_productis true. There is alsoITUNESADVISORY[ 1 ] which would also make sense, but it only applies to MP4/M4A/M4B. -
Fields
TMP_GENRE1,TMP_GENRE2: I've left them out intentionally so far nobody mentioned them missing. I'm now wondering if those are used at all and if there is a reason why you want them to be included? -
Field
RATING WMP: I've left this one out intentionally. It only makes sense for ID3v2 so I'd rather use a format-agnostic user-defined fieldRATINGand let the user do post-processing if necessary. -
Field
ALBUMARTISTS: I've changed this to only be written if the audiobook has multiple authors.
This is definitely my own invention
I Including them to make the script compatible with the original audiobook script same with RATING
Is it possible to do both so that we can maintain compatibility with existing stuff while at the same time moving forward
As far as why I wanted them, I used the template from the original audiobook library as the layout for MP3Tag, and it just looked like things were missing. That’s why I reenabled them.
Sounds good
is there any way to save the author ASIN that you can then of ie some sort of tag that is like a dictionary aka tag AUTHOR ASIN equals multiple key-pares Author name: ASIN
Also I was wondering if there is a way to filter out this like author name - editor or translator, etc The suffixes are not part of the author’s name, and only serve to confuse software.
As far as this goes, I think it would make sense to have both true and false. It just makes things simpler when you go to use or program media managers.
I honestly believe that we should take the audiobook tagging and generate a specification based upon the original audiobook tagging app script and then any changes we make call that version 1.1 that way media managers can implement the specification and we can continue to innovate based upon the information we find on Audible Also, if we do this, I think we should include in the tag the version number of the specification, that way media managers can easily identify and know what to expect.
Version 2 of the specification should be when we finally make a breaking change
Also do you agree with the ToDo file I included in the repo
Thanks again for your feedback!
I've just released v0.6.0 of the Tag Source which includes most of the changes and addressed most of the todos.
Let me know if you find something crucial missing or if there is something not working as expected.
Would you mind if I uploaded it to the repository that I created
No problem, please go ahead.
What did you think about the long-term todos that I had in the repository?
Also, I don’t know if it’s possible, but is it possible to make multiple submenus I know you can make one, but can you have audible then the URL and then the different options that you can use that URL for?
Also, is there a specific license that you would like me to add to the repo
My vote is for ether a GPL or MIT
I assume you're referring to using the AudiMeta API. I have no experience using this API and I'm not sure if it's worth the effort to switch. The only benefit I currently see is the chapters support - but most chapters are named "Chapter 1", "Chapter 2", ... anyway (at least in the audiobooks I own).
From what I understand, the developers of AudiMeta are also working on a dedicated Audiobook Database, which sounds interesting.
I think most users don't use all locales but only one or two and delete the rest of the files. To answer your question, it's currently not possible to make arbitrarily nested submenus.
If you want to add a license, please use the MIT license.
I guess something and keep an eye on until it actually makes sense. The reason I thought it might be beneficial to switch to it even now is it handles most of the string manipulation is very hard to do in lua
It's not even Lua: Developing Tag Sources – Mp3tag Documentation