Chris Young
Forum Replies Created
-
I have been demonstrating Raylight Ultra in Vegas, the latest version is 1.2 and so far it has had no problems with any of the P2 formats including Panasonic’s AVC-Intra codec. You must be running Vegas 9.0 though if you need to work with the AVC-Intra files. I honestly think a lot of your problems might be solved if you did go to Vegas 9.0c and Ultra. Can’t gaurantee that but worth trying out the Ultra demo to see if it does sort your problems. Ultra is a big step forward. Demo available at
https://dvfilm.com/raylight/ultra/index.htm
Chris Young
CYV Productions
Sydney -
I have experienced both of the scenarios you mentioned but only during editing as opposed to multicam work. Sometimes no movment with slip/move and sometimes way out of sync like many minutes out. Never quite worked that one out. I have learned to live with it because as you say sometimes the audio clip goes back to normal without moving. I think it’s a minor bug which hopefully will get fixed in v9.0d… whenever that’s due!
Chris Young
CYV Productions
Sydney -
I was away when you posted but am back now and have given it a go. For the life of me I cannot get this to happen. I don’t have any Mt2s files here but I tried it with three tracks of long m2t files. Chopped them up into pieces, removed the bits I didn’t want and using your method from the back end rippled the clips back both with and without ‘Event Grouping’. Can’t get an audio track to go that reddish out’o sync color.
I even tried switching ‘Quantize to Frames’ off and purposely cut in between vision frame boundaries to see if that would cause the problem. Still no issues.
When the audio clip goes reddish does it show you an out of sync +/- at the head of the audio clip? If not try right clicking on the reddish audio clip and using the right click/synchronize/moving or slipping mode and see if the clip moves and changes color. My bet is that it won’t move but will go back to its correct color. If that is the case then it could be a bug. Interested to hear how you go.
Chris Young
CYV Productions
Sydney -
Let us know what type of files you are using, DV, MXF, TS etc and I will see if I can replicate the problem here. I do a lot of Vegas multicam and haven’t seen this one… yet!
Chris Young
CYV Productions
Sydney -
Process ID = 0x4dc (1244). This rings a bell in the back of my memory. I think this is a .Net Framework related ID. Believe me there are a number of issues related to later versions of .Net under Vista. Been there myself.
There is a possible .Net fix but before going down that bumpy road try and do the following.
Create a new Vegas project and load the half dozen or so files that appear to be causing the problem. Edit them the way you want them and try rendering them out as say DV files. This may work and give you files to use in your problem project by replacing the suspect WMVs with the DV versions.
See how you go.
Chris Young
CYV Productions
Sydney -
This I haven’t seen before?
One suggestion. Try restoring all Vegas functions to the original Vegas ‘defaults’.
Note: ‘A WORD OF WARNING’ If you do this all your preferences will be reset plus all project properties will go back to the default settings as they were when you installed Vegas. Any folder assignments, such a temp folder, recorded files folder etc will also go back to default. This means if you do a reset be prepared to set up your project properties, preferences and personal defaults again.
If you want to try this hold down your CTRL and SHIFT keys as you double-click opening Vegas. You will be prompted with a dialogue box asking wether you want to reset to Vegas defaults. OK that if you wish to proceed. No guarantee but often this does fix certain behavioural anomalies displayed by Vegas.
Maybe someone has a better option or knows a fix for this?
Chris Young
CYV Productions
Sydney -
Hmm! 2 Gig of ram is right on the borderline of functionality. Vista 32 requires the best part of a gig to run correctly. I would suggest running out of ram could be one of the issues. The first one I would be looking at.
When you do a render open Task Manager (Ctrl, Alt, Delete) and watch under the Performance tab to see if running out of ram is an issue. If it is and seeing that you get to around about 70% through before it falls over try this work-around.
Create a timeline selection for about 65% or less of the timeline duration and render out a DV avi, that’s if DV is suitable for your needs, let’s call it Segment #1. Then render out the remaining timeline section as Segment #2.
Now on a new timeline put the two segments together and you will probably be able to get to a 100% WMV render. In your case the WMV files you are creating shouldn’t be too ram hungry so you might be okay.
Re the drives. Again a single USB drive is a bit marginal. A good option is to go with a dedicated video Raid configuration. Not that this suggestion is much help to you at the moment but it’s worth aiming to go that way if you will be doing a lot of editing in the future.
Actually there is one thing you could try before tackling the above. Try rendering out a short segment of the timeline. An area from 60~65% of the timeline to 75~80% of the timeline. If that falls over during a render you may have a corrupt file or image on the timeline in that vicinity. If it does fall over due to a corrupt file then it requires a bit of detective work to weed it out or fix it.
Chris Young
CYV Productions
Sydney -
The HDV codec is a constant bit rate 25-mbit stream with mpeg layer 2 compressed audio.
Not sitting in front of a unit but I think I am right in saying that with the current Sony Vegas HD MXF render flavours you have starting at the top the 1920×1080 50-mbit 4:2:2 constant bit rate codec (double that of HDV) with up to eight tracks of uncompressed PCM audio.
Next is the 35m-bit 4:2:0 (HQ) format. This can be either 1920×1080 or 1440×1080. This 35-mbit variable bit rate 4:2:0 codec compares quite favourably (apart from when keying) with the 50-mbit codec in spite of being 4:2:0 because its variable bit rate is very efficient and it’s compression ratio overall is 16:1 as opposed to 20:1 for the 50-mbit codec. This 35-mbit codec can support up to four PCM audio tracks.
Next is the 25-mbit fixed bit rate MXF (SP) format that is the same as HDV but with the better uncompressed PCM audio tracks.
Finally there is the 17.5-mbit codec, commonly referred to as 18-mbit, (LP) format. This is hardly used; sometimes know as the ENG choice.
So to answer your question? Yes the 50 and 35-mbit HD codecs are better than the standard 25-mbit HDV codec in terms of both video and audio. We shoot a lot of material in 35-mbit but always deliver our network masters rendered out at 1920x1080i 50-mbit 4:2:2. This is basically the best of the Vegas templates.
Chris Young
CYV Productions
Sydney -
Need more than that Ii am afraid. What is your source format/s? What format are you trying to render to? What PC processor power/speed are you using and how much ram does it have. The more info you can supply the more people can suggest possible solutions.
Chris Young
CYV Productions
Sydney -
As John says, if you are not doing a lot of compositing and the MXF files work fine for you then go with the MXF files, and as you say they take up much less space. If you have to do a lot of compositing then go with the Cineform codec. It’s $130 bucks you won’t regret. We shoot all our shows on XDCam HD cameras that record native MXF. We edit natively in MXF we render out in MXF and deliver to the networks MXF masters at 1920×1080 50i 4:2:2 50-mbit. Have no concerns because if done correctly your quality will be full broadcast. Quite a bit of our program material contains onboard camera footage shot in AVCHD 1920×1080 and once converted to either MXF or Cineform it comes up well. If you can satisfy network HD delivery requirements then there is not too much wrong with your quality.
Chris Young
CYV Productions
Sydney