When you come to play them back the fractionally different rate will drift over time relevant to a real clock, but that it doesn't change the 'whole frame' calculations you need to do. The 0.02 frames per second that are 'dropped' are irrelevant in this case as each whole frame was still recorded. If you want to find the reference from the frame that comes 01:00:00:12 after 00:00:01:12 then you add the two together and get 01:00:02:00. So, if all your material is at 23.98 and you do calculations using 24fps everything should still match up. Even using NTSC rates like 23.976 or 23.98 you can never view a 'point' of a frame, you still want to perform calculations based on whole frames. In the first instance you shouldn't need to change anything. There are two scenarios as I see it:ġ) You are comparing/calculating timecode from a single source, or from sources that are all recorded using the same timecode base.Ģ) You want to compare timecode from sources using different timecode standards OR you want to compare them to a 'real-world' clock that runs in hrs:mins:sec.dec I think it comes down to what you want to do with the timecode calculations you're making. How fast you play these frames back (at 23.976, 23.98, 24, 29.97, 30 etc) is a different question and only really becomes relevant when you want to compare your recording with other material (say a sound recording) or a clock in the real world. The recording still only consists of complete frames, there are no 'point' frames timecode only works with complete frames. The key thing to remember is that timecode is a reference on a recording for when each complete frame was recorded. I might be wrong with I'm about to say so please, anyone who knows better jump in! Obviously the variance will be very small but it's an important fraction over the duration of the Hi again, I've been thinking about this and maybe coming up with more questions than answers. Is there something fundamental in the macro that prevents decimal places in the frame rate. I've also done a version where I format the E5 cell on the set up page as a number format with 2 decimal places and that has no effect I've gone back over this all a few times to make sure I didn't make a mistake. Even when set to 2 decimal places it's still 24.00. I'm wondering if this is an excel rounding up thing rather than it not recognising the frame rate has changed? Testing it, when it's asked for number of frames in 1 second it returns 24 though. I changed the frame rate on the first page and saved and reopened as suggested before making any other changes. I'm working in a US based 23.98 frames system though. I've spent the last week trying to find a way of doing the timecode durations calculation then converting to and from total frames. Let me know if so and I'll post it up with some instructions.Īndrew this is incredible. Happy to put this on the Plugin Page but wasn't sure if it's appropriate. Once you've done the calculations you need on your spreadsheet you can export as a tab-seperated document for use in Isadora with Data Array, Timecode Comparator etc etc. We also found it useful to automate the editing of some video content we were making in Adobe CC based on in-out-duration of the shots in the same list, but that's another story. We used this primarily to populate a lot (over a thousand) timecode events in an ETC lighting desk Show Control list (using a. This means you can build formulas to easily do maths with large numbers of timecode values. (A lot of it was lifted from the work done by Allen Wyatt at Excel Ribbon). Basically, with macros enabled, two new functions are added to excel that convert a timecode value (HH:MM:SS:FF) to a total number of frames and then back again. A little while ago I built this excel sheet with functions for timecode calculations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |