• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Nikon 1 J5 MOV video files have the wrong capture date

Explorer ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

I'm importing MOV files from a Nikon 1 J5 camera, using a SD card reader, using LR's import wizard, using a date folder structure.

LR imports all the files into a 1 January 1970 folder, and displays the capture data as 1 January 1970.

I get the following info from the MOV file using MediaInfo:

<Encoded_Date>UTC 1970-01-01 00:00:00</Encoded_Date>

<Tagged_Date>UTC 1970-01-01 00:00:00</Tagged_Date>

<File_Created_Date>UTC 2017-12-05 02:35:44.100</File_Created_Date>

<File_Created_Date_Local>2017-12-04 18:35:44.100</File_Created_Date_Local>

<File_Modified_Date>UTC 2017-11-30 04:45:56.000</File_Modified_Date>

<File_Modified_Date_Local>2017-11-29 20:45:56.000</File_Modified_Date_Local>

And the following using ExifTool:

File Modification Date/Time     : 2017:11:29 20:45:56-08:00

File Access Date/Time           : 2017:12:04 18:35:44-08:00

File Creation Date/Time         : 2017:12:04 18:35:44-08:00

Model                           : NIKON 1 J5

Software                        : NIKON 1 J5

Create Date                     : 2017:11:29 20:45:56

Date/Time Original              : 2017:11:29 20:45:56

And with FFmpeg ffprobe:

  Metadata:

    major_brand     : qt

    minor_version   : 537331968

    compatible_brands: qt  niko

    creation_time   : 1970-01-01T00:00:00.000000Z

  Duration: 00:03:56.70, start: 0.000000, bitrate: 43573 kb/s

    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/bt709/bt470m), 1920x1080 [SAR 1:1 DAR 16:9], 42017 kb/s, 59.94 fps, 59.94 tbr, 60k tbn, 119.88 tbc (default)

    Metadata:

      creation_time   : 1970-01-01T00:00:00.000000Z

      encoder         : AVC Coding

    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 2 channels, s16, 1536 kb/s (default)

    Metadata:

      creation_time   : 1970-01-01T00:00:00.000000Z

So, it looks like the track dates in the MOV are wrong, but ExifTool created date is correct, and the file modified date is correct.

How do I get LR to recognize that 1 January 1970 is not a valid date, and to use the file modified date, or whatever tag ExifTool uses, instead?

Views

1.4K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

LEGEND , Dec 09, 2017 Dec 09, 2017

The authoritative ExifTool shows the following date fields in the sample file:

$ exiftool -a -G DSC_0720-1.MOV | grep -i date

[File]          File Modification Date/Time     : 2017:12:09 14:41:56-08:00

[File]          File Access Date/Time           : 2017:12:09 14:41:56-08:00

[File]          File Inode Change Date/Time     : 2017:12:09 14:41:57-08:00

[QuickTime]     Create Date                     : 0000:00:00 00:00:00

[QuickTime]     Modify Date                     : 0000:00:00 00:00:00

[QuickTime]  

...

Votes

Translate

Translate
Contributor ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

I have the same problem with MOV files from a Canon 6D camera. LR gives the time of the file as the time it was downloaded into LR, not the time it was taken, as it does with RAW files. If I right-click on the MOV file in File Explorer and select properties, the time the file was shot is given; how can I get LR to display the capture time, not the time the file was imported?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Contributor ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

I can edit the capture time from the Metadata tab in the Library view, but I have to copy it manually from the data in File Explorer for each video. Funnily enough, LR gets the capture time from files imported from my mobile phone correct.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

You two are experiencing different symptoms, likely not the "same problem".  If you upload a sample video to Dropbox or similar and post the sharing link here, I can identify whether this is a known bug, a known industry limitation of the QuickTime / MP4 spec, or a previously unreported bug, and I can then suggest workarounds.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

I'll PM you a link to a short sample file.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

The authoritative ExifTool shows the following date fields in the sample file:

$ exiftool -a -G DSC_0720-1.MOV | grep -i date

[File]          File Modification Date/Time     : 2017:12:09 14:41:56-08:00

[File]          File Access Date/Time           : 2017:12:09 14:41:56-08:00

[File]          File Inode Change Date/Time     : 2017:12:09 14:41:57-08:00

[QuickTime]     Create Date                     : 0000:00:00 00:00:00

[QuickTime]     Modify Date                     : 0000:00:00 00:00:00

[QuickTime]     Track Create Date               : 0000:00:00 00:00:00

[QuickTime]     Track Modify Date               : 0000:00:00 00:00:00

[QuickTime]     Media Create Date               : 0000:00:00 00:00:00

[QuickTime]     Media Modify Date               : 0000:00:00 00:00:00

[QuickTime]     Track Create Date               : 0000:00:00 00:00:00

[QuickTime]     Track Modify Date               : 0000:00:00 00:00:00

[QuickTime]     Media Create Date               : 0000:00:00 00:00:00

[QuickTime]     Media Modify Date               : 0000:00:00 00:00:00

[MakerNotes]    Create Date                     : 2017:10:08 23:33:29

[MakerNotes]    Date/Time Original              : 2017:10:08 23:33:29

[MakerNotes]    Date Display Format             : D/M/Y

The QuickTime fields are industry-standard; the MakerNotes are proprietary, undocumented Nikon fields.  LR reads the QuickTime fields but not the MakerNotes.

All the QuickTime fields are 0 (which gets interpreted as 1970/1/1).  Is this file straight out of the camera, or did some other software possibly modify it?

If it's the camera doing this, then you should file a bug report with Nikon.  To work around the problem, before importing into LR you can use ExifTool to copy the MakerNotes:CreateDate to the QuickTime:CreateDate, using this command line:

exiftool '-quicktime:createdate<MakerNotes:CreateDate' DSC_0720-1.MOV

ExifTool can process a whole folder or folder tree in batch.  But beware that the learning curve for ExifTool is steep.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

File is direct from camera, removed SD card, placed in reader, imported using LR.

I'll delete, set date, re-import the files, using your suggestion.

I do think that since the field values are 0, and LR does read RAW attributes (at least from image files), that I'd expect LR to pick the best date field from all available, I hope this could be enhanced in future versions.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

LATEST

I do think that since the field values are 0, and LR does read RAW attributes (at least from image files), that I'd expect LR to pick the best date field from all available, I hope this could be enhanced in future versions.

You could file a feature request in the official Adobe feedback forum: Lightroom Classic CC | Photoshop Family Customer Community

But I'd guess that Adobe's response will be to ignore it, since it appears to be a blatant Nikon bug.  The QuickTime fields are documented in an industry standard and where nearly all manufacturers and software apps store the create date and other metadata.  The MakerNotes are undocumented and differ between manufacturers and even between models from the same manufacturer.  Adobe works with manufacturers to understand their proprietary raw formats (which aren't publicly documented), but that is a relatively expensive legal and engineering process, and I'm guessing that Adobe wouldn't expend effort just to work around a manufacturer's careless bug.  But this is all just educated guesswork on my part based on years of observing Adobe.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

Funnily enough, LR gets the capture time from files imported from my mobile phone correct.

LR added specific support for iOS-created videos a couple of releases ago, reading proprietary, non-standard metadata added to the videos by iOS.  See here for gory details: Re: Why Doesn't Lightroom 6 *still* not import metadata correctly for Video?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Contributor ,
Dec 09, 2017 Dec 09, 2017

Copy link to clipboard

Copied

Actually i have an Android phone ...

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines