I'm subbing just because the amount of work and detail in this video

Holy Crap this was helpful. I was on the fence about getting a TC-1 and know I know I need one for my fx6. I honestly don't know why people bother with the Ursa but I loved your video bro.

Excellent stuff. As a person whose just getting into timecode this is very helpful. I tried it once on a short film and in post some things were off. One of them was a zoom recorder so now it all makes sense. Good to hear the fx6 is doing a good job as I just bought one.

This was very helpful. The FX6 internal clock is very solid.

Amazing timing! I’m setting up a 4/8-camera BM 6K-Pro to BM ATEM-Iso switcher package. Now the beauty of their system is that when plugging an HDMI cable between devices, the switcher takes control of many camera functions, including Timecode. (Check it out elsewhere it really is impressive) The result of this setup is that when you press record on the switcher, many things can happen: - it triggers recording on All of the cameras themselves, in 6K RAW - the ATEM itself records a folder full of goodies including 4/8 1080p downres Iso files, plus the “line cut” from the switch itself - the ATEM also generates a DaVinci Resolve project file .drp that has every switch as a cut/dissolve on the timeline So the idea is that at the end of a multicam shoot, whether you actually switch or not, you can hand the editor 1 SSD drive, and they can launch DaVinci and pickup in post right where production left off, with everything already in sync on the timeline, saving a ton of time. The post editor can then adjust every cut choice made by the live technical director, and perfect the final edit “master”. After that, because the Iso files were recorded in 1080 by the ATEM, AND in 6K RAW by the cameras themselves, you can link back the picture lock to the RAW files and color grade Digital Cinema footage for a multicam production, something unheard of not long ago. Pretty f**cking incredible. But in testing, the Camera Iso files didn’t sync…. They’re 2 frames off!!! All Blackmagic equipment, using their own intended workflow. So now I’m getting in the shower, heading over to Cinegear happening TODAY on the Paramount Pictures studio lot, and my first stop is Blackmagic to ask my guys over there WTF? I’ll keep you posted….

@G_handle

Жыл бұрын

Oh and my next test was going to be buying 3 of the Deity 3-packs and sticking them on everything. Glad to know that won't change anything!

@deadendboredom

Жыл бұрын

Yes please keep me up to date, I haven’t talked to Blackmagic about it yet. And give them a slap from me for the URSA‘s 5 frames. If there were the possibility in resolve to select all clips and move the Timecode of all at the same time by 2 (or 5 etc.) frames, you could at least correct it relatively quickly in post. I have been hoping for an update on this for a long time.

@G_handle

Жыл бұрын

@DeadEndBoredom Hey quick update: So I spent about an hour with my BM people at Cinegear yesterday. A) they're loosely aware of the issue here in LA (remember the company is Australian) and they're going to dig into it to see what's going. Then suggest fixes / Solutions. B) I'm going to go to thier Burbank office Tuesday afternoon and take some timecode gear (Denecke, Zoom, Mac running Horea, obviously BM gear) for us to test then, and then leave a large TC reader with them for them to extensively test with later. C) If you have any thoughts or specific ideas on what to test, or things you've noticed, let me know asap so I can include. D) we had a conversation in the context of thier cameras and thier switchers generating project files that don't match sync (2 frames off) and they (LA) had been aware. However your point is that basic TC input is being recorded 2 frames off right at the camera input, leading the search there. (And 5 frames on the 12K?) E) As possible solutions, 1-the camera, 2-the Switcher, or 3-Resolve can be made to correct this. But the Upstream solution seems to be at the camera(s), both for multi-cam sync but also Any other syncing, like frame accurate sync-sound. F) Lastly, so obviously I'm looking for bulletproof long-term solutions, but in the meantime: You mentioned not being able to batch offset the timecode of multiple clips which I thought was possible. Briefly brought that up and they thought so too. Should be as simple as shift-selecting a group of clips in your project in the Media tab, right clicking on any while that group is selected, and going to clip attributes, then timecode and making the change. That should offset All of the clips. This is all from memory, didn't test myself yet but I will. Let me know though if you did try and ran into trouble so I can bring that up as well. Again, from my perspective, timecode offsets are a fact of life and Every post app should have an easy way to address it. But in this case, Blackmagic made Everything in the pipeline, AND are featuring this essentially Proxy Workflow as a reason to buy their system. But you can't re-link to the camera originals if the proxies are 2-5 frames off!

@deadendboredom

Жыл бұрын

