Any chance an option could be added to automatically answer OK TO ALL when renaming files? Clicking this 1000s of times gives RSI, and using macOS Automator works but is much slower than if the feature was built-in.
thank you in advance.
There have been several similar discussions in the past about this. See here for some perspective on the thoughts around OK to All.
Thank you for your response. The referenced discussion doesn't appear to offer a solution; rather, it confirms that the feature in question is unavailable and will not be added.
the only way around it is to check the files first for integrity.and then tag only the ones that prove to be ok.
In my specific case, I encountered duplicate files within 100's of subfolders. There are 1000's of duplicates which remained hidden until I removed the track number from the filename and replaced the filename with %artist% - %title% using the %track% only in the ID3 tag.
From a logical standpoint, it would make sense for a tool like mp3tag to provide a warning in the event of overwriting or deleting such duplicates.
After alerting the user, the tool could then continue with its processes based on 1 chosen response from user.
Once complete, I would manually sort all tracks within mp3tag. subsequently, I would identify and remove the remaining duplicates that still have leading track numbers in their filenames.
Unfortunately manually checking for duplicates is impossible simply due to the number of files.
I can appreciate implementing such feature would be timely but wanted to share my user experience with MP3TAG.
Thanks for your feedback and the suggestion. You're not the first to ask for that and it's on my list. In your case, an OK for all option might help at identifying the duplicates so I appreciate the explanation of your use case.
It's only the former, not the latter. And even when I say something will not be implemented, there are — thankfully — cases where I've changed my mind in the past 20+ years.
thanks Florian, perhaps as a global option at least.
I think it's better done on a per feature-invocation basis and I've already started working on such "Apply to All" options in other parts of the app.
See this one for example, when writing tags fails for a file:
Hi Florian, yes that would be perfect!
The thread I referenced wasn’t a solution, but a discussion about identifying the root cause of the error.
Especially when batch renaming files, an error like this one is a clear indication that the naming convention used likely has a flaw that causes some or all tracks to overwrite others. I would strongly caution about having a “OK to All” option in this case.
The better approach would be to take a step back and identify what is causing the repeated condition, and correct that first. The last thing you would want is to have 18k files become 1 if you were to inadvertently use a fixed naming convention that tells mp3tag to set all files to the exact same folder and file location. Or to have a bunch of duplicate files created that will then require further work to identify and clean up.
This is just my opinion of course, but with 18k tracks I wouldn’t be so quick to blindly override that error message.
I think Florian hit the nail on the head.
How would you know which file to keep? The renamed one or the one with the track number? And if there are more than 1 of these files with e.g. different track numbers - how would you determine which of these files would be the best?
Here is a longer discussion on the topic how to deal with alleged duplicates:
I think that the critierion that ARTIST and TITLE are the same is probably not sufficiant as this would assume that the data is absoluletely correct. But even then you could have the original version, the one from the Greatest Hits album, the anthology. This does not even consider that data is missing from the tag fields like "live", or "remix" or a version that popped up years later.
So I think that eliminating the duplicates actually requires
If an option to remember the user input should be implemented I would favour one only for "Skip all" but not as confirmation to overwrite existing files.
The OK option in the existing implementation is essentially a Skip, so the suggested OK for All is actually a Skip for All.
Otherwise, the above-mentioned files with the track numbers that are used for identifying duplicates would also not exist anymore.
If skipping is the implementation, is there any plan to have a log created that would perhaps summarize the successful number of files, and also to indicate each file write that was skipped/failed? This would help to track down those that weren’t managed as expected.
For a single track it would be easy to find. For a large batch it might be more challenging.