Mikisuke Shimadzu Posted January 4 Report Posted January 4 I recently finished shooting two feature films using Zaxcom Deva24 and had some issues with timecode that I would like to share here. The editorial department reported that in the timecode sync process of all cuts, the sound preceded the picture by an average of two frames. At first I suspected that the problem might be caused by the camera, but when two films shot with different cameras both pointed out a two-frame error, I changed my mind and did a test at a later date using only my own equipment. I tested recording Deva24 and Fusion(also made by Zaxcom) simultaneously with the timecode boxes synced, and interestingly, the result was that Deva24's audio files were always about 1 and 1/2 frames ahead of the timecode. It appears that Deva24's timecode recording method is the cause of the problem, since this is the case no matter how the individual timecode boxes are swapped. Has anyone else had a similar experience working with Deva24?
Mark LeBlanc Posted January 4 Report Posted January 4 Greetings, A few questions.... 1. What firmware is your DEVA 24 running?? 2. What Frame rate are you using?? I've had my D24 at 23.97 and 24fps with no issues. 3. Are you using a sync box as master clock or internal timecode of Deva? For reference I, like many, use an external sync box.. thx
Mikisuke Shimadzu Posted January 4 Author Report Posted January 4 1 hour ago, Mark LeBlanc said: Greetings, A few questions.... 1. What firmware is your DEVA 24 running?? 2. What Frame rate are you using?? I've had my D24 at 23.97 and 24fps with no issues. 3. Are you using a sync box as master clock or internal timecode of Deva? For reference I, like many, use an external sync box.. thx Thanks for the reply. 1. My Deva’s firmware is v4.12. (The most recent version at this time) 2. The two films with errors of two frames repoted by the editorial department were at 23.976 and 24. Later testing was done at 23.976. 3. I’m using an external sync box (Denecke JB-1) as master clock. And I’m also using the other JB-1s for the boxes that attach to the cameras.
Matthias Richter Posted January 4 Report Posted January 4 one potential reason: the D24 will re-jam to the external TC only if the drift between int and ext exceeds 1 frame. This is to prevent the TC out of the D24 from discontinuity. That is even if the D24 set so „Cont Jam“
Mark LeBlanc Posted January 4 Report Posted January 4 Will Echo Matthias reply that My Deva is set to Cont Jam to make sure the Deva is sync'd to my external boxes.. Other than that where the cameras used on the 2 projects the same? and which cameras were used? I would also try doing a Factory Reset of both the Deva and TB1. Was this the same Post house reporting the issue? And how did they determine this was an issue?? Last... What wireless??
Matthias Richter Posted January 4 Report Posted January 4 what I was trying to say was: unfortunately the D24 is NOT jamming continuously to an external TC-Box. Only after the drift becomes bigger than 1 frame will the D24 jam again. So the drift (0.5 upto 1 frame) you were seeing in your test is caused by the D24 itself.
Mikisuke Shimadzu Posted January 4 Author Report Posted January 4 1 hour ago, Mark LeBlanc said: Will Echo Matthias reply that My Deva is set to Cont Jam to make sure the Deva is sync'd to my external boxes.. Other than that where the cameras used on the 2 projects the same? and which cameras were used? I would also try doing a Factory Reset of both the Deva and TB1. Was this the same Post house reporting the issue? And how did they determine this was an issue?? Last... What wireless?? The cameras used in those films were RED GEMINI and Sony FX9. And I mainly use Sony and Shure wireless. But the test using only Deva24 and Fusion was done with a wired microphone, so I believe this problem is due to a different cause than the camera or wireless. The editorial staffs of the two films were different. It was more of a personal conversation that came up, rather than being officially reported as an issue. I will try the factory reset next time. 31 minutes ago, Matthias Richter said: what I was trying to say was: unfortunately the D24 is NOT jamming continuously to an external TC-Box. Only after the drift becomes bigger than 1 frame will the D24 jam again. So the drift (0.5 upto 1 frame) you were seeing in your test is caused by the D24 itself. Thanks for the helpful information! However, I am curious to know that Deva24’s audio files were always about 1.5 frames ahead of the Fusion’s audio files, even in the tests I did with Deva24 and Fusion. It seems to me that Fusion probably has the same continuous mode behavior…
Bouke Posted January 5 Report Posted January 5 First, I have no clue on how this could happen, but QTchange is able to batch change (add positive or negative offset) all files of an entire feature in a matter of seconds. However, since it was originally based on QuickTime files only, the interface accepts only timecode to offset. If needed, I can add milliseconds or samples to make it more accurate. Just ask...
Mikisuke Shimadzu Posted January 6 Author Report Posted January 6 On 1/5/2025 at 10:09 PM, Bouke said: First, I have no clue on how this could happen, but QTchange is able to batch change (add positive or negative offset) all files of an entire feature in a matter of seconds. However, since it was originally based on QuickTime files only, the interface accepts only timecode to offset. If needed, I can add milliseconds or samples to make it more accurate. Just ask... Thank you, Bouke. I have tried the demo version of QTchange! I am very impressed as it seems to be a powerful solution to a problem I am facing right now. If it is possible to offset milliseconds and samples, both would be very useful and great. I would love to ask! One question, It seems that once a WAV file is loaded into a ProTools session and then offset with QTchange, it is not reflected in the ProTools session. If a file was processed in QTchange before being loaded into a Pro Tools session, the offset is reflected in Pro Tools with no problem. Do you have any advice on how to solve this problem?
Bouke Posted January 6 Report Posted January 6 Hi Mikisuke, It's a problem in a lot of apps that 'known' files have 'sticky' metadata. Avid (owner of PT) keeps a database with metadate that is hard to update. A forced (re) import can be needed. Renaming the assets is one option, but I'm not a ProTools guy. (I used to be a video editor, I know a lot about media composer...) I'll alter QTchange when I'm back from holiday, that will be end of this week. (Sitting in the south of Portugal now, nice sunny weather 🙂 But, another solution would be to just wait it out, Trump will fix it! Bouke
Mikisuke Shimadzu Posted January 6 Author Report Posted January 6 1 hour ago, Bouke said: Hi Mikisuke, It's a problem in a lot of apps that 'known' files have 'sticky' metadata. Avid (owner of PT) keeps a database with metadate that is hard to update. A forced (re) import can be needed. Renaming the assets is one option, but I'm not a ProTools guy. (I used to be a video editor, I know a lot about media composer...) I'll alter QTchange when I'm back from holiday, that will be end of this week. (Sitting in the south of Portugal now, nice sunny weather 🙂 But, another solution would be to just wait it out, Trump will fix it! Bouke Sorry I may have interrupted your holiday! My guess is that Trump would not care about a two-frame gap.
Bouke Posted January 6 Report Posted January 6 Trump indeed does not care, yet. He'll fix that first. (You did not interrupt my holiday, I'm bored as hell...) Science reveals: People believe anything if it's preceded by Science reveals:
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now