-
Audio sync problem.
In an effort to find out how good/bad the sync was between my Canon XL2 and my Sound Devices 744T, I recorded from the XL2 to an FS-4 Firestore set to QT movies last night for about an hour last night while simultaneously double recording to the 744T. Same sample rate; 48kHz.
Today, the audio waveforms from the XL2 to FS-4 and 744T lock up visually on the timeline, but the 744T AUDIO quickly walks away from its own waveform and is not in sync. SO what I’m seeing on the timeline for the 744T does not match its own waveform. I dumped the waveform cache, took the 744T tracks off the timeline, restarted the machine, and put the the file back on the timeline from the FCP browser. Same problem.
Solution?
Thanks,
Ty Ford
Want better production audio?: Ty Ford’s Audio Bootcamp Field Guide
Watch Ty play guitar -
1 Reply
-
No takers?!
FTR, here’s the answer, I’m guessing
Final Cut Pro (version 6.02 and higher)
Final Cut Pro changes an imported audio file’s playback speed if it detects that the file’s iXML TIMECODE_RATE flag is different from the Project frame rate. This results in sound playing back at a different rate than its original sampling rate, resulting in drift between picture and sound.To make certain that Broadcast Wave files play back at the correct speed in Final Cut Pro, it is important to ensure that their time code frame rate is the same as the Final Cut Project frame rate. This also ensures that the start time code value is calculated correctly, preventing time code offsets between picture and sound.
Here is an example of what can go wrong . . .
The Sound Devices 552 running version 1.1 firmware stamps the iXML TIMECODE_RATE with the frame rate of the connected external time code source. When the 552 is used in a non-sync scenario, with no external TC source connected, the 552 defaults the iXML TIMECODE_RATE to 30 fps and uses the time-of-day for its time code value. If the files are to be imported into a 29.97 fps-based Final Cut project, FCP will detect the iXML TIMECODE_RATE of 30 fps and assume that the files should be slowed down by 0.1% during playback. This will show up as an increasing drift of audio against picture. The drift becomes more severe as file length increases.
Workarounds:
Use Wave Agent to batch-convert the BWF files to 29.97ND, even the though time code value is not relevant.
During production, feed 29.97ND time code to the 552 from an Ambient, Denecke or similar sync box even if the material is to be manually synced in FCP.
To prevent this issue in the future, the next 552-firmware release will clear the iXML TIMECODE_RATE flag when there is no valid external time code detected. This will prevent Final Cut from altering playback speed of the 552 files.Want better production audio?: Ty Ford’s Audio Bootcamp Field Guide
Watch Ty play guitar
Reply to this Discussion! Login or Sign Up