@@G_handle Great that you are on it! Here in Germany I don’t have the opportunity to go directly to Blackmagic. Selecting several Clip and setting the timecode offset in the clip attributes does not work. If you have selected several, the frame offset is grayed out. It only works if you have selected a single clip. I’ve seen many discussions on the topic online, where people also say that it should work, but it doesn’t and it doesn’t seem to work for everyone else either. A few things I noticed: You can’t trust the displays of the devices when it comes to the timecode display, because the screens usually have a delay. So there is no point in filming the camera display and a timecode generator and comparing the times. In my tests, I recorded several devices and synchronized via an optical flash, the audio recorder via the sound. I then marked the clips at the point and synchronized them using timecode to see the offset. It is important that the bottom clip to which the others are synchronized is correct. Otherwise, you only see the difference between the cameras, but not the difference to the correct timecode. The more devices you test at the same time, the more you can recognize patterns that allow conclusions to be drawn about which devices are running correctly. It may also be that I have not tested enough devices and that I have classified the wrong devices as trustworthy, but that you had the same problem with 2 frames offset makes me believe that I have bet on the right horse.

@G_handle

Жыл бұрын

@DeadEndBoredom Thanks for getting back to me. (And we should probably shift to email or something, rather than the KZread comment section) Between your video and what you've written I think I see your approach. A) I think this will take time to suss out comprehensively. And I think BM at least are dedicated to doing that, but we'll see how tomorrow goes. B) From the Resolve perspective, that's where everything in production (Single cam sync sound, Multi-cam live production) ends up, and BM need to make sure DaVinci (and it's driver) can make sense of/ handle whatever it's given. In my specific case it's all coming from their own products! In your video's case (and my real life) there are Many devices that all need to sync up. And an NLE especially this Super-NLE have to be able to get everything together, no matter where it's from. C) In the interest of time and priority, I think getting them to focus on thier own ecosystem is the best start, one because it's in thier own best interest, also because it's the least outstanding variables and has internal controls, and because I've already Bought all this stuff and plan on buying more. From there I think "best practices" will emerge, and hopefully an all BM ecosystem will become watertight. After that, introducing other outsude devices should reveal what's incompatible or out of sync. D) That's approaching the problem from the opposite end to where you rightly attacked it. The sources themselves. I one-hundred-percent follow the philosophy of starting upstream at the source. If we go back to a time when Film used Dumb Slates and manually synced picture and sound to the clapper for Every shot. To the Broadcast workflow where everything had hardline-BNC Timecode as well as Genlock (which btw the BM people are also very much interested in investigating. Remember, they're selling cameras and switchers that need to Lock perfectly, so not only should they be frame accurate, but the scanning of each sensor should start at the same time on pixel one). E) Nowadays we have multiple synchronization solutions. -Dumb Slate -Timecode Lock and Smart Slates -Waveform Sync So ultimately I'd like to test everything comprehensively and Know what is going to happen in Post when I make certain choices in Production. Using ALL Three of the systems above, and in different configurations, is in order (and I think resonates with your testing). To start with: -running common TC out hard-line to multiple cameras and other devices TC inputs. -running that same code to Audio inputs on those cameras -running that same code to a Timecode Display Reader (like the running code on a Smart Slate, but bigger) that is Visually recorded by the cameras. That test should determine whether the Video, Audio, and Timecode Inputs of a camera are in sync and precisely by how much they are out of sync. (I'll probably duplicate or triplicate the clips and convert thier Metadata Timecode to reflect which is which. Actually probably quadruplicate! And throw a clap-sync in there as well) F) So to recap (more for myself than you) I'm looking at two main categories: Syncing from the Switcher to the Camera ISOs in an Offline/Online proxy type workflow. And Syncing sources individually and figuring out offsets with the various types of synchronization that we do these days. (And there are 4 sync types not three. I should go above and correct it, but I'm too lazy) So today I'm going to gather up a ton of gear to take with me for testing. If you think of Anything else, please speak up! And how can we connect outside of KZread. Maybe leave a comment that you can delete after I get it.

Fantastic test, thank you

Awesome test.

Fantastic video. I use the FX6 and FX3 with MixPre3-II and recently purchased the TC-1 set after dealing with these drift issues at 12 hour long events. One thing I'm left wondering is if the timecode is only captured at the start of the recorded clip and if it switches to the internal clock while recording, in which case it would drift during a long continuous recording (1-2 hours). Was there any indication of this happening?

@deadendboredom

Жыл бұрын

I have not seen any indication that only the first frame is provided with the external timecode and then switched to the internal timecode. As long as the external timecode generator is connected, the internal timecode is linked to it. This is also indicated by a small symbol next to the timecode, such as "EXT-LK". I cannot rule out the possibility that something is happening behind the scenes that we are not aware of... Some technical issue, but so far, I haven't seen any signs of it, and I don't know why it would be programmed that way to have only the first frame come from the external timecode. But I also have to admit that I never take takes that are longer than 1.5 hours and that is also very rare. If you have conducted tests or have any other indication or reason for your suspicion, I would be very interested to know, and we could further investigate the matter. EDIT: I can actually imagine a reason for how this could happen. I’ll get to the bottom of it.

