Losing date metadata with .avi and .mpg files

[cg]

I've noticed that for .avi and .mp4 files, any change to any of the metadata sets the "Date Subject Created" to the time of write-back and I lose the original date. All dates for the file in the 3 Image layout ("Create Date", "Metadata Date", "Modified Date") are reset.  This happens if if I just write back a single unrelated tag like "Country".

It appears as though an XMP sidecar file is being created and the new date comes from the creation date of that file, while the original .avi or .mp4 file's date is untouched.

This doesn't seem to be the case for .mov files. I understand that metadata for video files is a mess but the files are ingested with the correct date and I'm trying to figure out what combination of settings is needed in Metadata 2 to keep that date from being lost on write-back.

(I would prefer to not have to use XMP sidecar files, but if they're necessary for this purpose, it's not a problem.)

Also, I can't find an option to enable/disable SMP sidecar files in the Metadata 2 tab, even though it's listed in the help doc.

Allow to create XMP files

Thanks!

[Mario]

Video metadata is an even bigger mess than image metadata.
IMatch uses XMP sidecar files for most video formats for safety reasons. Some video formats support embedded XMP data (or at least camera vendors started using it).
IMatch 2021, as a breaking change, changes the default storage location for XMP to embedded for .MP4, .QT and .MOV Files.
I have even added a command to transfer XMP data from the sidecar file to the video file.
You can learn about this once the release notes and IMatch 2021 become publicly available.

IMatch produces a global File.DateTime value from date & time data available in the file.
In case of images this is usually EXIF metadata, but in case of video files, it can be a wide range of potential date and time fields.
See the documentation in How IMatch uses Date and Time Information for all details.
You can use the Metadata Analyst to check your files for problems and to see the data they actually contain.

Maybe your files don't contain any usable date and time information and so IMatch falls back to the "last modified on disk" timestamp?
This would explain why the timestamp changes after you write back.

If you set the date created and date subject created in the Metadata Panel once (or just click the pen in front of these fields to mark them as modified), IMatch will retain the data forever and also write it back to XMP.
This is the proper way to deal with files which have no timestamps yet.
Without knowing more about the data in your video files, I cannot say more.

[hluxem]

I run into the same issue with some movie files from a drone yesterday. Clicking the pen will work fine.

If you loose the time by accident you maybe able to recover with a meta data template to set the time. I find that most recent movie files decode the date and time in the file name.
I set XMP::photoshop\DateCreated and XMP::xmp\CreateDate with a template based on the file name. Something like below, but it depends on the naming scheme. It's important that the time is formatted correctly, otherwise it will revert back to the current time at write back. You can check that in the meta data panel before write back.

Below works for file names like 210724102304, the last 5 digits define the time zone.

20{File.Name|substr:0,2}:{File.Name|substr:2,2}:{File.Name|substr:4,2} { File.Name|substr:6,2}:{File.Name|substr:8,2}:{File.Name|substr:10,2}-04:00

Heiner

[Mario]

Do you drone files don't contain any of the many video time stamps IMatch supports? That would be unusual.
IMatch checks over 10 common video metadata timestamps, many from QuickTime...

What format? Maker? Sample video for download?

[cg]

Maybe your files don't contain any usable date and time information and so IMatch falls back to the "last modified on disk" timestamp?
This would explain why the timestamp changes after you write back.

If you set the date created and date subject created in the Metadata Panel once (or just click the pen in front of these fields to mark them as modified), IMatch will retain the data forever and also write it back to XMP.
This is the proper way to deal with files which have no timestamps yet.

I was able to recover the date using VarToy to see if the original date existed anywhere. Of these:

{File.DateTime}
{File.MD.originaldate}
{File.MD.createdate}
{File.MD.datecreated}
{File.Created}
{File.Modified}

the (original and desired) date was still in File.Modified (perhaps because that was the original file's unchanged modification date as shown in Windows). The rest of the variables had been reset at various points in the last few days as I worked with location metadata tags.

As I was starting to get into ways to format and copy the value in {File.Modified} to {File.Created}, I noticed that TimeWiz does just that with a very nice interface. So I was able to recover the correct date for those altered files and the Timeline is now back in order.

As you mentioned, Mario, when I clicked the pen on the unaltered files and wrote them back, the time did not reset when I changed location metadata fields. The same goes for those files I used TimeWiz on.

So I'll need to remember when importing another batch of media that includes video files to click the pen on the Date Subject Created tag and write them back before doing ANY further changes to any of the metadata or else risk losing the time.

Thank you for your help!

[Mario]

That's what I've expected, and what is explained in How IMatch uses Date and Time Information

Since IMatch was unable to find any usable timestamp in your files, it resorted to the last modified timestamp.

The setting to mark the date created / date subject created as pending when IMatch has filled them during import is by default off, so the tags are not written back automatically.
This setting was initially set to default on to avoid exactly this situation. But users complained, and I gave in.

IMatch 2021 introduces two changes related to this particular problem:

1. IMatch now falls back to the older of "file created" / "last modified" when there is no other usable timestamp.
When files are copied in Windows, the created date may be newer (!) than the last modified date.

2. The "mark file pending write-back" in Edit > Preferences > Metadata 2 is again on by default.
This means that when IMatch has filled the date created / date subject created during import, these tags are marked as modified.
But IMatch 2021 marks them only when it actually had to fall back to using file system timestamps, not when it derived these timestamps from other metadata.
This should work better for all scenarios typically encountered by users.