If you are rendering multiple files together, how can you expect the timestamp to remain constant?
file#1 00.00.04.22
file#2 00.05.11.03
file#3 00.01.44.25

How could the render possibly keep that information? It's a new file, whether unchanged or not. It's impossible for a rendered file containing several parts to keep t/c from its components. It's like asking the cake to keep chocolate chips, flour, and eggs intact when it bakes everything together. It's a new object that is the sum of the whole, not individual parts.

The question is contradictory. If the source is unchanged then it's not being rendered!
Perhaps what you're trying to do is say drop some footage into Vegas and without any cuts apply say CC and then print to tape preserving the TC from the original tape?
If that's what you're trying to do your biggest stumbling block I think is that DV (as opposed to DVCAM) doesn't handle that very well. From memory you cannot make a DV copy even going VCR to VCR and preserve source TC, some machines might do it but at best it's not a 100% reliable thing.
I know when we do a DV to digibetacam dub and we're asked to preserve TC we usually end up regenerating the TC.

Are you possibly talking about the date/time stamp? If so, I agree that it would be nice to have an option to preserve this in some manner, perhaps by specifying "use date/time from this track for all new media" or something similar. However, the problem is difficult, because when you do something even as simple as a transition, what date/time do you use for the duration of the transition? Do you want to use the date/time of the media leading into the transition, or the date/time of the media coming out of the transition?

With twenty or thirty tracks, and dozens of media clips combining at any instant in time, the problem gets even tougher.

I suppose another option would be to let the user specify a default date/time stamp for new media so that when you render, the date/time would be something other than today's date.

Yes, I also would like to have an option to preserve the original data stamp. Actually there are NLEs which does it. This would be very helpful for some kinds of organzing big projects and archiving. This is not meant for composited work. Hard cuts only. I often have big projects where I first do a rough cut just to small the size down. I usually do play out the rough cut version back to dv tape 1. to archive this rough cut version 2. to capture that stuff once again using automatic scene detection. Now the automatic scene detecting does not work no more because Vegas had generated a brand new data stamp.
And - no - this never worked in Vegas.

Marco

Didn't we have this conversation in these very forums a year ago? ;)

>>>How could the render possibly keep that information? It's a new file, whether unchanged or not. It's impossible for a rendered file containing several parts to keep t/c from its components. I<<<

I have to disagree with you Spot. I did not think of this prior to this topic coming up before but here is what I found out at that time, and holds true still - I cut a promo with Vegas and rendered it out. No problem...so when this whole time_Date thread came up in the past and rendering not keeping the info I ran the *rendered* promo through the free Date_time program - not only was the time code for each cut still there so was the orginal Date and time stamp.

If you do not do anything but re-render the cut footage Vegas (version 4 at least) retains the info. In the promo i cut where the footage was dissolved the info is lost. If you convert 30i > 24p for example the info would also be lost - at least the tuime code info. Date_time might still be there - I have not really checked that. I did a 30i > 30i render and at6 each cut there is all info intact.

Vegas, to my knowledge, never has retained the info. I just rendered in Vegas 3 and 4, neither contains the original t/c. Even if you tell the original to use custom timecode. If I'm wrong, I'll eat crow, but I don't think so. I've got every version of Vegas installed here...and just tried this on 3 versions before answering. both with custom and original timecode. At least it's not showing up in Vegas. Might be showing up in a third party inspection tool.

What might make this a lot easier is being able to specify an offset for the start of the timeline. You can do that effectively in most cameras and VCRs, would be nice if Vegas could do the same thing on the TL.

Maybe a few different issue than -

The promo i cut was done in Vegas 4 and rendered in Vegas 4. 4b I think...not 100% sure. So your comment of " Vegas, to my knowledge, never has retained the info." is wrong if we are talking about date, time stamp / orginal (Source tape captured from that is) TC. Now the other issue is if Vegas displays it - this I am not sure because Vegas doesn't seem to display date/time and seems to only read TC that is caputred from the vidcap utility. These topics have been talked about many times and it is where I discovered that this info is retained in a render. The thread and my finding came about in a thread about DV_DateCode. So right now I am running the promo through it - this is a Vegas rendered file, rendered form several other files. Here is some of the readings - and the format is DD.MM.YYYY HH:MM:SS Frame

00.01.1900 00:00:00 0 <<== this is a title card/fade up from black, done in Vegas. I did *not* set any info, Vegas rendered/burned in the date of January 0, 1900.

