I have a suggestion that I think could be usefull to many people.
I use all my music from network share, and speed is not ideal when using programs like mp3tag.
I would suggest adding action queue, so when you do a large action that takes like 5 minutes to complete (e.g. change artist on 1000 songs) you dont have to watch the progress bar fill, you can continue editing stuff, and program does long action in background, showing you only percentage of completion.
You could then also add more actions to queue as you perform them, GUI would show you the result, but actual changing of data would happen in background.
Also reading of data could be done in background, filling list in groups of 100 (or 10) as they are read, so you can start clicking right away, without waiting for all thousands of songs to be read first.
Thank you for taking your time to read and consider this
I do not think that background activities would really be useful. On the contrary: if you apply a filter and have actions being executed in the background you can never be sure that files you see actually match the filter or when the list will show the final result - consequently, you will wait for the actions to complete (which is just the behaviour you see today).
Also, you would have to implement some kind of locking mechanism to prevent simultaneous edits from different actions. THis would then result in incomplete execution of actions as files are locked. The forum is full of complaints about editing failures induced by Explorer - the mp3tag internal locking would make problems worse.
What I would suggest: instead of copying data over the network for each edit (which is the case if you edit the files on the network source) you should copy the files to a local folder on the local drive and do all the editing there. This would enhance the performance dramatically.
Just to be not all to negative: there are suggestions to make mp3tag command-line capable and call actions and action groups via command line parameters - this would then emulate some kind of batch-processing. This is feature is not yet available (and I have no clue whether it ever will be).
For me the Library feature solves the issue with reading in the data.
I understand robyhr's suggestion. My music is also on a network share and writing changed tags to the files takes forever. The UI forces you save and wait before you can continue.
Copying the files over the network is an alternative, but it is rather inconvenient.
So I would also like to be able to continue working while mp3tag writes the adjustments to the files in the background.
or taking the effort to copy the files to a location first where faster access is possible.
On a network drive, you have Megabits as access speed whereas an internal ssd allows several Gigabits, so 10 times the speed.
And that is the bottleneck, not MP3tag's user interface.
@ohrenkino you are correct, but with 1.7 TB of MP3 files in my library, storing my MP3 Library (128,000+ tracks and counting) on an internal SSD drive is not an option for me. Besides, with that many files I store them on a RAID array (because I'm nervous like that).
Since both options would solve issues for a lot of users, a 'toggled' choice to run tasks in the background (on/off) would be a cool feature (FWIW).
ok, so an SSD is not the medium of choice.
A good ole magnetic HDD would still be much faster than access via network.
But your local setup is your choice.
I still believe that any background task will slow down a foreground task - and vice versa.
So, for the best performance the foreground task should get as much access to the ressources as possible.
I can just see so many things that can go wrong here. What if you make a second and third change to the same file? What if another program accesses one or more of these files?
Thanks for the reactions and feedback. I would like to emphasize that I enjoy using MP3tag and from that point of view I would like to point out what could make it even better.
Copying the files locally is a good work around, but it is inconvenient for several reasons.
Currently, there is always some network (or internal drive) idle time while the user makes the changes in the UI, because it is not possible to queue them. So, it is not possible to optimally use the available bandwidth. The user has to wait until he can make the next changes, so he can not optimally use his time to manage his music files. Those two things are stupid and could be solved, so that is why I am reporting it.
Then the requested changes are made to the file. There are several good solutions. Either in several steps (several successive writes), or directly to the final version (changed buffered in software, then saved in one write). It does add some complexity, but nothing insurmountable.
This problem is not specific to network shares or batch jobs. With the current way of working, problems can just as easily occur when several programmes make adjustments at the same time.
I don't know the details and how mp3tag handles it, but software can lock files to prevent other programs from making changes. It can be used on both local disks and network shares.
In most cases, I suspect that it is one person making changes to the files with one program. Having multiple programs make changes to the same files at the same time is generally not a good idea.
But even then, it is still possible to handle it gracefully when difficulties arise.
In addition, with a proper setup, it is much easier to protect data from corruption on a network share. There is redundancy (RAID), protection against silent dat corruption, automatic snapshots and automatic backups.
No.
If you plan your steps carefully, you can write an action group that carries them out at the optimum speed.
See also this discussion around the implementation of the use of several instances of MP3tag which shows the pros and cons of a simultaneous access and other advantages and drawbacks:
Thank you for your answer. I really appreciate your responsiveness.
On your recommendation, I have read the discussion on the implementation of the use of several instances of MP3tag.
Do I understand correctly that the main difficulty is that when changes are made to files outside mp3tag's knowledge (or in a second instance or as queue actions), the status in mp3tag is no longer up to date, which means that actions may not have the desired effect?
Another solution might be to temporary storing the metadata in a database, apply the changes there and when finished, write it to the files? The UI can instantly update using the database. No issues with waiting for filters. The only condition is that nobody touches the files in the meantime, but I don't think that's asking too much. Otherwise, error: file not found.
I am pitching ideas, I realize it takes a lot more work to implement it in code.
I'm not entirely sure how action groups could help. Maybe there is a better solution, I don't know. I give a little scenario, to explain what I'm doing:
A family member loads some new music on the network share and I want to add it to my very well organized music library. So before adding it, I check the tags and file names using mp3tag. Say we have 10 albums with about 15 tracks each. I load it in mp3tag. It takes some time, but that is fine. When loaded I notice that for the first album the year is not filled in. I select the files and fill in the correct year and save. It takes about 15 seconds to adjust the files of the album. Then I notice that the numbering is wrong, I use the auto number feature. Again it takes 15 seconds. While I wait for it to finish, I see the next album has album artist not filled in. I have to wait for the full 15 seconds before I can make the adjustment and then wait again. Repeat that for the 10 albums and I have waited about 5 minutes total in between actions. When finished I used the tag to filename feature and move the files to the music library.
It doesn't matter that it takes a long time, as long as I can do something else in the meantime. The 15 seconds are too long for waiting and too short for doing something else and that is frustrating.
The problem with this approach is, as I see it: you have to do everything at least twice (takes probably much more time than the 5 minutes you calculated) as you have to find out first which of the files did not get the right information.
Depending on which file was blocked by the file manager, this could lead to inconsistent data in albums which are then torn apart.
If you create an action group that copies the artist to the album artist. or sets the number with format value actions, then at least the wating time betweeen these 2 steps is reduced to just 1 pause.
This would be the solution to your idea
where the complexity is on the user's side to get plan what to do and lay it down in actions.
If you rely on the UI, though, it is interactive - how many other programs do you have that deal with such amounts of data and so many files in one editing step?
How long would it take a local WMP to build its library from a network drive?
Or how long would it take iTunes to do the same?
How long would Foobar2000 be in the state of "Initializing" to read the metadata?
And even though at least WMP and Foobar2000 do this in the background, you still cannot access the files until those programs have incorporated them in their database.
And they only have to read the files once.
But if you access files on the network drive several times, reading an writing via the network occurs several times.
As you find
but it is necessary for processing to have them in the local RAM, and if the files cannot be found locally, then MP3tag copies them for you - which leads to the behaviour that you found.
Ok, I understand why the process is so slow. Each file has to be copied locally and loaded into RAM for each edit. It is indeed not optimal if this has to be done several times over the network.
So the best solution is to cache the files locally, one way or another, and then write them back to the server after processing. A sync program could do this.
So I use mp3tag to mange the tags locally and use another program to handle transferring the files.
Some good action groups could indeed speed things up. Thanks for the suggestion.
