FileModifyDate to sidecar XMP

[thatswedishguy]

Hi,

I have about 700 video files (AVI, MPG, 3GP) that have the correct capture date in the "[System] FileModifyDate" tag. When I import this videos into Apple Photos, they get added with CreateDate and all end up on the same date a couple of years after they were captured.

What I tried to do was to copy FileModifyDate to CreateDate, but these are mostly old AVI and MPG files with some 3GP thrown in for good measure. The AVI and MPG can't be written by exiftool, so no luck there. I tried to append FileModifyDate to the filenames, but the AVI and MPG files were ignored.

I thought maybe I can transfer FileModifyDate into photoshop:DateCreated which seems to be what Apple Photos uses when exporting files. (<photoshop:DateCreated>2011-02-22T10:56:28+01:00</photoshop:DateCreated>)

I just can't figure out how to do it. exiftool -tagsfromfile SRC.EXT DST.xmp doesn't bring the FileModifyDate tag over. I wouldn't mind converting all the videos to mp4 H.264 but I don't know how to carry over the date. Why has no one made a widespread video metadata standard yet?

Any help appreciated so I can get my precious family videos in the correct date in Apple Photos (and other software too).

[StarGeek]

I tried to append FileModifyDate to the filenames, but the AVI and MPG files were ignored.

See FAQ #16

I just can't figure out how to do it. exiftool -tagsfromfile SRC.EXT DST.xmp doesn't bring the FileModifyDate tag over. I wouldn't mind converting all the videos to mp4 H.264 but I don't know how to carry over the date.

You'll have to include it specifically and where you want it to go. 

Based upon Example 13 on the Metadata Sidecar Files page, try this
exiftool -ext avi -ext MPG -ext 3gp -tagsfromfile @ "-DateCreated<FileModifyDate" -srcfile %d%f.xmp /path/to/files/

This command will create backup files if the XMP sidecars already exisit.  Add -Overwrite_Original to suppress the creation of backup files.  Add -r to recurse into subdirectories.

[thatswedishguy]

Thank you!

That worked perfectly to create the xmp files. Unfortunately Apple Photos gives me an unknown error when trying to import. I'll have to keep thinking about how to get the dates to be correct in Photos.

[wywh]

I converted all old movies to H.264 or H.265 .mp4 with ffmpeg and used exiftool to put dates to them and locations to some of them. ffmpeg preserves chapters in .m4v but I found it better to set the dates and other metadata in exiftool. Then imported to Photos.app.

The viewer support for title, description, author or keywords is still so spotty and flaky that I have edited them only in selected .mp4 and .m4v.

BTW I noticed that exiftool 12.13 or later no longer seems to write 'UserData:DateTimeOriginal' without timezone? If true, I might tune my routine movie date command somewhat shorter. (If 'Keys:CreationDate' or 'UserData:DateTimeOriginal' lack the timezone suffix like +02:00, Photos.app 6.0 scrambles the year to something like '5828963' or otherwise displays wrong date for mp4, m4v and mov).

https://discussions.apple.com/docs/DOC-250002750

[StarGeek]

BTW I noticed that exiftool 12.13 or later no longer seems to write 'UserData:DateTimeOriginal' without timezone?

Yes. You can see the updated changes here.

https://discussions.apple.com/docs/DOC-250002750

Nice write up.  Not something I could have researched since I don't have a Mac.

[Phil Harvey]

BTW I noticed that exiftool 12.13 or later no longer seems to write 'UserData:DateTimeOriginal' without timezone?

Correct.  It will add the local time zone if you don't specify one.  We had some incompatibilities with other software if it didn't include a time zone.  The -n option may be used to bypass this and force writing without a time zone.  This is in the revision history as StarGeek mentioned.

- Phil

[thatswedishguy]

I converted all old movies to H.264 or H.265 .mp4 with ffmpeg and used exiftool to put dates to them and locations to some of them. ffmpeg preserves chapters in .m4v but I found it better to set the dates and other metadata in exiftool. Then imported to Photos.app.

The viewer support for title, description, author or keywords is still so spotty and flaky that I have edited them only in selected .mp4 and .m4v.

BTW I noticed that exiftool 12.13 or later no longer seems to write 'UserData:DateTimeOriginal' without timezone? If true, I might tune my routine movie date command somewhat shorter. (If 'Keys:CreationDate' or 'UserData:DateTimeOriginal' lack the timezone suffix like +02:00, Photos.app 6.0 scrambles the year to something like '5828963' or otherwise displays wrong date for mp4, m4v and mov).

https://discussions.apple.com/docs/DOC-250002750

I ended up converting all videos to MP4 H.264 and then I used exiftool to transfer all the date info over to the new files. Problem solved

[wywh]

BTW I noticed that exiftool 12.13 or later no longer seems to write 'UserData:DateTimeOriginal' without timezone?

Correct.  It will add the local time zone if you don't specify one.  We had some incompatibilities with other software if it didn't include a time zone.