28.06.2002 21:33:58 1463 <<== frame 1463 is the last frame of a cut from footage shot on June 28, 2002. This was from tape timecode of 21:33:58

11.09.2001 09:07:39 1464 <<== frame 1464 is the next frame, a new shot, which was shot on September 11, 2001 at 9:07:39. This is the original camera time and date.

04.01.2002 13:12:42 2614 <<== frame 2614 is the last frame of a cut.
09.11.2001 10:04:47 2615 <<== frame 2614 is the first frame of the next cut.

And so on - so you can see that Vegas *does* retain the date, time/timecode of the source tapes during a render. Does vegas *display* it than becomes the real issue. I can not say for Vegas 5, but the reason the topic of DV_DateCode came up (and seems to always some up) is because Vegas 4 (and prior) lacked a way to display, ala a SMPTE TC window, the date_time info. (I just tried looking at the promo in Vegas 4 - I dropped the SMPTE window burn efx onto the media in the media pool - does not read the TC info other than the "default" zero setting. I looked at the same file in SCLive and it does read the info - format is like this "NTSC 4:3 48kHz 2001-11-09 10:04:48 (26;19;00)". It retains not only the date and time shot (November 9, 2001 at 10:04:48 am) but also the tape time code (26;19;00) So, again, Vegas does indeed retain *all* orginal info.

I won't make you eat a cow. :)

Don't know why this should work on your system. None of my Vegas version 3, 4 or 5 does retain the original data code. And even Sonic Foundry stated this does not work because it is simply not meant to work this way (though I disagree here, at least for an optional choice).

Marco

are you knew difference between timestamp and timecode ?
timestamp = date,time
timecode = count from begin of episode

DaLiv,
timecode is NOT count from start of episode. Timecode can start from any arbitary value. A not uncommon practice is to set each camera in a multicamera shoot to start at a different initial value to make it easier to know which tape a camera came from.
Also it's not uncommon in broadcast to have program start at 10:00:00;00 rather than 0.

Don't know if you mean that: Actually you can set an offset to the Vegas timeline timecode by choosing a individual value at "options/ruler format/set time at cursor".

But timecode isn't the issue. Its the datacode. This is where there is a lack in Vegas - at least in my opinion.

Marco

Something else that it would be neat if Vegas supported was reading the embedded memory chips in the DV cassettes. Sony makes the tapes with them in (at a price!) but I haven't come across anything that makes use of them during capture.
For those that don't know, the idea is that you can flag scenes as being good/bad takes and then only capture the good takes. Many of the cameras will handle it, I don't know anything about the VCRs or capture software.

Whew! I'm glad to hear I'm not imagining this not working. I hate the taste of crow. Feathers tickle my throat.

Just curious, what's a REAL WORLD application for this? If you're culling shots for content, why would you want original source datacode anyway? It becomes logged (in my way of working) when I render the new file, so it's just a new piece of media for me. Maybe I'm missing something wonderful and exciting here?

I am not sure what a real world reason would be after the render but certianly before a render, or on raw footage, there can be needs for this. I suppose after a render it could come in handy, say, if the edl was lost - you could just pull the info from the render. However it wouldn't work if you had chnged things - added fades, dissolves or changed the frame rate for example.

Another reason would be logical - dubs. Isn';t the concept that you can take a DV tape and make a 1:1 copy and because it is digital *all* info is exactly the same? So why wouldn't the same logic apply in Vegas? Someone told me that FCP has this ability, we weren't talking about editing at all - they told me they could dub off a tape but they had it on thier Mac and they told me it was pretty "neat" how all the date and time info was retained in FCP, even upon output back to tape. To me it makes perfect sense. If the material is unchanged than the recorded info should be the same as it was/is on the master tape. Yes, once you render a project you have created a new master and there really isn't a painfully obvious reason to not create a new date and time stamp on the file. Ahhh - but wait. Maybe a workflow reason? Say you go into a project and make 1 or 2 small changes. For workflow you could check versions by going into the file and seeing the "revision date and time" on the sections. If the entire piece had the same date and time it would not be the revised version.

As for why some people can not duplicate the same results I don't know. Best steps would be to take some shots, obviously more than one shot and not all shot at the same time or from the same tape. Cut them up render them out. DV > DV only here. Than drop it into the free DV_DateCode and see what happens. As I pointed out it will also read in the SCLive program. However I do notice some variations - for example SCLive doesn't seem to read the TC info on the Vegas rendered titles whereas DV_DateCode will.

Best steps would be to take some shots, obviously more than one shot and not all shot at the same time or from the same tape. Cut them up render them out. DV > DV only here.
This is exactly what I did. Media from 3 different DV clips, very different T/C on all of them. Rendered straight, rendered using custom timecode, same new data found on new media. It may be that a third party tool can sniff out the original data in the new render, but since Vegas can't read this data remnant, for all intent and purpose, Vegas doesn't retain the information, IMO. Other than the dubbing, which I'd never use Vegas for because then it's a 2:1 transfer, meaning I've got to transfer TO the computer, then FROM the computer when it's a hell of a lot faster transferring straight from deck to deck...anyway, this doesn't seem to be an issue for me...

Organizing.
I sometimes work on long-time documentarys. 20 - 30 hours of footage for a 44 minute feature does happen there ;-(
What I often do then is capturing as much stuff as possible then doing a very, very ROUGH cut. Just sorting out unusable takes and cutting of unusable parts of some takes.
Usually I then have cut down the 20 to 30 hours to only about 5 hours. Only these 5 hours are of use for me so this must be my base even for archiving later. So I then do a playout of that stuff to dv tapes again. These are my real master tapes. I then capture the 5 tapes and then it would be very, very helpful to have retained the original data code. This is a very helpful base even if I have to recapture some stuff. There is a great big difference if you restart your work with 30 hours of unordered stuff or with 5 hours of ordered stuff. But though I did not even render - just cut and printed to tape - Vegas does not give me the original data code and so I cannot use the automated scene detection. This is what it's all about. I want to keep the automated scene detection after having printed the stuff to tape. In Vegas - no way.
I once used CineStream for editing. There this way of organizing the stuff worked fine.

Marco

You forgot to post what your result were for the rest of what I said -

Than drop it into the free DV_DateCode and see what happens. As I pointed out it will also read in the SCLive program.

If the info does read in those programs, which I have said more than one time now does, than Vegas rendered file *do* retain the info. Based on the only testing the first part - if Vegas can read the info - and saying therefore since Vegas can't read this data remnant, for all intent and purpose, Vegas doesn't retain the information would be like me saying since Vegas can not truly export or import an EDL it is not a true NLE. ;)

But going back to what has been asked around these parts time and time again - Vegas does not have the ability to display date and time info, as recorded on the "original", so when will it be able to? And, again not speaking of Vegas 5, I think it would be great to be able to encode new timecode info. You said you "rendered using custom timecode" so maybe you can do it in version 5, but in 4 setting a custom timecode really doesn't do anything as far as a render goes. if you create graphics and output from Vegas and you would like a timecode start of, say, 10:00:00;00, setting this and rendering means nothing because the end result will be a zero start. Also it seems due to the way Vegas actually writes that time code it would be unreadable in other programs. Kind of an endless pointless circle at times. :)

And on the tape > PC > tape method - if someone only has one deck/camera it would be hard to do a tape to tape dub. (Sepaking of DV > DV only. Not DV > VHS or the like)

how about output preview on external monitor with sound ?

don't mix timecode and timestamp - it's so different
timecode = count from episode begin
timestamp = real date,time when this episode was filmed.

DaLiv,
you are WRONG, timecode is NOT count from program start.
It's normal practise that program start isn't even zero in many institutions, the BBC being one of them. If a program starts at zero what timecode goes on the leaders and countdowns?
Programs can and do start at any point you care to nominate, hopefully the timecode will count up continuosly from program start but even that is neither necessary nor always the case.
This used to be pretty important in the days of linear editing but over the years much of that has just faded away.
I'm not saying in many places, such as broadcast it isn't vitally important but in the world of non linear editing it doesn't have the same importance. You can quite happily edit footage shot with timecode that's all over the place, the system will cope.

Premiere (and other programs) retains the date/time stamp. If you put two clips on the timeline with a transition between them, the resulting render will retain the clip's original date/time stamp except in the transition area.

I rather liked this feature, and am disappointed that Vegas does not have it.

Buddy

i'm not talk about need or not to me timecode but about TIMESTAMP preserving - so read carefully before posts ... timecode no matter - it's can be set as needed, but TIMESTAMP you can not set edit or make from them subtitles in vegas ...