Add clip metadata manifest fields

[IAmVigneswaran]

@samplue Sam Pluemacher suggest -

The CSV includes the clip name, but I would love to see the "Reel" information as well. For me the Reel information is even more important than the clip name.

@orchetect Can we add "Reel" "Scene" & "Take" columns as well? This enhancement links and circles back to #36 & #7

We would now have Clip Name, Clip Source Filename, Reel, Scene & Take columns.

Clip Name = It would be name of Multicam, Synchronize clips or Compound within FCP.

I believe it can get rather complex when we have Multicam, Synchronize clips or Compound. If a marker is placed on a Multicam clip, we can print the name of the Multicam clip for the Clip Name column and extract the metadata of that Multicam clip for Reel, Scene & Take information associate with these type of special clips.

Maybe there is some logic where if clips are Multicam, Synchronize clips or Compound types, Clip Source Filename columns would be empty or print it as Skipped or Not Parsed? With Multicam, Synchronize clips or Compound types, there can be umpteen number of source clips nested deep in these types. It may not make sense to print Source Filenames for Multicam, Synchronize clips or Compound types.

[samplue]

An option to include Start Source Timecode and End Source Timecode as well as Media Duration for the clips would be a nice & welcome addition.

[orchetect]

Clip In and Clip Out Timecode as well as Clip Type should be easy to do.

However I ran into a funny issue when investigating the clip and camera metadata.

Final Cut Pro only seems to export this data for clips that use actual video assets. It doesn't export it for things like Titles or Clouds generator (even though it allows you to enter text for its Reel, Scene, Take, Camera Angle, and Camera Name).

I suppose that doesn't matter that much since users probably only care about this metadata for actual video clips any how.

[IAmVigneswaran]

I suppose that doesn't matter that much since users probably only care about this metadata for actual video clips any how.

Yes. It should not matter for those Titles. Motion Templates and Generators. Those fields can be empty in our csv file for these assets/Clip Type.

[orchetect]

