I'm finding that using AMA to bring in R3d files brings them in with the numeric extension (i.e., ".001"). This breaks the ability to relink if the DNxHD files that were used for editorial were brought in with the header embedded information as the tape name (i.e., "A001_C002_1120SV"). Is there a workaround for this, or is it going to require a fix from Avid to ignore extensions in file names during "tape to file" relinks? BTW, this is something that Resolve avoids by allowing explicit tape name extraction from either the file name, the embedded tape ID, a folder name, or any combination thereof, on a per-clip basis. I do realize that Resolve is a color and conforming program and MC is an editor, but relinking via AMA is going to become a very common conforming method, and without more flexibility in generating tape names, that's going to present some issues, as it currently does with R3D files.
I brought this up during beta that the relink across SOURCE FILE and TAPE did not work with R3D spanned files when one of the processes uses REDCINE X. The _001 as MMost points out breaks the string match expected. This is something Avid needs to address either in the AMA plug-in or in the Avid AMT SDK used within REDCINE X.
That's what I thought might be the case. Actually, I generated the DNx files using Resolve, using the embedded header info for the tape name, but it yields the same result (a tape name without the _001 extension).
Surprised and pleased to hear about you going to New Orleans. Please say hi to Vinny and Bradley for me.
And yes, the issue is the same with any application using Avid's AMT for MXF wrapped DNxHD and AMA. They still deal with the source differently when it comes to RED. There is no need to track the _001 in the filename since the RED SDK handles the relationship. I suggested that the change be done in the R3D AMA plug-in with version 6 to not add the _001. We'll see what happens.
Hope you're well! I might be in LA the week of the 12th. I'll come by and say hi to the Mike(s).