Is it possible to include an action item in an action group so that when that particular action group is executed, the file modification date DOES NOT change unless actual changes are made to tags or files by that action group when it is applied to a collection of files.
We wish to be able to do this in such a way that the file modification date never changes UNLESS one or more tags are actually added or changed. Otherwise, it is difficult to keep track of the "age"of the files in a library if they are processed but no changes actually occur.
Now that I think about it, it seems appropriate that ANY TIME a tag command is executed, the file modification date is kept intact if no actual changes are made, regardless of the way the command is applied.
I've observed that repeating an action item changes the file modification date when it is known that all the changes were already made the first time it was executed.
We need to find a way to sort a collection of albums by their effective age, so we can isolate older albums whose last actual modification date precedes a specific date, e.g. all albums whose last file modification date/time was prior to, say, the beginning of 2016 or the 15th of January, etc.
It is not sufficient to check the "preserve file modification date" option, as we do wish to update the file modification datestamp when actual changes are made.
Thanks in advance for any insight as to how this can be accomlished.
If I'm understanding this correctly you were wanting a way to only change the date modified timestamp if the formatting actions made in Mp3Tag to a file differ from the existing tags? A kind of file comparison.
That is, if you have an artist named 'Greg' and you create an action that changes the artist tag to %artist% (or 'Greg') you'd like Mp3Tag in that case to not change the date modified timestamp. However if the artist tag is changed to 'Sandy' you'd like the date modified timestamp to change.
I think the current method of Mp3Tag is modifying the file since the user is technically writing the actions to the file again, even if it's the same data. Similar to how Photoshop would change the date modified timestamp of an image if one saved an image while open without making any changes.
I can see where having such a feature would be useful in your workflow.
Dennis, I assume that you know why there have been invented different datetime attributes for each file in a file system.
It can make some user's life easier, if someone knows all characteristics about the physical file stored on a disk.
Would it help for those files, which should not be changed, to set the file access attribute to "read-only"?
Or is your desire to 'hide' temporary changes within the file resp. reset the last change of the file's last modified datetime, by resetting the last modified datetime to the datetime value before modification?
If so, then you have to preserve the last mod datetime stamp, and afterwards write this old datetime stamp back to the file properties.
Note: Mp3tag has an on/off option under "Mp3tag Options/Tags/Tags" which can preserve the datetime stamp.
Another way could be to save the last mod datetime stamp into a tagfield within the current file, and use the stored value to decide how to apply other file operations in the future.
MY_FILE_MOD_DATETIME_RAW <== %_file_mod_datetime_raw%
MY_FILE_MOD_DATETIME <== %_file_mod_datetime%
... and do not change the stored value, if it already exists.
Hmm, therefore you have to toggle the option to off, when actual changes should be made.
I would think something like that would introduce a huge amount of overhead into Mp3tag's file processing.
How would Mp3tag know whether or not any data was changed when it saves values? It would have to keep a 'before' snapshot of the tag data for every file in the editor. And considering that you can have images or large text blocks as field values, that could easily add up to an amount of data that couldn't possibly be kept in memory. If it's not kept in memory, then every time Mp3tag went to save a file, it would have to re-read the tags from the file, then compare the field values to those being written.
Something to keep in mind: I don't know whether or not this is relative to your situation, but one thing I've noticed (and make use of) is that even when you use Mp3tag's 'Preserve file modification time' when editing, the archive (A) attribute of the file will always be set when a file is saved. Commonly used by backup software, this attribute is used to tell whether a file has changed. So if you were to haphazardly save a large number of files that you haven't actually edited, even if the file modification time is preserved and the file size doesn't changed, your backup software will still backup all of those files.
I'll have to check sometime if Macrium Reflect detects these changes, since according to a forum post on their site it sounds like they're using a different method of detection:
I use daily incremental backups, with a weekly full backup so I'd like any tag changes to be kept.
Perhaps as an option? Since Reflect's approach to backup is really more along the lines of cloning, that may be why they don't use and then clear the archive bit like traditional backup software. They may not want to alter anything in the file system at all.
I always want to keep the same approximate file modification time whenever I go back and edit existing files in my music library. This way I always keep the chronological order in which they were added. Partly so that my music software can display newly added files without edits of old files bubbling to the top. Whenever I do that, from within Mp3tag, using 'Tools' I run a small script that bumps the file modification times on the edited files by 2 seconds. This way I can easily use the timestamps for any mirroring and backup purposes. One of my Mp3tag requests in the past has been to have a third option when editing: "Bump file modification time by __ seconds".
What program are you using to modify the timestamps? It could be useful for me if there was a way of saving the original date modified timestamp to a custom tag, performing an action, then using a script to restore the original timestamp(s).
Devlev, you're amazing. This VBS script is beautiful with the thoughtful auto popup dialogs and everything. The only thing I changed was removing the opening of the Explorer window, since it doesn't seem to open the music directory anyway.
I did some testing and now I've added the following formatting as a custom tag to my regular formatting action to store the original date modified timestamps for my collection:
This essentially solves the problems of ReplayGain thread I posted! Now I can apply RG in foobar2000 and then restore the original timestamp using Mp3Tag. Perfect. Thanks so much
Discovered that the VBS script stops when it encounters filenames with Unicode characters. Edit: directory names, too, it seems.
So if a selection has 10 items and the 4th item has any Unicode (for example the following replacement characters, Japanese, etc) the script stops at the 4th item and doesn't update the timestamp.
Yes, creation time is often very different and unreliable. If you move a file it often gets a new creation timestamp. Modification time is the only thing my music software uses.
You do realize that Mp3tag itself has the ability to keep the original mod time, right? Under Options > General > Preserve file modification time when saving tags.
The script is only necessary when I want to bump the mod time a little. I use a VBScript I wrote that uses a touche.exe utility to change the timestamp. It's necessary to first make sure Mp3tag is set to preserve the time, then run the script.
Yeah, definitely, always have it enabled. Probably should have used a different word than 'action', since it's most associated with Mp3Tag Actions. How it actually helped me was for applying ReplayGain tags, since currently no program I've used to apply them can preserve the original timestamps. Made a thread about it here.
Guessing it's this program, from a quick search. Do you know if it supports Unicode characters in the filenames?
I use a VBScript and metaflac, which is usually bundled with flac.exe. Metaflac has a --preserve-modtime argument, so there's no need to touch the files after applying RG.
Here's my script. You'll also need the INI file, which you'll need to edit. Point it at your copy of metaflac and set other options according to the comments. Run flacrg.vbs /h to see command line options, such as whether to do subfolders and/or force the re-computing of ReplayGain. The script will treat all of the flac files within a folder as an album for the calculation of album gain.
Here's the touch utility for Windows that I found many years ago. There's a web site link in the text file, but looks like the site no longer exists. I have no idea whether it supports unicode filenames. It's not used by the VBScript above, but I use it for other things, like bumping the file times.
