I'm working with an engineer on a way to sync audio and video files using timecode after the files have gone through a video edit in an NLE. In order for it to work properly, we need to be able to extract date information from the metadata of multiple file types (video and audio) from multiple sources. The audio and video that were recorded on a specific day need to be associated with each other before we start lining them up by timecode, obviously.
The engineer is convinced that metadata creation dates are inconsistent (even if we presume the date on the camera/field recorder is set properly) and often get modified somewhere in the ingesting/editing/etc processes that precede our project. He seemed mostly concerned about creation date being changed to when the file was transferred to the computer, but there were some vague other issues that caused him to think creation date was unreliable. He's quite experienced in the field and knows what he's doing, so I trust him... but it's hard for me to believe. It would make metadata functionally useless.
So: Is he right? Does metadata (specifically the date that the file was created) dependably get altered by NLEs and general file handling and/or is inaccurate from the start?
I'm going through my archives with exiftool, and the metadata seems to be accurate, but this is just a cursory inspection, and I don't have as many camera types as we'd want to be able to accommodate. And perhaps I'm missing something.
If he is right, is there a reliable way of detecting if/when metadata has been changed so that we can flag it?
The first thing is to clarify which "creation date" you're looking at. In videos, there can be the Quicktime:CreationDate, the Quicktime:CreateDate, and the file system FileCreateDate. The first is rarely used, mostly in Apple programs, I think. The second is a required part of the Quicktime specs, but there are a lot of programs that don't set it at all. The last, which is what I think you are talking about, is the filesystem time stamp for when the file was created. In theory, this should be the date/time when the file was created, but it is very fragile.
When using the operating system to copy or move the file to another drive, then that time stamp will usually be copied with it. But if, for example, you decided you wanted to crop part of that file, then you would be creating a new file with a new time stamp, which would be very different from when the original file was created. And that doesn't even take into account something like passing the file to another computer over a network (not if the storage is mounted as a drive, though) or through cloud storage. In those cases, the FileCreateDate is completely lost.
It won't always be 100% accurate or inaccurate. It would depend upon the workflow and how it was passed from camera to computer to computer.
Interesting. Thanks for your reply - I've learned a lot from your posts and appreciate you being generous with your time.
Regarding this:
Quote from: StarGeek on May 20, 2022, 01:54:44 PM
When using the operating system to copy or move the file to another drive, then that time stamp will usually be copied with it.
Are there any coherent rules for this? Or is "usually" a matter of unpredictable circumstances like user OS and software? Is there a workflow that can dependably prevent this or are there too many outside factors?
Quote from: StarGeek on May 20, 2022, 01:54:44 PMAnd that doesn't even take into account something like passing the file to another computer over a network (not if the storage is mounted as a drive, though) or through cloud storage. In those cases, the FileCreateDate is completely lost.
That's discouraging. Moving files around is inevitable, so it sounds like
FileCreateDate isn't going to be dependable in this situation.
Quote from: Colin on May 21, 2022, 01:29:44 PM
Interesting. Thanks for your reply - I've learned a lot from your posts and appreciate you being generous with your time.
Regarding this:
Quote from: StarGeek on May 20, 2022, 01:54:44 PM
When using the operating system to copy or move the file to another drive, then that time stamp will usually be copied with it.
Are there any coherent rules for this? Or is "usually" a matter of unpredictable circumstances like user OS and software? Is there a workflow that can dependably prevent this or are there too many outside factors?
This is going beyond my area of expertise, so this will be how I
think things work, but could be 100% wrong.
Dragging/dropping/copy/pasting from a desktop, the file system time stamps should be the same. At least it does on my computer. But copying files on the command line, maybe not. On Windows,
copy preserves the
FileModifyDate, but the
FileCreateDate is the time of the copy. See this Superuser question (https://superuser.com/questions/146125/how-to-preserve-file-attributes-when-one-copies-files-in-windows) for some more details.
If it is some other program used to copy the file, who knows. On Windows, I use TeraCopy and that preserves the time stamps.
For images (.jpg, .heic, .raw, .tif) I treat ExifIFD:DateTimeOriginal as the golden standard and resort to other dates only if it is missing (after a detour to social media, scanned images etc) or seems incorrect.
For movies (.mp4, .m4v, .mov) I use QuickTime:CreateDate but it can only go to 1970. Keys:CreationDate usually has the same date at least on iOS devices and it supports older dates (but some apps like GooglePhotos do not support dates older than 1902 even in images). After re-encoding movies I copy the date from the filename to metadata.
I usually routinely copy those dates to filenames and other dates (-AllDates shortcut to 'DateTimeOriginal', 'CreateDate' and 'ModifyDate' in images) and also to those very fragile FileCreateDate & FileModifyDate so spotting errors is easier.
- Matti