Timecode issues with the Sony PMW-EX3

[tonetripper]

Hi all!

So I'm just fishing right now as I've settled into a job that is using the EX3.  I've already recorded once with the EX3 for this show for a doc series I started back in November in Mongolia and have just returned from a 6 week stint in Vietnam, New Zealand and Fiji for the same show.

This is the thing.  I received confirmation a week before leaving on the latest leg that the cross-jamming I was doing with my modded SB2A (Denecke) running my 744T at 29.97 NDF 24/48 to the SB2A running at 23.98 that everything synced up perfectly.  Whilst in the field, surviving Nam, in New Zealand, I find out that there is a sync issue where there is a drift from the camera feed (fed wirelessly) from the recorded audio from the 744 from 1 to 10 frames.  Now I believe this is a negligible value, but since I have recorded for two separate movies using 900 series Sony cameras and had no issues with post, I'm scratching my head over the issue.

Since I've been back I've witnessed the issue first hand with the raw footage (not codecs - although that's another weird issue) and noted that all the audio is out of sync by this annoying flanged/phased value.  Unfortunately this is a problem for the Assistant Editors who are finding it hard to find time in their rediculous turnaround for broadcast to adjust the audio files.  The deal is, however, that we've been using multi formats to shoot with (5D, pencil cams, GoPros, Handicams) of which I've been using a slate (which is also cross-jammed to 23.98) so that they may use my audio off the 744 (running at the normal NTSC rate) and have had no sync issues whatsoever.  Also when first noted of the issue in the field we did some tests on the sync with the raw footage and encountered no issues whatsoever.  It's a real head scratcher.

I was just wondering if any of you might know if there are any known issues with the timecode input of the EX3 whereby the camera slips a bit when put into record.  I've spoken to Charlie at Denecke and Harry Kwan out here in Toronto about it and they don't believe it's anything to do with configuration.  I was hoping someone here would be able to shed some light on a most annoying problem that is plaguing me no end as the EX3 is the A-Camera with the camera-man's Lens on it but I've had to be real creative to get sound for the camera.  Namely, rig in a dry bag while in Fiji in a canoe with two wires on people.  Moving vehicle stuff with conversation.  Yadayadayada...... running through the jungle.  Pack in a tender in the ocean recording cuz I couldn't be in there.  Basically precarious situations whereby the wireless feed is a no option for editing and my tracks off the 744 become the money.  The sync problem is annoying to say the least.

Any opinions or words of wisdom would be most grateful as I'm seeking ammunition to arm towards post in hopes that they understand that a 10000 dollar camera is not behaving properly.  Either that or I've fucked the job up which I doubt.  Any info would be great as I can find very little on line in terms of issues.

Cheers!

Paul

[tonetripper]

Thanks FarOutPro!

It seems to fall in line with the sync issues being represented.  I have a meeting before I head out to the Bahamas, Florida and California for 4 weeks and this is great to know.  I heard from Charlie at Denecke that there is another sound mixer in California that has been experiencing these same issues.  It sounds like the issue I'm encountering.  The problem is they are obviously pointing their fingers towards me which I'm desperately trying to debunk, so thank you I'm armed with a fair amount of knowledge that points problems to this prosumer format.  It wouldn't be of great concern if the tracks actually were very much needed in long lense situations where I'm with the talent than with the camera.  Thanks.  I will advise them of the fact that the firmware has not come out to solve this issue.  Cheers! 

Anyone else feel like arming me with more then I implore anyone with experience with these throw over the bridge cameras to chime in.  I'm going to try to convince production to stop wasting their time with them.

P

[TomBoisseau]

Well I'm glad to hear it's not just me!  Sounds like the TC generators in the EX3's are pretty worthless.

I did a shoot a few months back with 2 EX3's.  In this situation we only jam sync'ed the two cameras - no external TC generator.  Both cameras were set for 24p, so 23.976.  Within 30 minutes, the timecode was off by nearly 10 seconds!

We continued to re-jam but they never would stay in sync.  Fortunately each camera was shooting "different" behind the scene footage in different areas, so TC was really only for referencing time of day.

Tom

[tonetripper]

Well I've informed them of the issue and they want to proceed.  Obviously being a doc slating is not such a great thing in the heat of the battle of shooting since the EX3 is the A camera, so they are going to have to deal with this issue in post and they are not willing (doesn't surprise me as we've established a workflow and look) to change formats.  Neither here nor there it may have to come to Wave Agent to get them proper for sync with over 300 Gs of info already coming their way from the shoots.  It's a bit of a post nightmare, but as the phrase goes "They'll fix it in post!"  Hah!

Thanks Scott for the info.  Charlie contacted me through the forum.  In addition I checked the Denecke boxes to check the frequencies today with Harry and all is running proper so I definitely know it's a camera issue.

I'm going to tackle Sony at some point to get them going on going forward with solving this issue with some kind of firmware.  Harry seems to believe that the sync is low on the totem pole for priority in electronics which is why there are these issues.  Once again:  Prosumer cameras.

[André Boisvert]

Thanks for a great thread, Paul. This is very valuable information.

I love this board.

[Richard Ragon]

Common Issue..  Discovered this on my first large reality TV show gig.  From that point on I either send a TC to the camera via a wireless signal, or get an external lock box.

-Richard

[tonetripper]

What do you mean Borg357 by an external lock box?  Also if you are sending the RF T/C signal, then how would that solve the problem with the T/C in on the camera if the camera has a known issue of resolving any timecode being fed to it?  Are you speaking of an audio T/C signal down an audio channel?

[RPSharman]

What do you mean Borg357 by an external lock box?  Also if you are sending the RF T/C signal, then how would that solve the problem with the T/C in on the camera if the camera has a known issue of resolving any timecode being fed to it?  Are you speaking of an audio T/C signal down an audio channel?

Agreed.  The problem is the camera not keeping speed, so regardless of TC being fed or not, it will drift back and forth during a take because of the poor quality of the camera's internal clock.  If sound is run directly to the camera, then obviously it's not an issue.  If they are syncing big files, there might be drift that can be resolved in editorial.

This is great information to have, and another reason why this forum is so great.  If someone wants to use this camera on a shoot I am mixing, I'll be sure to mention that they should expect this easily resolvable issue.

Robert

[Richard Ragon]

What do you mean Borg357 by an external lock box?  Also if you are sending the RF T/C signal, then how would that solve the problem with the T/C in on the camera if the camera has a known issue of resolving any timecode being fed to it?  Are you speaking of an audio T/C signal down an audio channel?

Use outside sources for TC are more reliable that the internal TC that this camera has.

The camera syncs just like everything else, but it then drifts off based on factors such as how many times the record button is pressed, external hard drives attached, battery and just a plain mater of time.

By setting up an external clock source, it works more accurate. 

I've set up super cheap wireless mics receivers (azden) and stuck BNC connectors on them.  I was then able to send a wireless TC reference to all 8 cameras that were in the room at the same time.  If the camera came off TC, it corrects itself in the next tic.

-Richard

[RPSharman]

By setting up an external clock source, it works more accurate. 

-Richard

I guess this insures a common start point, but does not keep the camera from drifting within a specific take, which is what I think is the nature of the topic.  But it certainly helps to have the start code match, I imagine, especially with multiple cameras.

[tonetripper]

Use outside sources for TC are more reliable that the internal TC that this camera has.

The camera syncs just like everything else, but it then drifts off based on factors such as how many times the record button is pressed, external hard drives attached, battery and just a plain mater of time.

By setting up an external clock source, it works more accurate. 

I've set up super cheap wireless mics receivers (azden) and stuck BNC connectors on them.  I was then able to send a wireless TC reference to all 8 cameras that were in the room at the same time.  If the camera came off TC, it corrects itself in the next tic.

-Richard

Well with all due respect Richard it doesn't solve the drift with a wireless feed T/C in regards to what's being recorded on a separate machine with T/C.  The cameras may all be uniformed in terms of a timecode but the drift will also be uniformed (or possibly not) when record is activated on the camera, not to mention that the drift will land in different places if all the camera man all record at separate times or change cards and then restart the record process.  The issue will still have to be managed in post.  If you read my first post rather clearly it'll state the issues were possibly inherent in the camera and then clarified by Scott Farr as well.

Basically the T/C in is a piece of crap on the EX3.  They need to resolve it, so that these issues don't keep happening especially in lieu of 20 year old wiz kids recommending them to productions because of the immediacy.  The only way true code will be established on the EX3, imho, is to feed the sync box through an audio track and have post read the code, which ultimately they don't want to do as they would have to buy a A-D timecode reader specifically for FCP or create firmware to solve the drift.  The other option is to go with a professional camera.   The althernate fix is to change the code on the footage to match audio timelines which will also turn into some kind of huff and puff atmosphere with post.  Once again, you get what you pay for.

There is no easy fix with this camera.  I let them know the issues and they are reluctant to solve them, but proceed with the status quo.  It's bullshit in many respects cuz it's kind of an adventure show where sound needs to be with the subjects and cameras are doing all kinds of things outside from being fed by me directly to audio ins. 

I've ridden a horse in Mongolia with my pack on recording sound.  Run through the jungles of Vietnam recording sound for two handicams.  Swam to an Island in Fiji to get my pack that was recording in a dry pack so that I could make sure sound was recording properly.  Also during Fiji the camera went AWOL due to moisture and the audio inputs never came back not even a camera mic.  Picture came back.  We had no backup as we lost two in each location on location prior to Fiji, so the 744 became the main audio engine for picture.

Needless to say it's a post nightmare that I have now signed off on due to the information found on this board and research I did outside of it.  Stupid cameras.

[Philip Perkins]

To the OP: why are you cross jamming?  It just makes a complex situation more complex.  Why not roll your TC @ 23.98?  Re the EX3 TC--they use bunches of them on the TC series "Trauma" shot here.  They jam them all the time but in the end it is a good old clap slate that the editors look for.  We just did a 5 camera concert shoot with them, no $$ for lockits or etc..  When the producers asked about TC drift I explained that there was going to be drift no matter what we did, so think of the TC as getting you in the ball park and then figure that you will have to adjust sync to eye at each edit anyhow, since often numerically correct sync looks wrong in music shooting.  They also had lots of strange dinkycams rigged on stage, so they'll need to figure on tweaking sync all thru editorial.  Camera mic audio will be our friend.

Philip Perkins

[tonetripper]

To the OP: why are you cross jamming?  It just makes a complex situation more complex.  Why not roll your TC @ 23.98?  Re the EX3 TC--they use bunches of them on the TC series "Trauma" shot here.  They jam them all the time but in the end it is a good old clap slate that the editors look for.  We just did a 5 camera concert shoot with them, no $$ for lockits or etc..  When the producers asked about TC drift I explained that there was going to be drift no matter what we did, so think of the TC as getting you in the ball park and then figure that you will have to adjust sync to eye at each edit anyhow, since often numerically correct sync looks wrong in music shooting.  They also had lots of strange dinkycams rigged on stage, so they'll need to figure on tweaking sync all thru editorial.  Camera mic audio will be our friend.

Philip Perkins

I'm cross-jamming to keep the over-sampling rate congruent through to broadcast.  Otherwise they'll have to do some work in post to work out the 3:2 pulldown which inevitably alter to the oversampling rate and make everything out of sync for picture.

Also the simple answer to the question is I was asked to do it and I have worked on two big docs that have had no issue all the way through the post process.

The other answer is cross-jamming isn't the problem as the slates were all set to 23.98 while I recorded at 29.97 NDF and all the audio locks perfectly.  If the T/C in wasn't a piece of shit everything would line up perfectly which it's not.

[Marc Wielage]

I'm cross-jamming to keep the over-sampling rate congruent through to broadcast.  Otherwise they'll have to do some work in post to work out the 3:2 pulldown which inevitably alter to the oversampling rate and make everything out of sync for picture.

I'm confused. Is this something the editorial department asked for? 23.98fps works fine for broadcast, because it down-converts perfectly to NTSC, and it also works fine in HD for 1080i broadcasts.

Richard Ragon above is right: I think the only way to 100% guarantee no drift with cameras like this is to provide external genlock sync and timecode for each camera with a Denecke SB-T or Lockit box, assuming the cameras will run in external and not jam. Otherwise, all you get is "close," not exact. I'm suspicious of wireless timecode transmission, because I've seen them fail far too often. Under controlled conditions, though, and with cutting edge systems (like the Zaxcom ERX with a 1-watt booster), I think it can work, but I think a hardwired generator will always be more reliable and cheaper.

I also don't think it makes sense to record sound at 29.97 anymore on a 23.98 digital project, assuming your recorder and slates can handle 23.98. I think this was an issue four or five years ago, but the last dozen or so features I worked on in post have all started using 23.98 code, at least with digital cameras. The film projects seem to stick with 30NDF, but those are becoming fewer and far between.

I share your frustration, though, because it's clear that companies like Sony and Red seem to put 98% of their R&D money into picture, and less than 2% into sound and timecode stability.

--Marc W.

[tonetripper]

I also don't think it makes sense to record sound at 29.97 anymore on a 23.98 digital project, assuming your recorder and slates can handle 23.98. I think this was an issue four or five years ago, but the last dozen or so features I worked on in post have all started using 23.98 code, at least with digital cameras. The film projects seem to stick with 30NDF, but those are becoming fewer and far between.

I share your frustration, though, because it's clear that companies like Sony and Red seem to put 98% of their R&D money into picture, and less than 2% into sound and timecode stability.

--Marc W.

It's not the frame rate at issue here.  The issue is the sample rate.  What happens in the .01% pulldown is that it will change your sample rate.  Broadcast is at 29.97 NDF for television.

For instance:  Record video at 23.98 and say  audio as well at 23.98 24/48

When converted:  audio will end up at 29.97 24/48.048 which will stretch the audio and put it all out of sync and all the audio files will have to be re-converted for Broadcast to match up to it's original recorded sample rate

This means that at 23.98 HD video when pulled down .01% won't affect audio as 29.97 24/48 recorded when put ready for Broadcast.  It could become a disaster for post either way, but the tracks are really meant for Audio Post.

Ofcourse there are fixes in either regard.  In my mind if the sync boxes are perfectly locked (which they should be - of course drift can happen over time which is why we rejam) then everything stays in the audio world from Edit at 23.98 all the way through to Broadcast if Audio is recorded at 29.97 24/48.  Cutting natively shouldn't affect the audio portion.  Also after Colour Correction Audio Post should get the files.  In my hunble opinion, as I've not seen a film all the way through, most times the conversion would happen before audio post so that they may utilize the files in a more compressed fashion.  Even if it's cut natively then it should by rites be able to be cut correctly even at 29.97.

Once again I've done two docs in this configuration and all has been good.  Also I was asked by one of their techs to proceed at 29.97 and received confirmation that all was synced in Mongolia.  6 weeks on the road can really fuck things up when transitions may be needed although I believe it's still a deal if Audio needs to convert on the backend.

Of course there is the option of recording at 23.976 at 24/47.952 khz but I think it's all the same ball of wax.

In the end I think it's easier to alter the timecode of the picture than it is to alter the timecode of the audio in my particular case.  The slated pictures all line up perfectly but the sync box EX3s do not.

Link to Gearslutz thread on this:

http://www.gearslutz.com/board/post-production-forum/184636-definitive-explanation-29-97-23-98-timecode.html

This debate could go on for a while although I think the easiest route when thinking audio for picture is what is the pulldown for screening pleasure.

Also there is some evidence in the EX3 specifically that refers to doing any wordclock business which also makes the timecode fuck up even more.

Link:  http://www.petergray.org/lockits.html

Check out the EX3 settings and how the GenLock can mess things up.  it's a crystal thing.

Anyway I'm glad to be chiming into this forum.  It's always great to get some knowledge thrown my way.  And it's armed me to no end to deal with these guys when there is very little to do to resolve the issue.

I'm also, going to go on record to say I offered to record at either rate, but had success with the crossjam on prior films.  Not even using a GenLock or the Denecke T.  I can mod my SB2As to have the GenLock.  That's not a big deal.  But when you are using a camera with the unreliability in it's own T/C then it's still going to be a problem.  Please feel free to have at me.

[John Blankenship]

Danger, Will Robinson, danger!

The problem with the internet, as great as it is, lies in the fact that there is probably as much misinformation as there is correct information.  One must be extremely careful in sorting it out.

The article you reference, as well as some of its follow-up posts, contains errors, as does your well-intentioned post.

In brief, Pull-Down and/or Pull-Up occur when adjusting film speed to video speed, and vice-versa.  3:2 Pull-Down refers to the entire process of slowing a 24 fps film sufficiently (.1%, not .01%) that (in effect) 24 frames can be mapped onto 30 frames along with the field pattern utilized to create the six new intermediate frames.  Since video runs at 29.97 fps, and the relationship is therefore 24 to 29.97 (relationship=.8008008008,etc.) (the reciprocal of which is 1.24875), the 24 fps film is slowed down .1% to 23.976 fps in order to create a more advantageous mathematical relationship to video (23.976 to 29.97 = .8, the reciprocal of which is 1.25) which allows us to map (in effect) 24 frames onto 30 by creating six new intermediate frames.  Pull-Down refers to the process of slowing the film down by .1% while the 2:3 (some call it 3:2) part refers to the field pattern used to create the six new frames.

Time code is a way of counting frames and does not, and should not, affect speed.  Frame rate is the speed.  People quite often confuse time code rate and frame rate.  Along those lines, drop frame time code does not drop any frames, it just counts them differently.  Since both 23.976 and 29.97 both run at the same speed (video speed), exactly one second should still be exactly one second even after a conversion between them.  If not, there is a problem with the way the conversion was performed or with the software doing it.  The time relationship between them should still be 1:1.

Technical misconceptions tend to linger.  NTSC television switched from 30fps to 29.97fps in 1953.  I guess fifty-seven years is not enough time for everyone to adapt.  Many people still refer to CinemaScope films as 2.35:1 ratio even though the ratio was changed to 2.40:1 by the SMPTE back in the early 70s in order to help hide splices.  The Right-On-Red statute was implemented in our state well over thirty years ago but a few people still stop and wait even when there is no cross traffic.  I guess they think it could be rescinded at any given moment and they don't want to be caught mid-turn with a law change.

John B.

[John Blankenship]

To clarify (and probably confuse things further in the process) film is shot at one second equal to one second, just like video has one second equal to one second.

So, when we refer to film speed vs video speed, Film Speed refers to film that has NOT been slowed down (one second still equals one second, just like when it was shot).  Video Speed refers to video at its normal speed (one second equals one second), OR to film that has been slowed down by .1% (normally, in order to transfer it to video).

John B.

[pshap]

i recently captured audio with a 744t with 2 Sony pmw-ex3's. I set the sound devices unit at 23.976 and jammed the smart slate, then jammed both cameras.... Within 10 minutes the code in the cameras was way off. Slate still matched my sound devices unit but boy my cameraman was pissed at me. I had no explanation. I recommended that we just shoot the slate as much as possible throughout the night because his cameras were f'd up...... from what I read below even a sync box wont help this camera hold time code....

Question: Is 23.976 and 23.98 supposed to be the same? Sound Devices units are pretty heavy duty units regarding sound and I had to really scramble to figure out why these cameras were drifting..... I have spoken to a few people and they told me that post can resolve this issue easily...... it was pretty frustrating and I may have lost a client over it......  I saw the finished product a week later and it looked and sounded fine...... wonder if my cameraman didn't know that this camera wouldn't hold time code......

[John Blankenship]

Question: Is 23.976 and 23.98 supposed to be the same?

23.98 is just a shorthand way of saying 23.976.  Since there is no 23.98 standard it's not confusing once you know it's just shorthand.

However... 

Unfortunately, some equipment manufacturers use 24 and 30 as shorthand for 23.976 and 29.97 respectively.  Since each of those four rates is viable, it makes life more confusing.

John B.

[studiomprd]

" they (Camcorder makers) are reluctant to solve them, "

of course, they are working on the next flavor (model), this one is already almost obsolete!!

but this discussion (argument?) has some flaws:

" The problem with the Internet, as great as it is, lies in the fact that there is probably as much misinformation as there is correct information.  "

and it even happens on this discussion group...

" The issue is the sample rate.  What happens in the .01% pulldown is that it will change your sample rate.  Record video at 23.98 and say  audio as well at 23.98 24/48 When converted:  audio will end up at 29.97 24/48.048 which will stretch the audio " is misinformation.  there is no speed change involved in changing 23.976 to 29.97, only 3:2 conversion

" This means that at 23.98 HD video when pulled down .01% " HD has nothing to do with this, and there is no pulldown here!

and when well intentioned folks pass on misinformation, it somehow becomes more credible, even though still incorrect.  (that comment from my friend J1N)

continuous jamming (via radio, lockit, syncbox, whatever) only can work if the device being jammed can use external time code (and not just "jam" from it, it must actually use it as it arrives!).  Of course this is complicated on file based systems, in that the TC is not actually continuous, but stamped in the header (metadata) at the beginning of the file, and calculated from that point onward.  This brings in the requirement for an accurate time base for each piece of equipment, and one of the things that makes cheap stuff cheap is less dependable, less accurate time baseses... thus Tri-Level sync, with a time base signal (aka genlock) to keep the units all operating precisely.

as to the sampling rate issues, they are a McGuffin here.  if there is pullup or pulldown, the amount is the same for 29.97 to 30.00 as it is for 23.976 to 24.000, as they both represent a .1% change in the timebase.

OK, bottom line: some dinky-cam's don't have a stable, accurate time base and drift. Generally speaking, you get what you pay for... Re-read JB's post, and get used to it!

" Is 23.976 and 23.98 supposed to be the same?  "

YES, exactly!! (it is just rounded up for printing and display purposes!

" the code in the cameras was way off. Slate still matched my sound devices  "

well, obviously, the problem is with his toy!! your toys are playing well together...

[Derek H]

With all of these TC peccadillos on this (and many others.. hvx200 ahem..) "pro-sumer" camcorders what is one to do when a clap slate is not an option?

I realize that it sounds silly to think that a slate is too much of a hindrance but on some reality and documentary projects it really is. 

It seems that trying to use TC for sync with these cameras is ultimately an unrealistic and time-wasting endeavor.  Someone correct me if I'm wrong.  In my mind it seems that there must be a better way..

Possible solutions off the top of my head:

A) Single system, ENG sound.  If you can get by with 2 channels I see this as a good option for many projects.  In this scenario sync sound is on the master camera only and all the BS peripheral dinky cams amount to B-Roll and there should be no expectation of sync sound for them.

Dual system to 7xx/deva/552 with LTC on an audio track on the camera.  This makes sense to me but this method is rarely discussed.  I realize it represents an added layer of complication for post but wouldn't a solid aux LTC track that is locked to the picture and matches the audio master be a lesser evil than trying to use the dodgy, drifting camera TC?

C) Dual system to 7xx/deva/552 with reference audio sent to camera via RF.  I've never used Pluraleyes but it seems to be getting a lot of recommendations.  Manually syncing identical waveforms by eye is also not brain surgery.

