Some time ago I bought DMF6 Plus and I also own VS10, MSP7 & MSP8, among other Ulead programs. I use the Video Capture function of MSP7 (it's more stable than MSP8) to capture MPEG footage from my JVC GR-PD1 (the European equivalent of the HD1). Lately however I have been having difficulty with this function. Audio capture is out of sync with video by exactly 10 secs. I have been racking my brains out trying to find the cure. Ulead have not responded to any requests for help so I have been left to test every bit of my equipment and software myself. In a Eureka moment I have traced it back to a little file named mpgvparse.dll which Ulead place in Program files\Common Files\Ulead Systems\MPEG. This was "updated" when I installed DMF6. Because it is in Common Files it is NOT uninstalled when you remove DMF6. I had to manually replace this file with an older version (supplied some time ago by Ulead when they fixed a bug in their HDV Capture Plugin) and now I am capturing as before.
Ulead clearly do not backtest their own products when they make changes to files in the Common Files folder. The recent patch for DMF6 did not solve this problem. I hope that Ulead do read the messages on this forum because I would love an updated version of mpgvparse.dll which allows me to use both MSP Video Capture AND DMF6 Plus.
MSP Video Capture users beware DMF6
The real problem here is the fact that Ulead have common DLLs for many proggies.
This is a legacy going back to DOS days (obviously not with DLLs, but with COM files). If we go back to, e.g., WordPerfect c. 1986, this was already a complex word processor with many functions that came on 2 1.2 Mb 5¼ floppies and was installed on 10-20 Mb HDDs. Also, RAM was typically 1 Mb so that you couldn't have an infinite number of sub-routines called from there. There was therefore every reason to use the same routine for different parts of the application and common files were entirely justified. This could arguably be extended to the mid 1990s with WIN95 and HDDs of, say, ~50 Mb as the norm.
Then came the great explosion of HDD space and RAM became cheaper. No longer was it necessary to have common DLLs: each application could have its own. I learnt the value of this many years ago, about 12 years ago in some complex scientific software I wrote. I tweaked a common file once and achieved the result I was seeking but inadvertently did not test it in other parts where that sub-routine was used. It was a matter of a few days before the complaints poured in. I then moved the tweaked file to the specific directory and restored the original one to the common directory. This inspired me to work on eliminating the common directory (some files had to be moved to up to 6 different locations). The total disk space needed was increased by about 10% but each routine was entirely self-contained (to avoid risks, I changed the names, as well). What I did find was that execution times were slightly reduced, into the bargain, because calling up a common file meant searching for it on another part of the drive - and drives had seek times 10 times longer than today, in those days.
Since that day, all sub-routines I've programmed have been specific to the routine and I've never had common files, which I consider bad and lazy programming. Nobody would care today if a compiled proggy took up 100 Mb or 120 Mb of HDD, so the common file no longer has a raison d'être. Unfortunately, Ulead have never understood this, even though this is not the first time I've said this. I told them many years ago (I think when beta testing MSP7), but with no reaction. However, to be fair, they are not alone. Microsoft are much worse in this respect.
This is a legacy going back to DOS days (obviously not with DLLs, but with COM files). If we go back to, e.g., WordPerfect c. 1986, this was already a complex word processor with many functions that came on 2 1.2 Mb 5¼ floppies and was installed on 10-20 Mb HDDs. Also, RAM was typically 1 Mb so that you couldn't have an infinite number of sub-routines called from there. There was therefore every reason to use the same routine for different parts of the application and common files were entirely justified. This could arguably be extended to the mid 1990s with WIN95 and HDDs of, say, ~50 Mb as the norm.
Then came the great explosion of HDD space and RAM became cheaper. No longer was it necessary to have common DLLs: each application could have its own. I learnt the value of this many years ago, about 12 years ago in some complex scientific software I wrote. I tweaked a common file once and achieved the result I was seeking but inadvertently did not test it in other parts where that sub-routine was used. It was a matter of a few days before the complaints poured in. I then moved the tweaked file to the specific directory and restored the original one to the common directory. This inspired me to work on eliminating the common directory (some files had to be moved to up to 6 different locations). The total disk space needed was increased by about 10% but each routine was entirely self-contained (to avoid risks, I changed the names, as well). What I did find was that execution times were slightly reduced, into the bargain, because calling up a common file meant searching for it on another part of the drive - and drives had seek times 10 times longer than today, in those days.
Since that day, all sub-routines I've programmed have been specific to the routine and I've never had common files, which I consider bad and lazy programming. Nobody would care today if a compiled proggy took up 100 Mb or 120 Mb of HDD, so the common file no longer has a raison d'être. Unfortunately, Ulead have never understood this, even though this is not the first time I've said this. I told them many years ago (I think when beta testing MSP7), but with no reaction. However, to be fair, they are not alone. Microsoft are much worse in this respect.
[b][i][color=red]Devil[/color][/i][/b]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
And yet you assert that M$ produce "bloatware".Devil wrote:The real problem here is the fact that Ulead have common DLLs for many proggies... <snip>
Microsoft are much worse in this respect.
Windows caches DLLs by default (Steve Jones' tutorial on streamlining your video editing profile shows how to prevent DLLs from eating memory. Surely if it's a tweak worthy of addition to the tutorial, the savings from shared DLLs are advantageous.
DLL dependencies should be easy enough to ascertain in your own software, so regression testing the routines that use them after a change isn't particularly hard.
There's a difference between an extra 10 or 20 Mb for separate dlls and a basic installation of Vista requiring 10 Gb or more.Gorf wrote: And yet you assert that M$ produce "bloatware".
[b][i][color=red]Devil[/color][/i][/b]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]