Metadata Changes made in Bridge not Reflected Elsewhere

Report · Jan 21, 2023

Hello friends,

After many years of lurking these forums for various solutions over the years, I have finally come across an issue perplexing enough to warrant a post. For some background info, I recently updated all my devices and CC apps and am running macOS Ventura and Bridge 13.0.2.636

I'm in the process of consolidating my iPhone photo and videos backups to iCloud to free up space on my iMac/generally making my workflow more efficient. Previously, I would use Apple Photos to import images and videos from my iPhone onto my iMac and export them as "unmodified originals" to annual archive folders. However, last year I discoverd a batch of ~500 videos from 2019 that were in a different format (.m4v instead of the usual .MOV) and they'd somehow had their metadata stripped away and replaced with an incorrect creation date - I assume this date delineates when this disaster occured. Whats more bizarre, all the photos from this period (May-September) didn't have their metadata affected, but are .jpg images instead of the usal .HEIC, and can still be sorted chronologically. I've tried to recreate this error by exporting from Apple Photos with different settings but so far I'm still stumped as to what happened to this batch of media.

Anyway, over the past week, I've been tediously sorting the videos manually by comparing the dates to photos, trying to delineate different events and occurences, and using instagram to further corroborate dates. Once I've established the date and rough time of a video, I have been typing the corrected date and time into the "Camera Data (Exif)" drop down area of the Metadata viewer, altering the "Date Time Original" field to the corrected date/time. This change is also reflected in the "File Properties" drop down area of the Metadata viewer, showing the correctly altered "Date Created", as shown below.

After hours upon hours of this, I finally finished yesterday and went to import everything into Apple Photo/sync with iCloud and once again, these ~500 videos were recorded as having the incorrect creation date of September 25th, 2019 and were placed in a randomized order depending on their supposed time of creation. I removed them from Apple Photos, came here, found a couple of suggestions like the "Edit Capture Time" feature, which does in fact reflect my corrected dates, or clicking the "Apply" checkmark in the bottom right corner to make sure the change was applied. Even more perplexing is the fact that Bridge can now correctly sorted these videos by date created, but the "File Info" still shows the incorrect creation date (shown below) as does the file info provided in Finder. Note: all screen captures are for the same file.

Can anyone advise on how to solididy the metadata changes I've made to be reflected outside of Bridge so I can finally sorted these videos chronologically? I am desperately hoping that this can be achieved in a batch processing method because I've poured way too many hours into tediously and manually sorting these videos already and am terrified of it all being for nothing. Thanks for your help,

Sam

Report · Jan 22, 2023

A big part of this puzzle is knowing which date field Apple Photos sorts on, there are several: date file created, date created (content created), exif dates, XMP dates (many different types). I don't have any .m4V files to analyze, so I'm at a slight disadvantage.

I notice in your File properties that Date File Created is not showing. Would that be September 25th, 2019?

Turn on Date File Created in Preferences > Metadata.

I think the File Info Basic and Origin panels are reading different dates, which only adds to the confusion.

First, let's look at the embedded XMP metadata.

Open the File Info panel (File > File Info…) and click on "Raw Data" (in the list of panels on the left side).

Click on the XMP data. Select all then copy and paste it into a reply here.

Report · Jan 22, 2023

Hi there, thanks for your help with this. After enabling the additional metadata fields, this is the what I've found. The date created and date time original reflect the corrections I've made, but now there's a further mismatch between the Exif date time and date file created listed under file properties. Clearly something went very askew from September 25th-26th, 2019, possibly during an export procedure that was going on in the background. I'll post a screenshot of this below.

