Is VS10 such a good product?

Post by **jparnold** » Tue Nov 07, 2006 10:52 pm

I have been reading with interest the many postings from users who have experienced problems using VS10 especially crashes and freezing.

I too have experienced some crashing problems and I am now asking myself if I did the right thing in upgrading to VS10. I can't remember too many posting from users experiencing similar problems with earlier versions.
Oh yes there have been various suggestions as to mismatch of clip types (AVI mixed with MPEG clips), processor types etc causing problems but why didn't these same issues cause problems with earlier versions?
Was VS10 released prematurely by Ulead before all problems were corrected and/or user friendliness ensured?
It seems that Ulead must be made aware of these issues or their customer base will decrease in the future.

What does everyone else think?

PeterMilliken · Post by **PeterMilliken** » Wed Nov 08, 2006 12:04 am

Hi JP,

This is an extremely difficult question because there are no hard numbers or even repeatable test environments. For example, how do we know that VS 10 crashes anymore frequently than VS 9? Does your VS 10 crash because of a particular project content that you never tried on VS 9?

I "loaned" my nephew a copy of my VS 9 to do a school assignment. It crashed with a reasonably regular frequency on his computer. I use VS 9 on two computers (a desktop and a laptop) without a single crash experienced. The desktop has an AMD CPU the laptop an Intel. I don't own VS 10, I purchased MSP 8 in an endeavour to get off ULeads eternal feature creep and shell out of upgrade money

So I would suggest that it *might* be the environment in which VS is running rather than any necessarily inherent "buginess" in VS itself - but this is difficult to prove without a repeatable test environment.

A users computer environment is very much a unique combination of application software, device drivers and hardware bits and pieces - so what made VS 9 crash on my nephews computer and yet it is rock solid on my computers? Many factors come into play - is it because he surfs the Internet and visits sites that I don't on my computers? Was he exercising some feature of VS 9 that I have never used? etc etc

*IF* there are more crashes of VS 10 than previous version then is there more users of VS 10? i.e. is it statistically the same number of users or has the statistics changed?

So there is no really easy way to explore this question - even in your case, you seem to be saying VS 9 didn't crash and VS 10 does - is it the exact same computer/environment i.e. you haven't upgraded anything at all between versions? You haven't installed any new software (that might cause conflict), you haven't installed and then de-installed some game package that might have left some incidental debris behind?

Assuming you haven't changed your computer hardware, a reasonable test would be to reformat your hard drive, reload your base applications software (minus any version of VS) and then snapshot it to DVD. Then load VS 9 and use it for a while (how many projects is a reasonable test? How many hours of editing?). Then reload your C: drive from the DVD backup and load VS 10 and do exactly the same projects! Record when and how frequently either VS crashed. This is the only "scientific" method I can think of to determine whether there really is an instability in the current version of VS compared with a previous version.

This is one of the reasons why ULead may well NEVER be able to stop the crashes - they need a repeatable way of duplicating the problem before they can fix it. They can't do anything with tech support requests such as "VS 10 crashes randomly when I am editing a project" - I will guarantee they don't even pass those support requests onto their programmers because unless the user can provide some clue as to how they might repeat the problem in their test environment then it is just a waste of time.

Peter

CycleWriter · Post by **CycleWriter** » Wed Nov 08, 2006 12:06 am

I think Ulead needs to focus more on making VS stable and finding ways to make the things a budget video editor should do work properly without resorting to workarounds, and quit dumping more high-end features (like HD support and 5.1 surround sound) into the program that few users need or are better suited to a more robust editor. But I've said this all before...

Post by **Ken Berry** » Wed Nov 08, 2006 12:17 am

Peter has given IMHO an excellent response. However, he missed out one other important factor. A Board like this one is, by its very nature, one to which people come when they are experiencing problems. Presumably, unless you are people like me and others who come to try to help those people with problems, other users who don't experience any problems don't come to the Board. Like Peter, though, I can only repeat that we just don't have any figures for the breakdown of satisfied vs dissatisfied users. Asking your sort of question here is automatically skewed since it will be mostly only people who have problems who will even read it in the first place.

I personally have been using VS since version 7 through to VS10+, and I have never had the program totally crash. It did hang a few times with VS9, but that was when I used mpeg-2 files captured with another software package which came with a capture card and which were, as it turns out, corrupt. In other words, the hangs were not really caused by some inherent fault in VS9 but in the captured files. Another couple of times I had a hang -- I think also with VS9 though it may have been VS8 -- it turns out I had accidentally erased the relevant codec (in fact a number of codecs!!

). In other words, my fault, not Video Studio's...

That is not to say that I have never experienced some problems with any of the versions of VS I have used. I have. And I also have a list of gripes about the way VS goes about certain things. But at the end of the day, I find I also have complaints about other video editing software I use. None of them is perfect...

PeterMilliken · Post by **PeterMilliken** » Wed Nov 08, 2006 12:19 am

I agree on the stability comment

But personally have never experienced any problems with instability

But I disagree on the feature creep - they need a reason for all of us VS users to keep sending them more money i.e. a perfectly practical way is to offer a feature that they believe most current users will want bad enough to pay the upgrade i.e. 5 in 1 sound etc.

I joined the VS treadmill with VS 8. I upgraded to VS 9 and then along came VS 10 (with its increased upgrade price!) and I realised what ULead marketing were doing - dribbling in features that can already be found in MSP and getting a steady stream of money from the (larger) user base of VS land as they all scramble to upgrade. So I decided to break the cycle and get all the features in one upgrade - I got my hands on a copy of MSP 7 (VE) and then upgraded to MSP 8.

I would suggest that the VS users provide a lot of the funding (through "frequent" upgrades) to pay for ULeads development of their editing products (the user base for higher end products like MSP is most likely much smaller - witness the number of messages on the VS forum versus the MSP forum

). So I can't really blame their approach - I just decided not to contribute as much along the way

Peter

Post by **jparnold** » Wed Nov 08, 2006 12:23 am