Great! I could now shorten my routine filename-to-movie-tags command from:

exiftool -api QuickTimeUTC=1 '-CreateDate<filename' '-ModifyDate<filename' '-Track*Date<filename' '-Media*Date<filename' -execute '-FileCreateDate<filename' '-FileModifyDate<filename' -execute '-Keys:CreationDate<FileModifyDate' '-UserData:DateTimeOriginal<FileModifyDate' -common_args -m -P -overwrite_original_in_place -wm w .

to:

exiftool -api QuickTimeUTC=1 '-AllDates<filename' '-Track*Date<filename' '-Media*Date<filename' -execute '-FileCreateDate<filename' '-FileModifyDate<filename' -execute '-Keys:CreationDate<FileModifyDate' -common_args -m -P -overwrite_original_in_place -wm w .

(My command tries to set all movie date tags the same so it is easier to troubleshoot if some app picks a wrong date. I also set the QuickTime 'Track*' tags the same although they are not used for sorting.)

> The most recent production release is Version 12.00. (Other versions are considered development releases)

I have used v12.00 till now but maybe it is safe to update to later development releases?

I wish 'AllDates' shortcut would cover also 'Keys:CreationDate' so I could omit also it from that command. Is that possible? Currently (DST off) it does automatically add timezone with even the correct DST on, though:

exiftool '-Keys:CreationDate=2020:06:01 12:00:00' .
[Keys]          CreationDate                    : 2020:06:01 12:00:00+03:00

- Matti

[StarGeek]

I have used v12.00 till now but maybe it is safe to update to later development releases?

I've always updated exiftool and only had a problem one time and that was because Phil had changed something that interfered with the way IMatch read data. But then, that was on me because I updated the version IMatch was using rather than leaving it alone.

[Phil Harvey]

Phil had changed something that interfered with the way IMatch read data.

I feel the need to comment on this.  I try very hard to always maintain backward compatibility, but...

That iMatch problem was very particular.  IMatch was storing tag ID's in a permanent database, but the ID's of Composite tags were an implementation detail that was not meant to be used like this.  In fact, with earlier versions of ExifTool these could change between ExifTool invocations, which meant that the iMatch behaviour was inconsistent before ExifTool was patched to keep these constant.  Unfortunately the patch meant that all of the Composite tag ID's were changed, which lead to a version incompatibility, but this patch fixed a problem that iMatch didn't realize it had all along.

- Phil

[wywh]

I could now shorten my routine filename-to-movie-tags command

p.s. with exiftool -ver 12.13 or later I could shorten that old filename-to-movie-dates command as follows. I still had to separate '-FileCreateDate<filename' with '-execute' because  it can only move backwards in time if it is combined with other commands.

exiftool -api QuickTimeUTC=1 '-AllDates<filename' '-Track*Date<filename' '-Media*Date<filename' '-Keys:CreationDate<filename' -execute '-FileCreateDate<filename' '-FileModifyDate<filename' -common_args -m -P -overwrite_original_in_place -wm w .

[Phil Harvey]

I still had to separate '-FileCreateDate<filename' with '-execute' because  it can only move backwards in time if it is combined with other commands.

I don't understand.  Are you saying that writing FileCreateDate and FileModifyDate doesn't work when other "real" tags are written?  If so, this must be an O/S quirk.  What system are you running?

- Phil

Ah.  It seems you are using iOS9.  So I guess this OS is a bit quirky.  At the very least, you can add a -fast4 to the second command because ExifTool doesn't need to read the file at all to get the FileName.

[wywh]

I still had to separate '-FileCreateDate<filename' with '-execute' because  it can only move backwards in time if it is combined with other commands.

Are you saying that writing FileCreateDate and FileModifyDate doesn't work when other "real" tags are written?  If so, this must be an O/S quirk.  What system are you running?
you can add a -fast4 to the second command because ExifTool doesn't need to read the file at all to get the FileName.

I am running macOS 10.14.6 Mojave and it is the same in macOS 11.1 Big Sur. If I don't use that -execute in between, then the FileCreateDate moves only backwards together with FileModifyDate.  If the filename is adjusted forwards in time (1990-0101-1200-00.jpg -> 2000-0101-1200-00.jpg), the FileCreateDate stays in the past (at 1990 -- FileModifyDate does move to 2000) unless I insert that -execute, i.e. the following does not work in that respect:

exiftool -m -P -overwrite_original_in_place -wm w -api QuickTimeUTC=1 '-AllDates<filename' '-Track*Date<filename' '-Media*Date<filename' '-Keys:CreationDate<filename' '-FileCreateDate<filename' '-FileModifyDate<filename' .

And even with -execute, without the Xcode Command Line Tools install the FileCreateDate moves only backwards (FileModifyDate works OK even then).

Thanks for the tip about -fast4 option (I ran such a test with very small number of movies and without or with that option both took about 13 seconds).

- Matti

[Phil Harvey]

OK.  I understand.  I'll have a look at this. I should be able to add a patch to work around this.

- Phil