Jump to content

Recording TC on audio track issue.


johngooch

Recommended Posts

Revived this thread-  scroll down to bottom for new posts.   

 

 

Hi everybody,

 

I've run into a weirdness with TC.  I was helping a friend on music video project and it was decided that we do a live recording and treat the project as live concert.  No playback to artists.  

 

I decided to feed TC a pro-tools system that was manned by one of the bands mixer.  I am not a pro-tools person.  Audio was fed to the 16th track of the pro-tools input.  The TC source was an ambient slate.

 

When the tracks were mixed and distilled down to stereo master the editor was delivered 3 mono wav files.  L/R/TC.   In avid the Audio TC to be rendered as readable TC.  Some TC files were readable some were not.  

 

Doing some research as to why some files were good and some were bad,  i listened to wav files and found that some devices were able to read the code some simply would not.  Some devices needed the TC to be bumped up in level to be read.  The code was recorded at -6db. 

 

 tried to use GR-1 as a reshaper but that had no effect on stability.

 

Ambient slate:  Read code just fine without need to adjust level

Ambient Iphone App: Read code without adjustment.

Denecke GR-1: Read code with adjustment of level

Movieslate:  Needed adjustment of level to read with any stability.

Denecke Time code toolbox app:  Refused to read any of the code.  

 

So my question is --  has anybody had an issue like this with audio TC?  Some devices reading code and some not?  Is avid temperamental regarding Audio TC?  Is there a particular level that it likes?  

 

Thanks,

 

john.

 

 

Link to comment
Share on other sites

Well, yes, an assumption that TC will read w/o issues has only been possible since we've had file-based recording. Before that, TC on analog tape, TC off DATs etc was always kind of a crapshoot.  Running the LTC through audio devices always rounds off some of the squarewave edges, and various devices etc have varying tolerance for how smushed the waveform can be and still be able to recover readable TC.   I'd take a look at a piece of the TC that won't read well in PT or any waveform editor and make sure there are no dropouts.  Even really tiny dropouts, if they come at the head of the TC word can make the TC unusable by some devices.  Also check and see that the level is consistent, both zoomed in and zoomed out.  There may also be an issue with the frame boundaries of the TC being really different from those of the recorder (PT) or from the Avid.  You mention that you fed TC from an Ambient box to an audio channel of PT, but the PT's own sample clock was not being controlled by the Ambient box as well (or was it?).

Link to comment
Share on other sites

Ah, if the timecode is not locked to an external reference, it's basically free-wheeling. You have to feed the timecode into Pro Tools HD with a Sync HD box and lock it to word. I don't think regular Pro Tools will do this, nor can you embed external timecode into the file itself (not on a track). Having said that, you can probably manually correct sync every so often, and the drift may not be catastrophic -- my bet is a couple of frames every 10 minutes, maybe less.

 

I'd bump the level up in Avid and see if that changes anything. But be prepared to slip and slide it in the edit.

Link to comment
Share on other sites

Ok-- all good information.  Memories of coaxing resolvers to play nice back in the 1/4 world......  

 

Pt operator- was overloaded and did not want to entertain changing his reference...  The drift from having no lock is something editorial can deal with.  In fact the show is mostly cut.  It was the inconsistent acceptance of the recorded TC that thru me off.  

 

Thanks!  Now i know...

 

john.

Link to comment
Share on other sites

  • 2 weeks later...

Hi John,

 

From the list you gave, it seems the only things that wouldn't read the timecode were the Movie Slate app and the Denecke Tool Box app, which I assume both were using an iPhone or iPad. The apps are solid, but the iPhone and iPad are finicky with regards to levels and interface cable wiring schemes.

 

There is no reason that recording timecode properly as an audio track shouldn't work reliably. My guess is that there was a intermittent cable issue or a level issue. You mentioned that it was recorded at -6 on the track, but what may have happened before it got to the track could explain the problem.

 

gt

Link to comment
Share on other sites

Hi again, John,

 

Today I did some testing related to the discussion here. I recorded timecode simultaneously on three audio tracks at different levels: -20dBfs, -10dBfs, and 0dBfs (max).

 

The setup took LTC timecode out of a Deva-5 generator, plugging it into two analog inputs of the same Deva with trim set so that the input level was about -5dBfs.

 

Input 2 went prefader to track 3, with trim adjusted to record at -20dBfs.

Input 1 went prefacer to track 2, with trim adjusted to record at -10dBfs.

Input 1 also went postfader to track 1, with the fader adjusted to recorded at 0dBfs (max).

 

The timecode was played back from each of the tracks to Denecke TS-C, iPad, and iPhone. Each device had no trouble reading the timecode from each track. This was true even when varying the output levels from quite low (metering at the lower 25% of the iDevice's meter) to very high (+4dB, maxing out the iDevices meter). The apps used for the iDevices were Movie Slate, Denecke Tool Box, and Ambient Clockit.

 

So, it seems that the useful information from this test is that when recording timecode as audio onto a digital recorder, levels recorded on those tracks can range from -20 to 0dBfs (max) and still be easily read when played back. Therefor, it seems logical that the likely culprit in your case, John, was either in the cabling going to the Protools rig or in the Protools recording process.

 

Glen Trew

Link to comment
Share on other sites

I just saw these more recent posts on this thread. Very interesting.

Jeff- The tc was input thru a patch bay that fed into the protools rig. Should have gone straight into PT or did a line test

Glen- thanks for doing your tests. Inhind site in agree that cabling probably was to blame. But not sure how the inconsistencies are explained between devices. Not sure why GR-1 seemed to have no effect - I always thought if GR-1 could read the code then reshaped code output from the GR-1 would be stable and cleaned up.

Again thanks for your posts! Sorry for delay in response.

Link to comment
Share on other sites

  • 1 year later...

Reviving this thread.   I am about to embark on another project where I my plan is to to put TC on a pro- tools track. I am going to record code at -15dbfs.  Feeding directly to Protools from SB-3.   I will put a reader on the pro-tools output to confirm that it is getting signal.  Not locking to word.  I am ok with a few frames drift.  

Asking now now before I shoot this time - instead of conducting post mortem analysis.....

Again in thanks for your input from first version of this thread - particularly Glenn Trew who did some valuable tests. 

 

John  

 

Link to comment
Share on other sites

9 hours ago, johngooch said:

Asking now now before I shoot this time - instead of conducting post mortem analysis.....

not sure what you're asking?

but my answer is, do a full end to end workflow test with the same gear you're planning to do the shoot and see if it works as you need it to - better then any theory.

chris

Link to comment
Share on other sites

Well, what do you want this TC track to do for you?  Be a ballpark reference of where you were in the shoot or event? Or act as a way to post-sync camera files?  It seems like you understand the diffs between TC that is or isn't in lock to cameras.  I take it the PT system will be running off its host computer's clock?

Link to comment
Share on other sites

The time code is a reference for post. PT system will run off its own clock.   It does not have to be perfect synch, so i am forgoing locking to word or other sync source.  The original question that was posed at beginning  of this thread had to do with why in some cases on a previous shoot the TC was just fine and some takes it was not.  So going into this same situation again, i was wondering if there was a way to improve my gameplan before we started shooting.  I think just lowering the TC record level is probably going to make things alot better.   

Probably not much room for improvement but thought i would toss it out there...   much agreed- testing of workflow by running thru the entire production and post process would be best-  But this is a doc.  I am hitting ground running and have narrow window of opportunity to tweak anything.   OR- they eyeball synch and that is just too bad :0

Thanks you for everybody's input.

 

j

 

 

 

 

Link to comment
Share on other sites

  • 2 years later...

Working on a music video playback setup where I have printed 5minutes of LTC audio from http://elteesee.pehrhovey.net/ in Pro Tools to the Right channel, married it with a mono version of the song on the Left channel. The LTC file downloaded is very hot, peaking at around -6dBfs, I left both that file and the song’s clip gains untouched, bounced them out together (with 2 pop + 2 bar count-in).

 

Loaded the outputs into my 688 (not ideal for playback as it doesn’t like metadata of files it hasn’t created itself - so no Wave Agent allowed *grumbles*), routed the R channel LTC output to hit only my Comtek BST-75-216 transmitter (at full Tx power), adjusted input gain to land a little over unity on its meter, and had very mixed results with my Denecke TS-C reading the LTC from the Comtek PR-216 receiver (via 1/8” to 1/4” cable). Tried just about every combination of gain staging possible, and the most stable results with the slate seemed to be with the receiver at its max output volume.

 

Ultimately, the solution I am going with is to cable the LTC into the slate because it’s stable.. but I wonder, if this thread may be revived yet again, what could I do between the Pro Tools environment to the music video set to make audio LTC over wireless more stable? (with either Comtek or Sennheisser G3). I figure it has everything to do with the gain staging and, as mentioned earlier, the square wave being rounded off in transmission.

Link to comment
Share on other sites

31 minutes ago, canyouhearmenow said:

A newbie question, is time code as an audio signal agnostic to polarity, i.e. 180  deg phase shift?

 

Mark

 

 

 

Yes, the timecode square wave is a Bi-Phase signal. 

 

Flip the polarity and a 1 is still a 1 and a 0 is still a 0.

 

Link to comment
Share on other sites

59 minutes ago, Mike Westgate said:

I inserted

a low pass filter in the transmitter to round off the square edges of the code

+ 1
I think this will make some difference.
But, of course it's nice to see a hardware TC display running, but decoding will be in sofware.
Would it not be an idea  to test that?
(I'm happy to test for you here if you send me some testclips.)

 

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...