Can a digital camera tc drift WHILE rolling?

[al mcguire]

3 minutes ago, MartinTheMixer said:

Move on, ok. Sorry, I don't keep track of what I said to who. 

You could reread the 4 pages of posts, a lot of people took the time to reply to your experience.

 

Martin

>As I've mentioned before on here this is the first time ever ever "forumed"<

I just reread  the now 5 pages of posts.

I do not see any reference to what recorder you were using, what slate you were using or what  your frame rate was.

The first step in diagnosing any issue is describing the situation and what was involved

Check out some of the imdb's of folks who have replied to you and ask yourself if they might have more experience than you.

 Read their replies  carefully, you might learn something.

Al

PS: I do not know any seasoned mixers that do not have a sad  RED story to tell.

 

 

[MartinTheMixer]

20 minutes ago, al mcguire said:

You could reread the 4 pages of posts, a lot of people took the time to reply to your experience.

 

Martin

>As I've mentioned before on here this is the first time ever ever "forumed"<

I just reread  the now 5 pages of posts.

I do not see any reference to what recorder you were using, what slate you were using or what  your frame rate was.

The first step in diagnosing any issue is describing the situation and what was involved

Check out some of the imdb's of folks who have replied to you and ask yourself if they might have more experience than you.

 Read their replies  carefully, you might learn something.

Al

PS: I do not know any seasoned mixers that do not have a sad  RED story to tell.

 

 

Al, ok, it's working now. I did learn a lot. Absolutely. I'm not sure why you think I didn't. I'm not sure why the recorder that was feeding the zaxnet matters. I don't think the IFB200 knows or cares where it is getting time code from. If the ERX is getting tc , what comes before that, as far as I can tell, doesn't matter. If you think it might, you could respond. The camera was broken. Thank you.

[al mcguire]

[MartinTheMixer]

1 minute ago, al mcguire said:

Al, what am I supposed to get out of that? Gave me something to laugh at, I guess?

[al mcguire]

1) you are not the first sound person to get butt hurt by a RED

2) Lessons will be repeated until learned

3) Count your blessings that the Senator is not longer responding on jwsound

NB: you can go back to your first post and delete it, then everything that follows goes away

 

[Jeff Wexler]

To MartinTheMixer: I think you're done now. I don't think any of us want to hear you say again "the camera was broken", actually, I think there is no one here who wants to continue following any of this. Please refrain from posting in your own topic --- nothing beneficial can come from any further discussion. I do miss the Senator. 

[MartinTheMixer]

2 hours ago, Jeff Wexler said:

To MartinTheMixer: I think you're done now. I don't think any of us want to hear you say again "the camera was broken", actually, I think there is no one here who wants to continue following any of this. Please refrain from posting in your own topic --- nothing beneficial can come from any further discussion. I do miss the Senator. 

Jeff, I don't know what "posting in my own topic" means. Are you saying, after the first entry you post to start the topic, don't enter anything after that? And the camera had to be repaired. 

Thank you, Martin

P.s. I miss the senator too, I didn't have a problem with 90 percent of what he said.

[Jeff Wexler]

1 hour ago, MartinTheMixer said:

Jeff, I don't know what "posting in my own topic" means. Are you saying, after the first entry you post to start the topic, don't enter anything after that?

No, I'm just saying this particular topic has run it's course...  no more posts or comments needed. Done.

[Philip Perkins]

11 hours ago, Storyhub said:

I have done 3 features with multiple REDs on set. I simply send guide track to all the cameras via wireless. The camera audio is used to sync the multiple cameras. One camera audio is then used to sync the multiple tracks of audio from the recorder (manual mode) or just use pluraleyes to auto sync everything. Never had any picture or audio sync issues. Never used or needed to use TC or a TC slate because the guide track is more accurate than timecode since both are sampling at 48,000 times per sec and there internal clocks are very accurate. I have done 2 hour events (continuous record on cameras and recorder) without any issues. TC was invented for a system that uses a time base corrector that generates a master TC which then sends that TC to the camera (gen lock) to permit switching cameras (it is no longer required in switches because of other techniques). The cameras then sync to the master and all cameras snap a frame at exactly the same time so switching doesn't occur in the middle of a frame. WIthout gen lock TC running from the internal clock on each camera will be off by design.

 

Hi--a little clarity re this post:  1: audio scratch is not "more accurate" than TC, they are apples and oranges.  TC is necessary for all of the record keeping and conforming processes that need to happen in the audio post of your films.  You not taking care of this business re having the same TC on audio and cameras just means more work for someone else down the line.  It all comes out right in the end, but isn't as efficient a way of working. 2: "TC was invented for a system with a master clock....permit switching...(it is no longer required in switches because of other techniques.)"   You are confusing TC with genlock.  They are not the same thing, at all.  The cameras can use the ext TC to label the start frame of their recording, but the recordings they make are on their own internal sample clock unless they get external genlock signal.  In general I've found that real live-video switched projects DO require genlock to the cameras to avoid H-shift at switchpoints.  What are the techniques you mention to avoid this?   3: I've done a great many event and concert shoots with flocks of (non-switched) wildly disparate cameras with no shared sync ref of any kind anywhere.  They worked out because a lot of effort was put in in post to MAKE the sync work out.  PluralEyes etc can be deployed, but the results of using it are far from perfect and have to be eye-checked.  If you start multiple cameras of any type, especially REDs, together, on a slate, they will very quickly walk away from each other syncwise w/o genlock.  By this I mean that if you lined the recordings of the cameras up to the slate or start mark in an NLE, you could watch them fall out of dead sync with each other over a period of time.  In this regard the TC is irrelevant--it's just a label for the start frame of each camera's recording, easily used by a computer.  What matters is what the real record speed of each camera was, and how great the differences in record speed were between the cameras (and audio).  Again, for short takes or if the time and effort to eye-sync all the material is built into the workflow, then fine.  My pref is to start from a point where everything is in correct sync to start with, inasmuch as that's possible, and proceed from there in the knowledge that the basic sync was solid, not the results of an eye-sync or PluralEyes guess.

[Marc Wielage]

On 6/30/2016 at 7:47 AM, ProSound said:

I just did a RED Weapon shoot this week and we still had issues with the camera like all RED products. Had to reset the camera to get it to take timecode lock even though all the setting were correct. The AC and I both commented that a "RED will always be a RED" 

Yikes. So much for the theory that things are better...

Although: the Panavision DXL is said to be a different animal. We'll know for sure when it goes wide in January 2017...

And yes/yes/yes to everything Phil says above. Same experience here. Cameras will sometimes drift slightly, and it's post's job to compensate for that. Crap happens -- you fix it and move on. If it's wildly out of sync and drifting badly, that's a different story. The usual "1 or 2 frames every so often" is understandable.