Although I have checked Timecode in Preferences>Video>Show source frame numbers, I can't figure out why I can't see it in the project. The media is MOV, the timecode was set and is registered.
Can anyone help please
Timecode out of .mov containers has never been directly read by VegasPro. it may depend on the internal codec of the file, but this has been a problem that will not likely be fixed.
Hi thanks to both for replying. I have checked the View/ACtive Take Information but the timecode doesn't show. I guess it's another problem with the Mov files
Thanks though for replying. It helps to know
Margaret
Timecode out of .mov containers has never been directly read by VegasPro
Never say never. The Quicktime Timecode issue was actually addressed in one of the VP12 builds...12 versions later than it should have been, but still...
Unfortunately for me, the main ongoing project that pushes quicktime to me changed from tape to direct capture in FCP, so now all the media I get starts at 00:00:00;00. We changed at the same time that SCS FINALLY started supporting timecode in .mov files.
Anyway, as a test I dredged up some older footage and, yes, the timecode is there and it shows on the timeline. Starting at 3:25:18:29 and ending at 3:25:33:00.
In Prefs I have Video../..Show source frame numbers on event thumbnails as: Timecode.
rmack350 - when we say .mov container doesn't hold timecode what we mean is that apps like FCP or Premiere may read timecode for source but that is not direcly applicable to a universal timecode read in VPro.
let us know the source, the codec, and the laundry list of processing for a codec inside of your current .mov container in which you say you can examine runtime original timecode>please
I'm using DVCProHD media recorded to tape on a Panny HDX900 and then captured from tape in Final Cut. I'm using a Raylight Decoder codec to view it in Vegas.
No processing. Drop it on the timeline and the media TC shows in the timeline thumbnail. Hallelujah!
The TC is the same as what shows in Quicktime Player if you chose to view timecode.
Of course an argument about whether Vegas can see timecode in quicktime files doesn't help Margaret.
Looking at your previous posts it sounds like you're using a GH3, which supports time code. There are a few other GH3 owners here, maybe one of them has some direct experience with time code in the GH3's quicktime files.
I'd probably check to make sure the timecode is really there. I'm sure you've done that. When I look at a sample of my media in MediaInfo this is the timecode section: Other
And when I look at the clip in quicktime player I can see that the timecode is there.
Some possibilities that come to mind:
-- Vegas has a history of not finding timecode if it's not written as Vegas expects. For example, Vegas could read TC in its own DV media but not in DV media captured by Premiere. And Premiere couldn't read Vegas' timecode either.
-- Final Cut has a reputation for doing it's own thang. That might include the way it writes timecode. My media was captured with Final Cut and that might make a difference (more along the lines of what VideoIT seems to be saying, and more believable to me)
Anyway, I hope an actual GH3 owner has some input on this.
Regarding 1, 2, and 3, this all seems plausible but I can't find more details anywhere except for a few year-old complaints. Can you link to further reading?
I would suggest that anyone who has serious concerns about the issues of .mov on Windows8 OS platforms do some serious study of the Quiktime and Microsoft forums. I have been made aware of this since serious beta issues were raised in the Beta days of Win8.
For myself, for various reasons, I remain committed to a large networked server farm of WinXP and Win7 32/&64 platforms supporting a full day business of video editing. I have enough on my plate, that I am not going in the 8 direction at all.
Yep, still not finding anything, and it sounds like your info is at least a year old based on what you're saying. Combine that with your assertion that you're not dealing with Win8 and it adds up to heresay. Not helpful.
I don't have anything to add as far as timecode in quicktime files and Windows 8, I do use quicktime files extensively just never use the timecode, I don't think that canon DSLR's put timecode in their MOV's but, again, I've never sought it out, so I may be mistaken. I am however quite pleased with the overall performance of Windows 8 and now, having just installed it on two machines, Windows 8.1 RTM. I've mentioned this before on this forum about how good my midi interfaces work in W8, noticably better than W7x64 on the same hardware. My 2 cents.
Like VideoITguy, I'm not using Win8. Neither of us is writing with any authority on that front so it's good to hear an actual Win8/Quicktime user report their experience.
Timecode is one of those things that you don't need until you actually DO need it. I suspect that if SCS wants to pursue project interchange with Premiere and Final Cut then understanding timecode in those project files is worthwhile. And SCS is giving me the impression that they enabled the reading of TC in .mov files in general rather than just enabling it in the Raylight Decoder codec.
The reason I kept squeeking about TC in quicktime over the years was precisely because I was interacting with main edit systems at our shop that use Quicktime. If I wanted to refer to something in a clip it was useful to tell someone the timecode point where the thing happened.
All that said, Quicktime has a reputation in Vegas as being an unstable and moving target. I've never has any problem with Quicktime in Vegas and I don't limit my quicktime updates but other people do have troubles. I've just been lucky.
In any case, I can only offer one data point. We use just one type of Quicktime video requiring just one codec, and timecode in .mov works in the current build of Vegas while running under Win7. I assume that this isn't restricted to just my codec because SCS stated that timecode is now recognized in QuickTime files in general. SCS could be wrong, but broad functionality seems to be what they think they've got.
Claims that this is limited to just my codec don't dazzle me with brilliance. Rather, they baffle me with (fill in the blank).