Is this in the pipeline?

[chribba]

Is there any support for timecode coming soon? Is there support for MXF export or AAF export?

If this is on the way.....when will it be released?

If not i have to select a competitors editor for next testproject.

chribba

[chribba]

There are some timecode support but no way near other editors

chribba

[ted]

Did you just answer yourself? :D

Yup, again yesterday we had to dub footage for a client who wanted a TC dub. They could not imagine that we didn't have a way to get that for them.

I swear I don't think this would be that hard to do since SE already has the ability to display "time" over the clip. Now if they could make that "time" show something of use. :D

[mvansomeren]

You could use the Timcode.spd-effect, effect....although it does squeeze the output to 4:3 aspect, at least it gives you the timecode burn.

[mvansomeren]

One more thing about the timecode effect, you can go into the control tree and select it to display the clip timecode or the project timecode. I just wish it would allow output in 16x19 aspect and not force the output to 4:3

[ted]

MV, unfortunately, you can not display the clips actual timecode. At least as of yet. You can only display the time on the timeline or the duration of the clip.
Trust me, I've been trying to get by with this limitation for a long time.
Hope NewTek can gitter done soon.

[mvansomeren]

Well I guess that explains why I haven't noticed a problem. Typically, I will send my edited project to the client with timecode burn so they can tell me tell me where in the project they would like to make changes.

Of the three NLEs I use, PremierPro CS3, Edius 4 Pro, and SE, only Edius shows me the original clip timecode as recorded on the camera. I've only had one occasion where I needed to send the raw clips to clients with Timecode and that was before I had SE. The majority of the time, the client just let's me use my best judgment for which clips to use in the project.

[ted]

The majority of the time, the client just let's me use my best judgment for which clips to use in the project.

Man, you are soooo lucky! We usually have the client sitting behind us for the entire session. :eek:
It's not uncommon to have 2 or 3 "directors" behind us, often telling me to do different things all at once. :eek:

For a large number of our shoots our clients want a TC burn to do ofline decision making.
I have only once had a client utilize the timecode from the timeline as you have mentioned. It is nice to be able to offer that though. :thumbsup:

[chribba]

MV, unfortunately, you can not display the clips actual timecode. At least as of yet. You can only display the time on the timeline or the duration of the clip.
Trust me, I've been trying to get by with this limitation for a long time.
Hope NewTek can gitter done soon.

This is one of the things i need in my new project. The reason i say it has some timecode support is the fact that SE shows the cliptime on the timeline.

chribba

[ScorpioProd]

Though this should be an included feature in SpeedEDIT, it is not.

No point in waiting for Newtek any longer, buy this instead:

http://www.newtek.com/forums/showthread.php?t=84530

[mvansomeren]

Unfortunately, although it has all the features we want, it is only for 4:3 aspect ratio at the moment. it will squeeze 16x9 to 4:3. He did say that he would include 16x9 in the next release.

[KiloWatkins]

it will squeeze 16x9 to 4:3. He did say that he would include 16x9 in the next release.

Isn't that the TC accurate more important than Aspect? Chen did a nice job with positioning and extras. But try a copy from VT5 of Timecode.spd-effect. You see the Icon will change to a ? but you can still use the file in SE only PC's, or SE VTSE systems. Control tree enables Opacity, but you can also render the TC then set for 16:9. Might call it a work around, but isn't that the job of an editor anyways?

BestWishes

[mvansomeren]

He actually helped me to figure out the problem...which was on my end. It does render correctly to 16X9.

He found another bug (image position) but I'm sure he's fixed it by now.

Looks like a great tool for those who have clients that demand a TC Burn.

[CreatvGnius]

He actually helped me to figure out the problem...which was on my end. It does render correctly to 16X9.
Cool - but how is that accomplished, pray tell?

PeterG

[animlab]

My Timecode Burner is ready now. Here are the feature summary:
. Display Global (project) time
. Display Local time of TCB filter
. Display Stream (local) time of clip above TCB filter
. Display Tape time of clip above TCB filter (Tape time might be DF or NDF)
. Convert timecode to frame number
. non-Drop Frame (NDF) convertion (do not convert Tape time, since it is tape time)
. six position to display time code
. toggle black box background
. multiple TCB filters support
. three size of display font size to fit different project resolutions


