NOTE: MP3TAG is amazing (seriously!) and I have already donated but I would be willing to pay even more for a "Pro" version of the software capable of more enhanced features like those requested below.
User Story:
As a data curator, I have been assigned to curate a huge library (100k+) of MP3 and MP4 deposition files that require a significant number of metatag and filename updates. However, not all of these files require the same types of tag updates.
Since MP3Tag is only able to accept/execute 1 tag update at a time, the process of physically cleaning up the library requires that I manually define and execute a tag update and scope, monitor the "Writing tag data" process, wait for it to complete, then define and execute the next tag update and scope, manually monitor the "Writing tag data" process, wait for it to complete, rinse, repeat, etc.
If the process completes while I am working on something else, productivity and efficiency are negatively impacted until I notice the current update process has been completed.
Request:
Enable "queueing" of file updates, so that it is possible to "stack" multiple tag updates associated with different groups of files and have these tag updates process in sequence.
Enable an optional audio notification for when a "Writing tag data" update (or the current queue of stacked updates) has finished.
See e.g. this thread on running several instance of MP3tag which would serve the same purpose in a way: you can start different processes on files:
I would also like to draw your attention to numerous threads that deal with the problem of files that cannot be written due to simultaneous access of other programs, e.g. here:
I fear that several MP3tag processes running would lead to even more of these events.
Thanks for the quick reply @ohrenkino and for the links to those related threads, just finished reviewing them.
Just to clarify my intended use case and vision, the ideal solution would allow the following behavior:
User would define and scope tag updates to a specific set of files, and submit them for execution.
User would then define and scope another set of tag updates to a completely different set of files, and submit them for execution.
The second (and/or additional) tag updates submitted for execution would be added to a first-in/first-out processing queue, and executed in order of submission.
When all queued updates were complete, MP3Tag would play a defined alert sound.
This is important because (as long as the files in each tag update scope do not overlap) this would negate the very valid concern you raised regarding the problem of files that cannot be written due to simultaneous access of other programs.
Additional questions:
I reviewed the links you shared, and it seems that the takeaways are that there is no way to run multiple instances of MP3Tag from within the same OS at the same time, unless the instances are hosted virtually somehow (VM, Container, etc.). Is my understanding accurate? I fully recognize the simultaneous access issues would still persist, but I was considering potentially running multiple instances of MP3Tag to process simultaneous tag updates for files on completely different repositories. For example, if MP3Tag instance 1 were tasked with processing tag updates for files on HDD1, and MP3Tag instance 2 were tasked with processing a different set of tag updates for a different set of files on HDD2, this might be a clumsy yet workable workaround to accelerate efficiency?
I still fear that even though files may look as different sets initially, the manipulations of the first task may lead to criteria so that these files should also belong to the second set.
But this is just as hypothetical as all the reasoning that, of course, every user would take care to keep the sets nicely separated ...
The fact is: there is currently no function to achieve this. That is why you made the proposal.
In respect to several instances: yes, a VM would be the only way. And completely in your responsibility.
100% agree that ensuring the scope of files for each update do not overlap would be exclusively the responsibility of the user, not MP3Tag.
Based on your comments in the other threads I can tell this is not a product request you are fond of but I humbly request you consider implementing this or similar functionality someday. If used properly (again, the responsibility would wholly be upon the user) it would be tremendously helpful for large volume curation efforts!
In the meantime, thank you for your time and innovative suggestions. MP3Tag is amazing and your efforts are sincerely appreciated!
@ohrenkino - Thanks for clarifying!
Given your exceptional product knowledge and expertise, I assumed incorrectly you were somehow associated with the product, lol.
