Forum Home
Press F1
Thread ID: 110528	2010-06-21 04:24:00	Latest version of Ulead VideoStudio	FoxyMX (5)	Press F1

Post ID	Timestamp	Content	User
1111972	2010-06-21 04:24:00	OK, so it's Corel VideoStudio Pro X3 now, but does anyone here use it? It appears to have quite a few negative reviews from users. I have Ulead VideoStudio 8.0 SE which I like but it doesn't support some of the latest formats so I'm still looking for something to replace it.	FoxyMX (5)
1111973	2010-06-21 04:40:00	Ive got the trial of it, but havent installed it again yet.. Last time I used it tho, it kept closing on me, with a file I was editing. Probably because the file was over 3-4 GB (a stupid limitation of 32 bit programs).. What version of windows are you using, and what are you trying to edit? Whats the format?	Speedy Gonzales (78)
1111974	2010-06-21 11:00:00	MOV and AVCHD files from the camera using WinXP Home . Reviews have said the program is slow and a resource hog and since my PC is getting a bit long in the tooth these days I don't think it will hack it . AVS4U does the job but it has a few annoyances that makes it a pain to use after a while .	FoxyMX (5)
1111975	2010-06-21 11:04:00	Does the cam have firewire?? Is it a videocam ? If it does, you could use firewire to import it into Moviemaker. Thats if it works. But depending on how much ram is on it, it maybe a strain.	Speedy Gonzales (78)
1111976	2010-06-21 14:58:00	Foxy: My apologies for hijacking your thread - but I feel this needs to be said. Feel free to ignore my post, as it has nothing to do with the thread topic. Speedy: ...because the file was over 3-4 GB (a stupid limitation of 32 bit programs)...Incorrect. 32bit programs can address files of any size, provided they are using a suitable interface to do so, and the programmer who implemented it didn't do something stupid like trying to store (relatively) large byte offsets in a 32bit integer. In the real world, this usually means the smallest value permitted by the following: The kernel's implementation of file-related system calls The filesystem's internal addressing system / structure The particular implementation of the filesystem in use Internal handling of files by the program in question (e.g. storing byte offsets in a 32bit integer) Any library abstracting any of the other items in this list The most common filesize limit that people seem to run into is the 4GB max filesize on FAT32 filesystems. This is due to the internal use of 32bit addressing in the filesystem structure, and has nothing to do with whether a program is 32bit, 64bit, or something else entirely. --- I know it may seem like I'm out to get you over every tiny error you make (I'm not), but I do have a reason for constantly calling you out on stuff like this. I've explained it several times before, both via PM and (more recently) in the public forums, but here it is again (and yes, I know this particular error isn't going to damage anyone, but it's part of a larger picture): Over the years, you have amassed a huge amount of respect here, through giving many, many members (and probably even more anonymous googlers) a wealth of valuable information to help resolve their various IT woes. As a result, the automatic reaction of many people here is that it's OK to blindly trust everything you say. While this usually has the benefit of allowing people to resolve their problems quickly without an extensive search for additional information or opinions, it does occasionally cause them some additional strife. For a wee while now, you have been dishing out advice that is based purely on your guesses or opinions, without checking your facts, and without fully understanding the background that those guesses are based on. Thankfully this only happens in a small minority of cases, and you usually know what you're talking about, but noting your prolific posting output, you post enough of these zingers to do some serious damage to those who blindly follow such advice without checking it first - and a lot of people do. This applies more to you than most others on the forum. You're one of the most valuable contributors we have here, and you help an awful lot of people, but I think that this posting of guesses and assumptions really needs to stop - you may not realise it, but some of the information you give out can lead to a real loss of money, time, data and / or hardware. Please make sure you fully understand what you're talking about before you post, or if you don't actually know for sure that what you're saying is correct, then make that clear (or don't post it at all). Guesses are fine provided they're labelled as guesses, but when you state them as fact it can do a fair bit of damage. Over the years I've cleaned up after a lot of bad advice and / or technical support; this kind of thing can leave users devastated and in tears when it all goes wrong and they have to deal with the fallout. Incorrect advice or help, however well intentioned, is often worse than no help at all.	Erayd (23)
1111977	2010-06-21 22:18:00	Here we go again :rolleyes: Its time to put you on ignore. Try opening a 4 gb file in a 32 bit program. It'll load, but if you edit a video file, you'll get so far then the program will quit	Speedy Gonzales (78)
1111978	2010-06-21 23:56:00	A slower but workable solution is to use Super to convert the file to MPG format, and then let Video Studio loose on the MPG. I use Vid Studio 6 myself. Have played briefly with later versions to assess their worth (or the lack of) and have not been impressed! Whatever codec they use for compressing is also below par with regard to the level of compression and the resultant quality. Gotta wonder why I keep using it... familiarity I suppose, and taking the easy solution. I find it tends to crash if you have an edit involving the last second of a clip. I suspect it tries to look past the last frame of the clip for encoding future frame info into the code code for frames that are within the timeframe being kept, and consequently falls over when it addresses a point outside of the source file. What riles me most though, is the upgrades offer stuff all improvements, and come at a very high price compared to the full price of the product - they show no respect for their existing client base (weel, that was in the ULead days anyway)	Paul.Cov (425)
1111979	2010-06-22 00:41:00	Here we go again :rolleyes: Its time to put you on ignore. Try opening a 4 gb file in a 32 bit program. It'll load, but if you edit a video file, you'll get so far then the program will quit Oh really. OK, how about some examples of large file use on a 32bit system then? DVD ISO images (both creation and use) Most high-def editing projects of notable length Standard-def editing projects involving lots of raw footage Large databases Large archive files (zip, rar, windows backup etc) Any kind of open-ended stream processing (although this is a special case - things like sockets don't actually have a size, but can easily see considerably more data than we're talking about here) Raw access to block devices such as disks Emulator & hypervisor disk images (e.g. virtual PC & friends) The only reason that editing a large video file can cause your application to quit is if the application in question was poorly written. A well-written app will either use the file with no trouble (this will be the case for most video editing apps), or will display an error and simply refuse to use the file past whatever arbitrary limit the developers set. Where's your evidence? If you're guessing, say so. If you're not guessing, you will be able to find some proof of what you're claiming.	Erayd (23)
1111980	2010-06-22 00:47:00	I've been doing video editing for years, and of course started on 32bit. I've had no problems working with 10GB+ (yay for DV video..) video files. If it makes any difference I've always used Adobe Premiere.	Dannz (1668)
1111981	2010-06-22 01:10:00	Getting back to the first post you could try XMedia http://www.xmedia-recode.de/	Roger Hunt (13648)
1 2 3