Michael Phillips
1
COW Coin
Forum Replies Created
-
The first thing to try is duplicating that sequence, put it into its own bin, then open that bin in a 23.976 project. When in the 23.976 project, opening that sequence in the record monitor will prompt you to do a conversion. Do so, and it will create a new sequence at 23.976 that has motion adapters on all the events (Mix and Match).
I believe it defaults to a blending mode type of motion effect which will be hit and miss quality wise compared to hardware based conversions like Snell & Wilcox, Teranex, etc.
There will also be quality differences if original sources were 29.97 progressive or interlace, or with pulldown if they originated from 23.976 sources to star with. This method gives you individual control over each event which may be helpful if there are different forms of 29.97.
If not, and it is all of the same frame rate and flavor, then do a mixdown, and repeat the steps and use the mixdown instead and see how that looks. May be easier to manage, but lose the ability to make changes.
Michael
-
OK – my findings:
1. It is an MXF OP1a file meaning all essence files are contained within the same file. This means it cannot be added to to the Avid MediaFiles folder directly as it expects the files to separate for all tracks. If you open the file with MediaInfo you will see this info as well as it being DNx 220 1080i/59.94 and its timecode.
2. File plays fine with Assimilate Scratch Play, Resolve, and Premiere Pro CC 2014.
3. It also plays in Media Composer via AMA linking using MXF AMA plug-in, but cannot be transcoded or consolidate as I am getting the same errors you are. It does create a Crash log and I will email tha tback to you to send to Avid.
4. In Resolve, I exported both new OPAtom and OPAtom 1A files. OP1a linked fine with MXF AMA and I was able to consolidate with no issues. The OPAtom files were dropped into the Avid MediaFiles MXF folder structure, and they too were able to be consolidated, transcoded with no issues.
So, I still cannot point a finger at exactly the problem lies, but I would start with Avid as all other players seem fine with the file. But this does not rule out that something is missing in the file to satisfy Avid’s spec for MXF AMA. Sending the same file to AVID should give then the same info I was able to get from a few tests. As you can see, there are slight differences between the original MXF file sent, and the same file exported from Resolve with the same MXF specs and codec/data rate. Now whether or not any one or more of these makes a difference, I don’t know, but one works, and the other doesn’t.
Michael
-
Thanks, I’ll try to get to this today and get back to you with any findings.
Michael
-
Also, assuming ther is both picture and sound with these recording, if Avid native MXF, then there would be a one file for every track in the recording, for example 1 video and a LEFT/RIGHT mono would result in 3 separate files. Is that the case here?
If you can spare a file, I can look at it. Use filemail.com for large sends to michael[at]24p[dot]com
Michael
-
hmmm… was an image visible when loaded? Seems to me there might be an issue with the way the files are being created that is not fully up to spec with either the essence, the metadata or both. Can you open and play this file in Resolve or other application?
Michael
-
Are these AMA linked clips? Native DNxHD, other? Version of MC, version of OS?
Michael
-
The waveform cache may need to be deleted and redrawn as there have been some issues reported with certain versions of the application. Not in front of a system right now to tell you where they are exactly.
Michael
-
It sounds to me as though you recorded 50Mb on the Canon so that is why you are seeing it that way. When it converted to MXF, all it is doing is a rewrapping to an MXF wrapper keeping the codec the same. That is why there is no transcode option and it should be very fast, pretty much the speed of a copy. And while it “may” be renaming the file, it may not be renaming the source name used as part of a REEL ID for conform, relink, etc. On one of those clips you did get into the system, look at these three columns in the bin; Tape, Source File, TapeID. One of them will have what is considered the file name for these relink/conform operations.
Also, 50Mb versus DNxHD36 (Mb) is close in data rate but are very different encoding techniques. DNxHD is an I frame encoding allowing for fast performance as each frame is immediately addressable in editorial. The Canon material is encoded as LongGOP which allow for low data rates with better picture quality.
So one consideration is to edit with the native files as it only takes up ~50% more storage, and depending on storage and connection infrastructure, performance may not be an issue.
I have not Canon test material myself to test with to see what the issue might be with AMA – if you are willing to share a small file, zip it and send it to me via filemail.com which allows for large sends to michael[at]24p[cot]com
Michael
-
How were they added to the project? Dropped directly into the MXF file folder inside the Avid MediaFiles folder? They may need to be accessed via the MXF AMA folder then consolidated into the project.
Michael
-
It can be easy, but one needs to know how the proxies were made for the offline – meaning the R3D file can be referenced by an embedded REEL which is only 8 characters, or is it the entire 16 characters? AMA uses the entire 16 original file name, and if a spanned file, will also include the _001 (which is stupid, but that’s the way it works).
So, look at one of the offline proxy clips and bring up both the TAPE and SOURCE FILE column and see where the R3D file name lives, and whether it is 8, 16, or more. Then we can take it from there and set up the relink options.
Michael
