timecode reader

I have shot a series of interviews and I want to export them to a service for transcription. Each clips has its own timecode generated by my camera. When I put each of the interviews on the timeline and apply the timecode reader filter to the clips, the numbers are generated by the timeline and not the clips themselves. I would prefer to have the actual timecode from the individual clips displayed. When I open each clip in its own timeline and apply the filter, it shows me the actual timecode. I then copy that to the timeline with the other clips, and the reader reverts to the timeline timecode. Is there any way to work around this? Is there a filter out there where you can burn the timecode into clips before bringing it into the timeline? thx

Go to the FCPX plugins page on the this web site. I'm pretty sure someone has made a timecode reader that reads clip TC and can be applied to individual clips.

Maybe something like this might be of some help...

www.fcp.co/forum/utility/444-free-timecode-reader-for-fcpx#8648

Thanks. I found that, but the timecode readers only read the timecode from the timeline. I'm digging around to see if there's a work around, but no luck so far. It sort of shocks me that this would be a problem. Why wouldn't Apple think that there's value in having timecode unique to individual clips?

finalcutargentina.blogspot.com/2011/07/t...tuito-para-fcpx.html

Hi Tom, the one you linked to, only reads sequence timecode since a bug in Motion5/FCPX since 10.0.3.

That being said: some work-arounds for the original poster:

OPTION A: Right click the clip. Command: OPEN IN TIMELINE.
Click on the clip, X, go to the Generator Browser, Click the Timecode Reader Generator, and click Q for CONNECT. You will have a timecode on the clip.
*read my commend below

OPTION B: Right click on the clip, choose: New Compound Clip. Make a new compound clip from the clip, give it an approperiate name, make sure it has the same starting timecode as the original (FCPX will normally do this automatically, as you'll see) and make sure it has the same settings as the original (again, FCPX will detect this automatically, so you just have to name the compound clip, all the rest will be automatic).
You can for instance make a smart folder with Compound Clips and other criteria, to keep track of your new Compound Clips. (because in this scenario you will have a compound clip for every original clip)

Now the comment... What's the difference between these 2 options? Simple (but important):

When using Option A, if you edit the clips in the timeline, and afterwards go to the original clips, click Open in Timeline again, and remove the Timecode Reader again for your final edit, it won't delete that Timecode Reader in the clips in the timeline. (I don't know why, I sent feedback to Apple).

When using Option B, if you edit them in the timeline, then open the compound clips later again, and remove the Timecode Reader filter (or make it invisible by pressing V), the change will trickle down to your edited timeline, removing the timecode filter there.
That's why I like to use option B, although this maybe is not a good option if you work with a lot of clips, and it also depends on what's the relationship of the timeline you send to your client and what you keep for yourself (if it's the same or not).

With this work-around we are getting a good workflow in X with even some advantages in comparison with 7 (some extra flexibility, and much better performance). That being said, YES, I wish there would be a normal Timecode Reader/Timecode Generator in X so we would not need this complete work-around workflow. I sent Apple feedback about this multiple times, and I hope everyone else does too.

Kind regards,

Thanks. It must have taken you a while to come up with that, but I'm glad you did. I'll give it a try. I've heard warnings about using too many compound clips and bogging down the computer. Has this affected the performance at all? I've used compound clips animating stills (the Ken Burns Effect won't freeze without creating holds which require you to make compound clips), but I've tried to keep them to a minimum. It doesn't sound like it's affected you though.

For transcriptions I just export the clips individually as any old copy of QuickTime can read timecode.
Saves a lot of mucking around and rendering.

You mean the transcriber will be able to read the QT file's timecode at their end? I send my files to India and I believe they need to actually see the timecode. I'll ask them. Then I could take the selects using the hard copy and open the clips in the timeline to edit them. thx

Yes my work flow is either of two methods.
1. Just transcode the clips into H.264 and send the compressed files for them to read with QuickTime or Inqscribe.

2. If they absolutely MUST have burnt in timecode then I'll just make a sequence (compound clip) and add burnt in timecode to that and then use that compound clip as my source.

If you use Compressor, this can also burn on a timecode during conversion (create a custom setting and then go into "Filters" where you can add TC/watermarks etc), which we find much quicker than placing the FCPX timecode gen on the timeline and waiting for it to render. Doesn't give you the individ clip time though, which the OP asked about.

Does the transcriber need timecode though? We just export an MP3 and send that. Most transcribers will use a pedal audio playback system. They won't be interested in the pics.

parkerhqj wrote: Thanks. It must have taken you a while to come up with that, but I'm glad you did. I'll give it a try. I've heard warnings about using too many compound clips and bogging down the computer. Has this affected the performance at all? I've used compound clips animating stills (the Ken Burns Effect won't freeze without creating holds which require you to make compound clips), but I've tried to keep them to a minimum. It doesn't sound like it's affected you though.

Compound Clips used to effect performance, and could be problematic, because every compound clip was an independent entity. If you started cutting in one of them, it made a NEW compound clip. This caused bloat.
Since 10.0.6 it works more like the old nesting in FCP7, where a change in a compound clip, ripples trough to every edit where you used it. Since then compound clips are not a big performance-problem anymore. You just have to check the workflow and keep an eye on where you change things and where you used clips.

PS: I have noticed that rendering Timecode in FCPX is quick in comparison with 7 though.
We had a quad image we made, with 4 images on, with on all four a timecode. I thought rendering that out would be a nightmare, but it all went very smooth, on a retina Macbook Pro with Thunderbolt Raid.

That's good to hear. I find compound clips to be very useful and I would hate to have to use them sparingly if I don't have to. thx

Sadly Compound clips in FCP X do NOT behave the same was as they do in FCP 7. I really wish they did.

If you copy and paste a nested clip into another sequence it immediately becomes independent.
Same goes for duplicating a sequence in FCP 7. All nests are made independent.

This isn't quite right. Nested sequences are not always independent. They are with copy and paste, but not in other circumstances in legacy FCP.

In X you can make a new parent of any compound clip at any time.

The behavior is much more consistent in FCP than it was in 7.

Sorry for getting off topic.

Never said that nested clips were always independent in FCP Classic.
I was just wishing for the same behavior. When you dupe a project it makes the compound clips independent or if you edit a compound clip into a new project it becomes independent.

All it needs for me is a check box that says 'Make compound clips independent' on the dupe project dialogue window and I'll be happy.

mistermattsmith wrote: If you use Compressor, this can also burn on a timecode during conversion (create a custom setting and then go into "Filters" where you can add TC/watermarks etc), which we find much quicker than placing the FCPX timecode gen on the timeline and waiting for it to render. Doesn't give you the individ clip time though, which the OP asked about.

Does the transcriber need timecode though? We just export an MP3 and send that. Most transcribers will use a pedal audio playback system. They won't be interested in the pics.

If you feed compressor the raw camera clips (or the transcoded media for each clip) then it will burn the original source clip time code. Keep in mind that it will not place a semitransparent box behind the TC burn - which is a problem if you have varying luminance values in your shots around where the burn is. You can insert a semitransparent black box as a watermark in Compressor and get it to layer underneath the TC burn, but it's pretty finicky to set up.

Our transcribers require visual burn if we want them to insert time code into their transcriptions. We have one guy who is willing to use embedded TC displayed by QT layer, but he needed a lot of handholding to ensure he was displaying the actual TC track and not the running time. This is when we were able to feed him the raw proxy files from XDCAM-HD. This is less of an issue when using 5D DSLR footage as every clip resets itself to 00:00:00:00. However in instances like this, you need to direct the transcriber to insert the clip name (i.e. MVI_9275) every time they make a TC reference in the transcription.