I have to said that SpeedEdit (and SpeedEdit VT) always use 720x486 for realtime display output for any project resolutions (a performance consideration). When it come to render, SpeedEdit pass the correct resolution info to filter and have a correct render result. SpeedEdit VT (VT5 first release) have different behavior. Filter only receive 720x486 resolution info (I believe it is a bug :devil:) and it render the dsiplay as 720x486 and then stretch by SpeedEdit VT render engine to projcet resolution and aspect ratio. I hope the SpeedEdit VT in furture VT[5.(>1)] release will fix this issue.

So, mv, if you are using SE only, it is fine for you. If yo are using SE VT, then you have to suffer that in HD edit mode, the overlay effect video is stretched from 720x486.

There are some limitation for SpeedEdit plugingSDK if I want to keep the effect be SE version independant. For example, the feature I include above to use to identified the clip just above the TCB it-self is a SE version dependant function. NewTek designed the Effects (PluginSDK) to act as just receive the screen rendertree data with all clips above it and time data of the effect itself. If I want to keep the SE version independant, I have to giveup to communicate to timeline and it is impossible to get the tape timecode out of the clip. I don't know it is possible or not for NewTek to have a pluginSDK that can access timeline and also keep SE version independant. I hope it will in the future.

[mvansomeren]

I purchased the TCB effect developed by animlab for SpeedEdit. It performs as advertised and looks much more professional than the timecode effect included with SpeedEdit. More importantly, it does show the original timecode that was recorded to the clip by the camera so this should take care of those situations where your client requires a time code burn of the original footage.

I wish there were more people creating effects and plug-ins for SpeedEdit. :thumbsup:

[animlab]

Thank you, mvansomeren. :)

[ted]

Chen, this pluging still does NOT display the timecode from the actual .mxf clip correct?
If it does I'll order today.

[animlab]

TCB is based on NewTek's capture feature that save the tape time code into .timecode file and SE use that file to response the tape timecode request. By nature, it will not support .mxf file unless the .mfx reader can put the tape timecode to .timecode file.

However, we might have chance to make it happen by add some support utility. I don't have .mxf clips at hand to tryon. If you can send me one or two sample clips (3-5 seocnds), I will try to make it happen.

[ted]

Chen, if you give me your address I'll put a couple clips on a Data DVD and send them to you. You can give it to me here or send a Private Message.
I'd love to work with you on this because I will benefit as well as you and others.
Thanks for helping with this missing link on SE.

[Adam_LightPlay]

MV, unfortunately, you can not display the clips actual timecode. At least as of yet. You can only display the time on the timeline or the duration of the clip.
Trust me, I've been trying to get by with this limitation for a long time.
Hope NewTek can gitter done soon.

The SE TC Filter doesn't have to start at zero. I've adjusted it's in and out points to match the TC of the clip it's lined up with. True you would have to do it manually for each clip, but you can get there from here. From an already edited project, it would be a *****.

What I've been doing a lot of lately for clients to review their raw footage, is running a composite line from the camcorder or deck with TC overlay into a cheap real-time DVD recorder, (Panasonic) at the same time as capturing the full quality clean video onto the hard drives for future editing. It only takes a few more minutes to set up, but doesn't require any extra upload or download time. Even most cheap camcorders have a menu choice to put TC and maybe some other viewfinder stuff on top of the analog video output. And we've probably all met an XL1 that will NOT STOP putting it on the video out, unless you remembered to bring the remote :-)

[mvansomeren]

The SE TC Filter doesn't have to start at zero. I've adjusted it's in and out points to match the TC of the clip it's lined up with. True you would have to do it manually for each clip, but you can get there from here. From an already edited project, it would be a *****.

Maybe I'm missing something but how would you know what the actual timecode recorded to the clip was in the first place once it's on the timeline? For example, if you use auto chop and now you have a bunch of clips. You select 5 out of the ten that you will use and drop them all in the timeline to burn a DVD for the client so that they can choose the in/out points. SE will only show you TC relative to the position of the clip on the timeline.

As Ted mentioned, there isn't a way in SE to do that with the TC effect that comes with it. Animlab's effect does the job for footage captured through SE. Although to date I haven't had the same demands that Ted has from his clients, I wanted to be prepared as I'm sure it will happen one day.