D) Dual system to 7xx/deva/552 with a return to the bloop light?

Again, this all may be some bogus thinking but trying to use TC in an accurate way with these cameras seems to have so many pitfalls.

[JimMansen]

Actually found my Nagra based bloop light the other day. It is the kind that presents neon numbers set with a scroll wheel and got it's power from the Nagra and used the Nagra's own circuit to add a beep tone to the track.  The neatest thing was that it could also be configured to interrupt the pilot tone instead of adding a beep to the track. This was greaqt if you were using two or more cameras.  You could beep once for A cam twice for B cam etc. yet no beep was actually put on the track.  When transferring you could connect the alarm that indicated absence of Pilotone sync and that would add the beeps for syncing.  If there was beep over an important part of the track you could re-transfer minus the alarm beep and replace the contaminated dialogue. Spent a lot of time with that system and it worked great. What sort of bloop lights are now available for us these days? Anybody making an upgrade for the Neon Numbered bloop light.  David Lezinsky just told me he found a cheap  flashlight that made a funny signal when the light came on and that he had put that to good use on a multi-cam shoot just for that purpose.  What are the other options anyone?

Jim Mansen - Arizona

[tonetripper]

Thanks all who chimed in.  Your knowledge is invaluable to my learning curve and i may have been misinformed by some colleagues of whom I trust and have worked with about this issue.

