syncing problems with Edirol R4-Pro and XLH1

[Michael Galvan]

Hi,

I have been trying to sync the sound from an Edirol R4-Pro that was slaved to my XLH1 without success. I know that the timcode output of the XLH1 is always 29.97D, regardless of framerate. So I connect the R4-Pro, and run the camera using free-run, and the recorder set to 29.97D. They both have the same timecode upon recording with the camera.

But when I bring it into post is where the problem is. The timecodes just don't match in Final Cut Pro. I notice that the XLH1 timecode skips every 4th frame and goes up to 29 frames where as the Edirol Audio is consistant timecode at 24 frames. So although they record the same timecode in production, they don't match in edit. I'm editing in a 24p timeline as I shoot 24F. So although it is 23.976, the timecode of the camera still runs at 29.97.

Does anyone have any experience with this? I'm confused.

[Dan Keaton]

Originally Posted by Michael Galvan

I know that the timcode output of the XLH1 is always 29.97D, regardless of framerate.

Dear Michael,

The above does not sound right to me.

I have not tested it, but if you set the XL H1 to 24 frame mode, the timecode should not be 29.97 drop frame.

When I have a chance I will test it.

[Michael Galvan]

Hi Dan,

I thought this too, but after testing it, it is indeed 29.97D. When you switch over to 24F, the timecode remains 29.97, dropping every 4th frame.

I'm not sure why it wouldn't run it at 23.976 ...

[Dan Keaton]

Dear Michael,

That certainly is strange.

I think a call to Canon would be in order.

[Dan Keaton]

Dear Michael,

There is some interesting information on pages 56 through 59 of the Canon XL H1 manual.

Are you shooting in 24f SD or HD?

The manual states that it supports both Drop Frame and Non-Drop Frame timecode formats.

The HD-SDI and component outputs are always 29.97 since a 3:2 pulldown is used.

But the HDV recording, in 24F should be at 24 frames a second.

At least that is the way I understand it from reading the manual.

[Michael Galvan]

Hi Dan,

According to the Canon Inputs and Outputs whitepaper on their website:

"No matter what frame rate the XL H1 is set to, in 60i mode the Time Code signals are always 29.97DF and in 50i mode (optional) it is always 25."

I have the camera set to drop frame/freerun.

I dunno, but my gut feeling is telling me it has to something to do with Final Cut Pro. It seems the timecode is syncing properly upon capture.

Any other thoughts?

[Dan Keaton]

Dear Michael,

So I assume that you are recording in HDV.

Your whitepaper quote makes sense in that the 24f data is inserted into a 60i output, so that it will be using a 29.97DF timecode.

But, when you capture the 24f footage, then time code should be 24 (or 23.976 which is sometimes called 23.98).

Please understand that I am not an expert in this area, and I have never stayed in a Holiday Inn Express.

[Michael Galvan]

Yeah I shot 24F to HDV.

And although the footage is true 23.976, the timecode runs at 29.97D, skipping every 4th frame ... I wonder why Canon implemented it like this.

But its making it a pain to sync at this point to the R4-Pro. The recorder is accepting the timecode and they sync in production ... its just after importing it into Final Cut is where they don't match - the audio from the recorder is read from FCP as 23.976 with no frame dropping.

I'm totally confused ...

Thanks for helping me try to figure it out!

[A. J. deLange]

You certainly have bitten off an interesting problem. I don't have all the answers but I have been able to establish a couple of things. The XLH1 puts out 29.97 (really 30*1000/1001) video no matter what the frame settings. In 24FPS mode frames are written at the only rate HDV can support which is 60 fields ps but fields are arranged and/or repeated according to which of two pulldown schemes (2:3 or 2:3:3:2) you select. It is up to the capture software to detect the frame rate of the original (there are flag bits for this), pick out the right 29.97002997002997002... frames in each second and label them 0 through 23. The timecode clock's rate (not phase) is synchronzed to the same clock from which the video clock is derived. The time code consists of frames (of 40 bits) which come at exactly 30 frames per second. If audio is clocked at 48KHz each time code frame takes exactly 1600 samples while a video frame at 29.97... requires exactly 1601.600 (equal to 1600*1000/1001). Thus time code frames and video frames slip relative to one another and if you don't care about this you select NDF and the frames count up to 30 then roll with the difference between time codes accumulating. If you do care then DF is selected which means that the first frame number will be dropped (nothing is thrown away - frame numbers 1 just don't appear) at the beginning of each minute unless it is evenly divisible by 10. This is exactly the same concept as the use of leap days (Feb 29) every 4 years. If DF time code is used error between time code and wall time creeps up to be mostly reset at top of each minute with a second correction every 10 minutes.

Now where it gets hairy is that NLE's don't use timecodes. They use time tags (as near as I can figure) so that they try to calculate the time of each sample and each frame from what the know about where a file or clip starts. SMPTE has published algorithms for the sample count in each HDV frame (must average to 1601.6) but we don't know that Apple (or anyone else) uses the SMPTE algorithm. In fact they hint, in the FCP documentation, that they use the SMPTE algorithm sometimes and calculate based on 1000/1001 others with no details (that I have found) or where or when they do what.

At this point I don't understand it better than this. Empirically it seems that within a cut video (and camera audio) stay in sync with a word clocked external recorder throughout a cut no matter how long but between cuts there may be an indicated T/C slip.

[Steve House]

Wonder what you'd get with capturing video onto a 24 FPS timeline with the audio recorder set to 30ND? While frame numbers between seconds would differ, the hour:min:sec portions of the code should line up at the start of each second. Since all timecode does is establish a single lineup point within the file and does not control playback speed to keep audio and video in sync once aligned except at that one specific file location, that should be good enough. You really don't need to apply that drop-frame adjustment until late in the editing stage when cutting to length for broadcasting. Frankly, unless the output is destined for broadcast where running time according to the timecode has to match the time on the clock on the wall, drop-frame code is irrelevant.

Sound Devices Tech Notes page suggests the following ...

48k / 30
If picture is shot at true 24 fps and to be edited in an NTSC environment.

48k / 29.97NDF
If picture is shot on video at 23.976 or 29.97 and to be edited in an NTSC environment.

[A. J. deLange]

Originally Posted by Steve House

Wonder what you'd get with capturing video onto a 24 FPS timeline with the audio recorder set to 30ND?

I doubt it would matter much. If the audio file is, for example, a BWF file the timestamp of the first file is noted and all the NLE does is count samples and display a T/C determined by whatever rule it is using knowing audio sample rate and T/C format and that's where I think the key to all this may be. If I can find the button or check box or whatever it is that lets me clearly see what the algorithm is I may be able to fully understand this -- someday.

If the file is a SDII file (from DP for example) there is no timestamp and the starting frame's timecode must be entered into FCP manually.

Let me take this opportunity to once again curse the FCC comissioners who visited this nightmare on us 50 years ago in their ruling that the NTSC aural subcarrier could not be moved a lousy 5 kHz!

[Daniel Epstein]

Michael,
Most people recommend using Non Drop when shooting 24 Frame Video as the Drop Frame Timecode Mode makes the math nearly impossible at 24P. Some camera manufacturers actually lock out Drop frame recording when using 24P.

[Steve Oakley]

Dan is right. DF TC at 23.976 over 29.97 has very messy math. FCP does NOT support it ! most NLE's don't, most camera's don't, except it seems, yours :(

if you use NDF then all should be good. not much you can do about that now. FWIW I've found that FCP translates JVC's HDV 720p24 TC from 24 to 30 ! deck counts correctly, but after frame 12 or 13, FCP starts incrementing with an offset so that frame 14 /24 is 15/30, 15/24 is 17/30. haven't quite figured it out yet. then if you set and IN or OUT point past frame 23, FCP can never cue up because when the deck single frame advances, FCP doesn't apply the same bizzarre cheat. why they are not supporting correct 24FPS TC is beyond me.

good luck, and I hope you have a clap for every take or it will be a lot of pain.

[Michael Galvan]

Hey all,

I believe my issue definitely has to do with Final Cut Pro.

It's interesting the JVC footage has a similar issue at 24p. I'll have to try doing some more testing to figure out what works here.