RAW Data as per your request:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 7.1-c000 79.4d2f597, 2021/09/01-20:51:22 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:tiff="http://ns.adobe.com/tiff/1.0/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#" xmlns:kbrg="http://ns.adobe.com/bridge/1.0/" xmlns:exif="http://ns.adobe.com/exif/1.0/" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" xmlns:xmpDM="http://ns.adobe.com/xmp/1.0/DynamicMedia/"> <xmp:CreateDate>2019-09-26T04:41:05Z</xmp:CreateDate> <xmp:ModifyDate>2019-09-26T04:41:06Z</xmp:ModifyDate> <xmp:MetadataDate>2023-01-21T10:45:31-08:00</xmp:MetadataDate> <tiff:Orientation>1</tiff:Orientation> <xmpMM:InstanceID>xmp.iid:b2255872-8197-4686-92d7-be1a6c0cea85</xmpMM:InstanceID> <xmpMM:DocumentID>xmp.did:4401b4b8-33c6-4fbb-84df-9934344ac881</xmpMM:DocumentID> <xmpMM:OriginalDocumentID>xmp.did:4401b4b8-33c6-4fbb-84df-9934344ac881</xmpMM:OriginalDocumentID> <xmpMM:History> <rdf:Seq> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:4401b4b8-33c6-4fbb-84df-9934344ac881</stEvt:instanceID> <stEvt:when>2023-01-15T10:20:26-08:00</stEvt:when> <stEvt:softwareAgent>Adobe Bridge 2023</stEvt:softwareAgent> <stEvt:changed>/metadata</stEvt:changed> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:b2255872-8197-4686-92d7-be1a6c0cea85</stEvt:instanceID> <stEvt:when>2023-01-21T10:45:31-08:00</stEvt:when> <stEvt:softwareAgent>Adobe Bridge 2023</stEvt:softwareAgent> <stEvt:changed>/metadata</stEvt:changed> </rdf:li> </rdf:Seq> </xmpMM:History> <kbrg:InitialEditCaptureTime>2019-09-26T04:41:05Z</kbrg:InitialEditCaptureTime> <exif:DateTimeOriginal>2019-05-16T12:00-08:00</exif:DateTimeOriginal> <photoshop:DateCreated>2019-05-16T12:00</photoshop:DateCreated> <xmpDM:duration rdf:parseType="Resource"> <xmpDM:value>6299</xmpDM:value> <xmpDM:scale>1/600</xmpDM:scale> </xmpDM:duration> </rdf:Description> </rdf:RDF> </x:xmpmeta>

And as a screenshot:

Report · Jan 22, 2023

There are 4 dates in the XMP metadata:

Generally these are defined consistently, but some software might not honor the definition.

Date the file was created/modified:

xmp:CreateDate 2019-09-26T04:41:05Z
xmp:ModifyDate 2019-09-26T04:41:06Z

Date the content was created:

exif:DateTimeOriginal 2019-05-16T12:00-08:00
photoshop:DateCreated 2019-05-16T12:00

I bet that when you transferred the video files in September 25th-26th, 2019, they were considered to be new files in iCloud and the xmp:CreateDate and Modified dates were set the same as the new file date.

I found a discussion about a similar issue. It's about jpgs, but the problem of date changes might still be relevant. Your m4V files might have been handled differently than your jpgs on upload, I can't say why or how though.

https://discussions.apple.com/thread/253781687

There are ways to sync the file create date to DateTimeOriginal, but not in Bridge. Before we go down that path, it would be good to know if the corrected files will be changed again in iCloud or Apple Photo. You said you have not been able to recreate the problem. Has this been with .m4v files? I should have said from the beginning that I am a Windows user, so I can't test the issue directly. I can help with the metadata cleanup though.

Report · Jan 22, 2023

Hi Greg,

This is correct, I have not been able to replicate the issue by exporting "normal" .MOV files from Apple Photos that came from before and after the May-September period and to be honest, I don't even know where the .m4v extension came from - perhaps previous version of Apple Photos handled file export differently? Looking at previous years, I have .m4v files from 2015 that also have bizarre file creation dates shown in Finder but are still correctly sorted in Apple Photos and when exmained, show the correct capture time.

Examining a "normal" .MOV video in Apple Photos vs one of the September 25th .m4v anomalies doesn't provide much information either as the software is more user friendly to a fault and doesn't provided detailed metadata about each file - as seen below

Anomaly Normal

The user in the link you've provided seems to be having a similar problem in that Finder uses file creation dates and not Exif data to sort, probably irrespective of the file format - which is certainly a scary proposition: that Apple Photos could have stripped out the actual date and time the photo/video was created. I know that for the ~500 videos I appended, there was no sign of the original creation date/time anywhere to be found so I was mostly using educated guesses when I input the Date Time Original myself.

As you've suggested, syncing the file creation date to the Date Time Original I've manually input in Bridge would be the ticket. It would be good to test this on a single file and then see if Finder and Apple Photos can read the altered metadata correctly before proceeding with any batch processing. Let me know your thoughts.

