That we put out a petition for Vegas to have its known issues worked out.
Forget the marketing and forget what the compeition are doing.
Just look at what is happening here and consider what we need to make Vegas work for us
Im not complaining about what vegas cant do, and believe me when i say that it does more things in a more efficient way than any otehr NLE.
BUT it seems this mad rush to compete has lost focus on what an NLE is all about. And that is to provide a solid working environment where the tool does what it says it does.
Like a mechanic, there are a myriad of tools, makes and brands available to us. We can also use certain tools for differnt purposes, such as a trolly jack vs a hydrolift...
You get my meaning. They each get us from A to B.
HOW we get from A to B is the important issue here.
Im going to list elements here which i believe need to be looked at. As it stands, if these elements are not rectified by V9, I will be jumping ship.
Not because i want to but becuase i have to. I wont have a choice as Vegas wouldnt be able to delivery what i need.
1) TRUE SSE4 support. Not jsut within the render engine, but within the preview playback engine also.
If resources are available USE THEM.
Adobe have done this for a very long time now, and theyre obviously doign somethign right.
I would however like to invite my clients over to review their edits, however since i started usign vegas, i cannot do this as i CONSTANTLY have to explain that the dropped frames during preview wont be there in the final.
Vegas supports SSE4 on the render side, but we still need either a buffer, BG renderer, or proper SSE4 support for realtime playback
2) Progressive scan support. As it stands, vegas does not manage frame interpolation well.
A couple of examples.
You have interalced footage, and youve resized a 4:3 clip into 16:9
Youve cntrl dragged it for slowmo to 50%
Youve then rendered it out to progressive to match the another tape from a different camera and it looks fine.
Now to the same thing but before you render, REFRAME your pan and crop (is slide your frame up or down) to an odd number or a number which doesnt calculate within a factor of 2
Now render it and tell me what you see...
The slowmotion is all jerky and stuttery, with duplicate rubbish frames
Render to interlaced and it looks fine
In addition to this issue, the move of technology into HD forces the work itself to be of an even higher accepted value than waht SD used to be.
1080p footage is the bees knees at this time in regard to consumerism and frankly, Vegas cannot cut it.
Those wanting 1080p cannot utilise slowmotion. If stuttery Slowmotion is acceptable, then good for those people accepting it. But I paid 100bux for a slowmotion app which has absolutely NO ISSUE with offering a true interpolation of frames.
LLLets face it, the bulk of Vegas users are in fact wedding and events producers. The NLE falls within their budget, and once they realise that its a Vegas fault (when demand for 1080p increases to a point of saturation) then and only then will they realise that there is a serious issue with Vegas and Progressive scan
3) AC3 5.1 encoding should be faster than MPG 2 encoding. As it stands, irrespective of what CPU you use, AC3 encoding can be as fast as realtime, up to 4 to 5 times realtime. THIS is now what is slowing down render times. Not the other way around.
God forbid yo uuse the clipped peak restoration plugin.. youll be there for 6 hours for every hour..
4) 32bit rendering should be offered on a clip level, not project level. The colour space shouldnt automatically jump from studio to computer RGB. If it wasnt for Glenn Chan, noone would know WTF to do with it. 32bit rendering on teh outset also shouldnt affect colour gamut. Not until the process is running and viewwable to the editor. As it stands, those that do not understand how it works, (thanks to Glenn) would think there is something wrong.
Sadly this is the majority of users as not everyone comes here
32bit rendering should be an OPTION within a certain clip due to the fact that most times, its not needed.
That and the fact that it needs to have it memory management rebuilt. It just doesnt work
5) Vegas is in sore need of some new filters and motion manipulation
6) Timecode data per clip needs to be visible, much liek the data seen on an unporcessed DV stream previewing through 1394. Time date stamps are visible as are camera settings etc.
There is no reason why this data cannot be viewable. If not within the timeline in the media properties area
7) HD delivery. I dont know what the issue is surrounding DVDs support of DB or DVD5/9 to BD formats are. I also do not know why HD DVD has been looked over completely.
As it stands, teh only format which supports BOTH playback devices is VC1.
Admittadly, its MS< however rendering from Vegas, its as fast as DV. Using Bitrates between 12K and 17k the image quality is comparable to 25mbps HDV. 12k might sound a little low, but consider that Terminator 2 HD WMV commercial release is only encoded up to 8mbps
Somethign needs doing. If Sony dont want us to author BD using blueprint, thats fine, however there is no reason not to have teh ability to author a proper DVD-like menus with VC1, AVCHD, M2t or any other format we might want to use.
As it stands, Vegas is stunted in this regard and the mad rush for HD delivery has left Vegas and DVDA behind everyone.
Consideirng BD is a Sony product, one would like to think that its brethren companie would be the first to offer such possibilites.
Sadly its a case of the blind leading the blind.
8) HDV support.. I am sure there are many users or beta testers who use canon or other equipment which SCS could borrow for extensive testing. There is no reason for one camera to be supported while another is not, then to see totally new formats being supported while the older acquisition tools are forgotten.
It seems that SCS are forced to play a "get in in quick" game.. then lets fix it later mentality. This doesnt cut it. Consideirng it doesnt even support straight MXF on teh timeline of Sony EX material, it makes you wonder what the hell is going on there.
Even FCP supports straight MXF
9) speaking of testing. Extensive care needs to be taken with tis obviously. However it seems bet testing of the new apps has gone to an all time low.
Im sorry, but this has to be the worst management of released NLEs i have ever come across.
I used to sell and distribute turnkey NLE systems and Beta test for Pinnacle.
EVERY release has its issues, but NOT like this.. Not on such a global workflow scale.
Editors shoudl not need to spend hours troubleshooting. Theyre job is to edit. their time is precious.. beleive me.. I live it 29hrs a day and i write ths as i render
The point is, is that more extrremem through testing is paramount to Vegas success. Differnt enviornments, workstations, configurations. and what teh tester reports NEEDS to be actioned IMMEDIATELY before release.
Like i keep saying. im happy to wait lan additional 12months for Vegs to do what i need. I dont care about the other NLEs but if i can wait 12months to make sure Vegas does EXACTLY what i want it to, then im happy to wait that time to get the tool i need to get my job done.
this wil never happen becuase they obvioulsy think we want vegas to keep moving..
Keeping it "unfinished" but moving nonetheless...
As it stands, vegas is unfinished. Ther are no ifs or buts about it.
it cannot handle the most basic of Progressive scan streams, i loathe to imagine how it will handle 1080p or 2k in progressive.
So those working in PAL land wanting to use interpolation to change frame rates for NTSC delivery (25p to 30p or 60i) then your screwed if your using progressive, its that simple.. 24p shouldnt be a problem though, but this brings me back up to BD formats as 25p isnt even supported with BD (ie its not an approved format for which to deliver.. nice to see Sony think of the rest of the world...25p isnt even on the spec sheet...
10) HDV black frame.
A simple soluiton would be to create a database of timecode data in txt file format which is saved along the vidcap file after cpature. vegas then accesses this data if there is a break in timecode or GOP structure
As the clip is thrown on the timeline and the audio and frames are drawn for NLE access, this should occur at the same time.
This optical scanning of the clip will ensure that any timecode breaks are found and the clip is stitched back together as one clip opposed to creating random clips.
11) Smarrtrendering
Why is it slower than realtime on a dual core? All that is happening is the GOP is being rebuilt and stitched where required. The scanning of said clip shouldnt take this long. Yes its good to have, but its pointless if its as fast as rendering a whole new clip. The point is to retain quality and deliver faster is it not?
12) Vegas crash force reset.
If vegas crashes, in most cases you MUST reboot to remove the dead V from your pagefile. Even force removal apps do not work.
Ok my render is done time to get back to it..
BUT before i go, i really do think we need to petition these issues. They are known isues, they have ben bought up in the past and theyre are solutions to this.
I mean really how SCS can handle knowing people are using a $100 app to author hybrid BD discs is beyond me. I know if I was a boss, and my clients started going to someone else becuase they offered what i wasnt offering at THAT time, id be furious.
Irrespective of the politics behind it, the fct remains is that SCS are losign clients EVERY DAY
Be it throgh vegas issues or DVDA issues...
If something is not done quickly, i honestly dont see vegas and DVDA lasting for another year...Things are now moving forward so fast that were just keeping up with our clients. the only thing slowing us down is this particular tool whch we choose to use.
Im happy to wait (be it for a render or for an update), but i know many who are not
Forget the marketing and forget what the compeition are doing.
Just look at what is happening here and consider what we need to make Vegas work for us
Im not complaining about what vegas cant do, and believe me when i say that it does more things in a more efficient way than any otehr NLE.
BUT it seems this mad rush to compete has lost focus on what an NLE is all about. And that is to provide a solid working environment where the tool does what it says it does.
Like a mechanic, there are a myriad of tools, makes and brands available to us. We can also use certain tools for differnt purposes, such as a trolly jack vs a hydrolift...
You get my meaning. They each get us from A to B.
HOW we get from A to B is the important issue here.
Im going to list elements here which i believe need to be looked at. As it stands, if these elements are not rectified by V9, I will be jumping ship.
Not because i want to but becuase i have to. I wont have a choice as Vegas wouldnt be able to delivery what i need.
1) TRUE SSE4 support. Not jsut within the render engine, but within the preview playback engine also.
If resources are available USE THEM.
Adobe have done this for a very long time now, and theyre obviously doign somethign right.
I would however like to invite my clients over to review their edits, however since i started usign vegas, i cannot do this as i CONSTANTLY have to explain that the dropped frames during preview wont be there in the final.
Vegas supports SSE4 on the render side, but we still need either a buffer, BG renderer, or proper SSE4 support for realtime playback
2) Progressive scan support. As it stands, vegas does not manage frame interpolation well.
A couple of examples.
You have interalced footage, and youve resized a 4:3 clip into 16:9
Youve cntrl dragged it for slowmo to 50%
Youve then rendered it out to progressive to match the another tape from a different camera and it looks fine.
Now to the same thing but before you render, REFRAME your pan and crop (is slide your frame up or down) to an odd number or a number which doesnt calculate within a factor of 2
Now render it and tell me what you see...
The slowmotion is all jerky and stuttery, with duplicate rubbish frames
Render to interlaced and it looks fine
In addition to this issue, the move of technology into HD forces the work itself to be of an even higher accepted value than waht SD used to be.
1080p footage is the bees knees at this time in regard to consumerism and frankly, Vegas cannot cut it.
Those wanting 1080p cannot utilise slowmotion. If stuttery Slowmotion is acceptable, then good for those people accepting it. But I paid 100bux for a slowmotion app which has absolutely NO ISSUE with offering a true interpolation of frames.
LLLets face it, the bulk of Vegas users are in fact wedding and events producers. The NLE falls within their budget, and once they realise that its a Vegas fault (when demand for 1080p increases to a point of saturation) then and only then will they realise that there is a serious issue with Vegas and Progressive scan
3) AC3 5.1 encoding should be faster than MPG 2 encoding. As it stands, irrespective of what CPU you use, AC3 encoding can be as fast as realtime, up to 4 to 5 times realtime. THIS is now what is slowing down render times. Not the other way around.
God forbid yo uuse the clipped peak restoration plugin.. youll be there for 6 hours for every hour..
4) 32bit rendering should be offered on a clip level, not project level. The colour space shouldnt automatically jump from studio to computer RGB. If it wasnt for Glenn Chan, noone would know WTF to do with it. 32bit rendering on teh outset also shouldnt affect colour gamut. Not until the process is running and viewwable to the editor. As it stands, those that do not understand how it works, (thanks to Glenn) would think there is something wrong.
Sadly this is the majority of users as not everyone comes here
32bit rendering should be an OPTION within a certain clip due to the fact that most times, its not needed.
That and the fact that it needs to have it memory management rebuilt. It just doesnt work
5) Vegas is in sore need of some new filters and motion manipulation
6) Timecode data per clip needs to be visible, much liek the data seen on an unporcessed DV stream previewing through 1394. Time date stamps are visible as are camera settings etc.
There is no reason why this data cannot be viewable. If not within the timeline in the media properties area
7) HD delivery. I dont know what the issue is surrounding DVDs support of DB or DVD5/9 to BD formats are. I also do not know why HD DVD has been looked over completely.
As it stands, teh only format which supports BOTH playback devices is VC1.
Admittadly, its MS< however rendering from Vegas, its as fast as DV. Using Bitrates between 12K and 17k the image quality is comparable to 25mbps HDV. 12k might sound a little low, but consider that Terminator 2 HD WMV commercial release is only encoded up to 8mbps
Somethign needs doing. If Sony dont want us to author BD using blueprint, thats fine, however there is no reason not to have teh ability to author a proper DVD-like menus with VC1, AVCHD, M2t or any other format we might want to use.
As it stands, Vegas is stunted in this regard and the mad rush for HD delivery has left Vegas and DVDA behind everyone.
Consideirng BD is a Sony product, one would like to think that its brethren companie would be the first to offer such possibilites.
Sadly its a case of the blind leading the blind.
8) HDV support.. I am sure there are many users or beta testers who use canon or other equipment which SCS could borrow for extensive testing. There is no reason for one camera to be supported while another is not, then to see totally new formats being supported while the older acquisition tools are forgotten.
It seems that SCS are forced to play a "get in in quick" game.. then lets fix it later mentality. This doesnt cut it. Consideirng it doesnt even support straight MXF on teh timeline of Sony EX material, it makes you wonder what the hell is going on there.
Even FCP supports straight MXF
9) speaking of testing. Extensive care needs to be taken with tis obviously. However it seems bet testing of the new apps has gone to an all time low.
Im sorry, but this has to be the worst management of released NLEs i have ever come across.
I used to sell and distribute turnkey NLE systems and Beta test for Pinnacle.
EVERY release has its issues, but NOT like this.. Not on such a global workflow scale.
Editors shoudl not need to spend hours troubleshooting. Theyre job is to edit. their time is precious.. beleive me.. I live it 29hrs a day and i write ths as i render
The point is, is that more extrremem through testing is paramount to Vegas success. Differnt enviornments, workstations, configurations. and what teh tester reports NEEDS to be actioned IMMEDIATELY before release.
Like i keep saying. im happy to wait lan additional 12months for Vegs to do what i need. I dont care about the other NLEs but if i can wait 12months to make sure Vegas does EXACTLY what i want it to, then im happy to wait that time to get the tool i need to get my job done.
this wil never happen becuase they obvioulsy think we want vegas to keep moving..
Keeping it "unfinished" but moving nonetheless...
As it stands, vegas is unfinished. Ther are no ifs or buts about it.
it cannot handle the most basic of Progressive scan streams, i loathe to imagine how it will handle 1080p or 2k in progressive.
So those working in PAL land wanting to use interpolation to change frame rates for NTSC delivery (25p to 30p or 60i) then your screwed if your using progressive, its that simple.. 24p shouldnt be a problem though, but this brings me back up to BD formats as 25p isnt even supported with BD (ie its not an approved format for which to deliver.. nice to see Sony think of the rest of the world...25p isnt even on the spec sheet...
10) HDV black frame.
A simple soluiton would be to create a database of timecode data in txt file format which is saved along the vidcap file after cpature. vegas then accesses this data if there is a break in timecode or GOP structure
As the clip is thrown on the timeline and the audio and frames are drawn for NLE access, this should occur at the same time.
This optical scanning of the clip will ensure that any timecode breaks are found and the clip is stitched back together as one clip opposed to creating random clips.
11) Smarrtrendering
Why is it slower than realtime on a dual core? All that is happening is the GOP is being rebuilt and stitched where required. The scanning of said clip shouldnt take this long. Yes its good to have, but its pointless if its as fast as rendering a whole new clip. The point is to retain quality and deliver faster is it not?
12) Vegas crash force reset.
If vegas crashes, in most cases you MUST reboot to remove the dead V from your pagefile. Even force removal apps do not work.
Ok my render is done time to get back to it..
BUT before i go, i really do think we need to petition these issues. They are known isues, they have ben bought up in the past and theyre are solutions to this.
I mean really how SCS can handle knowing people are using a $100 app to author hybrid BD discs is beyond me. I know if I was a boss, and my clients started going to someone else becuase they offered what i wasnt offering at THAT time, id be furious.
Irrespective of the politics behind it, the fct remains is that SCS are losign clients EVERY DAY
Be it throgh vegas issues or DVDA issues...
If something is not done quickly, i honestly dont see vegas and DVDA lasting for another year...Things are now moving forward so fast that were just keeping up with our clients. the only thing slowing us down is this particular tool whch we choose to use.
Im happy to wait (be it for a render or for an update), but i know many who are not