@deadendboredom

Жыл бұрын

Hold on tight, I did a test and gained the following insights: I connected the FX3, FX6, and F8n recorders with the timecode generator and conducted a continuous recording for over 8 hours. During that time, I filmed all the displays and a properly configured timecode slate at various intervals. To have enough space on the memory card, all tests were recorded in HD. The first insight: The FX6 seems to split a clip at around 140 GB. The FX3 does not split a clip (tested up to 195 GB). The F8n splits clips after 2 GB. After synchronisation, the FX6's split recording loses 1 frame, but overall, both cameras remain on point after nearly 8.5 hours of constant recording. The timecode also remains accurate, except for a slight discrepancy when placing the clips directly back-to-back. The clip separation occurred at around 6 hours, and up until then, the cameras were identical. All in all, this suggests that the external clock has full control, and when connected to the timecode generator, there is no drift during long continuous recordings. However, keep in mind that clip separations due to file size limitations can create tiny gaps, but the timecode remains correct.

@hbp_

11 ай бұрын

Time code doesn't (usually) sync the internal frame clock of the camera or the clock of an audio recorder. It's just metadata that is stamped in each file. E.g. if you record 8 hours of video on two cameras with the same TC the frames you'll have are not taken at the exact same moment and the cameras will likely capture a different number of frames. Similarly two audio tracks on different devices won't be in sync at the lowest level. The only way to make sure that two or more devices are exactly in sync at frame level (a frame is recorded at the same moment) is to use genlock or some other clock sync method. Practically lets say you have two BMD URSAs and an SD mixpre. You could have a genlock generator feeding to the URSAs and then run sdi -> hdmi to the mixpre (which can sync clock from HDMI). However, the audio sync will be delayed by a few frames because URSA's SDI out has a constant delay and so does the SDI to HDMI conversion. Now TC between the cameras won't be in sync because BMD doesn't have a dedicated TC input. That could be fixed by actually feeding them an SDI signal w/timecode instead of genlock. Lastly you could also do the Sony way and chain from the SDI out to the SDI in of each camera. Again this adds a constant delay for each device in the chain but it's easy to offset.

@deadendboredom

11 ай бұрын

@@hbp_ How do you come to the conclusion that the internal clock isn't synchronized? If you connect an external timecode generator and then immediately disconnect it, you can observe that the internal clock has synchronized with the connected external one, and it continues running that way after the connection is severed. Without genlock, it might not be perfectly frame accurate, but unless you're producing stereoscopic 3D content, I'd posit that the difference of a fraction of a frame isn't so relevant. I'm a bit unclear about your example involving BMD and MixPre... Why go through the hassle and struggle with output delay when all devices have a timecode input? Blackmagic supports timecode input... and as I found in this video and Blackmagic has also confirmed, there's an unintended offset of 2-5 frames depending on the model, which hopefully will be fixed in the future. Regarding your last point, I have to disagree: Taking the FX6 and FX3 as examples from the test, if I connect the dedicated timecode output of the FX6 to the timecode input of the FX3, the result is that the timecode of the recorded clips is frame accurate and doesn't have a delay of several frames. Is there a misunderstanding or is there something from your statements that I haven't quite grasped correctly?

@deadendboredom

11 ай бұрын

P.S. If your issues with delays are like a tangled dance between timecode delays from video output signals, or the acrobatics of timecode going from SDI to HDMI and then somersaulting into another device, I'd humbly suggest giving external timecode generators a whirl. Sure, they might cost around 200€ a pop, but unless you're rocking a black magic camera with the infamous Timecode Input Delay bug, they could be your ticket to solving a multitude of troubles.

Nice vídeo. I came from a problem that i spotted: my ursa mini pro g1 can only read time code when the mini jack on deity device is barely plugged in. If I put the cable all the way in it no show the “ext” on lcd screen. If I put just a little (the 3.5mm side) it shows the “ext” flag on lcd. Does anybody knows what could be? I’ve tried with 3 different time code box

@deadendboredom

3 ай бұрын

Strange. What I can imagine is: with most timecode generators, there are different modes in which the timecode can be output. Either normal for timecode, or at microphone level (to record it on an audio track), or even on one channel at microphone level and on the other channel (as with the TC1) the integrated reference microphone. I'm not exactly sure how the URSA G1 would handle this with its timecode input if there's a microphone level on one channel and a microphone input on the other, and maybe it only works if the plug is halfway in and only the correct channel is received. But if the TC1 is set to "L-OUT" and the problem still persists, then, apart from a defect, I can't think of any reason why these issues would occur.

I just tested my Ursa 12k and found 4 frames on mine. bonkers.