Issue with Composite Tag in ExifTool for File Renaming

[veevoo]

Hello,

I'm using ExifTool 12.57 on Debian 12 to rename video files based on a custom composite tag, TestDate, defined as follows:

Code Select Expand

%Image::ExifTool::UserDefined = (
    'Image::ExifTool::Composite' => {
        TestDate => {
            Require => {
                0 => 'QuickTime:ModifyDate',
                1 => 'Duration',
            },
            ValueConv => q{
                if ($val[0] gt "1970:01:01") {
                    ShiftTime($val[0], "0:0:${val[1]}", -1);
                    return $val[0];
                }
                return undef;
            },
            PrintConv => '$self->ConvertDateTime($val)',
        },
    },
);
I use TestDate to rename video files with the following command:

Code Select Expand

exiftool '-filename<TestDate' -d "./%Y%m%d_%H%M%S%%+c.%%le" -overwrite_original -api quicktimeutc .
For most files, this works correctly. However, for some files, the renaming process uses an incorrect timestamp, even though TestDate appears to be calculated correctly when viewed. For example, one file has the following metadata:

Code Select Expand

Track Modify Date: 2025:04:06 04:23:59
Duration:         10.82 s
Test Date:        2025:04:06 04:23:48
Here, TestDate (04:23:48) is correctly calculated by subtracting the duration (10.82 seconds) from Track Modify Date (04:23:59). However, when renaming the file, I get 20250406_042359.mp4 instead of the expected 20250406_042348.mp4. This issue occurs sporadically and only with certain files.I've confirmed that the -api quicktimeutc option is not causing the renaming issue.

Questions:

• Why does the renaming process sometimes use the wrong timestamp despite TestDate being displayed correctly?
  
• I'm not familiar with Perl, but I noticed that ShiftTime($val[0], "0:0:${val[1]}", -1) modifies the existing QuickTime:ModifyDate value directly. Could this be problematic? Would it be better to copy QuickTime:ModifyDate to a temporary variable before performing the time shift to avoid altering the original value?
• If there are any other errors or potential improvements in my TestDate composite tag, I'd appreciate suggestions.
  

[Phil Harvey]

1. Why does the renaming process sometimes use the wrong timestamp despite TestDate being displayed correctly?

Now that is a real mystery.  Is this reproducible for a given file?  If so, could you send me a file which shows this issue?  (philharvey66 at gmail.com)

2. I'm not familiar with Perl, but I noticed that ShiftTime($val[0], "0:0:${val[1]}", -1) modifies the existing QuickTime:ModifyDate value directly. Could this be problematic?

The elements of the @val list are copies of the tag values, so this isn't a problem.

3. If there are any other errors or potential improvements in my TestDate composite tag, I'd appreciate suggestions.

Looks good to me.

- Phil

[StarGeek]

Code Select Expand

