Recently I have switched from making copies manually to a software called BackUp Maker [version 7.202 available for free at http://www.backupmaker.com]
And here is the problem: if I select a file[s] on a list, don't do anything to them, but evoke the save Command, then that file is changed; to the same. It just gets an info written to it, that it was saved [and thus, if it was saved then, it must have been changed]
And what that does is this: BackUp Maker sees later on such "changed" file at makes a copy of it; because I told him to automatically copy changed files [which in case of Mp3tag are suppose to be those with really upgraded tags]. So in my tests I end up with copies of changed files which are not really changed, because they are all the same as before
Although come to think of this, this should not have any real negative effect; because if I do not changes tags there is no need to save. And if I change tag but do not save, then data in tags reverts to original one. But every accidental or doubled save can result in copies being made of unchanged files. It is unlikely, but not impossible to happen
Mp3tag should not allow to save if there is no change done. For example Corel DRAW differentiate the action of Save from the Save As. So if there is no change done to a file opened in Corel, both the Save icon is inactive and the CTRL + S shortcut does not work- and only Save As can be executed. And so Mp3tag also should block the Save, until a change is made
Saving a file in MP3Tag always changes the archive-attribute of the file, regardless if you keep the date or change it.
Probably your backup-software looks for this attribute.
You cannot block the save-button in Mp3Tag because if you mark several files and edit changes in the tag-panel these changes may be changes to some files and not be changes to other files.
You would for instance not be able to change all tracks of an album to the the same album-tag if this change would not be a real change for some of the tracks.
Your wish would simply destroy one of the main useful features of Mp3Tag.
Not to do it with blocking the button would require that Mp3Tag would read each file again before saving, compare the tags and the decide to save or not.
This would be a possibilty but I honestly don't know if this requires extra file-handling beyond normal windows-api-functions.
But what would be won to tell MP3Tag not to set the archive bit with saving?
The thread-opener seems to use a backup-software that relies on the archive bit.
So it would be necessary that Mp3Tag would only set the archive bit if the file itself changes. And for that Mp3Tag again would have to examine each file before saving. There may even be changes done by other software while Mp3Tag has not made a refresh.
Another solution would be to use a backup-software that looks for the time-stamp or for the size of the file.
I keep a mirror of my music-files using freefilesync and synchronize my files with a second instance.
In practice, if I export settings from it, restore system and import setting back, when I want to make a partial bacup of only new / changed files, BackUp Maker first [one again] has to make a full backup copy [only after which it is able to make partial copies]
And that would mean read + save time?
Why? Loaded files were already red- I pick one from the list and see, what it contains
[And messing with files loaded to Mp3tag outside of Mp3tag is a whole different story; and with such concern, Mp3tag should re-read all folders before every single action, which would be simply preposterous]
I took a look at it- and the I went in search for something more user friendly
Two different EXE files for one software? Really?
But even if: would FreefileSync [or Synctoy] somehow avoid this issue with Mp3tag saves? Or would it be all the same like with BackUp Maker. After all, it is the Mp3tag who is the "culprit"
You can configure FreefileSync either to look for timestamp and filesize, only filesize or content of the file. Looking for the content naturally is the slowest alternative.
You are seriously suggesting that Mp3Tag should look for changes in thousands of files at the moment you mark them to be able to decide whether to display an active save-button or not?
I am trying to understand the workings, so that I can come with some optimal solution; something that would fit my both my workflow and my spread of data over HDDs / SSDs
Apparently there is no way to deal with this inside Mp3tag, and there is probably no way of dealing with this issue with BackUp Maker
No; I do not know
But what happens if a file is on the list but you move it to a different location outside of Mp3tag? How does Mp3tag "removes" [blanks] tags from that file when you select it?
Could we come back to the original reason for writing this thread: Mp3tag saves something but not in the way you want it.
The reason for the discovery of the alleged bug is then not a faulty behaviour of MP3tag - MP3tag saves all the information as one would expect - but the behaviour of other programs beyond the control of MP3tag.
To me it looks a lot like a feature request that is usually posted in the "General Discussion" section.
This would also be the place for discussions about e.g. backup programs and their benefits or drawbacks.