How to set quicktime:time:all to the value of FileModifyDate from the same file?

Started by snelso91, February 01, 2022, 01:28:59 PM

Previous topic - Next topic

snelso91

Hello,

I have been trying to set quicktime:time:all to be equal to the value of the FileModifyDate system tag using the command:

exiftool -P -wm w "-quicktime:time:all#<FileModifyDate" "Shangri-La Part 1 - Copy.mp4"

but every time I try to do so I get an error saying:

Warning: No writable tags set from Shangri-La Part 1 - Copy.mp4
    0 image files updated
    1 image files unchanged


I can read both quicktime:time:all and FileModifyDate using separate commands, and I can even successfully set one of the quicktime date-type tags (CreateDate) to the value of FileModifyDate separately using:
exiftool -P -wm w "-quicktime:createdate<FileModifyDate" "Shangri-La Part 1 - Copy.mp4"

but no matter what I enter I still can't set all the quicktime time tags in one go?

For reference, here are all the time-type tags in the file:
exiftool -groupnames -a "-time:all" "Shangri-La Part 1 - Copy.mp4"
[File]          File Modification Date/Time     : 2015:01:26 01:43:25+00:00
[File]          File Access Date/Time           : 2022:02:01 18:27:06+00:00
[File]          File Creation Date/Time         : 2022:02:01 17:00:13+00:00
[QuickTime]     Create Date                     : 2019:10:26 16:41:24
[QuickTime]     Modify Date                     : 2019:10:26 16:41:24
[QuickTime]     Track Create Date               : 2019:10:26 16:41:24
[QuickTime]     Track Modify Date               : 2019:10:26 16:41:24
[QuickTime]     Media Create Date               : 2019:10:26 16:41:24
[QuickTime]     Media Modify Date               : 2019:10:26 16:41:24
[QuickTime]     Track Create Date               : 2019:10:26 16:41:24
[QuickTime]     Track Modify Date               : 2019:10:26 16:41:24
[QuickTime]     Media Create Date               : 2019:10:26 16:41:24
[QuickTime]     Media Modify Date               : 2019:10:26 16:41:24


Thanks in advance

Phil Harvey

...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

StarGeek

So changing it to
exiftool -P -wm w "-quicktime:time:all#<$FileModifyDate" "Shangri-La Part 1 - Copy.mp4"
will work.

Though one thing to watch for is that most of those Quicktime time stamps are supposed to be set to UTC.  This command will not adjust the time stamps.  You can add the -api QuickTimeUTC option and the tags will be properly adjusted to UTC.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

snelso91

Thanks both for your help, I can confirm that the modified command works properly, although having read the documentation page you linked I still can't say I quite understand what the syntax $ means and why it is required in this specific case, but it works so I guess I'll just have to remember to use it for this edge case.

Regarding setting UTC quicktime metadata, is it recommended to do this every time I modify quicktime tags?
My initial assumption was that I should leave the original tags in exactly the format they were written for compatibility and consistency with any similar files that didn't need to be modified by exiftool?
For example, in my raw/unmodified recorded files, shadowplay usually writes the quicktime tags shown in my example without UTC formatting, and also doesn't even list days/hours for the "ContentCreateDate" quicktime tag and instead just writes "2022" or similar.

StarGeek

Not all Quicktime tags are supposed to be in UTC.  Only the ones that are of type integer.  They will be listed as int32u on the Quicktime tags page.  For the most part, these are
CreateDate
ModifyDate
TrackCreateDate
TrackModifyDate
MediaCreateDate
MediaModifyDate

Anything else should be a simple string and set to local time.  By default, exiftool will add a time zone to these tags because some Apple apps will show wildly inaccurate times without them.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

Quote from: snelso91 on February 02, 2022, 10:59:40 AM
I still can't say I quite understand what the syntax $ means and why it is required in this specific case

There are 2 syntaxes when copying a tag:

1. "-DSTTAG<SRCTAG"  - copies SRCTAG directly

2. "-DSTTAG<STR" - where STR is a string containing tag names preceded by "$" symbols.

Case number 2 make look like this:

"-DSTTAG<$TAG1 some test $TAG2 more text..."

or in the trivial case:

"-DSTTAG<$TAG"

but it is still an interpolated string.

Since you can interpolate many tags in the same string, the tag ID is effectively lost.

A destination tag name of "All" is special:

            A destination group and/or tag name of "All" or "*" writes to the
            same family 1 group and/or tag name as the source.


Since the source tag name is known for case 1, only the same-named tag is written.  But in case 2, all tags are written, because the source tag is not known, and the effect is the same as if you were writing a string.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

snelso91

Ah I see now, so it was to do with a quirk of the all tag.
It seems rather strange to me that when not using the $ string syntax (i.e. case 1. in your example) that the "x:y:all" tag refers to the group of the source tag (in this case the system group), rather than the tag that the "all" is attached to - in this case the "quicktime:time" group, which was the intended group since I did explicitly say "quicktime:time:all" not "system:time:all", etc., but I suppose what is intuitive is not always the same as what is syntactically correct.

snelso91

Quote from: StarGeek on February 02, 2022, 11:15:58 AM
Not all Quicktime tags are supposed to be in UTC.  Only the ones that are of type integer.  They will be listed as int32u on the Quicktime tags page.  For the most part, these are
CreateDate
ModifyDate
TrackCreateDate
TrackModifyDate
MediaCreateDate
MediaModifyDate

Anything else should be a simple string and set to local time.  By default, exiftool will add a time zone to these tags because some Apple apps will show wildly inaccurate times without them.

Regarding setting the quicktime metadata to the correct UTC format, I do have a separate issue that I noticed with some of my files, which is that the quicktime:time tags will be set to UTC+0 throughout the year by shadowplay. This doesn't always cause issues since here in the UK local time is UTC+0 during winter, but during summer when daylight savings apply the local time is UTC+1. Therefore, in these files recorded during the summer, the windows "FileCreateDate" and "FileModifyDate" datetimes will show the correct local time, but the quicktime metadata will show it exactly one hour behind which is UTC rather than local time, as shown in this example:

exiftool -groupnames -a "-time:all" "Try not to trample the scene.mp4"
[File]          File Modification Date/Time     : 2018:05:20 21:01:49+01:00
[File]          File Access Date/Time           : 2022:02:04 16:46:55+00:00
[File]          File Creation Date/Time         : 2018:05:20 21:01:49+01:00
[QuickTime]     Create Date                     : 2018:05:20 20:01:46
[QuickTime]     Modify Date                     : 2018:05:20 20:01:46
[QuickTime]     Track Create Date               : 2018:05:20 20:01:46
[QuickTime]     Track Modify Date               : 2018:05:20 20:01:46
[QuickTime]     Media Create Date               : 2018:05:20 20:01:46
[QuickTime]     Media Modify Date               : 2018:05:20 20:01:46
[QuickTime]     Track Create Date               : 2018:05:20 20:01:46
[QuickTime]     Track Modify Date               : 2018:05:20 20:01:46
[QuickTime]     Media Create Date               : 2018:05:20 20:01:46
[QuickTime]     Media Modify Date               : 2018:05:20 20:01:46
[QuickTime]     Content Create Date             : 2018


Firstly I wanted to check so I'm not being silly, that having the file time values stored in the local time zone (with a time zone extension on the end) instead of the UTC+0 time zone is the correct way of formatting these, since I believe the purpose of the +01:00 extension in the UTC time format is so you can convert from the original local time back to UTC (and optionally to another local time zone), but whilst still showing the original local time by default in the actual time value before the +01:00?

If this is true, then I wanted to ask how can I get exiftool to go through all my video files and convert the quicktime times to UTC format by setting the quicktime times forward by the same amount that the windows "FileCreateDate" time zone is, whilst also adding the appropriate time zone extension?

