Johnny Karlsson Posted June 27, 2016 Report Share Posted June 27, 2016 1 minute ago, MartinTheMixer said: If the frames are accurate, how can there be "drift" inside the camera? Because Time Code does not specify the speed of the camera, nor of any other device. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 Well, If you set the timecode in the camera, and you come back after X amount of time, and that time is no longer accurate, that would be what I would call a "drift". 1 minute ago, Johnny Karlsson said: Because Time Code does not specify the speed of the camera, nor of any other device. Don't call it time code, just call it time. Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted June 27, 2016 Report Share Posted June 27, 2016 17 minutes ago, MartinTheMixer said: Well, If you set the timecode in the camera, and you come back after X amount of time, and that time is no longer accurate, that would be what I would call a "drift" That sounds like you are comparing time code to the wall clock, correct? Unless you're running drop frame the Tc value will always differ from the wall clock. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 5 minutes ago, Wandering Ear said: That sounds like you are comparing time code to the wall clock, correct? Unless you're running drop frame the Tc value will always differ from the wall clock. That's a good response. In a real world event that did happen, I had Red Dragon that was gaining many frames in way under an hour. That was while NOT rolling. I have no idea what the drift was while it was rolling. I was afraid to look. But I hope you understand hear what the issue is. Inside any digital camera that has time code, apparently, if you rolled let's say for an hour, you could have and ending timecode that does NOT compute with how much timecode has elapsed. Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted June 27, 2016 Report Share Posted June 27, 2016 5 minutes ago, MartinTheMixer said: That's a good response. In a real world event that did happen, I had Red Dragon that was gaining many frames in way under an hour. That was while NOT rolling. I have no idea what the drift was while it was rolling. I was afraid to look. But I hope you understand hear what the issue is. Inside any digital camera that has time code, apparently, if you rolled let's say for an hour, you could have and ending timecode that does NOT compute with how much timecode has elapsed. The ending time code would compute with how much TIMECODE has elapsed, but not how much TIME has. After a 1 hour clip, you would have time code that does not equal 1 hour, because NTSC time code runs at a rate that is .1% slower than real time. At 23.98, if you roll a clip for an hour your finishing TIMECODE would be 00:59:56:09, while the wall clock has elapsed exactly 1 hour. So it sounds like you are confusing elapsed TIMECODE with elapsed TIME. What frame rate were you at when you were checking? Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 7 minutes ago, Wandering Ear said: The ending time code would compute with how much TIMECODE has elapsed, but not how much TIME has. After a 1 hour clip, you would have time code that does not equal 1 hour, because NTSC time code runs at a rate that is .1% slower than real time. At 23.98, if you roll a clip for an hour your finishing TIMECODE would be 00:59:56:09, while the wall clock has elapsed exactly 1 hour. So it sounds like you are confusing elapsed TIMECODE with elapsed TIME. What frame rate were you at when you were checking? I'm aware of everything you just typed. Is your question "What frame rate were you at when you were checking?" In relation to my statement about the Red Dragon that I mentioned above being many frames out in under an hour? Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted June 27, 2016 Report Share Posted June 27, 2016 4 hours ago, MartinTheMixer said: Phillip, Thank you. That is my point. Let's forget about code being time for a minute. Let's say the camera assigns just frame numbers 1-20000. Ok, so the camera also know it shot at 24 fps. Why is it so hard for that camera to properly assign numbers correctly? I don't think it would be all that hard for a programmer if that's all you wanted. But no one seems to want this re post, and if you did it you would end up with nonstandard files.... An NLE can tell you how many frames long a shot is, if you want to know, and I think some of the DIT apps like Shotput or Resolve might too? Quote Link to comment Share on other sites More sharing options...
Derek H Posted June 27, 2016 Report Share Posted June 27, 2016 I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed. Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second. Quote Link to comment Share on other sites More sharing options...
Tom Duffy Posted June 27, 2016 Report Share Posted June 27, 2016 14 minutes ago, Derek H said: I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed. Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second. Because the accuracy of measuring the incoming timecode signal would be no better than the accuracy of the camera free-running. If you do it once just to get the speed, how long do you measure over? - you'll need many (tens of) seconds of stable TC to get a good lock. If you can design the camera to modulate its frame rate in real time to keep up with the tiny variations as time goes on, you could get it to work, but the rest of the camera is not going to behave well... At TASCAM we designed such systems in the MMR series and X-48 recorders, because there is a niche need to lock to analogish and film systems, but the future is in (rock) stable frame rates. Also, black burst or trisync video is usually fed in as well, negating the need to rely on the LTC input's jitter. For a camera system without BB, you just create more problems. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 27, 2016 Author Report Share Posted June 27, 2016 42 minutes ago, Derek H said: I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed. Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second. Ok, we're getting somewhere. This is more like it. Quote Link to comment Share on other sites More sharing options...
Bash Posted June 27, 2016 Report Share Posted June 27, 2016 1 hour ago, MartinTheMixer said: Ok, we're getting somewhere. This is more like it. Hi Martin, puts on pedants hat. When a recorder (be it a recorder of pictures, or sound) makes a file - it puts a bunch of info in the file header. This info is referred to as metadata. In the case of audio files, the 'time' value, at the start of the file, is actually calculated from a counter that counts the samples after midnight, so, the first sample that the recorder counts, at midnight on the dot, is number 1, and the sample number about a second later is number 48001 (forty eight thousand and one), assuming you are running the recorder at 48k, ie forty eight thousand samples per second. I say the value at 'about' a second later, as the recorder runs its internal clock at 'a speed'. Its idea of a second might be slightly longer or shorter than that of any other piece of kit, or of an actual second. So - a camera might be running slightly faster than a recorder, or vice versa. If they both run for what each of them thinks is an hour, one may have recorded slightly more material than the other. If you subsequently play both back at the same speed, then one will drift with respect to the other. If the camera is running slightly faster or slower than 'actual' time, then when you play back the footage at a different rate (the difference may look tiny, like 0.001%) it will take a different amount of time to play it back than it did to record it. Video files recorded on modern cameras record their 'start frame time' by looking at the TC clock value at the start of the first frame recorded. The camera then records a load more frames (say 90000, ie 25x60x60) over the course of what 'it' believes to be an hour. In fact, if the camera is counting its hms at a different rate to the real world, then even if it is 0.001% off it will be wrong by 90 frames. To my knowledge a modern video camera does not 'record' a TC value for each frame of video. It calculates the value for each frame, using the frame value at the start, and the number of frames into the clip that you are interested in. That value may be different to the real world if the camera 'counts' seconds at a different rate to other devices around it. Say you and I each save a similar sized pizza. Say I cut mine into 10 slices and you cut yours into 8. If we each swap one slice of pizza, and try to fit the swapped slice into each others' pizzas, your pizza will now have a gap, and mine will have an overlap - the slices don't fit. If the camera and the audio recorder (or another camera, or an edit suite, or whatever device) do not run their own clocks at the same speed/rate, then they are shooting different 'sized' slices of time. Hence the whole genlock thing - genlock allows us to get all the different clocks to tick at the same rate, they all start a sample, or frame, or second, at the same time, and then they count at the same 'rate'. in this way all the seconds, frames, slices, etc.. are the same 'size', and the world turns effortlessly ;-) I hope that some of the above helps...... Simon B Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted June 28, 2016 Report Share Posted June 28, 2016 5 hours ago, Derek H said: I read somewhere recently that the Alexa mini uses the incoming timecode signal to drive it's gen clock speed. Why don't more cameras do this? Seems like an obvious solution for everyone involved.. just let the timecode source determine the length of one second. There are some devices that can use TC to drive their sample clocks, but in general it is frowned on as being not a very accurate way to go. Per several discussions here over the years, SD and Zax recorders, for instance, do not allow this, Tascam HDP2 and I believe Zoom F8 do (as do some MOTU interfaces like Traveler). It's been a handy thing for me when it was avail. I would like to see that article re the Alexa allowing its clock to be really driven by external TC--I hadn't heard about this and it would be very unusual (unprecedented) for a video camera to work this way. So far the tout on Arri video cams is that their clock is as accurate as the clock in a pro file based audio recorder, so feeding the camera genlock in addition to TC is unnecessary (in a pure non-combat sense). Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 28, 2016 Author Report Share Posted June 28, 2016 3 hours ago, Bash said: Hi Martin, puts on pedants hat. When a recorder (be it a recorder of pictures, or sound) makes a file - it puts a bunch of info in the file header. This info is referred to as metadata. In the case of audio files, the 'time' value, at the start of the file, is actually calculated from a counter that counts the samples after midnight, so, the first sample that the recorder counts, at midnight on the dot, is number 1, and the sample number about a second later is number 48001 (forty eight thousand and one), assuming you are running the recorder at 48k, ie forty eight thousand samples per second. I say the value at 'about' a second later, as the recorder runs its internal clock at 'a speed'. Its idea of a second might be slightly longer or shorter than that of any other piece of kit, or of an actual second. So - a camera might be running slightly faster than a recorder, or vice versa. If they both run for what each of them thinks is an hour, one may have recorded slightly more material than the other. If you subsequently play both back at the same speed, then one will drift with respect to the other. If the camera is running slightly faster or slower than 'actual' time, then when you play back the footage at a different rate (the difference may look tiny, like 0.001%) it will take a different amount of time to play it back than it did to record it. Video files recorded on modern cameras record their 'start frame time' by looking at the TC clock value at the start of the first frame recorded. The camera then records a load more frames (say 90000, ie 25x60x60) over the course of what 'it' believes to be an hour. In fact, if the camera is counting its hms at a different rate to the real world, then even if it is 0.001% off it will be wrong by 90 frames. To my knowledge a modern video camera does not 'record' a TC value for each frame of video. It calculates the value for each frame, using the frame value at the start, and the number of frames into the clip that you are interested in. That value may be different to the real world if the camera 'counts' seconds at a different rate to other devices around it. Say you and I each save a similar sized pizza. Say I cut mine into 10 slices and you cut yours into 8. If we each swap one slice of pizza, and try to fit the swapped slice into each others' pizzas, your pizza will now have a gap, and mine will have an overlap - the slices don't fit. If the camera and the audio recorder (or another camera, or an edit suite, or whatever device) do not run their own clocks at the same speed/rate, then they are shooting different 'sized' slices of time. Hence the whole genlock thing - genlock allows us to get all the different clocks to tick at the same rate, they all start a sample, or frame, or second, at the same time, and then they count at the same 'rate'. in this way all the seconds, frames, slices, etc.. are the same 'size', and the world turns effortlessly ;-) I hope that some of the above helps...... Simon B Simon, that was all great. I will read that a few more times after I have slept. Thank you. P.S. Not that we what you wrote is making me sleepy. Quote Link to comment Share on other sites More sharing options...
Ze Frias Posted June 28, 2016 Report Share Posted June 28, 2016 17 hours ago, T_will said: Jose, Hate to be pedantic but your 75 frames = 3 seconds, not minutes. (I'm sure you wrote in haste, let's not confuse the young'uns.) Cheers Yup. My apologies, will edit my post. Quote Link to comment Share on other sites More sharing options...
Ze Frias Posted June 28, 2016 Report Share Posted June 28, 2016 9 hours ago, MartinTheMixer said: Simon, that was all great. I will read that a few more times after I have slept. Thank you. P.S. Not that we what you wrote is making me sleepy. This (quite excellent) explanation has been given before, and similar analogies made, in this very same thread, particularly by Peter (shastapete). To break down some of the terms further: Timecode = value or "address" assigned to the file being created indicating a particular moment in time, usually the very start of the file. Drift = the difference in speed between two or more devices after a certain length of time. Genlock = a mechanism used to control the speed of two or more devices so that they run at the exact same speed, and so that there is no drift. Quote Link to comment Share on other sites More sharing options...
Nathaniel Robinson Posted June 28, 2016 Report Share Posted June 28, 2016 12 hours ago, Bash said: Video files recorded on modern cameras record their 'start frame time' by looking at the TC clock value at the start of the first frame recorded. The camera then records a load more frames (say 90000, ie 25x60x60) over the course of what 'it' believes to be an hour. In fact, if the camera is counting its hms at a different rate to the real world, then even if it is 0.001% off it will be wrong by 90 frames. Everyone keep your hats on for one more moment! Within Simon B's excellent and thorough explanation is one simple mathematical error. 90 frames out of 90,000 would be 0.1% drift (or a multiplication factor of 0.001, which is likely the mix up). Quote Link to comment Share on other sites More sharing options...
Derek H Posted June 28, 2016 Report Share Posted June 28, 2016 14 hours ago, Philip Perkins said: I would like to see that article re the Alexa allowing its clock to be really driven by external TC--I hadn't heard about this and it would be very unusual (unprecedented) for a video camera to work this way. Hi Phil, I'm bad at screenshots but download the Alexa mini user manual and read page 70. Seems to indicate that you can use LTC as a genlock signal. The mini does not have a dedicated genlock input connector. https://www.arri.com/support/downloads/?suchoption1_id=Camera/35_Format_Digital_Camera/ALEXA_Mini Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted June 28, 2016 Report Share Posted June 28, 2016 No it doesn't. I will ask my cam rental house buds about this--I'd really like to know. Thanks for the link. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 28, 2016 Author Report Share Posted June 28, 2016 8 hours ago, Jose Frias said: This (quite excellent) explanation has been given before, and similar analogies made, in this very same thread, particularly by Peter (shastapete). To break down some of the terms further: Timecode = value or "address" assigned to the file being created indicating a particular moment in time, usually the very start of the file. Drift = the difference in speed between two or more devices after a certain length of time. Genlock = a mechanism used to control the speed of two or more devices so that they run at the exact same speed, and so that there is no drift. Jose, I am ok with everything you just said, except the "drift" part. I call a device that can't maintain its own time code, drifting. What do you call that? 7 hours ago, Nathaniel Robinson said: Everyone keep your hats on for one more moment! Within Simon B's excellent and thorough explanation is one simple mathematical error. 90 frames out of 90,000 would be 0.1% drift (or a multiplication factor of 0.001, which is likely the mix up). Thanks for that. I am going to digest his message when I have time. I liked it the first time I read it. Quote Link to comment Share on other sites More sharing options...
Derek H Posted June 28, 2016 Report Share Posted June 28, 2016 1 hour ago, Philip Perkins said: No it doesn't. I will ask my cam rental house buds about this--I'd really like to know. Thanks for the link. Page 127 & 128 also elaborate on setting the Genlock source to timecode in. Maybe this means the timecode Lemo can be double duty and serve as a genlock input if you feed the Lemo tri-level signal but the way the manual reads it seems to want you to input LTC timecode to the Lemo for this option. Maybe I'll email Arri to clarify what the implications of this are. The manual also states that a hardware modification is required to use the RET/SYNC IN genlock option. I'm guessing that means if you want to use a real tri-level signal they need to modify one of the BNC connectors to be a dedicated genlock input. Quote Link to comment Share on other sites More sharing options...
al mcguire Posted June 28, 2016 Report Share Posted June 28, 2016 >I call a device that can't maintain its own time code, drifting. What do you call that?< I call it a machine doing it's own thing. I really do not know what this discussion is about, if you want the devices to stay in sync use a sync box, simple. Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 28, 2016 Author Report Share Posted June 28, 2016 5 minutes ago, al mcguire said: >I call a device that can't maintain its own time code, drifting. What do you call that?< I call it a machine doing it's own thing. I really do not know what this discussion is about, if you want the devices to stay in sync use a sync box, simple. Al, I don't think that you were here for the part. If that were the case then two devices don't match are they each doing their "own thing". If a clock is not keeping the correct time I would call that drifting. Quote Link to comment Share on other sites More sharing options...
al mcguire Posted June 28, 2016 Report Share Posted June 28, 2016 I've been here all along >Can a digital tc camera, let's pick Red Dragon, or Weapon, tc drift after the record button has been pushed and before the stop button is pushed?< No Quote Link to comment Share on other sites More sharing options...
MartinTheMixer Posted June 28, 2016 Author Report Share Posted June 28, 2016 8 minutes ago, al mcguire said: I've been here all along >Can a digital tc camera, let's pick Red Dragon, or Weapon, tc drift after the record button has been pushed and before the stop button is pushed?< No AL, your answer is that it cannot drift you just answered no correct? Quote Link to comment Share on other sites More sharing options...
Constantin Posted June 28, 2016 Report Share Posted June 28, 2016 Al, I don't think that you were here for the part. If that were the case then two devices don't match are they each doing their "own thing". If a clock is not keeping the correct time I would call that drifting. But how would you know it's drifting? If you compare to another clock, how would you know it's not the other one drifting? If you only have one clock, would the drift matter? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.