After some investigation, including updating to the latest version of MP3Tag (3.18), I have concluded it has some (from my point of view) unwanted behaviour.
If tags are edited in the tag editor panel, an explict save is required and a warning given if some other action is about to take the focus away without having saved. On the other hand, tags edited in the listing get saved automatically regardless, despite not having Options > Tags > Save tags when using arrow keys/single mouse click selected (what does that do anyway?).
The problem is that if I double-click a listing entry to have it play in the default player, and fumble the clicks, I can easily open a field for editing. If I then fail to use the ESCAPE key to cancel it and click somewhere else, the target file gets touched even though no alteration has been made to its content.
By "touched" I mean the file archive attribute (A) is set, and the timestamp is updated (unless Options > General > Preserve file modification time... is selected). The consequence is that it is not then easy to determine which files have been updated and which have just been touched but not actually updated.
Please consider revising the code so that files are only touched if an actual change is made to their data.
I'm not saying it is a bug, and neither is it quite the same situation.
It's reasonable to expect a block of selected files to get updated by a tag update operation, although for management purposes it would be handy if any individual file were only touched if an actual change is made.
At least the tag edit pane has an explicit save. Tags accidentally opened for editing in the file list do not have an explicit save – if you don't want to save (and thereby touch the file) you have to a) notice a tag has been opened for editing (which isn't necessarily obvious, especially if the tag content is just one character), and b) explicitly not save (ie press ESCAPE). Any other operation at all (eg a mouse click) results in the file being touched, and maybe an unwanted tag alteration as well.
This does not seem (to me) a particularly difficult thing to fix.
The interaction with the tag panel is different:
As you can select a lot of files, saving the modification each time you jump to the next object in the tag panel, would slow down the editing process.
And as MP3tag does not know when you have finished editing, you have to explicitly trigger the saving.
In the file list, you can only add one field at a time and only for one file at a time. There it is rather convenient to save as soon as the edit mode is finished.
This is not totally true: you have to click on/in an editable field. A click on a read-only field will not cause any update of the modified date.
But if you click in an editable field, then the assumption becomes true that the user wants to edit - with all the consequences.
Fair enough, I wasn't saying I disagree with that – in fact, I was supporting that.
That is not totally totally true (there is a misunderstanding due to the limitations of posting in text): if a field is opened for editing (possibly accidentally), any click anywhere (even outside the MP3Tag window) writes back the tag.
Convenient maybe, but it is an unsafe assumption that it is what the user wanted.
I also don't understand why the state of the MP3Tag window is not preserved when switching away from the window and returning to it. Why isn't a field being edited held in that state?
Another situation: editing tags down a column using RETURN to open each tag in turn. Press RETURN a second time to skip a row, and that file gets "touched" unnecessarily.
I say again: it should be simple enough and not processor-demanding (in single tag mode) to check whether there is a material change to the data before actually writing it (whether by setting a "modified" flag, or comparing data), with one caveat:
IF the file is being locked from alteration by other apps by opening it for write, AND IF closing the write handle (even without actually writing) automatically sets the Archive attribute (we know it doesn't necessarily update the timestamp, as that can be disabled in settings).
Where's the harm in asking for such a simple thing? Whose use-case would be negatively affected? It's as if design decisions made should be inviolable.
I too, have had issues with opening mp3's just to look at the attributes, and then hitting "OK", and watch my cloud services "light up" with syncing thousands of music files.
Sure, now I know, I should hit "Cancel", but it's not very intuitive that the "OK" selection actually saves a new timestamp, when there are no changes.
And the "Preserve TimeStamp" option is problematic when you actually do want to make changes to the files.
I'm not sure how this could be remedied, but would love to see some way that a file change does move the "File Modified" stamp, and vice versa.
In my opinion, an intelligent synchronisation- or backup software should check the timestamp AND the file size to decide if a file has changed or not.
A perfect software would create a hash about a file to be 100% sure if a file has changed or not.
But barring that, why change a timestamp when there is no change? I can't think of any other program that has the ability to view and edit that makes a change to that file, if its not touched...
I think maybe the change to "save" would help. It would at least imply that "hey, I'm about to tax your backup software for no reason if you hit me"......
Don't get me wrong, Mp3Tag is a great piece of software, and I am appreciative of the dev's time and effort here.....
I just think viewing should be just that, and that "save" icon at the top of the toolbar shouldn't be there just for nothing...
That button does not work in the extended tags dialogue - like all the other buttons do not.
By definition in many style guides the "OK" button means "saves the changes and closes the dialogue". As MP3tag does not (as mentioned several times now) compare old and new data but simply saves the complete tag back to the file, every file gets touched. The modification date is accurate in this respect.
I have specific requirements, and I'm building a system to cache hashes and compare them with current hashes... but I'm not a software developer so I'm using .bat scripts to coordinate command line utilities, plus AWK to process the results!
Depending on what you really need you could have a look at Syncthing.
The database directory contains the following files, among others: index-*.db
...holding the database with metadata and hashes of the files currently on disk and available from peers.