I just realized that for the same reason why we should remove Clip Filename (#65) from the output manifest, Media Duration is not a viable field. As you mention in the original post of this thread, sync clips, compound clips, and multicam clips can contain more than one clip of different lengths and reference more than one media file. In those cases it would be ambiguous what data should populate the field and may end up being half-useful at best and confusing at worst.

Clip Duration is viable however, and is already a part of the output manifest.

[IAmVigneswaran]

Noted!

[IAmVigneswaran]

Hopefully in subsequent build, we can add, Reel, Scene, Take, Clip In and Clip Out fields.

[orchetect]

Just to be clear, for our purposes, Clip In and Clip Out timecodes will be absolute timecodes (based on main project timeline) and not the local media's timeline.

[IAmVigneswaran]

Just to be clear, for our purposes, Clip In and Clip Out timecodes will be absolute timecodes (based on main project timeline) and not the local media's timeline.

I believe that is what the users might be expecting. Clip In and Clip Out values based on the range used from the main project timeline.

[orchetect]

Yes, but I only mention it because within Final Cut Pro's clip inspector, clip start and end timecodes are shown in relation to the its own media's timeline, as it can have its own arbitrary start timecode and frame rate even. It of course makes more sense for us to use the main (absolute) timeline context.

[IAmVigneswaran]

To bring awareness to the user, I can add a small column info (i) to both Clip In and Clip Out.

[orchetect]

Probably not necessary, since absolute timecode is intuitively obvious in our case. But you could add something to the wiki docs for MarkersExtractor and Marker Data that clarifies this if you want.

[orchetect]

It took most of today to build out the metadata parser but it's mostly done. With any luck, populating the fields should be fairly straightforward. I'll try to get it implemented in the next day or so.

[IAmVigneswaran]

Thank you! 🙏

[orchetect]

Side note: when new fields are implemented, they automatically become available as thumbnail image --label burn-in options.

[orchetect]

Ok - now implemented, and seems to be working as expected in my limited testing. Will be in 0.3.6.

FCP project:

Manifest output:

[orchetect]

@IAmVigneswaran new alpha build for testing:

https://github.com/TheAcharya/MarkersExtractor/releases/tag/0.3.6-alpha3

[IAmVigneswaran]

Thanks for the test build!

Just tested using Sam's sample project; seems to extract all the desired metadata.

@samplue do test it out at your end with any of your more complex projects. Thanks.

[samplue]

Thanks a lot, it's working on one of the more complex timelines! What I've noticed though, is that it will not extract the Reel information for Multicam clips. That would be important for me. It should read the active MC angle data and not the MC container information. Here's the .csv and fcpxml for further inspection.

Generally speaking: it should always use the source media clip timecode and not the container timecodes. Or at least make this optional.

BRS_LOCKED6_20210521 - 01 Opening Scene.csv BRS_LOCKED6_20210521 - 01 Opening Scene_00000000.fcpxmld.zip

[IAmVigneswaran]

@orchetect Would it be possible or does it makes sense to have --use-active-multicam-metadata?

When enabled, it would use the metadata from Multicam's active angle.

[orchetect]

It makes more sense just to use angle metadata as default behavior. Grabbing metadata from the multicam container wasn't intentional, it's just the first round of naive parsing that needs to be improved.

There may be other clip types that need tweaks, I only tested basic clips. Especially check ref-clips, sync-clips and audition clips as well.

[orchetect]

I believe the best approach is to first grab the angle's media metadata, then grab the angle's metadata and overlay it on the container's, replacing the container's keys with the angle's metadata if there are any duplicate keys. From my observations, it's rare (if not impossible) to have the same metadata key in both places, but I would take this approach in any event.

In the XML, the angle tends to contain the reel, scene, and shot (take):

<mc-angle name="A" angleID="+L5xmXXnRXOGdjFq1Eo7EQ">
    <gap name="Gap" offset="0s" start="86400314/24000s" duration="90090/24000s"/>
    <asset-clip ref="r3" offset="90090/24000s" name="Cam 1" duration="5801796/24000s" tcFormat="NDF" audioRole="dialogue">
        <adjust-colorConform enabled="1" autoOrManual="manual" conformType="conformNone" peakNitsOfPQSource="1000" peakNitsOfSDRToPQSource="203"/>
        <marker start="233233/8000s" duration="1001/24000s" value="Marker in Multicam Clip on Angle A"/>
        <metadata>
            <md key="com.apple.proapps.studio.reel" value="Cam 1 Reel"/>
            <md key="com.apple.proapps.studio.scene" value="Cam 1 Scene"/>
            <md key="com.apple.proapps.studio.shot" value="Cam 1 Take"/>
            <md key="com.apple.proapps.studio.angle" value="A"/>
        </metadata>
    </asset-clip>
</mc-angle>

The angle's media tends to contain the camera information like cameraName, cameraISO, etc.:

<asset id="r3" name="Cam 1" uid="1EA25267F6D3D42BB06493C883B080F2" start="0s" duration="21756735/90000s" hasVideo="1" format="r1" hasAudio="1" videoSources="1" audioSources="1" audioChannels="2" audioRate="48000">
    <media-rep kind="original-media" sig="1EA25267F6D3D42BB06493C883B080F2" src="file:///Users/user/Movies/Cam%201.mp4"/>
    <metadata>
        <md key="com.apple.proapps.mio.cameraName" value="Cam 1 Camera Name"/>
        <md key="com.apple.proapps.studio.rawToLogConversion" value="0"/>
        <md key="com.apple.proapps.studio.cameraISO" value="0"/>
        <md key="com.apple.proapps.studio.cameraColorTemperature" value="0"/>
        <md key="com.apple.proapps.mio.ingestDate" value="2022-09-13 17:57:22 -0700"/>
    </metadata>
</asset>

[IAmVigneswaran]

We don't need the camera information like cameraName, cameraISO. Those seems a little excessive and not entirely pertains to editorial.

[orchetect]

I'm not adding them, this is for my own reference.

The parser is gathering all known metadata and filtering out the ones it needs.

[orchetect]

Ok multicam metadata is now fixed. Will be in next build.

Still need to test other complex clip types which I think will also require special handling.

• [x] mc-clip fixed
• [x] sync-clip fixed
• [x] ref-clip fixed
• [x] audition is confirmed working as expected
• [x] asset-clip is confirmed working as expected
• [x] title FCP never exports metadata for titles AFAIK

[orchetect]

Generally speaking: it should always use the source media clip timecode and not the container timecodes. Or at least make this optional.

@samplue do you mind clarifying this?

[orchetect]

New alpha for testing:

https://github.com/TheAcharya/MarkersExtractor/releases/tag/0.3.6-alpha5

[samplue]

Generally speaking: it should always use the source media clip timecode and not the container timecodes. Or at least make this optional.

@samplue do you mind clarifying this?

Please ignore that comment, I was mixing this up with something else.

Regarding alpha5, happy to confirm this will now correctly pull the Reel, Scene, etc metadata for Multicam clips on my complex test timeline.

[IAmVigneswaran]

I think we can safely release 0.3.6.