Michael Phillips
1
COW Coin
Forum Replies Created
-
Just make sure the camera doesn’t start counting over again for filenames. Some do when removing battery and such – so make sure that is part of the production to postproduction procedures and you should be fine.
The “time of creation date” does get converted to a time of day timecode and can be found in the Auxiliary TC1 column. I do find that useful when working with a director and you get the “I’m sure we shot something on Tuesday after lunch” and you can use that to narrow down the range.
It’s sort of a decision you need to make before editing – insert the timecode as a real value with QTChange or go with 00:00:00:00 and make sure that filenames are unique (well this should always be the case, but even more so when timecodes are all the same). This ensures that any third party application will respond to the clip the same way – such as in an Resolve conform.
Michael
-
It seems that the .thm file is the reference frame used by cameras and applications to give a thumbmail view of the video clip and is the first frame of the video clip:
https://www.digicamhelp.com/glossary/thm-files/QTChange by VideoToolShed can take the creation date from the file and insert it into the .mov file to give it a real and permanent timecode rather than the default 00:00:00:00.
Michael
-
Just got it – I see that it is is a Apple HDV codec at 1080p/25. Does that sound correct? Is this the original camera file, or has it been transcoded somewhere along the way?
Michael
-
Very strange – nothing comes to mind that would solve this other than a workaround to export out as QT wrapped DNxHD from those other programs.
Can you send a small clip with the problem to me? I can look a few different things on my system just in case. Use wetransfer or yousendit.. to michael(at)24p(dot)com
Michael
-
Very strange – do those clips open in another application with no issues?
Michael
-
Does it decode the same way when in a 1080p/24 (24.000) project?
Michael
-
I love Resolve and all it can do, and this is a natural progression for it to go in to reduce the number of steps and such with round-tripping for color correction only. But it is very early on to call it an editor and Erik nailed it with being a conform editing system which is the same way I use smoke today. Depending on the program type, this may or may not fit the needs of the program itself – but it is a great first step in that direction.
Michael
-
If you’re only looking to use it to capture non digital sources, then any of the cards will do – most editors with third party cards tend to grumble more on the performance of the cards while editing, scrubbing, and such not being as fluid as Avid hardware – and there are a few missing features such as audio punch-in, universal mastering and such that may or may not matter to you.
Michael
-
I have recently worked in a 720p/59.94 project and the audio would import, but the timecode would stop counting halfway through the clip. The fact that the OMFI cannot import in either a p50 or p25 leads me to believe there is an issue with the OMF itself, can you try a good old PAL 25i and see if it works there? Can production create a BWF instead and try that?
Michael
-
Unless you write the timecode into the .mov file with QTchange, I would suggest you leave it as 00:00:00:00 as that is what is in the file – the camera does not write timecode into the file (unless Mark III). As long as the filename stays unique, then it is not an issue – I did a DI conform with over 200 .mov VFX files that were all 00:00:00:00 in Resolve with no issues since the filename was unique.
And speaking of Resolve, if you do go back to to the camera originals for a conform and do not write the timecode into the file, then it will use 00:00:00:00.
Michael