Timecode and tapeless workflow?

[Dominique Grenier]

There's something I've been wondering for some time now.

How will TC work with a camera like RED ? I mean, on tape based workflows, the tape has one continuous TC that span across the entire tape, you then make clips out of this long recording based on takes and their respective TC. Right?

Now, I've never worked with tapeless workflow so far, but to my understanding each seperate take (or each time you start/stop recording) is also a seperate file on the disk. So, where does TC fit into this? Does each clip have its own independant TC, or each clip is just a part of a longer TC, just like with tape? But then, what's its purpose, since you can't go back and recapture, you just go into your backup and drag the corresponding file? No?

Thank for enlighting me on this!

[Nick Shaw]

If RED works like other non tape based systems, each clip has timecode which starts where the last clip finished (unless you are using free running time of day code). That way if you put a sequence of clips together on a timeline in the order they were shot, you get continuous timecode.

Timecode is still needed for offline/online workflows, as it would be used to create a Red Pull List to send to REDCINE.

This if of course all just my own assumptions.

[Stuart English]

Good assumptions Nick.

Enbedded in the metadata are two timecodes, one is a continous timecode that spans across clips - esentially the same as RUN RECORD mode on a tape based recording system, the other is an internal or external clock TIME OF DAY timecode.

These values are stored in each and every frame of REDCODE RAW or RGB video, so you can choose either one as the basis of the timecode to use throughout the editing process.

[Nick Shaw]

Twin timecode - nice idea, but I expect nothing less from RED! Will you be able to access them both in FCP as main and auxilliary timecode?

Brings together the usefulness of both continuous and time of day timecode. I know DV also has time and date info stored in the meta data, but as far as I know there is no way to see that meta data in FCP. It would be great if RED media did not have that limitation, and just used two standard timecode tracks in the reference Quicktime movies.

[Michael Hastings]

Stewart anywaay to make it easy to put in GPS metadata, maybe use GPS time also to update the clock?


Good assumptions Nick.

Enbedded in the metadata are two timecodes, one is a continous timecode that spans across clips - esentially the same as RUN RECORD mode on a tape based recording system, the other is an internal or external clock TIME OF DAY timecode.

These values are stored in each and every frame of REDCODE RAW or RGB video, so you can choose either one as the basis of the timecode to use throughout the editing process.

[Keith Nealy]

Very Nice Stuart, thank you.

Are there user bits as well?

[Jesse Wendel]

Enbedded in the metadata are two timecodes, one is a continous timecode that spans across clips - esentially the same as RUN RECORD mode on a tape based recording system, the other is an internal or external clock TIME OF DAY timecode.

I seem to remember reading that the camera does NOT have an IP address. Hmmm. I'm a senior IT guy by profession, currently working to sync up roughly 100K devices to NTP - the Network Time Protocol. So my first question is, can we sync the RED on-board clock to NTP and if not, how about it? I can think of some things I want to shoot which I'd like to be synced to truly accurate time.

On a closely related issue, the more I read, the happier I'd be to see RED be reachable by IP. How else can we write programs ourself? Give people an IP address, several GB of memory to run in, access to the OS whatever it is, and a 4GB flash memory to story data, and you've got something people can hack in a major way. I'm sure if my memory serves me correctly and there isn't a reachable IP, that this has been discussed at length and there are good and valid reasons against this, especially this late in the game. And y'all are about as open and friendly as any developers I've ever seen. Which is why I hope you reconsider and provide access to the inside of the box so people can build on what you've done. I'm sure it could be done in a way which still walls off your proprietary code safely, but allows for a workspace for people to run programs, work with the data and do stuff prior to it leaving the camera.

For example, I'd like to run a program which encrypts everything before it is written to memory. It's unlikely you're going to ever add that as an option. But I want it. I want to be able to shoot stuff that is fully encrypted before frame one gets written out to storage. That requires doing something to the data-flow in-camera. Probably not a big-deal. But without access to inside the box, I can't know. *smiles again*

There will be thousands of possible hacks such as this, many of them quite good. Which is why I make the case that an IP, accesss to the CPU memory, and say 4GB of flash memory for local storage, would provide amazing creativity, consistent with the community developed here. Again, I believe it would be possible to wall off the core code; you don't have to give root access to us; just sufficient access we can write and run stuff. The crown jewels could be on a separate partition; there are many ways to protect them in addition to passwords. A good unix (assuming a unix) hacker can show you. If you are interested.

