Help - Avidemux is changing the date of my videos

[Gameshow Host]

I wanted to use Avidemux to trim down a large number of my old videos (get rid of unwanted bits), but every time I save the video, it loses the original date and saves it with the current date!

If I trimmed my videos this way, I'd have to painstakingly go through every file afterwards with date-changing software, manually restoring the original date. I can't imagine anyone would WANT this behavior, so I presume it's some kind of error?

Surely, non-destructive editing and date retention go hand in hand?

I wanted to report this on the Avidemux site but there's no way to contact them.

[zing269]

It's not Avidemux changing the date, it is your OS. The edited file is a new file and therefore gets new dates.

[DB83]

The essence of the above reply went through my head earlier.


But how do you think your editing is 'non-destructive' as far as the original is concerned ?


Maybe a solution for you would be include the original creation date as part of the file name.

[Gameshow Host]

It's not Avidemux changing the date, it is your OS. The edited file is a new file and therefore gets new dates.

I feel that is a trivial point. Other non-destructive editing programs ensure (one way or another) that the dates are retained. It's not difficult to change a file's date.

But how do you think your editing is 'non-destructive' as far as the original is concerned ?

I simply mean it's lossless. No recompression. You don't need to keep the originals because there is no generational loss of quality. Unless I'm mistaken?

Maybe a solution for you would be include the original creation date as part of the file name.

Thanks but that is absolutely not an option for me. I want all my file dates to be accurate.

I wonder if anyone here has an account on the Avidemux forum? (Registration is closed so I can't sign up.) Perhaps they could mention the issue there? I'm sure I can't be the only one who thinks date retention is a sensible and worthwhile feature.

Can anyone think of any reason NOT to retain the date?

[davexnet]

As long as audio and video say "copy" on the left, then the new file saved can be considered lossless.
But it's still a new file, so post #2 is perfect valid

[DB83]

Well do point out the other 'non-destructive' editing programs that retain the date. And by that I mean the date you see in the folder. If you mean some other date then pls enlighten me.


But I fail to see your resistance to my modest suggestion. You have a file written to your HDD (even that for reasons already explained is not the true date unless you transferred a, for example, camera recording on the same day as the actual recording). You now edit that file and the OS creates a new file. That new file, unless I am mistaken, must be worded different to the original since an OS can not write a file of an exact same name when the file is 'open'. Or in this case being read by avidemux. So when you write your new file to the HDD you manually add the critical info to the file name.

[Gameshow Host]

Well do point out the other 'non-destructive' editing programs that retain the date.

I would like to hope they all do, but two that pop into my head are Xnview image editor - if you losslessly rotate images, the date is not changed. And JPEGCrops - which allows you to losslessly crop JPEGs, again, the original date is retained.

You have a file written to your HDD (even that for reasons already explained is not the true date unless you transferred a, for example, camera recording on the same day as the actual recording).

Hmmm. The date of my recordings is never changed when I transfer them to my computer. I would be very annoyed if it was! I like to know the time of recording to the exact second!

In Windows, when you cut and paste a file from one drive to another, its date does not change. Even copying files doesn't change the 'modified' date, which is the date you see in Windows.

So when you write your new file to the HDD you manually add the critical info to the file name.

Yes, I understand what you're saying, but I'm sorry, that really does not sit well with me personally. Call me fussy, but I like all my files to have correct dates. It would upset me if the dates were off. Maybe it wouldn't upset other people, but I like everything to be correct.

To me, having wrong dates is like reading my diary and finding that dates have been randomly changed, so I don't know when things actually happened. I am someone who places a lot of importance on time, and when things happened. I like all my information to be accurate.

[DB83]

An exact copy of a file is somewhat different to an edit of one.


I do not know either of the programs you mention but neither are appropriate for the purpose you require.


This 'exact accuracy' thing still puzzles me. Can you illustrate that with a real example such as an extract of what you see in the file directory. Or are you viewing by other means ?

[TimA-C]

First off, Boo Hoo! This is how the VAST MAJORITY of programs deal with files, ever since the good/bad ol' days of MS-DOS. Get over it.

Secondly, if you have a look at a file's properties (right-click etc.) you'll often see both the original creation date as well as the date the file was last altered.

Thirdly, I'm sure there's at least one util out there that can pick up a file's date and either add it to one of that file's metadata fields or attach it to the end of the file's name. Try MajorGeeks.

[butterw]

I wanted to use Avidemux to trim down a large number of my old videos (get rid of unwanted bits), but every time I save the video, it loses the original date and saves it with the current date!

If I trimmed my videos this way, I'd have to painstakingly go through every file afterwards with date-changing software, manually restoring the original date. I can't imagine anyone would WANT this behavior, so I presume it's some kind of error?

Surely, non-destructive editing and date retention go hand in hand?

This is normal OS behavior, unrelated to Avidemux.

The simplest way around this issue is to ensure your filenames include the desired date.

[DB83]

^^ Which he has been told more than once yet is not prepared to accept it.

[Gameshow Host]

This 'exact accuracy' thing still puzzles me. Can you illustrate that with a real example such as an extract of what you see in the file directory. Or are you viewing by other means ?

I don't understand. Can you quote the part that puzzles you?

First off, Boo Hoo! This is how the VAST MAJORITY of programs deal with files, ever since the good/bad ol' days of MS-DOS. Get over it.

Sure, in the vast majority of cases, that's desirable - you always want newly created files to bear the current date, so you know when the file was made or modified.

But - obviously - there are also some times when you don't want the date to change, because you want a record of the original date, and the time of edit is irrelevant.

You personally may not find yourself in that situation, but many people do, especially those who have a professional workflow and need certain media to be dated correctly.

Secondly, if you have a look at a file's properties (right-click etc.) you'll often see both the original creation date as well as the date the file was last altered.

That only happens when the original file has been MODIFIED. In the case of Avidemux, the file isn't being modified, but a brand new file is being created.

Thirdly, I'm sure there's at least one util out there that can pick up a file's date and either add it to one of that file's metadata fields or attach it to the end of the file's name.

There is, and I own it and use it. But I find it stupid having dates in the filename when there is already an allocated file date, which would contain inaccurate information if I were to do this.

^^ Which he has been told more than once yet is not prepared to accept it.

There is no need to be so hostile sir.

You folks need to accept that we're all different and have different requirements. Like many people, I am fussy about my file dates being correct. You folks aren't. That doesn't make me "wrong". Everyone organizes their files differently. There is no "right and wrong", only personal preference.

There is a reason why many non-destructive editing programs automatically retain the original date, and that is that there are many people out there like me.

The "solution" offered here is no solution to me. I would far rather not edit the videos at all than have the dates messed with.

[DB83]

I am not trying to be hostile. You were asked for a real example. Are you trying to convince us that transferring from camera to HDD (which writes the file) actually quotes the exact date and time you shot the video ?

[Gameshow Host]

You were asked for a real example. Are you trying to convince us that transferring from camera to HDD (which writes the file) actually quotes the exact date and time you shot the video ?

I have owned many digital cameras and camcorders and they all work this way in my experience. I thought that was normal. The date of the file is set the instant the recording ends, so the date is accurate to when you shot the video. I would genuinely be surprised to learn there are cameras which don't do this.

Copying the file over to the PC from the SD card does not change that date. Once plugged into a USB port, the SD card is effectively just another drive, and I'm sure you would agree that file dates don't change when you cut/paste from one drive to another.

[DB83]

Already explained. Pure copy is treated differently by the DOS.


Ok. I though you were doing a 'capture' from camera to PC which then creates a file with a different date.


Now consider the following.


1. Your edits are 'destructive' as far as the entire file is concerned even though you are not altering the integral elements.
2. Were you write that edit to overwrite the old file which you, theoretically, could as long as the original is not open in the editing software and retain the date (which even then you can not) you have completely destroyed the original. Far safer to edit/re-write with a new filename and retain the original for archive purposes - will still have the original date - should you wish to revisit it at a later date for more editing.

[Gameshow Host]

Ok. I though you were doing a 'capture' from camera to PC which then creates a file with a different date.

Never even heard of such a thing, but never mind.

1. Your edits are 'destructive' as far as the entire file is concerned

"Nondestructive editing" was probably a bad choice of words. It's a well-known phrase in the Adobe community, but perhaps not anywhere else. I simply meant "lossless" - no recompression.

Far safer to edit/re-write with a new filename and retain the original for archive purposes - will still have the original date - should you wish to revisit it at a later date for more editing.

Everyone has different needs and different purposes. Sometimes people may want to "save as" a new file and keep the original video. But other times, we want to completely overwrite the original, because we don't want the parts we cut out, for example, removing commercials from recordings.

My own case is the latter. I have a large number of videos to trim down of many different kinds, some are me talking to the camera, some are screen captures, some is nature photography. These videos contain many portions I don't want, portions where I'm setting up the camera and there's nothing to see, outtakes, long periods where nothing happened, etc. I have absolutely no use for anything I will be cutting out and don't want to keep it.

Avidemux seems like the perfect tool to trim them down. But it seems I'm going to have to manually correct all the dates.

I'm honestly surprised by the reaction here. I would have thought everyone would find it useful to be able to retain the original file date.

[DB83]

OK. But why are you so resistant to saving a file from $£$%^.{whatever} to '{date}_rant'.mp4 (or {whatever}) ?


Or to put it another way. I have 00's of files with filenames that do not begin to describe the content of them. To determine that I must view the file or, eventually, edit the file name.

[Cornucopia]

Maybe this can clear things up.

Nondestructive editing, as referred to by Adobe in the context that you are familiar with, is dealing with PHOTOS. Not video.

And only when doing a few specialty operations which do not change the integrity of the original main data - it is merely changing certain METADATA. Rotation/orientation, cropping. Those save back the metadata into the original file and yet do not usually change the file timestamp, though that is optional and not universal. The app must be specially designed to hold the timestamp in memory, so that it can guide the OS to re-input that same original timestamp, which it would 't otherwise do. Sort of like what a Touch function does.

N-D features can also sometimes do further changes (hue, contrast, etc), but then almost invariably they are using a sidecar xml type file to hold the metadata (and possibly its history of steps, so you can roll back). That sidecar file DOES change timestamps, though the original doesn't. This is common with something like Lightroom, working on RAW files.

Note this does not refer to VIDEO (or audio).

N-D in video/audio is almost ALWAYS in reference to the ND of the original assets in compositions that combine/assemble, and those orig assets are not changed at all, but a new resulting file is created from the combination/assembly. It WILL and SHOULD have a different timestamp, because it is a new creation. Even if the source is 1 clip and the change is simple top & tails trim. Adobe also refers to this as N-D, and don't highlight the fundamental difference between them, confounding the term.

Now, if the file format supports it, certain operations COULD be done in the same manner that are done with photos - rotation, cropping, single clip trim. But I have been around a long while and I cannot think of a single VIDEO editing app that does that, even adobe's.

In the further instance, the "sidecar" file applies to video also, but in the form of the timeline project file aka the edit decision list or EDL. And that also does change/update its timestamp, without changing the source assets.
But a Render will always be a new timestamp, even if it is a lossless process aka "smart rendering".

Note also that in most NLE/DAWs that provide N-D, they often also provide some operations which ARE destructive. These will also modify the timestamp of the orig in those operations.

Avidemux is doing what is expected under the circumstances.


Scott

[Gameshow Host]

Maybe this can clear things up.

Thank you for your contribution, but, as I have already said, I used the wrong term. I simply meant lossless editing.

OK. But why are you so resistant to saving a file from $£$%^.{whatever} to '{date}_rant'.mp4 (or {whatever}) ?

Or to put it another way. I have 00's of files with filenames that do not begin to describe the content of them. To determine that I must view the file or, eventually, edit the file name.

Sure, there are no "rules" saying a filename has to describe the file's content, and can't describe the date. You can put the date in the filename if you wish. Each to his own.

But I could give you various reasons why I personally don't want to do this:

1. Above all, this would result in half my videos (randomly) having a different naming/date convention - I cannot tolerate that. I strive for uniformity, consistency and elegance in my filing system.
2. I personally find it distasteful including the file's date in the filename, since the files already have dedicated metadata/fields for this. It's like having a cookie jar that says "cookies" on it, and putting the cookies in a different tin next to it, if you know what I mean.
3. Another reason is that I consider the date field to be far more 'solid', 'fixed' and 'locked' - never to be changed again. Whereas I regard file names as less 'protected' and much more open to change. So the idea of dumping permanent, uneditable data into a variable field just doesn't sit right with me.
4. Files lacking a proper date would mean I'd be unable to view folders by date, or glance at the date column to compare recordings by date.
5. Each name would be a combination of both date and description, and I don't like different types of data to be mixed.
6. This would result in some of my videos having a 'bogus' date in the date field - I may accidentally look at this date, and take it as accurate.
7. Adding date info to a file's title reduces the maximum allowable file name, and I often find myself battling against this as I give my files very descriptive names.
8. A minor point, but if I died and my video collection passed to my descendents, they might not be aware of my convention, that half the dates of the videos were wrong.

To you, this may all sound terribly fussy, but it's just the way I am. I guess not everyone cares so much about date fields, perhaps I'm in a minority. But nevertheless, I do care a great deal about this.

For me, dumping the file dates into the name is just never going to happen. I would much rather not edit the files at all, or manually fix all the dates, than lose the date information.

[DB83]

Sobeit then


But what is the maximum filename sixe these days ?. I guess, like me, you were around when it was 8+3. So you go to all the effort to create a descriptive filename but not wish to 'foul' that with, at most, 9 chars >> YYYYMMDD_ << which is even for a Brit a fair use of the American date pattern. And all files can then be sorted by that.


But it's your baby so best of luck.

[sophisticles]

I have read through this entire thread and I can't seem to understand what has the OP so up in arms, what date is it that he claims AviDemux is changing that has him so pissed?

Using one of the files from that other thread about neat video, on Win 10, if I right click on the file --> Properties, on the General tab you will see 3 dates, Created, Modified and Accessed. If you only look at File Explorer it shows just the date Modified, by default.

If you want to see all three in File Explorer, right click anywhere on the column header in File Explorer and select the options you want. Once this is done, go to the top where it says View, click on Options, Change Folder and Search Options, View, Apply To All Folders.

What the OP is complaining about is not an AviDemux issue, it's a Folder option in Windows.

At least that's what I think he means.

[DB83]

Well it is my understanding that the 'Created' date is the one after the edit. Not before. The 'Modified' date will be slightly after the 'Created' being the time it takes to write the file to disk.

[DB83]

So I ran a few tests with dates and avidemux.


1. The program refused to write the same file since it was 'open' in the program.
2. A quirky one here. A 'copy' of a file shows the original date of the file in the 'modified' property but the 'created' date is the current date


Using the suggestion of opening up the file explorer to show the 'created' date, here is a possible solution for the OP.


1. Create a copy of the file before loading the copy in to avidemux for editing
2. Write the edited file back to the original version. The edited version will still show the current date in the 'modified' property but in my test it showed the original date in the 'created' property.
3. Delete the copy.


Voila !! Original date is now shown.

[Cornucopia]

Did some more digging about Date/TimeStamps, and especially looking at the forensic analyses of filesystems, I can say that CreateDate, ModifiedDate, and AccessDate are more fluid than we all were thinking, and ultimately are not entirely reliable. Example: Windows will often (but not always) change create date of the result if you simply copy a file, particularly to a new volume. Robocopy can be made to preserve the date, but requires an explicit switch.

In fact, for media files, many digital forensic experts suggest relying on internal file format metadata (e.g. EXIF, xml tags) as being the best authority.

If the OP wants to go that route, I believe that custom fields may be made visible in Explorer. If stock explorer cannot do it, a shell extension can be found to provide that (possibly Icaros, or MediaInfo's MediaTab). Once they are visible columns in Explorer, they can always be sorted that way if that is your preference.

However, in light of what I have already mentioned and newly found out, continued reliance on createdate or modifieddate as your primary means of differentiating & organizing is going to be a constant uphill battle.

Also, in that light, the OP's expectations WRT the operation of most editors and their treatment of file timestamps doesn't seem realistic. The term "lossless editing" as a process has always primarily applied to not messing with originals and with transferring the bulk of the core data of those originals to a new result, specifically without re-encoding and incurring further generational losses. But the resultant file is almost always a NEW file, and as such has new timestamps.


Scott

[_Al_]

I'd have to painstakingly go through every file afterwards with date-changing software, manually restoring the original date.

You can do it en masse, using some code language, python as the easiest one. You create a database of pairs,
file_path : created date
, per directory. Then new files to a new directory-same names or same directory with a suffix/prefix. Then overwrite those dates again when done again as a whole dir, pasting created times back in.

[abolibibelot]

I feel that is a trivial point. Other non-destructive editing programs ensure (one way or another) that the dates are retained. It's not difficult to change a file's date.

As it's been mentioned already, some picture editing programs can have that option, and I know that at least Monkey's Audio (a lossless audio compressor) has that option, but I have yet to find a video editor with that ability, so making a fuss about this being an issue with Avidemux in particular is a bit puzzling.

I would like to hope they all do, but two that pop into my head are Xnview image editor - if you losslessly rotate images, the date is not changed. And JPEGCrops - which allows you to losslessly crop JPEGs, again, the original date is retained.

XnView can retain the date even following “destructive” editing.

In Windows, when you cut and paste a file from one drive to another, its date does not change. Even copying files doesn't change the 'modified' date, which is the date you see in Windows.

Access date does change (arguably it's less important than the other two visible timestamps{*}). If copy and pasting, the creation date changes as well.
One quirky thing I discovered long ago, but only found an explanation for recently : put two files with the same extension in the same folder (if you care about preserving the timestamps of existing files, create new files for that test) ; examine the creation date of file A and file B, take note of it ; in less than 15 seconds, copy the name of file A, then rename it (adding a single character will do), then rename file B with the name of file A (the one which you just renamed) — the creation date of file B becomes identical to the creation date of file A ! That's called “creation date tunneling effect”, and it's meant to preserve the creation date for files which are regularly updated in a secure manner, by first creating an updated copy then deleting the original. The default delay is 15sec. but it can be changed in the Registry, or this effect can be disabled altogether.

{*} In fact there are more than three, there's also the “record changed” timestamp which does not appear in the Explorer.

You personally may not find yourself in that situation, but many people do, especially those who have a professional workflow and need certain media to be dated correctly.

Not to be rude but bragging about having a professional workflow and complaining about a freeware lacking a feature which (as far as I know) is non existent among video editors is kind of strange...

That only happens when the original file has been MODIFIED. In the case of Avidemux, the file isn't being modified, but a brand new file is being created.

Is there any video editor that does otherwise ? It would be a very bad idea, to overwrite the original file, any SNAFU during the operation could permanently destroy it.

Everyone has different needs and different purposes. Sometimes people may want to "save as" a new file and keep the original video. But other times, we want to completely overwrite the original, because we don't want the parts we cut out, for example, removing commercials from recordings.

Again, that sounds like a very bad practice, you can never be 100% sure that the process was flawless, if the original file is deleted right away you can no longer correct a mistake, or start over if the program or the system crashed during the operation.

Avidemux seems like the perfect tool to trim them down. But it seems I'm going to have to manually correct all the dates.

See below.

A minor point, but if I died and my video collection passed to my descendents, they might not be aware of my convention, that half the dates of the videos were wrong.

Well, that is thinking ahead ! O_O Not to be pessimistic, but I would think that if the descendants care at all about the videos themselves (which is already doubtful, for everything gets obsolete very quickly these days and that trend sure isn't going to revert any time soon), they sure won't care at all about their carefully preserved timestamps.

To you, this may all sound terribly fussy, but it's just the way I am. I guess not everyone cares so much about date fields, perhaps I'm in a minority. But nevertheless, I do care a great deal about this.

I do care about that aspect as well, too much probably, but I'm kind of relieved to see someone even more extreme in that regard ! è_é

1. Create a copy of the file before loading the copy in to avidemux for editing
2. Write the edited file back to the original version. The edited version will still show the current date in the 'modified' property but in my test it showed the original date in the 'created' property.
3. Delete the copy.
Voila !! Original date is now shown.

That is convoluted and impractical, and for such purposes the modification date would be the most important to preserve.

Did some more digging about Date/TimeStamps, and especially looking at the forensic analyses of filesystems, I can say that CreateDate, ModifiedDate, and AccessDate are more fluid than we all were thinking, and ultimately are not entirely reliable. Example: Windows will often (but not always) change create date of the result if you simply copy a file, particularly to a new volume. Robocopy can be made to preserve the date, but requires an explicit switch.

Robocopy does preserve files' timestamps by default, it's directories' timestamps that require a specific switch to be preserved.
Windows always updates the creation date in case of a copy (except when this “tunneling effect” kicks in), regardless of whether the copy is made on the same volume or another ; not in the case of cut-and-paste, which affects only the access date.

However, in light of what I have already mentioned and newly found out, continued reliance on createdate or modifieddate as your primary means of differentiating & organizing is going to be a constant uphill battle.

Using only tools which preserve timestamps, it's not so difficult. Problem is, there are very few on Windows. I know only three which preserve all visible timestamps : Robocopy, Synchronize It, FastCopy. Everything else alters at least some of them (usually files' creation dates, and most file transfer tools alter all directories' timestamps). I did thorough tests about a decade ago, it may have changed since then but I doubt it, it really is a “niche” kind of feature (most people do not care about timestamps at all).

Also, in that light, the OP's expectations WRT the operation of most editors and their treatment of file timestamps doesn't seem realistic. The term "lossless editing" as a process has always primarily applied to not messing with originals and with transferring the bulk of the core data of those originals to a new result, specifically without re-encoding and incurring further generational losses. But the resultant file is almost always a NEW file, and as such has new timestamps.

Indeed, but I discovered a method relying on Robocopy which achieves the intented result, and which I already described here. I'll quote myself below :
– First create an empty copy of the directory where the original files are :

robocopy "E:\path\to\video files" "E:\path\to\video files [C]" /E /B /DCOPY:T /TIMFIX /FFT /DST /XJ /R:0 /W:1 /CREATE

The most important switch here is /CREATE, which will create an empty copy of each file, meaning a copy with a size of 0 byte, but otherwise preserving all timestamps and attributes (except the “compressed” attribute which Robocopy does not retain, but anyway a 0 byte file doesn't have to be compressed so it's moot here). I add “[C]” to the new directory name to remember that it has been created with Robocopy /CREATE and is therefore expected to contain 0 byte files.
– Then do whatever processing you need to do with those files.
– Then rename the output files exactly as the original files (after moving those in another directory if you want to keep them), or exactly as their empty counterparts in the “[C]” directory (you can also rename the empty files with a batch file renamer prior to performing the next step). If the output files have a different extension (for instance .mkv instead of .mp4) you have to temporarily change the extension to match the original one. (Windows should always be set to display all file extensions.)
– Then re-apply the timestamps from the empty copies to the processed files with a second Robocopy command, switching source and destination paths :

robocopy "E:\path\to\video files [C]" "E:\path\to\video files" /E /B /DCOPY:T /TIMFIX /FFT /DST /XJ /R:0 /W:1 /CREATE

The /CREATE switch is especially important here, as without it the files with a matching name in the second directory would get replaced by a 0 byte file. With /CREATE, it will only apply the timestamps / attributes, if different. The /TIMFIX switch is supposed to fix timestamps for files which are ignored / filtered, but is not required here (I'm not so sure when it is actually required, I just tested with or without it, with filters or no filters, didn't change anything). With the /E switch, subfolders are processed, which may not be desired in this case (if not, simply remove it). The /B stands for “backup mode”, as opposed to “restart mode”, I use it out of habit but couldn't say for sure when either of those two options is preferred. The /DCOPY:T switch allows to preserve or apply the timestamps to directories as well, not required here but can be very useful, as very few Windows applications allow to copy / transfer a directory tree and preserve all timestamps incuding those of directories (beside Robocopy I know only two that do : Synchronize It, FastCopy). Then /FFT, /DST, /XJ, /R:0 /W:1 should not be required here but I always keep them in the commands just in case (/FFT accounts for the 2sec. time granularity in FAT32, so it doesn't overwrite files which have a less than 2sec. time discrepancy ; /DST does the same for Daylight Saving Time discrepancies ; /XJ disables junctions, without it Robocopy can get trapped in an endless loop, typically when attempting to copy the Windows “AppData” directory ; /R:0 sets the number of retries to 0 and /W:1 the time between retries to 1sec. — the default value for the latter is a whopping 1 million... if there's any SNAFU preventing a file to be copied, retrying 1 million times is not likely to accomplish anything useful ! what were they thinking ?). Other switches are available and may come in handy in other situations (type « robocopy /? » or search a thorough guide if you need more information).
You could create two scripts with the corresponding commands and put them on the Desktop with explicit names, like “create empty copy.bat” and “recover timestamps.bat”.
And another personal tip, since the OCD-ness level of this thread is off the scale : I took the habit of keeping archives of empty file trees (sometimes a whole HDD's contents with 1-2 million files), for future reference of how files were organized at that point in time, or sometimes to recover the original timestamps of a file or folder that was accidentally modified... (WinRAR has explicit options to preserve creation / access timestamps in addition to modification timestamps which are stored by default ; in 7-Zip the same can be obtained with command line switches « tc=on ta=on », which can also be added in the GUI under “parameters”. Significant difference is that 7-Zip compresses headers by default, WinRAR does not by design — I asked the author, he replied that it would be unreliable —, so an archive containing a large number of empty files will be much smaller with 7-Zip. I also asked WinRAR's author if this could be included as a standalone feature in a future update of the software — it would directly create an archive of empty files with no need to first create them with Robocopy — so if it ever happens it'll be my idea...)

“Time is never time at all
You can never ever leave
Without leaving a piece of youth...”
Smashing Pumpkins

[DB83]

^^ My method might appear impractical but it is a sure way less convoluted than the above which also relies on a copy of the file beit empty and a rename which it seems from the OP will be not a short entry.


For the record, I would be nervous over-writing an original file were it not for the copy. The DOS prevents that in normal situations.

[Gameshow Host]

Phew! A lot of very in-depth response for what I thought was a simple issue! Thanks to all for your contributions and insight.

Windows will often (but not always) change create date of the result if you simply copy a file, particularly to a new volume. Robocopy can be made to preserve the date, but requires an explicit switch.

Absolutely, Windows always screws with the Created date, and as such I have absolutely no interest it. And certainly not the Accessed date.

The only field I have ever been interested in is the Modified date, which is what Windows users generally mean when we say 'date'. Windows doesn't screw with this field. (At least, I've never seen that happen in 25 years of using Windows, so that's good enough for me.)

Though still, I do regularly use Robocopy to relocate FOLDERS, since folders use "Created" date, which Windows resets to the current date when you copy a folder.

1. Create a copy of the file before loading the copy in to avidemux for editing
2. Write the edited file back to the original version. The edited version will still show the current date in the 'modified' property but in my test it showed the original date in the 'created' property.
3. Delete the copy.


Voila !! Original date is now shown.

AWESOME! Thank you DB83!

This works perfectly. All I do after this is use Bulk File Changer to copy the Created field into the Modified field! (Which I've tested and works great!)

Thread closed as far as I'm concerned!

Abolibibelot, thank you very much for your lengthy, in-depth insights and proposed solution, which is very thoughtful. However, I am definitely going with DB83. It's ideal for me.

Not to be rude but bragging about having a professional workflow and complaining about a freeware lacking a feature which (as far as I know) is non existent among video editors is kind of strange...

I wasn't necessarily talking about myself and certainly not 'bragging'. I just know that there are many professional environments that are very particular about such details, with strong emphasis on file organization. I don't work for one, but I do place huge importance on file organization. Some people just don't care about such things and have folders full of jumbled up, chaotic files, which is fine for them. But every document on my computer has to be in its proper place and follow the strict conventions I've established. Maybe I'm a little OCD, but I'm certainly not the only one!

It would be a very bad idea, to overwrite the original file… you can never be 100% sure that the process was flawless, if the original file is deleted right away you can no longer correct a mistake, or start over if the program or the system crashed during the operation.

Well most editing programs allow a file to be "saved" to itself, and users understand the risk of not being able to undo the changes after hitting 'save' and closing it. I guess some programs will immediately, directly overwrite the file, others will employ some intermediate copy, others deliberately make a backup of open files. And in other cases, one might save a copy and then delete the original file. The exact methodolgy isn't what I'm interested in here, only the final result.

[abolibibelot]

The only field I have ever been interested in is the Modified date, which is what Windows users generally mean when we say 'date'. Windows doesn't screw with this field. (At least, I've never seen that happen in 25 years of using Windows, so that's good enough for me.)

Well, there's the issue of Daylight Saving Time which screws up all timestamps, that can be irritating, especially when it comes to personal pictures having their system dates off by one hour (not sure exactly how it's supposed to work, but when pictures / videos are imported from a memory card to a NTFS partition at a later date with different DST settings, timestamps are off ; I wonder how other filesystems / operating systems deal with this).
Also I discovered a bug in the otherwise excellent file renaming tool Bulk Rename Utility (at least until version 3.4.1.0 — I reported it to the developpers no less than three times, starting from 2018, last time in December 2020 I was so pissed off that it was still an ongoing issue — I made it sound like the last verse of the song “Stan” by Eminem, which I quoted —, that I think they finally took notice) : whenever files are renamed, and the renaming operation is cancelled, all timestamps for the files which were processed get shifted back by 1 or 2 hours — depending on current DST settings —, even if timestamps options were totally disabled ! (And again if another renaming operation is cancelled : then timestamps are off by 2 or 4 hours, and so on.) I discovered that SNAFU when doing a thorough comparison between my main HDD and its backup : many files had a 2 hours time discrepancy on the “active” drive, took me a while to find the culprit.
Also when timestamps are changed or restored manually with a third party utility, timestamps are rounded to the inferior second, e.g. 15:59:33.846 becomes 15:59:33:000 (at least that's the case with Attribute Changer, as I asked about it the developper replied that his utility was not changing timestamps by editing the MFT directly — which would be hazardous — but rather through a Microsoft API which apparently is not as precise, so I guess that all timestamps editing tools work the same). That's a problem for instance when comparing files, or when looking for exact duplicates which should also have the same modified / creation date (my favorite tools for that purpose : DoubleKiller, AllDup, each has its strengths and weaknesses), or when using Robocopy which will unnecessarily overwrite a file with even a very small time discrepancy (unless using the /FFT switch).

EDIT : I can happily report that the bug mentioned above in Bulk Rename Utility has been finally fixed in version 3.4.2 from February 2021.

Though still, I do regularly use Robocopy to relocate FOLDERS, since folders use "Created" date, which Windows resets to the current date when you copy a folder.

Folders “use” the same three (visible) timestamps as files, but possibly you refer to the absurd “Date” column which is now displayed by default (this can be changed), or indeed the creation date is the only one which appear in a folder's properties (also absurd, don't know if that can be changed).
It should be noted that Robocopy does not preserve NTFS compression, and it has a bug whenever there is a “collision” between the long name of one file and the short name (8.3) of another.
Synchronize It does preserve NTFS compression, as well as files' and directories' timestamps, but the current official version (3.5 which is from 2009) has a bug which corrupts “sparse” files. I discovered it back in 2010, reported my observations (it would specifically corrupt files which were downloaded with two download managers I was using then, totally wiping the contents beyond exactly 25000 bytes) but the developper waved it off as most likely a problem on my system ; I reported it again in 2015, with a bit more details, and this time the developper acknowledged the issue, found what was wrong, and quickly provided me with a fixed version (3.6b), but for some reason didn't make it public. (I had a brief chat with him a few months ago : he explained that he had had little time to work on it over the past few years, and wanted to implement many other improvements before a new release. He still agreed that it would be good to at least release that specific fix, but still didn't do it. He allowed me to share the non public link to the upgraded version though, so here it is ; if you want to try it, install it with the installer downloaded from the web page above, then replace the executable by the one in that ZIP archive ; or use it directly, it works in so-called “portable” mode, it will create a .ini settings file, only the .chm help file and language files will be missing.)

I wasn't necessarily talking about myself and certainly not 'bragging'.

Sorry, poor choice of words, I was tired and I don't always have the best words at my fingertips...

Well most editing programs allow a file to be "saved" to itself, and users understand the risk of not being able to undo the changes after hitting 'save' and closing it. I guess some programs will immediately, directly overwrite the file, others will employ some intermediate copy, others deliberately make a backup of open files. And in other cases, one might save a copy and then delete the original file. The exact methodolgy isn't what I'm interested in here, only the final result.

So did you try the method I proposed with Robocopy /CREATE ?

[Gameshow Host]

So did you try the method I proposed with Robocopy /CREATE ?

Forgive me, no, I didn't. I liked the simplicity of DB83's solution and it worked so I didn't try yours. The description seemed rather long and complicated. Sorry!