So first off I thought I edited my post about the .01% pulldown and for some reason it didn't change as I was writing it late last night.  It is .1%.

But to clarify because my brain is going to mush, if the picture is edited in it's native 23.98 (23.976) and audio is recorded and edited at 23.98 24/48 when they convert to 29.97 for broadcast the sample rate won't change?  Because this is in direct contradiction to some colleagues of mine out here in Toronto.  I already have my head wrapped around the 30 to 29.97 debate blah blah blah in terms of speed change, but for some reason I feel misinformed about this change to 29.97.

[tonetripper]

Also I should state that this company had some weird way longer drifting scenarios for a Dive show they did for Nat Geo when the recordist recorded at 23.98 and they asked him to record at 29.97 and most of the issue was resolved.  Still drifted but not by 7 seconds at points which falls in line with Pshap's post.  Once again I will clarify I did offer up the 23.98 recording but was asked to do it at 29.97 because of this prior drift with sound on a prior show with the same camera.

On the same sort of line however the 5DMkII has had tremendously good sync when busting out a slate at 23.98 in terms of my working at 29.97.  Once again I still believe post audio will end up using a 29.97 picture when laying sound on it.  In many respects it would all jive.

Once again thanks for the feedback as it's great to extract info from some seriously informed individuals about it.  It's not my first rodeo by any stretch of the imagination, but I'm sure there are those here who have lasso'd many more cattle than I.

[Marc Wielage]

Yep -- what John B. says. 

--Marc W.