Summary
On Sony Alpha MP4 files carrying the camera's RTMD (Real Time Metadata) track,
MediaInfo no longer reports the drop-frame flag. Version 24.04 reported it
correctly; 26.01 and 26.05 do not.
The change appears related to I2094, MXF: Sony Real Time Metadata: fix timecode drop frame flag in the 24.11 changelog. That entry refers to MXF, but the
regression shows up on MP4.
Sample file
W0292.MP4 — Sony A7S III, 119.88 fps, NTSC drop-frame.
Happy to upload the file wherever is most convenient.
Observed
$ mediainfo --Output='Other;%TimeCode_FirstFrame%|%TimeCode_DropFrame%' W0292.MP4
| MediaInfo version |
TimeCode_FirstFrame |
TimeCode_DropFrame |
| 24.04 |
02:34:28;12 |
Yes |
| 26.01 |
02:34:28:12 |
No |
| 26.05 |
02:34:28:12 |
No |
The full dump (mediainfo -f) on 26.05 also reports TimeCode_DropFrame : No,
so this is not a template or output-format issue.
Expected
The file is drop-frame. Two independent references agree:
- Sony Catalyst Browse (the camera manufacturer's own tool) shows
02:34:28;012, with the drop-frame separator.
- DaVinci Resolve reports the clip as
119.880 DF.
MediaInfo 24.04 agreed with both. 26.x does not.
Environment
- macOS, Intel
- MediaInfo CLI 24.04 (correct) and 26.01 / 26.05 (incorrect)
- Also reproduced with MediaInfo 26.01 on Windows 10, so it does not look
platform-specific.
Impact
Without the drop-frame flag the end timecode is computed with non-drop arithmetic,
whichat 119.88 fps drifts by 8 frames per minute — 80 frames on a ten-minute take.
The exported timecode then disagrees with what Catalyst Browse and Resolve
display for the same clip.
We have not downgraded to 24.04, because 26.05 is a clear improvement elsewhere
(HEVC profile reporting, Canon manufacturer capitalisation, bitrate accuracy),
and we would rather wait for a fix than lose those.
Notes
The timecode value itself is read correctly in every version — the frame field
matches Catalyst exactly. Only the drop-frame flag and its separator are
affected.
We could not recover the flag from any other source in the file: ffprobe reports
the same timecode without the separator from both the tmcd track and the
container, and ExifTool exposes no timecode tag at all (including with -ee).
The information does appear to survive in the file itself, since both Catalyst
and Resolve still read it.
Summary
On Sony Alpha MP4 files carrying the camera's RTMD (Real Time Metadata) track,
MediaInfo no longer reports the drop-frame flag. Version 24.04 reported it
correctly; 26.01 and 26.05 do not.
The change appears related to
I2094, MXF: Sony Real Time Metadata: fix timecode drop frame flagin the 24.11 changelog. That entry refers to MXF, but theregression shows up on MP4.
Sample file
W0292.MP4— Sony A7S III, 119.88 fps, NTSC drop-frame.Happy to upload the file wherever is most convenient.
Observed
02:34:28;12Yes02:34:28:12No02:34:28:12NoThe full dump (
mediainfo -f) on 26.05 also reportsTimeCode_DropFrame : No,so this is not a template or output-format issue.
Expected
The file is drop-frame. Two independent references agree:
02:34:28;012, with the drop-frame separator.119.880 DF.MediaInfo 24.04 agreed with both. 26.x does not.
Environment
platform-specific.
Impact
Without the drop-frame flag the end timecode is computed with non-drop arithmetic,
whichat 119.88 fps drifts by 8 frames per minute — 80 frames on a ten-minute take.
The exported timecode then disagrees with what Catalyst Browse and Resolve
display for the same clip.
We have not downgraded to 24.04, because 26.05 is a clear improvement elsewhere
(HEVC profile reporting, Canon manufacturer capitalisation, bitrate accuracy),
and we would rather wait for a fix than lose those.
Notes
The timecode value itself is read correctly in every version — the frame field
matches Catalyst exactly. Only the drop-frame flag and its separator are
affected.
We could not recover the flag from any other source in the file: ffprobe reports
the same timecode without the separator from both the tmcd track and the
container, and ExifTool exposes no timecode tag at all (including with
-ee).The information does appear to survive in the file itself, since both Catalyst
and Resolve still read it.