Best always,
Jesse Wendel/Seattle

[Stuart English]

If there are User Bits associated with an External Timecode feed, we can record that, but many of the traditional uses of that timecode element - such as reel number, camera I.D, date - plus new items such as project, copyright owner, director, producer, DoP, Editor, etc can be stored as "Slate" metadata.

[Keith Nealy]

That's great Stuart, thanks.

"Userbits... and so much more."

"timecode and data and reels... Oh My!"

(Ok...Back to storybook with my 10 year old)

[Pete Horvath]

How does that slate metadata get entered into the camera?

Pete

[GlennChan]

I seem to remember reading that the camera does NOT have an IP address. Hmmm. I'm a senior IT guy by profession, currently working to sync up roughly 100K devices to NTP - the Network Time Protocol. So my first question is, can we sync the RED on-board clock to NTP and if not, how about it? I can think of some things I want to shoot which I'd like to be synced to truly accurate time.
Possible solution/workaround...
You should be able to jam-sync all the cameras to the same clock... i.e. such as the Ambient Lockit boxes (though after 12 hours the sync might slip a frame, as with any of these boxes; it's better than the camera).

2- If you need to sync with NTP time, then get a laptop showing NTP time and show it with all your cameras. Then run off and shoot whatever it is you need to shoot.

3- Btw, is NTP frame accurate? (After network lag/latency.)

[Cail Young]

3- Btw, is NTP frame accurate? (After network lag/latency.)

My understanding is that NTP is subframe accurate - in the milliseconds.

[Jesse Wendel]

Btw, is NTP frame accurate? (After network lag/latency.)NTP at Stratum 1 level assuming no major temperature fluctuations can be expected to get down under 100 nanoseconds.

For field use, I would expect to operate at roughly millisecond accuracy or perhaps a touch better. I don't know what OS RED runs, but any modern Unix/Linux either has NTPv4 built into the core OS or can have it added, including the part which disciplines the clock frequency which is the part which gives such accurate times. If the clock inside the RED camera body is fairly decent, and the RED computer runs NTPv4, one wouldn't need to hit http://www.pool.ntp.org/ timeservers all that often, or other timeservers; say once a day, or even less once the clocks are truly dialed in. That would give very precise timing on the cameras independent of anything else.

Again, this is truly not a big deal, assuming IP access to the OS.

Now, if RED simply doesn't provide IP access to the system, then it's obviously much harder and we have to try and jam backwards using timecode which I don't know how accurate it is, what its timesource is, or how that works. As I said, my background is IT, so I like solving well-known IT problems -- providing accurate time -- with well-known IT solutions; run NTP. *grins*

Again, obviously this issue as a whole has no doubt been considered by the RED Team. I'm just hoping that if their prior answer was no, they'll reconsider. If not in time for the initial release, then in the months that follow. Not just with a SDK alone, but with IP access as well as all but root access to the OS, storage, datastream, and so on. We should be able to play with this and make it do what WE want, without going on Staff at RED. *laughs*

People as smart as they are at RED, know how to partition off the Crown Jewels and give access to everything else, of this much I am certain. *smiles*

Jesse Wendel/Seattle

[Jonathan L. Bowen]

I get really annoyed by timecode problems that arise when capturing footage, especially when you took extra care never to rewind or mess with the footage you were shooting. You just stopped the camera, then pushed record when you were ready again. Thank god for "Warn After Capture," lol.

[Nick Shaw]

Most timecode problems occur due to regen issues with tape. The DV reset to zero problem, the Digi Beta 790 problem (timecode slips by a couple of frames if you change a battery or review a take). None of this should be an issue with a data centric workflow. And thank god for that indeed.

[Steve Sherrick]

Jesse's posts point to a very interesting shift in the industry, an IT-centric post production workflow. It's a very interesting time for sure!

Steve

[GlennChan]

NTP at Stratum 1 level assuming no major temperature fluctuations can be expected to get down under 100 nanoseconds.

For field use, I would expect to operate at roughly millisecond accuracy or perhaps a touch better. I don't know what OS RED runs, but any modern Unix/Linux either has NTPv4 built into the core OS or can have it added, including the part which disciplines the clock frequency which is the part which gives such accurate times. If the clock inside the RED camera body is fairly decent, and the RED computer runs NTPv4, one wouldn't need to hit http://www.pool.ntp.org/ timeservers all that often, or other timeservers; say once a day, or even less once the clocks are truly dialed in. That would give very precise timing on the cameras independent of anything else.

Jesse, isn't NTP limited by your network latency? According to Wikipedia: NTPv4 can usually maintain time to within 10 milliseconds (1/100 s) over the public Internet.

2- In the field, you may have an inadequate or no Internet connection.

3- I doubt that the Red camera's clock will maintain frame accuracy through a day. The clocks on devices like the Lockit boxes are presumably better.

4- For getting double system sound to sync with cameras, the Lockit/Denecke boxes are what people use now. Possibly their biggest shortcoming is that the process is not idiot-proof and that they need to be re-jammed every once in a while (preferably every meal break). When people do dailies, sometimes they find that the audio is out of sync. And the clapper is not always in frame. They spend a fair bit of time checking sync and fixing audio sync problems.

Probably a better solution for Red is:
A- Unlike film cameras, Red can record sound too. So record timecode on the 3/4th audio track.
B- Somehow open up Redcine so that it facilitates audio sync. Automatically sync to .bwf files based on timecode, and let the user scrub through footage to check sync (audio waveforms would help) to check and fix sync. And read timecode off the 3/4th audio channel and see if that matches the timecode in on the camera.

So there's four ways of getting frame-accurate sync, and this should be fairly painless + idiot-safe:
A- Use an external timecode+genlock box. Frame accurate if you don't screw it up.
B- Also record timecode on one of the audio tracks. It works as long as your wireless doesn't screw up or run out of batteries.
C- Now if both of the above fail, then you can use a clapper. This should make it really easy to check and fix sync, esp. in a data-based environment where you don't have to wait on tape shuttling.
D- Record sound onto the camera.
E- Now if you managed to screw all three of the above up, it's still not so bad to manually sync up audio. Find a part where someone says a b or p word. When their lips are closed, the audio waveform will go null... so you just match that up. (And apparently documentary filmmakers shooting on film used to have to do this... manually sync sound without the benefit of a slate.)

The CML has discussion on this:
http://www.cinematography.net/Pages%20DW/F900Genlock.htm

[Jesse Wendel]

Isn't NTP limited by your network latency? According to Wikipedia: NTPv4 can usually maintain time to within 10 milliseconds (1/100 s) over the public Internet.

2- In the field, you may have an inadequate or no Internet connection.

3- I doubt that the Red camera's clock will maintain frame accuracy through a day. The clocks on devices like the Lockit boxes are presumably better.

4- For getting double system sound to sync with cameras, the Lockit/Denecke boxes are what people use now. Possibly their biggest shortcoming is that the process is not idiot-proof and that they need to be re-jammed every once in a while (preferably every meal break). When people do dailies, sometimes they find that the audio is out of sync. And the clapper is not always in frame. They spend a fair bit of time checking sync and fixing audio sync problems.

Wikipedia is wrong. Network latency is considered as part of the discipline of NTP. Along with much else, from how the CPU ticks, to the differences between managing time off the CPU while powered up vs the on-board clock that keeps time during a powered off state vs receiving time hacks from everything from GPS feeds to internet clocks and how to tell the difference from a truechimer and a falseticker. This and much more is part of the NTP discipline. When running on say a FreeBSD which has the ability to discipline the CPU clock, one can and will routinely get millisecond accuracy. That's on a device picking up timehacks not connected directly to a reference clock itself, just grabbing them from the internet.

So...

If RED is based on a Unix -- big presumption on my part -- then in short, we have a Unix computer. It then has the capacity to run NTP whenever it's turned on. If it has an IP address -- as I recall, the answer to that is no, for some reason I found a little silly at the time, having to do with protecting the Crown Jewels basically, which I believe could be worked around, especially with the level of talent the RED Team has -- then it goes out to pool.ntp.org and grabs time. Part of grabbing time is noting how long the latency is. This will change, but that's part of what NTP keeps track of.

Assuming the CPU isn't junk, and I can't imagine it is, and assuming the on-board clock which keeps time while the camera/computer is turned off isn't junk, and that's more of an open question, then it should be possible to keep time using NTP to about 1 millisecond ongoingly, if the camera is being used daily for shooting, and one plugs it in at night to recharge, including to the internet to grab correct time.

If one doesn't, well, then that's on the shooter. And I'm making assumptions throughout about what is possible and the design of RED's internals, and also about what RED might open up.

Going back up to the quote and expanding on it a bit, there are two clocks which NTP is concerned with on a computer. The one it is least concerned with is the one which runs while the computer is off. That clock is typically not very good, and we don't care about it much. The clock we do care about is the CPU clock. This clock, especially on modern CPU's can split time down to at least millisecond time, but NTP can discipline this clock adjusting both its frequency and its timing, its jitter and its latency, such that it is accurate -- assuming a sufficiently accurate reference clock, such as a GPS receiver of the correct type or a radio receiver tuned into the NIST broadcast at 60mHz in the United States lower 48 (we call these Stratum 1 reference clocks) -- down to under 100 nanoseconds assuming no major temperature variations.

Now, would the RED computer clock handle this? No, I doubt it. Why? Not because it couldn't. But because a) it isn't hooked up to a reference clock. b) it isn't hooked up to a timeserver via the internet all the time, although one presumes during a shoot the shooters would hook it up at night. c) I've talked about the different clocks and presumably the two clocks in RED, the CPU would be good and the battery-back-up clock would be at least adequate. Then part of the practice of going out into the field would be to grab a timehack from the internet, so you're at least fairly close to accurate, and if you let it sync to a timeserver overnight, or just leave your RED on your network for a day or so before shooting, then you're going to have very accurate time.

