Using a QU16 for filming with timecode

[timhumParticipant]

It works! and here’s how.

The QU range operates with a sampling frequency of 48KHz which is exactly what is required for interfacing with video work. This makes the mixer a good choice for using with video shoots bar one thing, the lack of timecode in the operating system. I figured out a workaround for this which works, I attended the edit and saw the audio timecode match the picture timecode without drifting or dropping out.

At the shoot I took a feed of the timecode from a camera and plugged it into ST1 (input 17). This is a line input only which is good because timecode as an audio signal is dirty and prone to crosstalk into adjacent channels especially if they have lots of gain associated with them as in a mic channel. I could not hear any crosstalk and I set the level to -20 dB.
The shoot was a 2 hour gig which I recorded as one clip in multitrack for mixing down later.

When remixing I routed ST1 to Mix 1 and routed the Mix 1 output to the timecode input of my Zaxcom Fusion recorder, adjusted the level of Mix 1 to enable the recorder to pick up the signal and sync to it, added a few more dB for luck and then mixed down the tracks knowing that the timecode was recorded in real time with the audio so no drifting was possible. (set the timecode sync on the Fusion to constant jam to ensure it uses the recorded timecode of course).

Result, happiness all round and I will have confidence using this technique on more video shoots.

[DetonatorParticipant]

Nice post, thoughtful and helpful. Kudos.

-Tim T

[DJParticipant]

Sorry to raise this from the grave, but i just acquired this mixer for similar purposes, and in my testing, a 90minute video results in a 2 frame drift, which isn’t the end of the world for our application, but no drift would be ideal. Thus, i’m looking to see how i can do a workaround to get timecode into the recorded files if possible

The setup has timecode available from an LTC BNC port, and i am wondering if i get a BNC to XLR cable, and feed that into an empty channel, would that be read through usb streaming by a program such as boom recorder? It looks like it should work, but it’s outside my familiarity and looking to see if anyone knows for certain

[AndreasModerator]

Only two frames after 90 minutes? How lucky you must be, see much worse, depending on cameras, temperature, humidity etc.
LTC is fine to locate matching points between seperately recorded audio and video, but it probably does not help for long-time synchronicity. It probably depends on the capabilities of your video application to stretch either audio or video.
Proper way would be to sample-synchronize all components during recording. Since the Qu does not synchronize to something external, using the S/PDIF output would be your only source of synchronization which the cameras have to hook on.

[airickessParticipant]

Andreas, what do you mean by S/PDIF output? Surely you aren’t referring to the Qu 16.

[AndreasModerator]

Sorry I’m a techie and referring to the protocol not the connector type. AES3 and S/PDIF basically differ in signal levels (Interfacing AES3 and S/PDIF) along with tiny but essential differences within the subcode bits. So I’m referring to the AES socket which also exists on the Qu16.

[timhumParticipant]

Those two frames difference in 90 minutes would be unacceptable in many workflows. The error might be down to the camera drifting or having a one off glitch which can be caused by changing the camera battery for example. I work on a TV show where the timecode is synchronised between the sound recorder and cameras just twice during the day, first thing and lunchtime, the timecode stays in sync except for those occasional problems which to be honest amount to operator error.

Your idea of using a constant feed of timecode onto a spare channel is fine and what I did with good results. I used the ST1 input but a spare channel at line level should work too, just check for the distinctive timecode crosstalk in adjacent channels.

Contact your editor and ask if you can supply timecode as an audio track, most systems allow this but some editors don’t know they do.

USB, ABS and S/PDIF are just means to an end, as long as the timecode is recorded in the same audio file as the audio, all will be good.
Modern synchronising workflows do not always use timecode, a clapper board is a great reference whatever system may bein use and some editors are perfectly happy with that nearly 100 year old system! Putting an offset into the audio or video when synching up is routine and not an issue. Look up pluraleyes, it is used as an automatic synching system which looks at the audio waveforms on the audio and camera (feed the camera with audio or use its owm microphone).
I did a shoot with 10 cameras recently, Go Pros, DSLRs and all manner of mini cameras, only two had timecode capability and when I offered to sync those cameras with my audio, I got a blank look from the Director/Editor! Idon’t think he knew what it was but runs a production company making top quality corporate videos.

[Author]

Posts