In reply.
VS10 crashed when editing a project which I created using VS9 (which did NOT crash!). That is I had created (but not finished) a project using VS9 and had NO problems.
In between VS9 and VS10 I installed a NEW larger hard drive (VS data files were on my D: drive) and re-installed XP Home edition plus SP2 then installed VS10 plus SP1.
I NEVER had problems with VS7, VS8 or VS9 so I really do think that the crashing problems are DUE TO VS10 and not my environment.
VS10 crashed when I simply selected (left mouse click) on a clip within the project before I attempted to trim that clip. I had been doing other thing s(to the project before the crash insluding rearranging clips in the timeline, adding transitions etc.
The ONLY thing I can attribute the crash to was the fact that I was editing a project (with VS10) which had been created using VS9 BUT I would have thought that projects created in earlier versions would be TOTALLY COMPATIBLE with later versions.
Any comments?
John

PeterMilliken · Post by **PeterMilliken** » Wed Nov 08, 2006 1:07 am

As I said, I don't have VS 10, so I haven't tried using a VS 9 project file with VS 10. VS 10 is supposed to be compatible with VS 9 project files - but you might have discovered an incompatibility. I would venture to say that since VS 10 has been released for some time now there are very few people who are still in a position of using a VS 9 project file on VS 10.

The aim when troubleshooting a problem is to isolate the problem so that the perceived symptom (a crash in this case) is repeatable and you can then make a tech support request that ULead might actually look at

Perhaps start the project from scratch i.e. don't use the VS 9 project file at all, do the editing etc the same way and attempt to reach the same point where VS 10 crashes with the VS 9 project file - is it repeatable? Or is the problem only evident if you use the VS 9 project file as a starting point?

If you don't get a crash when working from scratch then you have used a "work around" and I seriously doubt you will get any response from ULead wrt "fixing" the issue. If you do get a crash, then attempt to make it repeatable and you have an ideal point to take the issue to ULead for support - describe the problem, environment, editing steps that led up to the crash and then make a copy of all input material so they can repeat it and send it off in the post.

I do remember when VS 10 first came out that people experienced problems due to memory leak - I believe it was due to use of the overlay track. I assume that this particular issue has been fixed with a patch? Perhaps you have discovered another memory leak?

If you search the board you can probably find posts relating to suggestions on how to troubleshoot problems. Use the Windows task manager while you do your editing and monitor memory usage.

Alternatively, finish the project in VS 9 and see whether new projects using VS 10 crash - probably the simplest approach

.

Peter

heinz-oz · Post by **heinz-oz** » Wed Nov 08, 2006 1:14 am

AFAIK, the recommendations are to finish a project in one version and not to jump mid project. I would create a new project to try it out and load the already captured clips into that.

CycleWriter · Post by **CycleWriter** » Wed Nov 08, 2006 1:16 am

PeterMilliken wrote:I agree on the stability comment But personally have never experienced any problems with instability

But I disagree on the feature creep - they need a reason for all of us VS users to keep sending them more money i.e. a perfectly practical way is to offer a feature that they believe most current users will want bad enough to pay the upgrade i.e. 5 in 1 sound etc.

Peter, you misundertook me (get it

). I'm all for new features, but they shouldn't come before things that have been complained about in successive versions are fixed. For one, SmartSounds has a long history of causing problems with VS. I use VS mainly for SS when I need to create music from scratch. When I don't, I rarely use VS because all the other problems and workarounds are too much to deal with. For instance, I hate the naming conventions VS uses on captured videos. I want to be able to name them myself when I create them. Why VS has ignored this for years is beyond me. When doing simple little video I want to be able to burn directly from the timeline. Unfortunately, this is often a hit-or-miss proposition in VS, particularly when a menu is involved. It shouldn't require adopting a workflow dramatically different from what the manual tells you to do. Many aspects of VS are hardly what one would call intuitive. Why does the library constantly revert back to default with every change of workspace? These are just a few of the things I would rather see fixed before adding features like HD and 5.1 support. These are things that affect ALL users, while those features are utilized by so few and are really beyond the scope of what an entry-level video editor should do.

PeterMilliken · Post by **PeterMilliken** » Wed Nov 08, 2006 1:32 am

Hi CycleWriter,

Unfortunately I was letting my cynicism shine through

I agree with all of your improvements - I would personally prefer to upgrade for things such as you mention (making VS a more user friendly environment) than things like 5 in 1 sound etc.

What I strongly suspect is that ULead don't want to "waste" money on VS fixing "problems" that are long standing and well recognised (such as burning from the timeline). I suspect it is relatively "cheap" for them to take existing code from the MSP codebase and drop it into the VS codebase i.e. 5 in 1 sound. Not much investment in programmer effort and the test cases that the verification people do are already documented in the MSP test manuals, so it is just a matter of running the tests.

Whereas fixing a problem such as burning from the timeline (which obviously hasn't affected sales BTW!) would probably require considerable programmer effort and then test effort as well.

ULead obviously follow the same philosophy as Microsoft - if it doesn't affect sales then leave it be.

Peter

frank-l · Post by **frank-l** » Sat Nov 11, 2006 5:19 am

As a newcomer to VS10 and a programmer, I am puzzled by the readiness of users to accept excuses such as corrupt files etc. Any well designed program should detect and gracefully handle such situations. Just letting the program crash is indicative of either carelessness or incompetence on the programmers part. Yes it takes extra effort to design a quality program, but my experience has been it pays off in sales. Just take a look at the reviews of VS 10 on Amazon.

htchien · Post by **htchien** » Sat Nov 11, 2006 6:36 am

Hi Peter,

PeterMilliken wrote:What I strongly suspect is that ULead don't want to "waste" money on VS fixing "problems" that are long standing and well recognised (such as burning from the timeline). I suspect it is relatively "cheap" for them to take existing code from the MSP codebase and drop it into the VS codebase i.e. 5 in 1 sound. Not much investment in programmer effort and the test cases that the verification people do are already documented in the MSP test manuals, so it is just a matter of running the tests.

It is not so simple. Yes, there are some common modules shared in all Ulead products, however every time when each product is been tested it will go through the same long testing process. And every product will add its own new features to the share modules. It's not really that "cheap" and easy to take some code from one product codebase to the other.

PeterMilliken wrote:Whereas fixing a problem such as burning from the timeline (which obviously hasn't affected sales BTW!) would probably require considerable programmer effort and then test effort as well.

ULead obviously follow the same philosophy as Microsoft - if it doesn't affect sales then leave it be.

This is also not true. Ulead welcomes any bug or issue reports and will look forward to get them solved in the update pack (or the next version). However, if Ulead cannot get the response or cannot reproduce the issue then it's hard to solve the issue because you might not know where the problem is.

Again I would say, Ulead welcomes any report about problems and issues and will try to solve them if they can be reproduced in the lab.

Hope this helps.

H.T.

htchien · Post by **htchien** » Sat Nov 11, 2006 6:48 am

Hi Frank,

As a programmer you must know what you said is only an ideal situation. No matter how well designed a program, you will always find bugs in it. But software providers should be responsible to fix the issues user reports if they can be reproduced and verified.

However, sometimes it's the environment issue not the product itself.

Regards,
H.T.

frank-l · Post by **frank-l** » Sat Nov 11, 2006 7:44 am

Hi, H.T.
I agree with you that bugs will always creep in and can be hard to find. My point was that the video editing community seems to accept that frequent crashes just go with the territory. Worse, there is no expectation that the software will check capture device or file compatibility before attempting to use it and then fail gracefully. This culture seems to extend to the ULead folks. I keep finding "workarounds" that warn against using the software in an intuitive way rather than fixing a known problem. If the problem is well enough characterized to post a workaround then it should be repeatable and fixable.
As for the environment, I am running a clean install of Win2000 SP4 on an Intel mother board. I use a removeable hard drive drawer to be able to keep the video/audio editing off the internet with no security software installed. The computer shows no signs of problem using the alternate HD where I run realtime data acquistion software (mine) so the hardware seems reliable.

best,
frank

htchien · Post by **htchien** » Sat Nov 11, 2006 8:10 am

Hi Frank,

frank-l wrote:My point was that the video editing community seems to accept that frequent crashes just go with the territory.

Because it's really easy to get crashed sometimes, not just with Ulead but also with other software providers.

When you get involved in video editing, you will definitely need to use codec packs, which are following Microsoft DirectShow interface in the Windows world. The DirectShow interface basically is a plug-in mechanism to enumerate all codec packs in the system and tell the video software to use them via the common interface. However, if any codec pack is not well designed to follow the DirectShow interface or has some fatal bugs then it will crash the video editing system easily.

That's the world we need to live with video editing. No software is perfect, including the editing tool itself and the codec packs, but we can do as best as we can and find some workarounds to do it.

frank-l wrote:Worse, there is no expectation that the software will check capture device or file compatibility before attempting to use it and then fail gracefully. This culture seems to extend to the ULead folks. I keep finding "workarounds" that warn against using the software in an intuitive way rather than fixing a known problem. If the problem is well enough characterized to post a workaround then it should be repeatable and fixable.

Sometimes it's not that simple, really I mean it. Sometimes software providers can only provide workarounds because the problem is not in their side but is from Windows itself or some third party driver/codec packs.

frank-l wrote:As for the environment, I am running a clean install of Win2000 SP4 on an Intel mother board. I use a removeable hard drive drawer to be able to keep the video/audio editing off the internet with no security software installed. The computer shows no signs of problem using the alternate HD where I run realtime data acquistion software (mine) so the hardware seems reliable.

Maybe. But one software might be OK with the hardware configuration, the other might not and it's possible. Have you tried to copy the video file to the local HD and then try again to see if the issue will be fixed?

Best regards,
H.T.

Alludo USER to USER Web Board