In fact, there's no reason at all, regardless of if we're given access to the box or not, that RED can't be given the ability to at least grab a DHCP address or be assigned an IP address, and for internally the RED Team to set NTPv4 to look at pool.ntp.org for time. And for one of our menu options to be to set a time zone. That way we have correct time always on the box, and there you go.

Again, my fuller claim here is not about NTP although as I said I have stuff I want deadly accurate time for. My fuller claim is, open up the box please so anyone can add on whatever we want how we want to.

Many people perhaps won't want to. But those of us whom know how to work inside, let us. Worst case, we reload the firmware from the original DVD or flashdrive, and start over again. But in the meantime, we can be creative and try stuff which could build on top of the creativity already there.

Going back to NTP. If people are having the trouble keeping accurate frame/audio synch which is being pointed to in the quote, then having absolutely accurate time would seem at least to me, to be one way of getting around that. As I said, I'm an IT guy, not a camera/audio guy, so I don't know if what I'm saying makes sense within the film/video world. But I am sure about what I said about keeping time, assuming my assumptions about the box are correct. And if one has accurate time all day long, then I would guess one could make the frame and audio stay connected as well. *shrugs*

As I said, I'm a raw amateur at this, not having shot anything since the late 80's when I did a lot of live event shooting in the Bay Area and nothing since. I'm now coming at this strictly from the IT side. There may be 20 different reasons why no one has ever done what I'm suggesting. It just makes sense to me -- synch time, then synch everything else to the time. That's how we do things in IT. I just don't see why it wouldn't work if in fact RED is, if you look at it that way, a fast Unix computer. *smiles*

