David and I have spent a lot of time tinkering with the creation time on MP4's, and going back and forth with the folks who produce the metadata extractor. jAlbum 19.3 includes the latest version of M-E, though there are still some buggy aspects to it. But there's an unsolved, underlying problem. Suggestions are welcome.
Let's summarize. The people who created the MP4 standard made one spectacularly, jaw-droppingly stupid decision. The only timestamp in the MP4 metadata reflects UTC (a.k.a. GMT). Well, in theory, at least.
So, if I use my smartphone to shoot a video at 10:00 in Connecticut (GMT-5), the timestamp in the metadata is 15:00. That's very nice, but since there's no timezone information stored in the metadata, there is simply no way to determine the local time at which the video was taken.
But it gets worse. My Nikon doesn't know what time it is, other that what I tell it. So if I shoot the same scene at the same time as the smartphone video, the timestamp is 10:00. The camera has no idea what UTC is.
So, we now have two videos shot at the same time, but with two different timestamps, five hours apart. And lord knows what happens with a video you save from someplace like Facebook - I don't even want to think about that one, since FB routinely clobbers the metadata in files.
What about using the filename? On my phone, the file name reveals the actual local time. But that's just one device. My Nikon labels it DSC_1234.MOV - not very helpful.
What about using the file creation time, as reported by the OS? The danger there is that when you copy the video from the shooting device to your PC, you might end up with a new file creation time.
Letting the user change the internal MP4 timestamp might seem like a good solution, but as a general principle, device-recorded information should be left alone. File Explorer, for example, might be hopelessly confused by a media creation time that's been manually fiddled.
The only approach that would be reliable would be to allow the user to record a real, local media creation time, based on his own knowledge of where he was at the time. That could be stored by jAlbum in one of its .info files, and used if it's present, both to display the creation time and to sort album objects. Alas, that won't "travel" with the file, so if you use the same video in another project, you'll have to make the adjustment again.
That also means that you would have to "touch" each video individually. It might be possible to provide a way to say, "all of the videos in this project were shot in EST, so subtract five hours from all of the timestamps." But if the project contains a mix of videos, either shot in different time zones or shot with different devices, that would produce a muddle.
This is a subject of interest to me. However, I think a satisfactory solution would require changing metadata and I doubt this is possible unless the latest version of M-E has significantly improved capability with video files. (Or unless you want to use Exiftool - not Java I know, but neither is ffmpeg.)
For what its worth though I would suggest:
(a) Allow bulk changes of the same type (e.g. 'set offset to zero') to all videos selected in the front end and/or all videos in selected folder(s) and the folders’ descendants. Seems like a good compromise between having to "touch" each video individually and process all videos in one hit. (Maybe it would facilitate this if the changes were made using an "External Tool")
(b) I would have a slight preference for storing the local time in the .info files, rather than just the offset, for two reasons. First, given that generally the metadata creation times are a mess (e.g. videos shot on devices which do not have geolocation probably store local rather than UTC time), it would permit retrospective correction of the metadata without upsetting the local time in the .info file. Second, this solution would be compatible with any odd videos which do not have UTC metadata.
(c) Whatever solution is chosen, it would be cool if it permitted user-modification, via a tool, of the originalDate variable (by supplementing the AlbumObject api?).
Edited by: sburke on 02-Feb-2020 03:17 - clarified ‘selection’ idea