I have some thoughts on enhancements to Picard. What is the best way to share these ideas? If it is here, that is fine, but it seems not the best platform. I have some user stories I would like to share.
The forum is a good place for brainstorming, but if that brainstorming leads to concrete ideas, the bug tracker is the obvious place to report those.
4 Likes
Ok, I will start here as you suggest.
- As I have stated prior, I do not use Picard for tagging. This is sad as Picard is a great tool. What I would like to see (maybe it is there and I cannot see it) is to have a preset on which values are to be saved ad which are to be discarded on save.
- The ability to convert between ID3v2.3 and ID3v2.4 would be nice. I know I can select how I want to save, but a feature to convert as a tool is what I mean.
- Error checking on the contents would be a great addition. For example, the BPM field must contain only numbers. While it is nice to say “110-125”, that is a violation.
- The ability to convert tags from the ID3 format to MP4 format would be great. This can be used when tagging AAC files. While the AAC format does not have an official tagging format, it is most common (to my perspective) that using the MP4 (M4A) tag works best.
-
I suspect that the Keep Tags plugin from Picard’s “official plugins” list will allow you to do what you want. If not, I created a Keep Only Tags plugin but never submitted it to the official list.
-
I’m not sure I completely understand what you’re after, but I think you may be able to accomplish this simply by re-processing the file after setting the desired tag format for the output.
-
That can be done through a script, although it may be a bit of a hack. For example, something like:
$set(BPM,$add(%BPM%,0))will clear the value of theBPMtag if it does not contain only the digits 0-9. It would be easy enough to add additional testing to ensure that the result is greater than zero. -
I can’t really comment on this because I’ll admit that I don’t understand the formats well enough. In these cases, I generally defer to @outsidecontext.
Have you used kid3? If so, that will make this explanation far easier. If not, I refer to the ability to “right click” and just convert from one to the other. I prefer ID3v2.4, however, the common is ID3v2.3. So the ability to change/switch is nice to have.
All good there. There is so much to understand that it leaves all of us in a cloud of smoke. The MP4(M4A) is the worst. I appreciate the honest statement, you can add me to the list of the non expert.
@outsidecontext - any comments on this?
What I refer to he is say the existing tags are ID3v2.3 and I want them ID3v2.4. It would be nice to have a feature to click to make this happen. Same for the other way around.
This might seen trivial, but for me, I prefer ID3v2.4. However, there are times that I need ID3v2.3, for compatibility issues in players that are old to read the tags.
There is this feature. Load up a release that is now is ID3v2.3 (or even a v1.0), and what ever you have set in Options \ Tags \ ID3 is what will then be saved. (Along with updated tags). As long as you have it set to always save to v2.4 then that will happen.
I realise it is those extra updated tags that may be an issue. It is just the way Picard is - it is designed to work with a database to update files. This is why personally I also have something like MP3TAG in my toolbox to do this kind of simple “shift but don’t change” edit.
Sort of. There is a setting to specify how to save, but I cannot change between them easily… meaning I need to go to the settings, change it, save, then go back to settings and change to the norm. This is compared to have a menu items:
- ID3v2.3 → ID3v2.4
- ID3v2.4 → ID3v2.3
The tagger I use normally has this feature.
I used to like Mp3Tag, but it is not Linux compatible. So, I use Kid3 now. I tried Puddletag as it seemed similar to Mp3Tag, but due to issues not appropriate for here, I will no longer use it, or consider it for future.
This comes up frequently, and I think we have a ticket about this somewhere. Current solutions / workaround are (which can be combined):
- In Picard mark the tags you don’t want to get modified as “preserved”
- Use the
$keepplugin to remove all tags except for the ones you care about - Explicitly use
$unseton the tags you don’t want to use
What keeps me personally from starting implementing this whitelist is for one the complexity it’ll add to the already complex handling of tag changes with preserved tags, clear all tags and format specific differences; and secondly that I see other areas as more important.
I think this would best be put into a plugin. The current behavior of Picard is that file modifications are only explicitly done when you hit “save” for a file. These context menu actions for the conversion would go a bit against that. Also I think it would be kind of confusing, because saving could easily change the format again. E.g. if you have configured Picard to save as v2.4, you use the context menu action on a file to convert it to v2.3, then save (which will save as v2.4 again).
I think the current way to do this with Picard would be to actually “save” the files with the appropriate setting. But I would welcome a plugin adding the actions as described by you.
There is PICARD-856 as a feature request for something like that. It has a bit different argumentation, but the basic idea is still to have data validated. I would be a bit careful with that and not too strictly enforce data formats, but only add warnings (e.g. the tag editor could show some warning icon next to invalid values, with some description about the issue when you click on it). The reason is that some people prefer to store non-standard data nonetheless. E.g. people like to store non-integer values for track numbers (e.g. A1 etc. for Vinyl tracks). This violates the standards and might actually cause compatibility issues with players, but it is still possible with most formats (see also the FAQ).
There is not really such a thing as converting ID3 tags to MP4 tags in an arbitrary file. You can’t put MP4 tags into a MP3 or WMA file, for example. MP4 tags only make sense in a MP4 file.
What you describe for the AAC files you have is conversion of ADTS / ADIF file format to MP4 file format. ADTS / ADIF both are very lightweight containers for AAC audio data. This file format conversion currently is a bit out of scope from a technical perspective for Picard. Current Picard / mutagen code is all about manipulating only the metadata portion of the various supported file formats. Code to create a MP4 file from scratch would need to be added.
I’d rather put time into improving Picard’s core functionality than to turn it into a tool for file format conversions. There are existing tools optimized for that. Again, I wouldn’t mind a file format conversion Picard plugin if someone wants to write one.
2 Likes
Interesting information you provided here. The files in question are “.aac”. When I referred to AAC files, I meant the container / file format of AAC, not just the AAC encoding used in M4A/MP4 files.
Avoiding a long conversation, it is my interpretation that that the best option would be to copy the AAC audio to a MP4 container, thus getting the MP4 metadata. This would not be so bad as there is no re-encoding of the audio, just a change in container. As you stated, doing this would be outside the scope of Picard, it would be easier to do this via terminal anyway.
1 Like
Yes, exactly
It is not necessarily totally out of scope, I can see good arguments for Picard to get into this it. I more see it kind of technically out of scope, since Picard would need to get the code to a) fully parse the .AAC files to get the audio and b) to generate a MP4 from scratch and place the audio in it. When we start adding this we quickly get into additional formats, e.g. why not add conversion between AIFF and WAVE, or AAC into a different container, or MP3 audio into MP4 container? And once there the next step is things like WAVE to FLAC?
As there are not many actively working on Picard (mostly rdswift, zas and myself, with varying available time) I’d rather focus on things that are more core functionality.
What I think would be a nice addition would be a plugin which allows to trigger conversions like this, maybe using ffmpeg or sox command line utilities. That could indeed be useful.
I fully understand what you are saying in regard to a plugin to resolve the need. However, I want to share my opinion on that.
Plugins, user scripts, extensions, etc all break things. Yes, there are few exceptions to this, but that is generally the case. When debugging say Chrome, step one is to disable all extensions. In Linux, GNOME extensions are the same, when you have a shell memory leak, disable all extensions. I will stop there as I am sure as a developer you understand my point.
I am sure I am thinking outside of the intent of Picard, but I can see an easy way to add a file converter easily. Say I want to change MP3 to M4A, or FLAC to Opus. There could be a customizable button where I as the user could add a custom command line variable to do what I cant, and clicking said button could execute this command and provide me the result.
Personally, I use a few of such things. However, I learned to not rely on them. If they are cosmetic, when they break it is a pain, but not really problematic. When you start to combine data from multiple sources, write data, etc… that changes. I host only 2 tools so far for MB (but have at least 1/2 dozen in development but not ready for production). I am fine wit the iTunes artwork finder as errors will only not provide you artwork. No harm done. The TOC submitter, that code has been stale for years, many know of it, and it still works. So I have a passive trust there. Plus, it is fairly simplistic, its purpose is focused.
To my point, it is my belief that if a function or feature is deemed useful by the powers that be, they are to be integrated and become a part of the official release, so any and all changes can be coordinated. Even if it is done as a “plugin” where the plugin is a part of the repo, but it is required to be updated and compatible before a new total release can be made, or it is excluded and not available in that new version.
The only similar type of software I have really dug into is Kid3. I talked fairly extensively with the developer and shared many issues… which he has addressed quite well. I mention this as I am well aware how having such dependencies of other’s work can cause issues, but at least they are known vs having the user keep a plugin that breaks the whole.
I have shared my thoughts, so I have a question… since others have written scripts, plugins, etc… the logic has been done already. What is the barrier to integration, aside from time?
EDIT: When I say “in development”, what I mean is that I am looking at the work of others, I have not done anything thus far from scratch.
Plugins can be taken into the official plugin repository if they pass the code style linting and are generally accepted in a code review. For complex plugins it’s also good if the author shows some willingness to maintain the plugin going forward.
We usually prefer to keep functionality in plugins instead of moving them into Picard for reasons like:
- use of external services that might break / go away at any time
- very opinionated functionality
- functionality that is only of interest to very few users
- experimental functionality
- functionality generally considered to be out of scope of Picard’s core functionality
- code that gets things done, but is kind of hacky and prone to breakage
Plugins are much better suited here, because they can be more easily added, changed or even removed again independent from Picard releases.
If a plugin proves to be useful its functionality might become part of Picard. E.g. a lot of scripting functions started their lifes as plugins and later got integrated into Picard. But likewise we might move functionality from core Picard to plugins, like e.g. we did with the Amazon cover art plugin, or plan to do with the music player functionality.
Yes, configurable tools would be a nice feature indeed
1 Like
Thanks for the reply. That leaves me with some things to think on. While I can see the reasoning you supplied, by linking the repos to the main, it is easy to include or exclude. So if it is no longer maintained, it is excluded. Breakage, excluded. Opinionated or limited users, if it works, included.
If there is interest in configurable tools, things like converting from one codec to another or one container to another, I have a solid collection of scripts that do this with the least degradation of quality (or none) I can find. Maybe useful as presets, allowing the user to do as they wish. I have these for FLAC, M4A (iTunes/Apple CoreAudio / qaac), MP3 (without the 16kHz cutoff, hard or soft) and OPUS… of course WAV as well, but I never really store anything as WAV.
As I finally addressed this issue, I realized that the method might be of use to others here. As this is a process I had not previously done, I created a new script to handle a folder of files for this… with the idea being no transcoding or conversions, just placing the AAC audio into a M4A wrapper. I do not know how others think, but for me, this is already compressed audio, so I prefer to not touch it and degrade it further.
It got me thinking on the comment that configurable tools would be nice. There was an interesting app (a blank GUI of sorts) when I used Windows that allowed me to add commands into the GUI and make it sort of a custom app. I wonder if Picard could not include a section for this?
I would vision a nice two tab type section. One tab is where I might add my command line tools, like a title field for MP4Box and a path for its respective local path /usr/bin/MP4Box. On the other tab, I would be able to assign a name for my function Change AAC to M4A and in the function field, allow me to use any of the tools specified prior and allow me to add in the custom command line arguments MP4Box -add <input>.aac#audio <output>.m4a (very quick and dirty example)… if that makes sense.
1 Like