As MP3Tag is only able to accept/execute 1 tag update at a time, the process of physically cleaning up a large volume of large files requires the MP3Tag user to manually define and execute a tag update and scope, monitor the "Writing tag data" process and wait indefinitely for it to complete, then define and execute the next tag update and scope, manually monitor the "Writing tag data" process and wait for it to complete, rinse, repeat, etc.
If the "Writing tag data" process completes while the user is working on something else, productivity and efficiency are negatively impacted until they return and manually notice the "Writing tag data" process has been completed.
Request:
Enhance MP3Tag with the option (within settings) to play an audio alert notification when MP3Tag completes a tag update process.
As you have described a couple of times that you have to wait such a long time, I wonder whether you apply a streamlined workflow.
A first step would be to reduce the number of files that have to be treated in each step.
I would recommend to apply a filter first.
If you feel unsure about how and which filter expression to use, you may post an example to get support.
@ohrenkino - I appreciate the offer, but the performance/wait issue is not so much a process problem as it is just that if there has not been any tag data in a file previously, MP3Tag has to add the new tag data to the file, and the file copied/rewritten by MP3Tag.
The files I am working with are relatively large deposition videos (mp4 format) generally between 15GB to 50GB. To maximize performance the files I am curating are copied to a local drive and connected to the workstation via USB 3.1, but the time required to copy/rewrite the file with the additional tags just takes forever, which is why I have been asking so many questions lately about potentially running multiple instances of MP3Tag in parallel.
Normally meta management would be done externally, but for complicated legal discovery reasons, the tags must be embedded in the files themselves as well. These are the types of solutions you end up with when you let lawyers define your data management requirements, lol
Unfortunately that is the nature of the beast with large video files that initially have little to no tag data. As soon as that header needs to be increased, the entire file gets rewritten. If you update several large files like this at once, you could conceivably be tying up some system resources for quite a while.
As far as the request for a sysem sound after the save completes, were you able to get that enabled? You should be able to enable that in Options>Messages preference.
For such a workflow it will be significantly faster to copy the files to the workstation internal drive (assuming it is a ssd) before tag writing. And then copy it back to the USB drive. This is because USB protocol is slow. Even if the USB drive is a SSD.
It would not be viable with more instances of tag writing as simultaneous I/O operations on the USB would bring it basically to a halt.
@AreDigg - Only if the files being updated are on the same external drive. I've been experimenting with 3 virtualized instances simultaneously running 3 instances of MP3Tag, each updating files on different external USB drives and observing near peak transfers on each instance.