To elaborate further, in the example above what I would want is all the quicktime times (apart from "Content Create Date" since that is just showing the overall year) to go from 2018:05:20 20:01:46 to 2018:05:20 21:01:46+01:00 so that it matches the normal UTC formatting and time zone of the windows "FileCreateDate" field.
Similarly, for a file that is created in winter such as the one that I posted in my first post:
exiftool -groupnames -a "-time:all" "Shangri-La Part 1 - Copy.mp4"
[File]          File Modification Date/Time     : 2015:01:26 01:43:25+00:00
[File]          File Access Date/Time           : 2022:02:01 18:27:06+00:00
[File]          File Creation Date/Time         : 2022:02:01 17:00:13+00:00
[QuickTime]     Create Date                     : 2019:10:26 16:41:24

, then the exact same code would run but it would produce a slightly different result which is that the "FileCreateDate" would go from 2019:10:26 16:41:24 to 2019:10:26 16:41:24+00:00, since in this case the time zone is UTC+0 so the original quicktime time would be shifted by 0 hours, and then have the +00:00 extension added to make it into a normal UTC format.

StarGeek

I'm not quite getting what you're asking, but I think what you want is the -api QuickTimeUTC option.

When reading
C:\Programs\My_Stuff>exiftool -time:all -G1 -a -s Y:\!temp\aa\Test.mp4
[System]        FileModifyDate                  : 2022:02:04 12:00:00-08:00
[System]        FileAccessDate                  : 2022:02:04 12:00:00-08:00
[System]        FileCreateDate                  : 2022:02:04 12:00:00-08:00
[QuickTime]     CreateDate                      : 2022:02:04 20:00:00
[QuickTime]     ModifyDate                      : 2022:02:04 20:00:00
[Track1]        TrackCreateDate                 : 2022:02:04 20:00:00
[Track1]        TrackModifyDate                 : 2022:02:04 20:00:00
[Track1]        MediaCreateDate                 : 2022:02:04 20:00:00
[Track1]        MediaModifyDate                 : 2022:02:04 20:00:00
[Track2]        TrackCreateDate                 : 2022:02:04 20:00:00
[Track2]        TrackModifyDate                 : 2022:02:04 20:00:00
[Track2]        MediaCreateDate                 : 2022:02:04 20:00:00
[Track2]        MediaModifyDate                 : 2022:02:04 20:00:00

C:\Programs\My_Stuff>exiftool -time:all -G1 -a -s Y:\!temp\aa\Test.mp4 -api QuickTimeUTC
[System]        FileModifyDate                  : 2022:02:04 12:00:00-08:00
[System]        FileAccessDate                  : 2022:02:04 09:34:43-08:00
[System]        FileCreateDate                  : 2022:02:04 12:00:00-08:00
[QuickTime]     CreateDate                      : 2022:02:04 12:00:00-08:00
[QuickTime]     ModifyDate                      : 2022:02:04 12:00:00-08:00
[Track1]        TrackCreateDate                 : 2022:02:04 12:00:00-08:00
[Track1]        TrackModifyDate                 : 2022:02:04 12:00:00-08:00
[Track1]        MediaCreateDate                 : 2022:02:04 12:00:00-08:00
[Track1]        MediaModifyDate                 : 2022:02:04 12:00:00-08:00
[Track2]        TrackCreateDate                 : 2022:02:04 12:00:00-08:00
[Track2]        TrackModifyDate                 : 2022:02:04 12:00:00-08:00
[Track2]        MediaCreateDate                 : 2022:02:04 12:00:00-08:00
[Track2]        MediaModifyDate                 : 2022:02:04 12:00:00-08:00


When writing, if your FileCreateDate is the correct local time, then you would use
exiftool -api QuickTimeUTC "-Quicktime:CreateDate<FileCreateDate" file.mp4

Exiftool will adjust a time stamp that includes a time zone to UTC when writing a video time stamp that is supposed to be in UTC.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

snelso91

After having read the QuickTimeUTC manual page it seems I was mistaken and that the metadata is already in the correct format, which is UTC time as per the quicktime spec.
In addition, although it is stored as UTC, windows' "Media Created Date" field seems to automatically adjust the metadata to show local time like the QuickTimeUTC option does when reading, so that it matches up with the File Created and File Modified dates.

So I guess it doesn't need to be converted to local time with a time zone appended to the end like with FileCreateDate - in other words, it is already stored in the correct/normal format?