I have a master library on my main PC which I then sync to multiple other locations, and may have to sync back as well, but I have difficulty identifying which files need to be synced.
It ought to be possible to use the Archive flag, but Windows doesn't make it very easy to copy according to whether that flag is set. I could probably write a batch process to do it, just not got around to that yet (note to self).
If I turn off timestamp updates in MP3Tag, I can't identify updated files by their timestamp. If I turn on timestamp updates, MP3Tag seems to "touch" files even if I accidentally double click a field in the listing, thus opening it for edit.
Have I got some setting wrong? Am I doing something wrong? Does anybody else see this / not see this? What do other people do to keep multiple deployments synced (I resort to copying the whole lot at times, which is lengthy and not useful if there have been alterations in more than one place)?
I have Foobar2000 in the mix, which is also capable of updating tags in audio files.
In my configuration, the timestamp in Mp3tag is activated.
I copy all touched files periodically to all my various backup destinations with the above mentioned ROBOCOPY.
In this (german) thread, another (GUI-) Tool called FreeFileSync was suggested:
Every double click on a file in the main File List of Mp3tag automatically save it.
Please also check your Tags options:
Every time I run Robocopy I have to copy thousands of files, so it doesn't really matter, if some more "untouched" files will be transferred.
The copy process runs in background, I can do something else in the meantime.
Maybe this question/answer (do not be confused by the title) can help you too:
From the link to my posting above you know that I use FreeFileSync. This software has 3 alternative options for detecting the necessarity to sync:
Filetime and Size
File Content
File Size
The only practical way for me is "Filetime and Size". I try to prevent mass change of the timestamp in Mp3Tag, which can occur if you don't make use of filters and apply changes on your unfiltered complete library. The few accidently happening changes of the timestamp don't really slow down syncing.
The option "File Content" could be a solution to not using the timestamp but detecting different content between files takes much more time than unnecessary syncing files with accidently changed timestamps.
i must make some time to do trials: find out what exactly MP3Tag (and FB2K) does to files under what circumstances and according to settings. It doesn't work for me to just turn off timestamp updating completely (unless the archive flag can act as a substitute), nor copying files "just in case". And do my current copy operations preserve timestamps? Not sure.
There is a risk of specific files being marked "changed" (whether that be by archive bit or by timestamp) in two places, so then I need to check whether there was an actual change in one or other of the copies to be treated as "master", and if there was an actual change in both flag that up for manual inspection and repair. Obviously it would be best not to mark a file as changed unless it really has been!
I wasn't aware of the robocopy command, but I see it has a plethora of command switches available. That might well form the basis of a series of BATs.
I have concluded MP3Tag (3.18) has some undesirable behaviour, in that it touches files (ie sets the A attribute, and updates the timestamp if not disabled in settings) when it doesn't need to. I'll take this up in the appropriate area of the forum.
I am not very confident that you will get MP3tag to change the behaviour to write back the tag data once you have opened the file.
MP3tag does not compare whether you have made any changes.
Getting into edit mode for a field is action enough to assume that you as the user wanted to modify something.
Also, instead of changing MP3tag's behaviour it would be an idea to change a workflow which seems to include more or less random changes to files instead of having a master collection and then a number of slave installations into which all files that seem to have been modified in the master can safely be copied.
To avoid allegedly unwanted changes, the extensive use of filters helps to narrow down the files that really need treatment.
All this as a firendly hint on how to overcome the problem until the
Is it? You've never had a slip of the mouse?? That is a lazy assumption by the software and not user-friendly.
Just because it doesn't, doesn't mean it couldn't. Write comparison need not be required, just a flag to register input has occurred and not just that the tag field was highlighted. I would also suggest nothing should be committed unless Enter/Return gets pressed (which is the data-processing meaning of that key!). People who do want changes committed regardless could have an option setting.
Change the user to suit the software rather than the software to suit the user? Hmm.
I know that a number of features have been introduced to MP3tag in the meantime that where out of the question until otherwise.
Form my point of view it is always a question of give and take.
MP3tag offers you a couple of features (as a freeware program) and you see the advantages and perhaps the problems.
You have now a problem coming from a certain workflow - and I cannot judge how pressing that problem is.
If it is a bad problem, then currently the only way around is to avoid the steps that lead to the problem. Suggestions have been made.
If it is no real problem then you can probably live with it until the function is implemented in the program.
So, I do not know what your approach will be.
You have written the request which is the only way to do it.
But as always with requests it is not easy to find out whether the request aims at the implementation of just one particular function or whether it is a plea for help to find a way around it.
Of course I have double-clicked on places that later on proved to be not the right ones.
But perhaps your use of MP3tag is not the optimum way.
MP3tag is a tagging program, so the first purpose is to make tagging as easy as possible. The double click or the simple click is therefore assumed to start editing - not playing a track.
If you have the workflow that goes through your collection manually and only occasionally, you want to edit the data, then perhaps the use of a dedicated player like Foobar would be the better approach.
That usually plays a track instead going into edit mode.
And if you want to use MP3tag for editing, then simply drag&drop the entry from Foobar to MP3tag. This would avoid the ambiguity of your intentions.
I've had an idea for a work-around: is there a facility to make backups of files before altering them, eg copy the original file to (say) songfile.mp3.bak? The .bak might preserve the timestamp info, but even if it doesn't the existence of a .bak would flag a file which might have been changed.
is really the best way - assuming that you use MP3tag with all its virtues in respect to to bulk editing and edit thousands of files in one go. Then the added .bak files would clog up your disk, with all the problems that arise from shrinking free disk space.
Another problem may be that the .bak files are usually not treated by MP3tag so you can't delete them or load them any more which would mean that you do not see the "flag" in MP3tag.
The way I've been preserving original file timestamps for years, in case of accidental timestamp updates (eg: if another program modifies the timestamp such as foobar2000 when adding ReplayGain to MP3 files*) is a system the marvelous user DetlevD created years ago.
You first have to store the original file's date modified timestamp to a custom tag in the file itself, using a custom Mp3Tag action of your making.
Then if you want to restore the date modified timestamps back to the file itself use DetlevD's Mp3Tag export script which creates and runs a temporary VBS script. It can also apply these in batch (ie: multiple files at once).
The action I use is as follows:
Action type: Format Value
Field: LAST_FILE_MOD_DATETIME
Format string: $if2(%last_file_mod_datetime%,%_file_mod_datetime%)
This action creates the date modified custom tag that can then be used by the export script to apply the original timestamp... Or you could just leave the file as-is since you now have preserved the original timestamp in the file itself.
I personally also like to preserve the date created in the file itself, even though the VBS script doesn't restore that, using:
Action type: Format Value
Field: LAST_FILE_CREATE_DATETIME
Format string: $if2(%last_file_create_datetime%,%_file_create_datetime%)
Only caveat is the VBS script doesn't handle various special characters in paths, so sometimes I have to rename the files first or move them to a different directory temporarily.
I made some small tweaks to the export script, so it doesn't try to open the File Explorer directory following being run and so the temp VBS script is created in the standard Temp directory.
Thank you for the long and detailed reply, that looks like a useful tool for future reference.
Unfortunately it completely misses the point. MP3Tag has a setting which enables timestamps to be preserved.
I want to identify material changes to files by timestamp, but if timestamps are set to be updated in MP3Tag it also updates the timestamps on files which get touched incidentally with no material change to the content.
The problem is this: I maintain my library on several machines. I need to be able to tell which files have been modified so that they can be synced. If a timestamp has been updated unnecessarily, it doesn't need to be synced.
It doesn't sound too bad for a file to be synced unnecessarily, but what it it then overwrites a legitimate update made on another machine's library, with an earlier timestamp? The legitimate update will be lost.
When there is a "sync conflict" (as above), I have to investigate what has changed and potentially combine the changes. That is a manual process. Obviously I don't want false positives.
But isn't this a problem of the syncing software? How should a software determine what you consider a legitmate update? It could just as well be that you first modified a file and then later went back to a version that looks like the old version but is in fact the most recent update.
You are right: such changes require
Why is it a "problem of the syncing software" that MP3Tag updates timestamps unnecessarily?
Yes, updates in multiple places are and always will be a problem requiring manual intervention, but the problem is exacerbated when there are false positives. Stopping MP3Tag (and other software) from updating the timestamp unless there is a material change to the file content would minimise the false positives, and minimise the tedious task of merging files.
It would be enormously helpful if MP3Tag didn't have this trait, and I cannot understand why anyone would consider it desirable that it does this except the lack of will to fix it. Without such a fix, I am contemplating intricate workarounds such as creating a database of file hashes, and LaurenBacall's suggestion above might prove useful (where the hash of a file has not changed, the timestamp can be restored).
I agree it would be challenging if Mp3Tag updates files' timestamps without modifying the file itself (personally I haven't tried reproducing it as I leave the preserve timestamps option enabled).
In terms of syncing files, yeah, timestamp-based matching isn't the most robust unfortunately, though it probably works fine for most users/use cases.
Rsync for example has the --checksum option which automatically calculates a checksum for files to see which need syncing (rather than its default more simplistic approach), though there are also other methods I've seen from other sync/backup solutions such as checking filesize + timestamp checking, or checking only portions of a file, etc.
