Bug Reports?

[PeterPan]

I'm curious whether in all these forums there is any area to specifically report bugs, problems, or crashes. I've owned Creator 2009 for less than a week and have already found plenty of ways to crash it (I mean like... VideoWave has encountered a problem and needs to close down... sorry for the inconvenience") type of problems. I'd thik they would want to know so they could better track them down?

[gaper1]

If you want to provide feedback, you can go to Help -> Provide Feedback to Roxio in Roxio Home.

[REDWAGON]

I wouldn't call your specific crash a bug in the software. There are Many types of hardware and computer specifications that can cause "crashes" and other problems when you run a particular program in C2009 (and other previous Roxio programs as well). If you have a very specific problem that you can tell us about, then that can be looked into. Not something as general as you posted.

 

Frank...

[PeterPan]

I wouldn't call your specific crash a bug in the software. There are Many types of hardware and computer specifications that can cause "crashes" and other problems when you run a particular program in C2009 (and other previous Roxio programs as well). If you have a very specific problem that you can tell us about, then that can be looked into. Not something as general as you posted.

 

Frank...

 

Well Gee... I was general because I wasn't sure if this was the area to post it in! But since you ask, let me say this before I describe the details. As a programmer myself, ANY combination of actions that can repeatably result in a program abort is certainly a bug. Granted there are many bugs that actually can be traced to operating system or peripheral supplied DLLs and services. There are even bugs in the Direct-X 9 this program uses, which is why there is Direct-X 10. But the point is if it were my product and that happened, I'd look for a work around.

 

Anyway, here's the issue. It relates to sound processing during export. As near as I can tell, it is the result of (a) having used the audio editor to modify the volume envelope of a segment of the native audio portion of a clip, specifically to boost the volume of important content at that point, and ( Attempting to export the audio WITH the box checked to NORMALIZE the audio in the entire exported file. After crashing at the same point in the export repeatedly, I came to realize it was crashing while processing that portion of the project where my graphically drawn volume boost was occurring. Undoing the NORMALIZE resulted in a clean export.

 

I realize that details can be a factor, and it is obviously impossible to send you an entire project when huge video clips are involved. But in case it matters, the main Video track (as opposed to clips I had in the overlay track) was an AVI file, and the output method I had chosen was DV format AVI. I don't know exactly what type of AVI file the original imported clip was. there were also some speare audio clips in the audio track, but there were no such audio clips in the portion of the project that would caust the crash.

 

I believe some kind of math error is occuring, perhaps an un-handled overflow exception, and probably due to a conflict between the normalize function and the volume boost produced by the envelope built up graphically in the sound editor. The resulting crash would display the typical warning that "the program has encountered a problem and needs to shut down", along with a dialog box referencing a pure virtual function call that had failed. The title bar on that dialog box specifically mentioned VideoWave, so there is a reasonable likelihood there is an oversight in the product code.

 

A simple NORMALIZE function typically works by pre-scanning an entire audio track (or clip) to find the greatest peak amplitude. It then calculates a factor to multiply that loudest peak by in order to achieve the maximum possible number within the allowed (usually 16 bit ) resolution. As the file is processed, it then multiplies every data point in the sound track by that number. So the problem may lie in the pre-scan not taking the manual volume boost into account, thus causing an overflow condition when the boost AND the normalize factor are both applied..

 

That's just a guess at what's going on. In any case, the problem is repeatable, and if the company is interested in resolving it I'd be happy to try a few recommendations. Obviously I KNOW now how to avoid the problem. But it seems that either a smarter NORMALIZE algorithm is in order. I use a lot of high end audio software that handles such unintended user generated audio overflows without crashing. Unintentional audio overflows are too easy to do, and the program should predict and CATCH such exceptions.

 

--PeterPan

 

 

 

[Jim_Hardin]

Program has been out for 7 months and you are the first to notice this??? Not what I would call a bug but - In VW, click on Tools – Report Bug.

 

[PeterPan]

Program has been out for 7 months and you are the first to notice this??? Not what I would call a bug but - In VW, click on Tools – Report Bug.

 

Ah thanks!

 

Regarding your comment, yes that's how bugs are discovered... when someone new comes and uses the tool in a new way. See, I'm new at the program. The reason companies give programs to beta testers is to get the into new hands.

 

Of course if everyone, including the company, sees this program as "bug free", then whatever bugs exist will remain. Kind of like "Windows" :-)

 

Program has been out for 7 months and you are the first to notice this??? Not what I would call a bug but - In VW, click on Tools – Report Bug.

 

In Videowave, under TOOLs, there is no "report bugs" option.