%Image::ExifTool::UserDefined = (
    'Image::ExifTool::Composite' => {
        TestDate => {
            Require => {
                0 => 'QuickTime:ModifyDate',

...

Code Select Expand

Track Modify Date: 2025:04:06 04:23:59
Duration:         10.82 s
Test Date:        2025:04:06 04:23:48
Here, TestDate (04:23:48) is correctly calculated by subtracting the duration (10.82 seconds) from Track Modify Date (04:23:59). However, when renaming the file, I get 20250406_042359.mp4 instead of the expected 20250406_042348.mp4. This issue occurs sporadically and only with certain files.I've confirmed that the -api quicktimeutc option is not causing the renaming issue.

Your code uses Quicktime:ModifyDate, not Quicktime:TrackModifyDate. What is the value of Quicktime:ModifyDate?

IMO, Quicktime:TrackModifyDate isn't the best time stamp to use when reading video files. There are going to be multiple Quicktime:TrackModifyDate in a video file, one for each track (audio track, video track, subtitle/data track), and, depending upon the source of the file, these values might be different from the Quicktime:ModifyDate.

[veevoo]

Now that is a real mystery.  Is this reproducible for a given file?  If so, could you send me a file which shows this issue?  (philharvey66 at gmail.com)

Thank you for the response. Unfortunately, I cannot share the video from my previous message. However, I can provide a link to a video, https://2ch.hk/au/src/6582706/17462107626600.webm, for which TestDate fails to work correctly both in output and during renaming, which is even stranger

[veevoo]

IMO, Quicktime:TrackModifyDate isn't the best time stamp to use when reading video files

Thank you for the response. In my first message, I mistakenly referred to the output of the Track Modify Date tag instead of Modify Date (exiftool -ModifyDate), but in my case, Track Modify Date and Modify Date are identical.

[Phil Harvey]

The Duration metadata in the file you linked is 0 seconds.

- Phil

[StarGeek]

There is something wrong with that file. No matter what I try, it downloads as an MP4, not a WebM.  Once downloaded, the only video player I have that will play it is VLC. Everything else just plays audio, not video.

[veevoo]

The Duration metadata in the file you linked is 0 seconds

Yes, indeed, ExifTool displays the video duration as 0 seconds, while mediainfo and ffprobe correctly show the duration as 11.58 seconds.

I found two videos with the same ExifTool behavior as described in my first message:

https://i.arhivach.site/storage/7/27/72781b7fb2a0eec424d58548bd1fdfc8.mp4
https://i.arhivach.site/storage/6/f7/6f78a94a6d14913e6e4a92f02a32c599.mp4

the only video player I have that will play it is VLC

mpv video player plays this video perfectly.

P.S.: Please disregard the content of the videos; these are just random internet videos used to demonstrate the issue

[StarGeek]

Yes, indeed, ExifTool displays the video duration as 0 seconds, while mediainfo and ffprobe correctly show the duration as 11.58 seconds.

These tools read the video stream so they are able to find the exact duration. Exiftool only reads the header data and the file size to calculate the duration. See here.

I found two videos with the same ExifTool behavior as described in my first message:

That site has hot links disabled and return 403 Forbidden. I was able to download one by first going to the main site and then pasting the link.

Once I downloaded them, your config file works correctly for me.

Code Select Expand

C:\>exiftool -config test.config -G1 -a -s -TestDate -quicktime:modifydate -Duration Y:\!temp\x\y\72781b7fb2a0eec424d58548bd1fdfc8.mp4 Y:\!temp\x\y\6f78a94a6d14913e6e4a92f02a32c599.mp4
======== Y:/!temp/x/y/72781b7fb2a0eec424d58548bd1fdfc8.mp4
[Composite]     TestDate                        : 2021:06:23 15:10:46
[QuickTime]     ModifyDate                      : 2021:06:23 15:11:11
[QuickTime]     Duration                        : 25.05 s
======== Y:/!temp/x/y/6f78a94a6d14913e6e4a92f02a32c599.mp4
[Composite]     TestDate                        : 2024:08:17 16:30:34
[QuickTime]     ModifyDate                      : 2024:08:17 16:31:09
[QuickTime]     Duration                        : 0:00:35
    2 image files read
Edit: Since you're using a very old version of exiftool, I double checked with version 12.57. I had no change in the results.

[veevoo]

your config file works correctly

I use TestDate to rename video files with the following command:
Code Select Expand

Code Select Expand

exiftool '-filename<TestDate' -d "./%Y%m%d_%H%M%S%%+c.%%le" -overwrite_original -api quicktimeutc .
For most files, this works correctly. However, for some files, the renaming process uses an incorrect timestamp, even though TestDate appears to be calculated correctly when viewed. For example, one file has the following metadata:

Code Select Expand

Code Select Expand

Track Modify Date: 2025:04:06 04:23:59
Duration:         10.82 s
Test Date:        2025:04:06 04:23:48
Here, TestDate (04:23:48) is correctly calculated by subtracting the duration (10.82 seconds) from Track Modify Date (04:23:59). However, when renaming the file, I get 20250406_042359.mp4 instead of the expected 20250406_042348.mp4

The issue occurs specifically during file renaming. Please try renaming these two files using the command:

 exiftool '-filename<TestDate' -d "./%Y%m%d_%H%M%S%%+c.%%le" -overwrite_original -api quicktimeutc .

[StarGeek]

Very, very strange. This will be something Phil will need to look into.

I added a couple of print statements to debug with and when doing the rename, Duration isn't filled properly.

My changes

Code Select Expand

            ValueConv => q{
            print "ModifyDate $val[0]\n";
            print "Duration $val[1]\n";
                if ($val[0] gt "1970:01:01") {
                    ShiftTime($val[0], "0:0:${val[1]}", -1);
                    print "ModifyDate after Shifttime $val[0]\n";
                    return $val[0];
                }
                return undef;
            },
            PrintConv => 'print "convertdatetime $val\n";$self->ConvertDateTime($val)',
When run to list the data, everything works correctly.

Code Select Expand

C:\>exiftool -config test.config -G1 -a -s -testdate -modifydate -Duration -api QuickTimeUTC Y:\!temp\x\y\6f78a94a6d14913e6e4a92f02a32c599.mp4
ModifyDate 2024:08:17 09:31:09-07:00
Duration 34.9013333333333
ModifyDate after Shifttime 2024:08:17 09:30:34-07:00
convertdatetime 2024:08:17 09:30:34-07:00
[Composite]     TestDate                        : 2024:08:17 09:30:34-07:00
[QuickTime]     ModifyDate                      : 2024:08:17 09:31:09-07:00
[XMP-xmp]       ModifyDate                      : 2024:08:17 19:31:09+03:00
[QuickTime]     Duration                        : 0:00:35
But add the rename and Duration becomes a hash reference

Code Select Expand

C:\>exiftool -config test.config -G1 -a -s "-testname<TestDate" -d "./%Y%m%d_%H%M%S%%+c.%%le" -api QuickTimeUTC Y:\!temp\x\y\6f78a94a6d14913e6e4a92f02a32c599.mp4
ModifyDate 2024:08:17 09:31:09-07:00
Duration HASH(0x40a7100)
ModifyDate after Shifttime 2024:08:17 09:31:09-07:00
convertdatetime 2024:08:17 09:31:09-07:00
'Y:/!temp/x/y/6f78a94a6d14913e6e4a92f02a32c599.mp4' --> './20240817_093109.mp4'
    0 image files updated
    1 image files unchanged
Edit: Link to one of the files to avoid dealing with the hot link protection.

[Phil Harvey]

This is the issue:

Code Select Expand

> exiftool ~/Downloads/6f78a94a6d14913e6e4a92f02a32c599.mp4 -duration -G1 -struct -a
[QuickTime]     Duration                        : 0:00:35
[XMP-xmpDM]     Duration                        : {Scale=1.11111111111111e-05,Value=3141120}
Note that the -struct option is set by default when copying tags from file.

Either specify "QuickTime:Duration" in the config file or use -api struct=0 to avoid using the XMP-xmpDM:Duration structure in your calculations.

- Phil