Jump to content

Audio timecode track sent wirelessly from 664


mross

Recommended Posts

Does anyone here have any experience related to sending timecode wirelessly to a camera audio track and the workflow of using audio timecode in post?

 

Timecode sync is essential for a upcoming production i will be working on and the style of Doc won't allow for TC slate or anything like that. 

 

Using the 664 I will be sending audio via 2 channel hop. I would like to attach a lockit box to ensure sync but there will be no TC I/O on the camera unless a extension is added. 

 

I'm pushing for the extension but if the budget won't allow it I, would the below set up work?

664 TC Lemo to TA5 female into the Lectro SMQV, then from the Lectro dual receiver to camera,

 

To me this seems risky and it would be a massive headache, especially if in post if the TC can't be decoded for whatever reason.

 

Also don't think pluraleyes will be an option as I read in this forum that it doesn't like multi channel audio files?

Will be 8+ tracks poly wavs mostly. 

 

Any thoughts?

 

Thanks in advance!!!

Link to comment
Share on other sites

You said you have a lockit available? You could use it for the TC. You'll have more reliable TC on your camera than if sent wireless. And you save one hop channel. Relying on audio TC is just as risky as PluralEyes if you have a post team that doesn't know how to deal with it.

Link to comment
Share on other sites

I'm not a fan of wireless timecode unless it's going to a Zaxcom unit or a Timecode Buddy where it'll jam in the event the transmitted timecode stream is momentarily interrupted. Wireless transmission is very flakey in general, especially for something as demanding as timecode bits. I think a jam box (Ambient or Denecke) is much more reliable.

Link to comment
Share on other sites

why not add a small TC box like a Tig QL (or Lockit or similar) to the camera?

wouldn't me much bigger nor more expensive then our wireless tc hop (saves you one channel of wireless).

 

but yeah, plural eyes gave me trouble last time when i had files with different track count - anybody knows if that has been resolved? (i guess ideally you could tell it which track to look at for synch waveforms)

chris

Link to comment
Share on other sites

"unless [an] extension is added"

sounds to me like there might be some unrealistic expectations higher up the chain...

tell your client if they want timecode sync, you can provide a syncbox, as long as the necessary implements are in place to do so... otherwise, they will be using PluralEyes...

end of discussion.

you're not a miracle worker. there are limitations to our craft. make the client understand this in as diplomatic a way possible.

~tt

Link to comment
Share on other sites

Pay attention people, there's no TC in on the camera........

 

yes, as far as i understood the question was about audio timecode or plural eyes, no?

 

both possible, so i would discuss the advantages and disadvantages with post and producer and let them decide (and of course shoot a test ;).

 

chris

Link to comment
Share on other sites

Pay attention people, there's no TC in on the camera........

read the OP again...

"Using the 664 I will be sending audio via 2 channel hop. I would like to attach a lockit box to ensure sync but there will be no TC I/O on the camera unless a extension is added. "

(That last part is key)

...so, add the extension and be done with it. if they opt not to add the extension, that's their choice... and they choose to try and sync using Pluraleyes... not your luggage, don't pick it up and carry it around for them.

~tt

Link to comment
Share on other sites

no one is suggesting that... give them the information and let them decide - it's pretty simple.

Why bend over backwards trying to add audible TC to hops and all the headache that entails, when a perfectly eloquent solution is right at the fingertips in the form of an extension and a syncbox -- if they choose not to go that route, leave it at that -- trying to run audible TC is like stepping back 20 years - just because a client doesn't want to bother with a simple extension for TC? Sounds unrealistic to me.

~tt

Link to comment
Share on other sites

no one is suggesting that... give them the information and let them decide - it's pretty simple.

Why bend over backwards trying to add audible TC to hops and all the headache that entails, when a perfectly eloquent solution is right at the fingertips in the form of an extension and a syncbox -- if they choose not to go that route, leave it at that -- trying to run audible TC is like stepping back 20 years - just because a client doesn't want to bother with a simple extension for TC? Sounds unrealistic to me.

 

 

agreed. i find audio timecode worth considering for cameras that don't have any TC capabilities and if post is ok with it, but if there's a module why not use that? unless it's a ultra low budget shoot where nobody gets paid it's probably cheaper in the end too (less time wasted on set and in editorial).

Link to comment
Share on other sites

Pay attention people, there's no TC in on the camera........

Funnily enough, this makes no difference to the suggestions made above. A sync box on the camera is always more reliable than transmitting TC wirelessly as an audio signal. The sync box outputs audio, too, so this would still be the best solution
Link to comment
Share on other sites

Funnily enough, this makes no difference to the suggestions made above. A sync box on the camera is always more reliable than transmitting TC wirelessly as an audio signal. The sync box outputs audio, too, so this would still be the best solution

