iPhone videos - the QuickTime:CreateDate value is often wrong for some reason

[delerious]

I wrote a script that uses ExifTool to go through all my photos/videos and look for inconsistencies in timestamps.

From what I understand, QuickTime:CreateDate is supposed to be the UTC time and QuickTime:CreationDate is supposed to be the local time. (That is true for the iPhone, although I have seen other camera brands that set the QuickTime:CreateDate to the local time, and I haven't seen any brands except the iPhone support the QuickTime:CreationDate tag.)

I have found that a lot of my iPhone videos have an incorrect QuickTime:CreateDate value. My script converts the correct QuickTime:CreationDate value to UTC, and compares that to the QuickTime:CreateDate value, and the QuickTime:CreateDate value when it is incorrect could be anywhere from 1 second to a few weeks later than the QuickTime:CreationDate value converted to UTC.

So here is a summary of my findings:

• not all iPhone videos have an incorrect QuickTime:CreateDate value
• when an iPhone video does have an incorrect QuickTime:CreateDate value, the time is always later than what it is supposed to be, never earlier, and it could be off by a tiny amount or a huge amount
• all edited iPhone videos (e.g. they have a filename like IMG_E####.MOV) will definitely have an incorrect QuickTime:CreateDate value

I am not sure why some of my iPhone videos have a correct QuickTime:CreateDate value, while others have an incorrect QuickTime:CreateDate value.

Anyone else notice this?

[Hayo Baan]

Haven't noticed this, but my guess is that the create date is set to when the file was altered (e.g. edited), not when it was originally shot?

[delerious]

Even a lot of unedited videos have an incorrect QuickTime:CreateDate value.

[Hayo Baan]

I can't recall I've ever seen this. Can you share an example? The output of `exiftool -s -G0:1 -api QuickTimeUTC=1` should be enough.

Writing this, perhaps the issue is UTC vs non-UTC? By default (because of errors by many camera manufacturers), exiftool does not interpret the times in the quick time block as UTC, even if they should be according to the spec. Apple at least does this correctly so I included the `-api QuickTimeUTC=1` option in the exiftool command to tell exiftool to (correctly) interpret the times as UTC.

[delerious]

I can't recall I've ever seen this. Can you share an example? The output of `exiftool -s -G0:1 -api QuickTimeUTC=1` should be enough.

Writing this, perhaps the issue is UTC vs non-UTC? By default (because of errors by many camera manufacturers), exiftool does not interpret the times in the quick time block as UTC, even if they should be according to the spec. Apple at least does this correctly so I included the `-api QuickTimeUTC=1` option in the exiftool command to tell exiftool to (correctly) interpret the times as UTC.

Here's the output of exiftool -s -G0:1 -api QuickTimeUTC=1 for one video that has a QuickTime:CreateDate that is more than 7 days off the correct value (which can be seen in the QuickTime:CreationDate tag). It's definitely not a UTC vs non-UTC issue.

Code Select Expand

[ExifTool]      ExifToolVersion                 : 12.49
[File:System]   FileName                        : IMG_0465.MOV
[File:System]   Directory                       : h:/2023-01 Lake Placid/iPhone 14 Pro
[File:System]   FileSize                        : 30 MB
[File:System]   FileModifyDate                  : 2023:01:27 03:42:21-05:00
[File:System]   FileAccessDate                  : 2023:07:16 19:42:48-04:00
[File:System]   FileCreateDate                  : 2023:03:08 02:02:33-05:00
[File:System]   FilePermissions                 : -rw-rw-rw-
[File]          FileType                        : MOV
[File]          FileTypeExtension               : mov
[File]          MIMEType                        : video/quicktime
[QuickTime]     MajorBrand                      : Apple QuickTime (.MOV/QT)
[QuickTime]     MinorVersion                    : 0.0.0
[QuickTime]     CompatibleBrands                : qt
[QuickTime]     MediaDataSize                   : 30211582
[QuickTime]     MediaDataOffset                 : 36
[QuickTime]     MovieHeaderVersion              : 0
[QuickTime]     CreateDate                      : 2023:01:28 22:35:06-05:00
[QuickTime]     ModifyDate                      : 2023:01:28 22:35:11-05:00
[QuickTime]     TimeScale                       : 600
[QuickTime]     Duration                        : 12.54 s
[QuickTime]     PreferredRate                   : 1
[QuickTime]     PreferredVolume                 : 100.00%
[QuickTime]     PreviewTime                     : 0 s
[QuickTime]     PreviewDuration                 : 0 s
[QuickTime]     PosterTime                      : 0 s
[QuickTime]     SelectionTime                   : 0 s
[QuickTime]     SelectionDuration               : 0 s
[QuickTime]     CurrentTime                     : 0 s
[QuickTime]     NextTrackID                     : 6
[QuickTime]     HandlerType                     : Metadata Tags
[QuickTime:Track1] TrackHeaderVersion           : 0
[QuickTime:Track1] TrackCreateDate              : 2023:01:28 22:35:06-05:00
[QuickTime:Track1] TrackModifyDate              : 2023:01:28 22:35:11-05:00
[QuickTime:Track1] TrackID                      : 1
[QuickTime:Track1] TrackDuration                : 12.54 s
[QuickTime:Track1] TrackLayer                   : 0
[QuickTime:Track1] TrackVolume                  : 0.00%
[QuickTime:Track1] ImageWidth                   : 1920
[QuickTime:Track1] ImageHeight                  : 1080
[QuickTime:Track1] CleanApertureDimensions      : 1920x1080
[QuickTime:Track1] ProductionApertureDimensions : 1920x1080
[QuickTime:Track1] EncodedPixelsDimensions      : 1920x1080
[QuickTime:Track1] GraphicsMode                 : ditherCopy
[QuickTime:Track1] OpColor                      : 32768 32768 32768
[QuickTime:Track1] CompressorID                 : avc1
[QuickTime:Track1] SourceImageWidth             : 1920
[QuickTime:Track1] SourceImageHeight            : 1080
[QuickTime:Track1] XResolution                  : 72
[QuickTime:Track1] YResolution                  : 72
[QuickTime:Track1] CompressorName               : H.264
[QuickTime:Track1] BitDepth                     : 24
[QuickTime:Track1] VideoFrameRate               : 29.996
[QuickTime:Track2] Balance                      : 0
[QuickTime:Track2] AudioFormat                  : mp4a
[QuickTime:Track2] AudioChannels                : 2
[QuickTime:Track2] AudioBitsPerSample           : 16
[QuickTime:Track2] AudioSampleRate              : 44100
[QuickTime:Track2] PurchaseFileFormat           : mp4a
[ExifTool:Track3] Warning                       : [minor] The ExtractEmbedded option may find more tags in the media data
[QuickTime:Track5] MatrixStructure              : 1 0 0 0 1 0 0 0 1
[QuickTime:Track5] MediaHeaderVersion           : 0
[QuickTime:Track5] MediaCreateDate              : 2023:01:28 22:35:06-05:00
[QuickTime:Track5] MediaModifyDate              : 2023:01:28 22:35:11-05:00
[QuickTime:Track5] MediaTimeScale               : 600
[QuickTime:Track5] MediaDuration                : 12.54 s
[QuickTime:Track5] MediaLanguageCode            : und
[QuickTime:Track5] GenMediaVersion              : 0
[QuickTime:Track5] GenFlags                     : 0 0 0
[QuickTime:Track5] GenGraphicsMode              : ditherCopy
[QuickTime:Track5] GenOpColor                   : 32768 32768 32768
[QuickTime:Track5] GenBalance                   : 0
[QuickTime:Track5] HandlerClass                 : Data Handler
[QuickTime:Track5] HandlerVendorID              : Apple
[QuickTime:Track5] HandlerDescription           : Core Media Data Handler
[QuickTime:Track5] MetaFormat                   : mebx
[QuickTime:Keys] LocationAccuracyHorizontal     : 4.715772
[QuickTime:Keys] GPSCoordinates                 : 44 deg 12' 54.72" N, 73 deg 55' 35.04" W, 699.853 m Above Sea Level
[QuickTime:Keys] Make                           : Apple
[QuickTime:Keys] Model                          : iPhone 14 Pro
[QuickTime:Keys] Software                       : 16.2
[QuickTime:Keys] CreationDate                   : 2023:01:21 12:05:53-05:00
[QuickTime:Keys] ApplePhotosOriginatingSignature: AXRCedr05zk0tZ10SWG3+hs4iK+r
[Composite]     ImageSize                       : 1920x1080
[Composite]     Megapixels                      : 2.1
[Composite]     AvgBitrate                      : 19.3 Mbps
[Composite]     GPSAltitude                     : 699.853 m
[Composite]     GPSAltitudeRef                  : Above Sea Level
[Composite]     GPSLatitude                     : 44 deg 12' 54.72" N
[Composite]     GPSLongitude                    : 73 deg 55' 35.04" W
[Composite]     Rotation                        : 0
[Composite]     GPSPosition                     : 44 deg 12' 54.72" N, 73 deg 55' 35.04" W



[wywh]

FYI for troubleshooting.

If I edit a movie date in iOS 15.7.7, and send it via AirDrop to the Mac, then only the Keys:CreationDate is modified but QuickTime:CreateDate remains the original date (you can revert to that original date on the iOS device). I have not tested but AFAIK via iCloud Photos library it is the same. But notice that via USB to Image Capture it always sends the original without any metadata edits (date, caption, location) done on the iOS device.

- Matti

[Hayo Baan]

Interesting! How do you import the movies and are you running Mac/windows/Linux? (I'm on a Mac and always import using image capture, maybe this could explain it?)

[delerious]

I'm on Windows 10, and I use the file manager (Windows Explorer) to access the photos/videos inside the Apple iPhone > Internal Storage > DCIM > YYYYMM__ folders.

[wywh]

metadata edits (date, caption, location) done on the iOS device

In that previous test I edited date, caption and location via the iPhone Photos Info "i" button. I now tested the "Edit" button besides it to edit pixel data.

If I edit image or movie pixel data on an iOS device, the edited copies have a filename like IMG_E####.MOV (and there is also *.AAE adjustmentData sidecar file).

The original and edited version can be copied to the Mac via Image Capture. Via AirDrop only the edited version is copied. I now noticed that AirDrop has also an "All Photos Data" option which sends the original without any metadata edits.

Such edited image has the original date in ExifIFD:DateTimeOriginal.

Such edited movie has the original date in Keys:CreationDate and the edit date in QuickTime:CreateDate. In Mac apps (QuickTime Player, Photos.app) Keys:CreationDate overrides QuickTime:CreateDate.

I tested this in Win 10 via VMWare Fusion and File Explorer > Apple iPhone > Internal Storage > DCIM > YYYYMM_ behaves the same as Image Capture in macOS.

I don't know if there is an AirDrop equivalent for Windows that would allow also date, caption, location edits to copy to the computer (also the edited IMG_E####.* do not copy edited metadata via Image Capture or File Explorer). AFAIK iCloud Photos in Windows should do that.

- Matti