Finally, for people who actually care about NTP -- I realize now we are wandering far, far afield -- in my view and many others, the best deep (you've been warned) book on NTP is by Professor David Mills, NTP's co-inventor: Computer Network Time Synchronization: The Network Time Protocol (http://www.amazon.com/Computer-Network-Time-Synchronization-Protocol/dp/0849358051/ref=pd_bbs_sr_1/104-0789476-7777528?ie=UTF8&s=books&qid=1180314318&sr=8-1). And the NTP Support Web (http://ntp.isc.org/bin/view/Support/WebHome) has the actual "how to" on getting going with NTP, as it is the documentation portion of the NTP official web site (http://www.ntp.org/).

Jesse Wendel/Seattle

[Mark L. Pederson]

Jesse's posts point to a very interesting shift in the industry, an IT-centric post production workflow. It's a very interesting time for sure!

Steve
Meta-data centric - pre, production, post production and delivery workflows coming soon.

[GlennChan]

Going back to NTP. If people are having the trouble keeping accurate frame/audio synch which is being pointed to in the quote, then having absolutely accurate time would seem at least to me, to be one way of getting around that.
I think that the problem has to do with reference clocks slowly drifting out of sync with each other (between all your video sources and your separate audio recorder). The clocks on the sync boxes can hold sync within a frame for 24 hours... though if there's temperature changes, you should re-jam all the clocks more often (i.e. every meal break). You also need to re-jam if the batteries die (or start dying?). Which happens a lot faster if you are shooting in really cold places.

It doesn't seem like NTP would solve this?? A sync box that compared itself to stratum or GPS might (and it could have a big flashing light that indicated to you that you need to re-jam everything). I think the Ambient master clock can sync to GPS time; the Lockit boxes can jam to the master clock, but they use their internal clock as a reference.


Wikipedia is wrong.
Hehe it wouldn't be the first time.

[Jesse Wendel]

I think that the problem has to do with reference clocks slowly drifting out of sync with each other.That's the whole point of NTP.

If you've running NTPv4 on the camera, you leave it running and let it get a good baseline read so it dials in cleanly based on the CPU, not the battery-clock while the camera is off, which is typically not very accurate at all, then you're going to have millisecond accuracy.

RED doesn't shoot at that frame rate. Doesn't even come close. Even if it slips a little during the day, you're still fine. But so long as the camera is left on, the CPU should maintain that tick as a predictable rate of slippage, along with any other RED's on set, thus instead of trying to run around jamming this that and the other thing as batteries run low or stuff gets out of synch, everything keeps going back to a steady reliably time-source, NTP.

My smaller point is -- related to the point I'm making over in the SDK thread -- these issues are solved in the IT world. I freely admit my beginner status in the film/video world. None the less, with the convergence of these worlds occurring of which RED is leading the way, unless there is a compelling reason to do otherwise -- for example, a) there really will be too much slippage during a long shoot, b) RED is solidly committed to a closed instead of an open design, or c) adding an additional menu item to give time zone access is simply too much of a pain this late in the game; perhaps later, and so on and so on -- it seems to me that RED should welcome using well-known IT solutions instead of settling for the same old tired film solutions.

I mean, what is this silliness? Do people truly run around during a shoot and, what is the word, jam time to every camera, every sound device, every time slate so all is in sync? With all due respect to the traditional way of doing things, what a truly fxxxxd up way of doing things. Seriously. Time should always be there, always be accurate, and be transparent to the devices. And if it isn't, it's because that's a we've always done it this way, not because there isn't a better way to do it. As an IT pro, that offends me.

NTP is that better way, and RED should be leading the way, not doing the same old thing.

Now, having said that, I wish to be very clear yet again and then yet again and again, I know IT, not film, not video, and sure as hell not the inside of RED, how things work on a film set, and so on. The RED Team may have as I've said, many good reasons for doing things the way they've always been done. If so, power to them. It's only if we're doing it this way because it's the way it's always been done, well, see above please.

There was an entire bit below this, that made the top part not so forceful, you see. I don't want this to seem as if I'm telling RED what they should do on a specific technical part; I am not. I'm suggesting an approach, where known solutions from IT be mixed with known solutions from the film world, and may the best solution win, everything considered.

Jesse Wendel/Seattle

[Everything below here moved to the SDK thread; original post above added to in order to make what remained not as forceful as it became once the bottom 2/3rds was moved -- Jesse]

[Jiri Bakala]

I'd rather RED to be Apple. Far less crashes!

Besides, digital cinematography is and will always remain a niche market. Even 10,000+ cameras sold is still a niche and highly specilized market.

[Jesse Wendel]

Gang --

Apologies... I was clearly in the wrong thread. The conversation above about Open Systems clearly belongs in the SDK thread, so I'm going to cut it out and post it over there.

Bakalaj's post immediately above isn't going to make sense any more because of this. My bad, but it's best to have everything in the correct place.

jwe/sea

[Cail Young]

I mean, what is this silliness? Do people truly run around during a shoot and, what is the word, jam time to every camera, every sound device, every time slate so all is in sync? With all due respect to the traditional way of doing things, what a truly fxxxxd up way of doing things. Seriously. Time should always be there, always be accurate, and be transparent to the devices. And if it isn't, it's because that's a we've always done it this way, not because there isn't a better way to do it. As an IT pro, that offends me.

NTP is that better way, and RED should be leading the way, not doing the same old thing.

NTP synchronises clocks, but if those clocks are seperated, it can't keep them in sync; which is exactly the issue at hand.

A DAT recorder, for example, can have 2,000 samples to choose from every (1/24 second) frame to use as the start of the timecode frame. NTP will give the recorder really accurate time-of-day, but even if we then tell every device to start TC frames on exactly .000 of given seconds how do we control drift? Drift of one millisecond will desync sound and picture.

Perhaps this is a question of the quality of clocking devices, not the synch method...

[RobRoySyd]

The problem is a bit more complex. It's one thing to have clocks that are being adjusted from a known reference however it's what happens while they're being adjusted that can really screw things up. Audio clocks need sub millisecond accuracy with no jitter or things can get really messed up.
I think thats why having a master SPG and word clock running everything from the one source is still the norm. The Lockits can sync to GPS time which is about the best there is, HF time references drift over a 24 hour cycle, I've seen this plotted against a local atomic clock.

[Jesse Wendel]

NTP synchronises clocks, but if those clocks are seperated, it can't keep them in sync; which is exactly the issue at hand.


The problem is a bit more complex. It's one thing to have clocks that are being adjusted from a known reference however it's what happens while they're being adjusted that can really screw things up. Audio clocks need sub millisecond accuracy with no jitter or things can get really messed up.
I think thats why having a master SPG and word clock running everything from the one source is still the norm. The Lockits can sync to GPS time which is about the best there is, HF time references drift over a 24 hour cycle, I've seen this plotted against a local atomic clock.

I didn't quite get all of this, for example "HF time references", but I think what y'all are saying is, to make this work you need to have audio accurate to sub-frame across everything, and that the advantage of some device I don't know about but that is generally accepted as the time source on shoots called the Lockits, is that it grabs GPS time. In my world, that's what is called a Reference Clock. You can buy one for $100 USD oem, $125 retail, hook it up to an old Pentium running FreeBSD and you have a Stratum 1 timeserver at sub-100 nanosecond accuracy assuming non-major temperature changes.

I don't know how much the Lockits is or precisely its function other than synching time to everything, but based on what I'm gleaning, it sounds as if the Lockit is in fact grabbing NTP time from GPS, then pushing it out to all the devices, and it is the devices which are failing -- because they aren't running an NTPv4 client against the CPU -- to maintain accurate time. I suggest that were the devices running NTP, they would in fact be able to keep time at a level that would not require them to keep being, um, re-jammed, with time from this specialized device, when all one needs in my world is software which comes as part of any Unix and a general purpose computer. Add on a $125 GPS receiver and you have a Stratum 1 timeserver playing rock and roll.

Enough. I still have much more to learn than contribute, so I'm staying quiet unless I see something else in the thread to comment on specifically or someone asks me a question.

Best,

Jesse Wendel/Seattle

[Jiri Bakala]

I honestly don't understand why this needs to be so complicated. If you have a multicam shoot, jam the cameras with a simple BNC cable and they will run in sync all day. No brainer. The less complication the better. The more software on various different levels the better chance of crashes and problems. Part of the advantage of film is still its simplicity. In its most basic form it can run in a hand-cranked camera and still deliver beautiful images. In order for RED to become the next robust acquisition tool it needs to maintain a balance of sophistication (feature-richness) vs. simplicity of use and maintenance in the field (whatever that specific field might be - Arctic, tropical jungle thousands of kilometers from any service or even civilization, etc.)

[GlennChan]

I'm not an audio or dailies guy, but as I understand it:

There's two different kinds of sync you might be worried about
A- Whether your time of day timecode is close to actual time. (Analagous to whether the watch on your wrist is close to accurate time.) I don't know of any cases where you need to be extremely accurate with this.
B- Sync between your picture recorders (film/video) and your audio recorder. You may want to record audio onto a separate device since you can record *a lot* of tracks, whereas your camera is limited to crappier electronics and typically no more than 4 tracks. When you do this, it's nice if your audio and your picture are always in sync since they will get matched up/combined via timecode.
C- If you're doing live switching, most switchers need everything to be genlocked together (where genlock provides the reference signal). You need to be really close with sync there, much less than a frame. (But that's not what I'm talking about.)

So for B...
You use something as your master reference clock... it could be your audio recorder's clock, or the clock on your TC slate. When you jam two devices together, their timecodes will sync up. When you separate the two devices, how long they stay in sync will be determined by the accuracy of their clocks. The Ambient/Denecke boxes have more accurate clocks than those found on cameras. Your audio recorder and your picture sources will stay in sync for 24 hours, unless there are temperature fluctuations. So to be safe, you should re-jam them every meal break.

And of course you need to make sure the batteries are fresh.

2- In practice, an (inexperienced?) audio person can and do screw up this process. So the dailies colorist (and his/her assistant) have to sit there and verify sync. They play back the film, and the audio recorder will play in parallel based on timecode. This gets recorded onto the master tape and also onto another deck (i.e. 3/4"). They shuttle back the tape on the other deck to find where the slate is. And they check sync by checking that on the slate, the two sticks hitting each other corresponds to the sound on the audio track. And sometimes the slate will be out of focus or not in frame, so you have to use other cues to verify sync. And yes you could re-slate, but when you're shooting in really cold conditions for 10-16 hour days (both of these things really suck), you may not be really vigilant about that.

2- You could run cables into the camera, but cables are a pain in the butt when they get tangled and you have to waste time untangling them.

3- Probably the best thing for Red to do would be to implement audio sync capabilities in Redcine, or open it up so that a 3rd party developer can add that in. It makes the process idiot-safe, since it's not going to be that painful to fix audio sync. Or perhaps Scratch can do something here.

3b- Though if you record your audio right onto Red, then you don't need to worry about sync. And four channels is good for most people. Though that's not 100% idiot-proof (you can disconnect the cables when moving the camera and forget to reconnect, or accidentally hit line/mic-level switches on the camera or mixer [hmm I've done the second]). No system is idiot-proof of course, though implementing such features in Redcine (or another app) would make it more idiot-safe.

The current methods work and is not particularly problematic other than it not being idiot-proof. Though you can never truly make something idiot-proof. i.e. the return features on mixers theoretically let you spot audio problems with the camera (disconnect cables, accidentally hit mic/line). Though idiots like me don't know to check it (often enough).

4- The folks at the CML would know more than I do. Here is one page of discussion....
http://www.cinematography.net/Pages%20DW/F900Genlock.htm

[Jiri Bakala]

Red's audio recording quality, I am pretty sure, will be excellent. Hence, the need for dual recording diminishing. The biggest reason for syncing devices is shooting multicam for later edit. For that, as you said Glenn, jamming is good enough for 24 hrs, particularly if the cameras are re-jammed every 4-6 hrs. Live switching requires a reference signal anyway, without the need for TC to necessary match, unless it is expected that later editing will happen and the devices are iso-recording. Once again, I'd say, there are well tested and established ways of doing things and it would be great to keep the camera as simple (which in this case is a bit of oxymoron already) as possible.

[M Most]

Red's audio recording quality, I am pretty sure, will be excellent. Hence, the need for dual recording diminishing.

Sound quality is not the issue. Levels and reliable recording are, at least for a professional sound mixer. That's why virtually all sound on film style productions is recorded double system - so that the mixer has not only a direct indicator of the levels being recorded, but also has confidence playback (i.e., read after write on a digital recorder - which is what's primarily used these days) to confirm that the sound has actually been recorded. Neither of these things are available to the mixer if the camera is the recording device.

With digital sound recordings, time code is not the synchronizing signal. It is only a number, stamped once at the beginning of the file, that is used for convenience in locating a particular frame. Sync is achieved by playing the file at its proper rate - i.e., 48KHz if it's recorded that way, other variations on that if it's not. And the use of time code slates is not the panacea, because in more cases than not, they are inaccurate, regardless of what's being said here to the contrary. As someone who's been around these things since Mike Deneke came up with them, I can tell you that's always been the case. If you don't believe me, ask any dailies colorist anywhere in the world. The most accurate, and simplest, way of achieving sync is by using sticks. Simple. Cheap. Accurate. And in digital editing programs, extremely quick to match up. Unless you're shooting documentaries or other somewhat uncontrollable situtations, you're better off just banging sticks than using any time code based or other more exotic synching system. Because it works. Every time.

[Jiri Bakala]

... - so that the mixer has not only a direct indicator of the levels being recorded, but also has confidence playback. ... Neither of these things are available to the mixer if the camera is the recording device.

Not exactly. In the video world this has been the norm for ages:

First of all, once the record levels are set by a reference (tone) on the camera, they are identical to the mixer.

As for confidence recording/feedback, the sound recordist listens back from the camera either EE or PB. Simple. To further confirm that the sound is actually recorded to tape/file, it's a simple matter of playing back the last few seconds of the last take.

I realize that this is more the TV/documentary standard and in features the sound recordist wants more control. Fine, for that we go back to the good old slate and a dual system.

What I am saying is that once RED (and other similar systems) prove reliable enough, most productions will likely record directly to the camera as their primary material and only use separate audio recording as a backup.