...until the TC recorded to an audio track bleeds all over the dial...

Didn't the OP say they were considering an extension for a syncbox? so, sway them in that direction... if they decline, let it go. Putting TC on an audio track just seems like such an antiquated and troublesome method with all the options available today.

~tt

Link to comment
Share on other sites

Funnily enough, this makes no difference to the suggestions made above. A sync box on the camera is always more reliable than transmitting TC wirelessly as an audio signal. The sync box outputs audio, too, so this would still be the best solution

The sync box i have is the Denecke SB3, could i go BNC to XLR out of the Denecke box into the camera?

 

It has no levels or other outputs available. 

Link to comment
Share on other sites

read the OP again...

"Using the 664 I will be sending audio via 2 channel hop. I would like to attach a lockit box to ensure sync but there will be no TC I/O on the camera unless a extension is added. "

(That last part is key)

...so, add the extension and be done with it. if they opt not to add the extension, that's their choice... and they choose to try and sync using Pluraleyes... not your luggage, don't pick it up and carry it around for them.

~tt

Thanks Taylor, ya they mentioned the option of using a timecode audio track instead and I'm trying to get as much info to see if it is even a realistic option or more trouble than its worth.

So it really isn't reliable then especially compared to using a timecode input that stamps the files?

 

Definitely pushing towards the extension, I don't think the editor will want to go with the audio track timecode route either. 

All the info helps, I really don't have experience sending LTC onto an audio track, I've always used the TC input or used a slate. 

Link to comment
Share on other sites

The sync box i have is the Denecke SB3, could i go BNC to XLR out of the Denecke box into the camera?

It has no levels or other outputs available.

Yes. Remember that a TC signal is essentially an audio signal. The SB3 doesn't need a level control, but your camera should have one.
Link to comment
Share on other sites

...until the TC recorded to an audio track bleeds all over the dial...

Possible of course, but something I have never encountered in real life. YMMV

Even if it did happen the audio on the other channel should not be production soundtrack, but for reference only. So a bit of bleed shouldn't matter.

Considering all the options, without said extension, I think that this one is most reliable. It may not be the most elegant solution, but it is one that works. It's not that much more work than working with timecode embedded and especially no more work than PluralEyes IF the editor knows what he's doing and has all plugibs available.

Link to comment
Share on other sites

Possible of course, but something I have never encountered in real life. YMMV

Even if it did happen the audio on the other channel should not be production soundtrack, but for reference only. So a bit of bleed shouldn't matter.

Considering all the options, without said extension, I think that this one is most reliable. It may not be the most elegant solution, but it is one that works. It's not that much more work than working with timecode embedded and especially no more work than PluralEyes IF the editor knows what he's doing and has all plugibs available.

Right on, the production is checking with the editor, I think they will go with the extension but it's great to know that I could do it this way with the Denecke box rather than wireless. Thanks!

Link to comment
Share on other sites

Sending LTC timecode to a camera from an syncbox is not a problem. Timecode signal is like a pulse wave with width modulation. Just make sure that the amplitude is not peaking. I don't think it could bleak to the other track. Maybe i'm mistaken but wasn't the bleading a problem only with tape?

Link to comment
Share on other sites

Maybe i'm mistaken but wasn't the bleading a problem only with tape?

Yes and no. What's referred to here is called crosstalk, where the signal from one channel (or more) bleeds to another channel. So bleeding is not incorrect and it's not confined to tapes.

The bleeding of tapes is actually called print-through, so it's off by just as much, i.e. not much.

Link to comment
Share on other sites

  • 4 weeks later...

Yes and no. What's referred to here is called crosstalk, where the signal from one channel (or more) bleeds to another channel. So bleeding is not incorrect and it's not confined to tapes.

The bleeding of tapes is actually called print-through, so it's off by just as much, i.e. not much.

Often the cross-talk in tape recorders is in the only place you can't shield, the record head. This was a common problem doing cassette transcription tapes even when the proper cable hygiene was observed and the timecode was properly padded down  before it hit the recorder and recorded at an appropriate level. Once you beat the level down hard enough, print-through wasn't really a huge problem. I still have a mess of cassette decks somewhere out in the shop and a bunch of now useless purpose-built cables, a couple of modded direct boxes and bad memories of hundreds thousands of hours of interviews making transcription recordings with an audio timecode track. The Jukebox MP3 recorder fixed the problem audio-wise but the horrible user interface made up for the lack of timecode bleed. Everything was fine until you fat-fingered the pause button and stopped the recording rather than pause it. Since there was no auto file number incrementing, you had to take the time to rename the file or erase what you'd just recorded. Progress of sorts, I suppose.

Best regards,

Jim

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...