Copy and Trim – leaving massive 18 gig file

[Pcamps]

I too have had this problem – with all versions of Vegas. If you have a velocity envelope on a clip the entire source file will be copied with save and trim. I must be a bug in the program.
Paul

[Edward Troxel]

A couple of options:

1) You’ve applied a velocity envelope somewhere?

2) You’re using a video type that can’t be trimmed? (i.e. MPEG)

Edward Troxel

[Chris Young]

That’s an odd one? We do this every week and use a fair bit of opacity in these jobs. Using ‘Save As’ with 2 second handles and the new files created are correct length, as per the timeline plus their handles, this is on v6.0c and d. Got me puzzled to the point I just tried doing it again on a small job and yes, it saved correctly. Why should this problem happen?

Just a thought, haven’t tried it but maybe this is a work around. Save your master job with the opacity settings, do another save with the opacity settings but call it ‘version 2’ or something. Next reset all opacity levels to no opacity, do a ‘save as’ with ‘trim media’ selected into a new folder called ‘archive’, call this job something like ‘save as trim job’. This should then archive everything with the correct clip lengths plus your defined handles into the archive folder. Remove or delete the .veg file for ‘save as trim job’, rename the ‘version 2’ .veg file to ‘save as trim job’. Open this .veg file and direct it to the archive folder where all the assets are and hopefully, as this .veg has your correct opacity settings it should open up the archived job with the correct opacity levels intact and hopefully you have overcome the 18 Gig file problem.

If that won’t work than that I guess it means a tedious job of resetting all opacity levels. If you try this work around let us all know if it works. It may dig any of us out of a hole in the future if we find this happening.

Chris Young
CYV Productions
Sydney

Chris Young
CYV Productions
Sydney

[Randall Clarke]

Thanks for all the responses

Yes, I do have a velocity envelope so I suspect that is the problem.
I guess the tedious work around is to re render the velocity clips as separate clips and remove
the envelope from the big 18 gig file. Never had this problem with opacity adjustments…

hopefully this bug will get resolved, surprised I haven’t seen it before…

regards
Randall

[Edward Troxel]

[Chris Young] “That’s an odd one? We do this every week and use a fair bit of opacity in these jobs. Using ‘Save As’ with 2 second handles and the new files created are correct length, as per the timeline plus their handles, this is on v6.0c and d.”

Who said anything about opacity? I mentioned Velocity.

Edward Troxel

[Chris Young]

Ed ~

Sorry if you said velocity, suffering brain fade no doubt. All the same I haven’t suffered the problem and there would be around at least fifteen to twenty velocity events, fifty percent usually, with slo-mo replays of every race start and every major racing incident in each sixty minute program (motor sports) and we still don’t have the problem that was outlined, so still a bit puzzled. Hmm! must read slower next time.

Chris Young
Sydney

[Pcamps]

I’ve never had a successful trim with velocity envelopes. Are you sure the files are being trimmed? Where they large files to begin with?
Paul

[Chris Young]

Paul ~

Yes, well all this got me thinking and so I tried an exercise. I found an avi that happened to be 67 minutes and 28 seconds long, file size (PAL) was 14.3GB. Dumped this on a timeline, no velocity settings, trimmed and selected a loop region of 10 minutes exact and ‘saved as’ with copy and trim selected plus 2 second handles. Got what I expected, a 10 min 4 second file with a size of 2.03GB.

Next I applied a velocity envelope to the 10 min loop selection and set it to 50%, then dragged it out to exactly 20 mins duration. Selected that 20 min loop and did a ‘save as’ plus copy trim with 2 second handles. The resultant file was now 32 min 7 seconds long with a size of 6.47GB, an odd one!

So upon examination it is definitely not ‘saving as’ a full copy of the original media, it is trimming, as the original in this case was 14.3GB. It created from the 20 min loop selection, with velocity envelope applied, an unexpected file size of 6.47GB with the odd length of 32 minutes 7 seconds.

Most our jobs have and avi of around 1.5 to 3 hours duration from which the bed of a one hour show is made. So yes, to answer your question the file size created is larger than I expected but well short of the original avi file size. I have never examined this in detail before so I never questioned exactly how big the ‘saved as’ avi’s were. All I knew is that they were considerably smaller than the original avi’s from which they were derived. How to explain this odd sizing I don’t know. Is it a ‘bug’ or not? Good question. Wonder if someone from Sony might know?

Chris Young
CYV Productions
Sydney

[Pcamps]

Chris,
Your test is interesting. I have never looked closely at the resulting file sizes. Where I find it frustrating is when I take one or two 5 second clips from an hour dump – if one has a velocity clip then the trimmed file is multiple gigs in size and the project – (even a 30 second spot) can’t be archived to a data DVD without work arounds.
I have submitted a request to Sony about this (a number of months ago)but have not heard a response.
Paul

[Chris Young]

Paul ~

I don’t know as I haven’t done it but as a work around consider the following, it should work. The five second bits that you need from your hour avi. What if you select them in the trimmer, make subclips, bang them all on a track and render them out as a new file and then import that and re-select your five second bits from it as you need them. On archiving the job it will then only refer to the new render avi when making the back-up. Good luck!

Chris Young
Sydney