Report · Jan 23, 2023

Hi Samuel,

One drawback to editing the File Creation Date is that it might be changed during a future backup/sync/upload. Still, it would be good to try it, as you said, to determine if that is the date Finder and Apple Photos are sorting on.

As a side note, I wonder if converting your m4V files to MOV, in case they would work better in the Apple environment.

To sync the file creation date to the Date Time Original, I would ExifTool. It's a very well established tool and is very powerful and fast for batch processes. It is a command line tool, so that can take a little getting used to.

https://exiftool.org/

Have a look at it and perhaps start with just reading the metadata from a few files. There are some tutorials on YouTube, and elsewhere, to help. There are also some Mac GUI wrappers that provide a friendlier interface. Given you are doing a single, straightforward edit, the command line version should get the job done quickly.

Here is the command to sync the file creation date to the Date Time Original:

exiftool "-filecreatedate<datetimeoriginal" [path to video file]

If this works, you could change the command to process an entire folder and subfolders:

exiftool -r "-filecreatedate<datetimeoriginal" [path to folder of video files]

Note that while testing this, I found that Bridge would not display the edited file creation date until I purged the cache. I was getting frustrated that the edit did not work until I saw the new date in File Explorer. After purging the Bridge cache the date displayed correctly. Yeah, that's Bridge problem.

I can help you with Exiftool, but I will be offline for a few days starting tomorrow.

Report · Jan 24, 2023

Hi Greg,

There's no rush on this - we both have lives. I did download ExifTool and have a very brief peruse through it before becoming somewhat overhwelmed. Using Terminal sans ExifTool, I did figure out how to examine the metadata for a sample anomaly file, shown below:

samhoffe$ mdls /Users/samhoffe/Pictures/2019/iphone_2019_0577.m4v

_kMDItemDisplayNameWithExtensions = "iphone_2019_0577.m4v"

kMDItemAudioBitRate = 94

kMDItemAudioChannelCount = 1

kMDItemCodecs = (

"MPEG-4 AAC",

"H.264"

)

kMDItemContentCreationDate = 2019-09-26 04:41:05 +0000

kMDItemContentCreationDate_Ranking = 2019-09-26 00:00:00 +0000

kMDItemContentModificationDate = 2023-01-21 18:45:31 +0000

kMDItemContentType = "com.apple.m4v-video"

kMDItemContentTypeTree = (

"com.apple.m4v-video",

"public.mpeg-4",

"public.movie",

"public.audiovisual-content",

"public.data",

"public.item",

"public.content"

)

kMDItemDateAdded = 2023-01-21 01:23:45 +0000

kMDItemDisplayName = "iphone_2019_0577.m4v"

kMDItemDocumentIdentifier = 3002

kMDItemDurationSeconds = 10.49833333333333

kMDItemFSContentChangeDate = 2023-01-21 18:45:31 +0000

kMDItemFSCreationDate = 2019-09-26 04:41:05 +0000

kMDItemFSCreatorCode = ""

kMDItemFSFinderFlags = 0

kMDItemFSHasCustomIcon = (null)

kMDItemFSInvisible = 0

kMDItemFSIsExtensionHidden = 0

kMDItemFSIsStationery = (null)

kMDItemFSLabel = 0

kMDItemFSName = "iphone_2019_0577.m4v"

kMDItemFSNodeCount = (null)

kMDItemFSOwnerGroupID = 20

kMDItemFSOwnerUserID = 502

kMDItemFSSize = 14304949

kMDItemFSTypeCode = ""

kMDItemInterestingDate_Ranking = 2019-09-26 00:00:00 +0000

kMDItemKind = "Apple MPEG-4 movie"

kMDItemLastUsedDate = 2019-09-26 04:55:49 +0000

kMDItemLastUsedDate_Ranking = 2019-09-26 00:00:00 +0000

kMDItemLogicalSize = 14304949

kMDItemMediaTypes = (

Sound,

Video

)

kMDItemPhysicalSize = 14307328

kMDItemPixelHeight = 1080

kMDItemPixelWidth = 1920

kMDItemProfileName = "HD (1-1-1)"

kMDItemStreamable = 0

kMDItemTotalBitRate = 10891

kMDItemUseCount = 11

kMDItemUsedDates = (

"2019-09-25 07:00:00 +0000"

)

kMDItemVideoBitRate = 10796

Unfortunately, it looks like whatever happened during that September 25th export process did some serious damage and has completey replaced the metadata of the original video with that of the created file. More unsettling is the absence of my corrected date above, which I can still only see and sort with in Bridge. Anyway, I'll start having a look at how to potentially replace the creation date with the date time original, if that information is even embedded in the file.

Report · Feb 01, 2023

That terminal export you did mught not be reading all the metadata, especially XMP which is where your corrected original creation date is.

Try using exiftool to read all the metadata for file iphone_2019_0577.m4v

Launch the Terminal application from your /Applications/Utilities folder.
Type "exiftool" followed by a SPACE in the Terminal window.
Drag and drop files and folders on the Terminal window.
(This saves you typing the full path names of the files/folders.)
Press RETURN to view the metadata from the files you dropped.

Report · Feb 01, 2023

Hi Greg,

Thank again for all your time and effort with this. What you mentioned above was exactly the case: Exiftool reads the above file as follows:

ExifTool Version Number : 12.55

File Name : iphone_2019_0577.m4v

Directory : /Users/samhoffe/Pictures/2019

File Size : 14 MB

File Modification Date/Time : 2023:01:21 10:45:31-08:00

File Access Date/Time : 2023:02:01 20:46:41-08:00

File Inode Change Date/Time : 2023:01:21 10:45:31-08:00

File Permissions : -rw-r--r--

File Type : M4V

File Type Extension : m4v

MIME Type : video/x-m4v

Major Brand : Apple iTunes Video (.M4V) Video

Minor Version : 0.0.1

Compatible Brands : M4V , M4A , mp42, isom

Movie Header Version : 0

Time Scale : 600

Duration : 10.50 s

Preferred Rate : 1

Preferred Volume : 100.00%

Preview Time : 0 s

Preview Duration : 0 s

Poster Time : 0 s

Selection Time : 0 s

Selection Duration : 0 s

Current Time : 0 s

Next Track ID : 3

Track Header Version : 0

Track Create Date : 2019:09:26 04:41:05

Track Modify Date : 2019:09:26 04:41:06

Track ID : 1

Track Duration : 10.50 s

Track Layer : 0

Track Volume : 100.00%

Balance : 0

Audio Format : mp4a

Audio Channels : 2

Audio Bits Per Sample : 16

Audio Sample Rate : 44100

Matrix Structure : 1 0 0 0 1 0 0 0 1

Image Width : 1920

Image Height : 1080

Media Header Version : 0

Media Create Date : 2019:09:26 04:41:05

Media Modify Date : 2019:09:26 04:41:06

Media Time Scale : 600

Media Duration : 10.50 s

Media Language Code : und

Handler Description : Core Media Video

Graphics Mode : srcCopy

Op Color : 0 0 0

Compressor ID : avc1

Source Image Width : 1920

Source Image Height : 1080

X Resolution : 72

Y Resolution : 72

Bit Depth : 24

Color Profiles : nclx

Color Primaries : BT.709

Transfer Characteristics : BT.709

Matrix Coefficients : BT.709

Pixel Aspect Ratio : 1:1

Video Frame Rate : 30.005

Location Information : (none) Role=shooting Lat=49.05229 Lon=-125.72389 Alt=2.04 Body=earth Notes=

Handler Type : Metadata

User Data mak : Apple

Media Data Size : 14293767

Media Data Offset : 7759

XMP Toolkit : Adobe XMP Core 7.1-c000 79.4d2f597, 2021/09/01-20:51:22

Create Date : 2019:09:26 04:41:05Z

Modify Date : 2019:09:26 04:41:06Z

Metadata Date : 2023:01:21 10:45:31-08:00

Orientation : Horizontal (normal)

Instance ID : xmp.iid:b2255872-8197-4686-92d7-be1a6c0cea85

Document ID : xmp.did:4401b4b8-33c6-4fbb-84df-9934344ac881

Original Document ID : xmp.did:4401b4b8-33c6-4fbb-84df-9934344ac881

Initial Edit Capture Time : 2019:09:26 04:41:05Z

Date/Time Original : 2019:05:16 12:00-08:00

Date Created : 2019:05:16 12:00

History Action : saved, saved

History Instance ID : xmp.iid:4401b4b8-33c6-4fbb-84df-9934344ac881, xmp.iid:b2255872-8197-4686-92d7-be1a6c0cea85

History When : 2023:01:15 10:20:26-08:00, 2023:01:21 10:45:31-08:00

History Software Agent : Adobe Bridge 2023, Adobe Bridge 2023

History Changed : /metadata, /metadata

Duration Value : 6299

Duration Scale : 0.00166666666666667

Image Size : 1920x1080

Megapixels : 2.1

Avg Bitrate : 10.9 Mbps

GPS Altitude : 2.04 m

GPS Altitude Ref : Above Sea Level

GPS Latitude : 49 deg 3' 8.24" N

GPS Longitude : 125 deg 43' 26.00" W

Rotation : 0

GPS Position : 49 deg 3' 8.24" N, 125 deg 43' 26.00" W

Interstingly, .M4V appears to be a native Apple file format. Anyway, the "Date/Time Original" and "Date Created" fields properly reflect the corrections I made in Bridge. Unfortunately, it seems the true original creation date and time have indeed been lost. As you mentioned in previous replies, what would be the command to synchronize the creation date with DTO? This appears to be the primary criteria used for sorting. I'd be curious to test it on one file and see how Apple Photos handles it before comitting to a batch process.

Report · Feb 01, 2023

Hi Greg, please disreagrd my last reply as I just remembered you posted that command in a previous reply. I'll give it a go and report back.

Report · Feb 10, 2023

Hi Greg,

I've tried running some commands to no avail. Of course, I'm assuming this is due to user error first and foremost. I'll paste some of the errors below:

Samuels-iMac-Retina-5K-27-inch-2019:~ samhoffe$ /usr/local/bin/exiftool-filecreatedate<createdate/Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

-bash: createdate/Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v: No such file or directory

I managed to tweak the command after exploring some other forums and get a different result as shown below:

Samuels-iMac-Retina-5K-27-inch-2019:~ samhoffe$ exiftool '-createdate<filename'[/Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v ]

Warning: Error opening file - ]

Error: File not found - ]

0 image files updated

1 files weren't updated due to errors

Report · Feb 11, 2023

Hi Sam,

Your second attempt looks like you are close. I don't think you need the [ ] around the file path. Those were in my example to indidate where you place your own file path. Instead, try a space just before the file path:

exiftool '-createdate<filename' /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

It looks like you are very good about not using spaces in folder and file names, but if you have space, be sure to surround the file path in quotes.

I was also going to suggest you just play around with reading some metadata to get comfortable with the command format.

You can read the create date this way:

exiftool -createdate /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

(When reading a tag, you don't surround the tag name with quotes)

Other date tags to try:

-FileCreateDate
-DateTimeOriginal
-OffsetTimeOriginal
-CreateDate
-OffsetTimeDigitized
-ModifyDate
-OffsetTime
-DateTimeOriginal

Report · Feb 17, 2023

Hi Greg,

Sorry to keep dragging this out, I do appreciate the time you've volunteered to this silly problem. I've been punching in different commands, reading some snippets of metadata and getting more familiar with using the command line format and upon review of the above posts, realized I was mostly just typing in jibberish with a shotgun approach to see what commands would stick/run.

Anyway, I can indeed read the corrected DTO as I've written it in Bridge, but I'm still having trouble confirming the update in terminal:

$ exiftool -filecreatedate<datetimeoriginal /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

File Creation Date/Time : 2019:09:25 21:41:05-07:00

Doesn't look promising, but let's go ahead and check the overall metadata for the file again to see if anything has changed:

$ /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

-bash: /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v: Permission denied

Permission denied? I succesfully entered this command a few lines up to check the metadata for the file and now I can no longer exmaine it? Attemped to fix permissions:

$ exiftool -filepermissions=rw-rw-rw- /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

1 image files updated

Okay, let's check again...

$ /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v

-bash: /Users/samhoffe/Pictures/2019/M4Vs/iphone_2019_0577.m4v: Permission denied

Anyway, I'll be away this weekend and the following week but will try and pick this up when I return.

Report · Feb 17, 2023

God, please disregard the above: remembering to type in "exiftool" before the file name usually helps when trying to examine it. These Adobe forums aren't exactly forgiving as any mistakes made are now permanently on public display without a delete post feature.

Anyway, still can't manage to synchronize the create date with DTO. Until next time!