[Adam_LightPlay]

Sorry I wasn't more specific. Maybe I missed one of the initial paramiters of this thread.
I was referring to clips captured thru Firewire-1394, both DV and HDV. I use Auto-chop, and the clips always have the original timecode. They don't all start at 00:00 like a capture thru the VT. I get that even if the tape was recorded in a higher end camera that lets the user set the TC starting point.

The Animlab effect sounds good. I may add it to my arsenal someday, too.

[mvansomeren]

Yes, the clips do retain the original TC. The problem occurs when you put them on the timeline...starting at 00:00:00:00. SE's TC effect now shows TC relative to their position on the Timeline, not the embedded, original timecode.

I understand your idea of shifting the effect/clip to the point of the timeline that matches the original clip timecode. Unfortunately, that isn't very practical if you have large gaps in TC between clips and/or a large number of clips that are not sequential. But, I have to give you credit, it is one way of getting it done.:thumbsup:

[ScorpioProd]

Remember, ignoring the rather limited SE TC "effect", you can switch on the local time code readout inside of SE.

This doesn't help you for TC window burns, but it does show you your real TC internally.

Don't attempt this with the SE TC effect on as well, weird stuff happens.

[mvansomeren]

Yup. In my view, Animlab's product is the only viable TC Burn solution at the moment for captured footage. Hopefully, the addition of a utility will address files that are transfered to the PC outside of SE capture such as .mxf, etc.

Now if we can just get someone to develop HD transitions and effects... :cool:

[Adam_LightPlay]

Now if we can just get someone to develop HD transitions and effects... :cool:

"Paging Mr. Pratt..." "Mr. Eric Pratt, to the white phone, please".
How about some, "HDat Tricks".

[ted]

Chen, I just sent you a few .mxf clips in 480, 720 and 1080 formats.
Hopefully you can gitter done.
Then I can start whining about my next most needed feature. :hey:

[animlab]

I just do a research in reading metadata of mxf file and it is complicated but possible to get the tape timecode out. There are two different work flow to have this job done and I need your opinion as reference.

Work flow 1: An exrtra mxf timecode utility to read out the mxf timecode component and create the "*.TimeCode" file under "NewTek Info" directory. I don't need to change any code of my TCB effect. User have to run the utility before they drag clips into SE. This work flow is efficiency and reliable but user need to pay attention on adding the "*.timecode" file first.

Work flow 2: I add mxf timecode support into TCB. No "*.TimeCode" file generated. It will add loading to the TCB itself since it need to access mxf file every frame to check. The only benifit for this work flow is user don't need to do anything extra.

BTW. MXF can have multiple items (video clips) in a single file. I will not support multiple items MXF. It should be more efficiency to do that with mxf core code of SE. Hope NewTek will add reading metadata features on future SE builds.

[ScorpioProd]

"Paging Mr. Pratt..." "Mr. Eric Pratt, to the white phone, please".
How about some, "HDat Tricks".
Once there are actual HD DVE creation tools released by Newtek... AFAIK, they are not yet available. The only HD DVEs currently are ones that Bob Tasa's plug-in uses in his own render engine, instead of Newtek's engine.

[Dufusyte]

I need your opinion as reference.
Could there be another way: TCB auto-launches utility which creates *.TimeCode file, and then when the utility has finished, TCB continues.

[Adam_LightPlay]

Yes, the clips do retain the original TC. The problem occurs when you put them on the timeline...starting at 00:00:00:00. SE's TC effect now shows TC relative to their position on the Timeline, not the embedded, original timecode.
I understand your idea of shifting the effect/clip to the point of the timeline that matches the original clip timecode. Unfortunately, that isn't very practical if you have large gaps in TC between clips and/or a large number of clips that are not sequential. But, I have to give you credit, it is one way of getting it done.

That's kind of cool, but not what I meant. :0
OK. I stopped talking in theory from home, and tried it out again at the office.
There appears to be a bug, or technical limitation, with pasting or typing a new time code in the IN Point field, for the TC.Spd-Effect, in the Selected Clip Properties panel.

So here's the manual instructions. Too muck work for an edited project but not too bad for 5 or 10 clips that need to be window burned for a client.
Put clips on Timeline.
Have the Selected Clip Properties panel open (F8)
If the clips are somewhat sequential, it may be best to start with the last video clip.
Drag the "Timecode.spd-effect somewhere underneath one of the video clips. I'm gonna call it the "TC overlay", for short from now on.
Select the video clip, and copy the OUT POINT timecode in the Selected Clip Properties panel.
Select the TC overlay and paste the Time Code into it's OUT POINT field.
You will probably now have a really long TC Overlay clip on the timeline.
Drag the TC Overlay clip to the left until the end point snaps to the end point of the Video Clip.
Select the Video clip and the keyboard shortcut "q" to go to the first frame of the video clip.
Select the TC Overlay and Type "c" to cut it. Bam, that's one down.
Drag the excess TC Overlay on the left, to the next video clip, and repeat the process. (Now you'll see why we started with the last video clip).

Am I brilliant or nuts? I know... both. :hey:

[mvansomeren]

I'll give you a "brilliant". :agree: That actually does work...but what a Pain in the A** for more than a couple of clips as you mentioned...especially if some of your clips are in the upper 50 min timecode while others are near 00.

But, if you've got to get it done, this works in a pinch. Nice find.

Having used both Animlab's TCB effect and your idea, I would still recommend getting the TCB effect if you have to burn Timecode burns with any regularity and/or you need to see multiple timecode references simultaneously. But for the occasional burn, your method is perfect.:)

[animlab]

Could there be another way: TCB auto-launches utility which creates *.TimeCode file, and then when the utility has finished, TCB continues.

I have think of that.
The *.TimeCode was read only when the video clip was draged into timeline. So it is impossible to use TCB to generated the *.TimeCode file.

[animlab]

I have good news for Ted and everybody here. I just receive the MXF sample files from Ted and you can't believe is that SE do support "Panasonic P2" mxf file timecode from metadata. You don't know it is so supprise to find that there are *.TimeCode files in the "NewTek Info" directory already.

I make a test to delete the "NewTek Info" and use SE's filebin to check the P2 MXF files and *.TimeCode regenerated automatically. Great worrk :thumbsup: NewTek!

But I make more test with MSF files from other source and found that ONLY MXF file from P2 will generated *.TimeCode automatically. :confused: I check the metadata of the mxf files and don't find any different in the Timecode Component parts of metadata. I guess NewTek did not follow the standard way to check the metadata of MXF file but use some special method (such as offset) to check the timecode for P2 MXF file. So the mxf timecode support feature did not applied to other mxf files but P2's only.
:2guns: :newtek: I believe you can fix that.

So, Ted. Your problem solved automatically but users who not using P2 systems are not!

[mvansomeren]

So what you're saying is that your TCB effect will already work with P2 .mxf files?

[Jim_C]

Go Chen Go!!!!!

:)

[animlab]

So what you're saying is that your TCB effect will already work with P2 .mxf files?

Yes.

[mvansomeren]

NICE! :thumbsup:

[ted]

What? Huh? But, you mean....??? :eek:

Yeeeehaaaaa!!!!!!! :dance:
Thanks for trying those files Chen. :thumbsup:
I'll give you an order by Monday.

[animlab]

I wrote a small utility (mxftc_gui.exe) that can export MXF file timecode for use with SE. It will go with TCB without extra charge. The UI is as follow:

60002

Although NewTek have support P2 timecode already but I found that there is a 1 or 2 frames error on SE generated timecode. The timecode on above screen capture is based on the P2 MXF sample files Ted sent to me.

The SE generated timecode were:

0032Q0.MXF.TimeCode 10:07:05.07
0033AU.MXF.TimeCode 10:08:00.06
0035QU.MXF.TimeCode 10:09:01.28

but the correct timecode should be

0032Q0.MXF.TimeCode 10:07:05.06
0033AU.MXF.TimeCode 10:08:00.04
0035QU.MXF.TimeCode 10:09:01.27

I check the MXF files with MXF utility from MOG Solutions. My calculated results are correct, SE were wrong. :D I believe it is due to DropFrame timecode caculation bugs or float point error on SE.

[mvansomeren]

Fantastic customer support, Chen. Thank you! :thumbsup: