A 12 gig file is unusually large, Thomas, so it's going to stress your system and, if there's a weak spot, it's going to find it.
Even if you work with a low-resource program like MovieMaker, your machine is going to lug, processing is going to take time and, with all the temp files flying around, a little fragmentation on your video drive could lock things up.
That said, if you're just doing simple editing and you want to create a WMV, I'd recommend (at least in this case) you do all your work in MovieMaker, since it tends to require less scratch disk space.
Otherwise, for more typical video editing, I think you'll find Premiere Elements works very well -- particularly on a computer with adequate power and with more like 30-50 gig free on your C drive instead of a mere 11 gig.
Adobe is hardly using the free 11GB and that value is higher than their bare minimum. I realize it may not be optimum for professional movie editing, but I cannot connect the behavior I'm seeing with 11GB of free space. The drive is also freshly defragmented using an excellent defrag program.
I used PRE7 instead of either Movie Maker or Nero8 as a way of introducing myself to the product. I'd like to try to get it to work.
I did that thing outlined in another forum thread about using Moviemaker to export a duplicate AVI. The two sizes were almost identical. I then used the new Moviemaker-generated 12GB AVI in PRE7, and it got to the same "Estimated Time: 0:00:05" as it did when it hit the 50% CPU utilization bug I mentioned, but this time, instead of 50% CPU, I'm seeing this error: "Audio encoding failed. If audio is in 2-pass VBR encoding mode, try CBR or 1-pass encoding." I don't know if this different behavior is due to the MoveMaker exported AVI or something else. I have not seen this particular error before.
Based on your feedback, I'm guessing folks don't typically import an entire hour long minidv for direct use. Given this, I'll try to break that file down into smaller chunks to see what that does.
Thanks for your suggestions.
But I still think you're bucking the odds, trying to operate such and intensive, high-resource program with only 11 gigs of free space on your C drive.
As I said, that C drive is going to be doing a lot of paging and a lot of fragmenting -- and fragmentation can mean huge blocks of space may not be available to use as page files.
BTW, that second drive you're editing to? It is formatted NTFS and not FAT32, right? FAT32 drives have a file size limitations that will choke video editing relatively quickly.
I know this is probably a dumb question, but sobeit...
Am I correct that it makes the most sense to capture to your internal (C) drive but edit to (scratch disks) to an external drive (like an eSATA)?
I'd capture, edit and keep my project and scratch disks on my second drive, Michael. (I'd also ensure that that drive is formatted NTFS rather than FAT32 to avoid file size issues.)
Thanks. That was my initial intention, but on some of the documentation on the website (or maybe in the PE 4.0 tutorial) it says to use your fastest drive which is usually your internal drive.
I appreciate your quick responses. I bought PE7 today so it should arrive in a few days. Hopefully, there will be less crashes than Pinnacle.
A well-tuned, well-maintained computer with all the necessary updates and, particularly if Vista, the proper optimization (per the FAQs at the top of this forum) are vital, Michael.
<<<...that second drive you're editing to ... is formatted NTFS and not FAT32, right?>>>
Yes, the external drive is formatted with NTFS. Thanks for your suggestions and the FAQs.
Michael & Thomas,
In a perfect world, the ideal setup would be an internal multi-disc setup like this:
Smaller (dont need great capacity here, but speed is a big bonus) fast SATA II HDD for:
OS, Virtual Memory (Page File) and program files.(See below for an option on Page File placement)
Optimally with a different/separate SATA II controller card/chip, the following:
Large fast HDD for media Assets. If you are playing/editing HDV material, this should optimally be a RAID 0 or similar (2x, or 3x physical HDDs, depending on the level of RAID), or similar array. SD material only benefits slightly from a RAID configuration.
Large fast HDD for your Projects, with Scratch Disks and Render files.
Addition: Large fast HDD for Audio and common Assets, like art work, SFX files, etc.
Possible addition: a second smaller, fastest HDD primarily for your Virtual Memory (Page File)
Now, thats the ultimate I/O system, but does tend to fill up a case and empty a wallet pretty quickly. Were talking the Cadillac of NLE workstations, especially if one added a full eSATA array of hot-swappable storage HDDs for a cool US$16,000. Hey, we can dream, cant we?.
In the real world, things are not quite so easy. On my laptop, with 3x 200GB 7200RPM SATA II HDDs, I have been editing to/from 2TB external 7200RPM HDDs over FireWire 800 (IEEE-1394b). Using eSATA, if possible, would be faster still, but most of my externals do not offer eSATA connections, so Im stuck with FW-800. Still, I have only noticed a very slight slowdown, over my workstation (configured per above +/-), and have experienced no problems with SD material. Of note, I just picked up a couple of RAID 0 2TB externals, that offer FW-400, FW-800 and eSATA, should I work with HDV material. Id need to add an eSATA controller card to the system then.
Note: I tried editing on USB externals, and encountered many problems. Some of these could have been with the particular models of externals. Some could have been with the NLE in use then. I am not saying that USBs do not work, but just that I experienced all sorts of problems with them, and none with FW-800.
Thanks for the info. I went out and picked up a 1TB Maxtor external USB, and I see you had better luck with Firewire. This is not the first time I've heard of benefits of 1394 over usb. In another context, I heard performance was better but I don't have specifics on that. So far, this drive seems very responsive so we'll see.
I have some more info on the hang which I've been experiencing during export/share of a project which uses an AVI as its one main clip. Adobe Premiere Elements 7 (PRE7) appears to be hanging because it's looping endlessly in ImporterAVI.prm. I'm wondering if this info can be passed onto Adobe developers and/or if I can submit this information elsewhere for such processing. I also have a process dump file which might be helpful, not to mention the original project files.
I used Process Monitor to help analyze this situation, and prior to PRE7 getting into the endless loop, it appears to be reading from the AVI file little by little, and WMEncodingHelper.exe is writing out little by little to the destination file, both of which I would expect. When PRE7 gets to the end of the import/export, Process Monitor appears to show all the aforementioned disk activity ceasing. I see neither process reading or writing. This would be normal if the share/export procedure had completed. But PRE7 is not complete. It is hung and is operating at 50% CPU utilization.
Far below in this post are technical details which may be helpful to an Adobe developer determine why the importer could get into this endless loop. In those details, there is a jump instruction, "jb ImporterAVI!xImportEntry+0xf32", which will always jump if a particular compare always turns out a certain way. But in my review of the counters being compared, it never will get to a point of exiting. When I modify a flag (the carry flag) to be 0, the loop exits. When I did this, my export/share of my project completed successfully. So it was done, but for some reason, PRE7 was looping and looping in its AVI importor instead of completing the export (aka "Share").
I cannot say that this certainly indicates a bug with PRE7, but it seems to me that there's enough data for Adobe to be at least investigating this particular issue. I'm not the only person who has seen this as there was at least one other message describing the same problem which the user resolved by effectively re-creating the AVI file via a no-op import/export into and out of MovieMaker. My AVI also goes through MovieMaker, import/export, without a hitch.
In a sense, I view PRE7's "share" as essentially an import, processing of imported information (i.e., effects and transitions), and an export. It's an import of all clips into the project at the right times, a processing of all effects, and finally an export to a destination. I realize this is simplistic, but the point I'm making is I have a simple project with a single AVI, and it appears that the "import" portion of PRE7's Share option is choking on the only clip used by this project. I also don't have much but simple transitions and a beginning/ending title on the project, so I'm not thinking this use of PRE7 is much more than what I'm doing with MovieMaker when importing/exporting this AVI.
I fully agree that optimum hardware can be either required or critical for certain types of video editing, but PRE7 is a consumer program and I'm not using anything extensive about it and the symptoms are that PRE7 is looping on its import of a file other programs don't have a problem with. I already tried purchasing a 1TB external, which I'm glad I did, but I really think Adobe developers should look at this issue. There may be a problem with handling certain AVI clips used in a project when those clips come from certain sources. If there is an issue, perhaps it could warrant a fix that would make PRE7 more compatible with these other clips.
Does Adobe have a procedure for people to upload (or mail) projects and files to it so that they can troubleshoot why the importer gets into this state? I also mentioned earlier that I have a full user-mode dump of the process which may be of value to a dev. Can I submit this information anywhere?
Here are textual technical details:
Plug-in which loops: C:\Program Files\Adobe\Adobe Premiere Elements 7.0\Plug-ins\en_US\ImporterAVI.prm
The following are the instructions at the "bottom" of the loop which never ends. Below, I put "***" at the jump instruction I mentioned earler. If I force the carry flag to be 0 at that point, and the jump is skipped, the export completed successfully. Additionally, notice that [esp-0x1c] is 0x2000, and that both eax and edi are 0. When I see it loop, eax stays at 0 and never reaches 0x2000. I wonder if something about the AVI is causing values used by this importer to be such that it causes this endless loop, and if that's the case, and if such values are valid/good, I'm wondering if the importer can be fixed by being able to detect such values so as to not choke (if in fact it's an importer issue).
1239dda2 50 push eax
1239dda3 ffd1 call ecx
1239dda5 8b442424 mov eax,dword ptr [esp+24h]
1239dda9 015c2428 add dword ptr [esp+28h],ebx
1239ddad 03c7 add eax,edi
1239ddaf 83c410 add esp,10h
1239ddb2 3b44241c cmp eax,dword ptr [esp+1Ch]
1239ddb6 89442414 mov dword ptr [esp+14h],eax
; *** This is where it loops around and around.
1239ddba 0f82f2feffff jb ImporterAVI!xImportEntry+0xf32 (1239dcb2)
1239ddc0 8b542420 mov edx,dword ptr [esp+20h]
1239ddc4 52 push edx
1239ddc5 e810d40000 call ImporterAVI!xImportEntry+0xe45a (123ab1da)
1239ddca 83c404 add esp,4
1239ddcd 5f pop edi
1239ddce 5e pop esi
1239ddcf 5d pop ebp
1239ddd0 33c0 xor eax,eax
1239ddd2 5b pop ebx
1239ddd3 83c428 add esp,28h
1239ddd6 c3 ret
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
3195d9b8 12387545 10590f9c 27c53e00 06b35ff6 ImporterAVI!xImportEntry+0x103a
3195d9ec 1239ea10 06b35ff6 00000000 27ad8a60 ImporterAVI+0x7545
3195da1c 1238aa31 06b3554b 00000000 7fdf0000 ImporterAVI!xImportEntry+0x1c90
00000000 00000000 00000000 00000000 00000000 ImporterAVI+0xaa31
[esp-1Ch]: 3195d9a0 00002000
eax=00000000 ebx=00000000 ecx=3195dbcc edx=00000000 esi=27ad8a60 edi=00000000
eip=1239ddba esp=3195d984 ebp=3c7ba50b iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000287
1239ddba 0f82f2feffff jb ImporterAVI!xImportEntry+0xf32 (1239dcb2) [br=1]
thanks so much for your info and suggestions. I'll have to wait just a bit for my $16K system though but I'm dreaming tool
I'll try doing everything on my eSATA external. Hopefully that will do it. Now, I just have to wait for my software to arrive! I'm leaving Pinnacle and trying PE7 for the first time. I just hope the learning curve isn't too steep. Any suggestions on an excellent tutorial or book to get me up and running quickly?
The two best methods of reaching the Adobe developers are:
1.) File a "bug report" (I *think* there's a link at the top of the main forum page, but will check and furnish one if not there)
2.) Call Adobe Technical Support (can also e-mail, but this seems to not get their attention very quickly)
Back to your original post, I just noticed something that may, or may not have any bearing. You mention that you have 11GB of free space on your internal drive, and that the Captured Video (about 1 hr's worth at 12GB) is on an external. What caught my attention was the 11GB free space. PE needs a lot of additional space to do its processing (Audio & Video) in additon to the space that you are drawing Assest from, and then writing processed Assets to. I'm not smart enough, nor do I have the equations necessary, to say how much free space, on the internal drive(s), will be required to process an hr's worth of Video & Audio, but I'd *guess* that it would be about 2 - 2.5x the Duration of the AV file. Could be as high as 5x.
I would try cleaning up your internal HDD (move documents, etc. to the external, delete any TMP files, etc., and then defragment the HDD), and trying again, with more free space. Also, check where your Scratch Disks are directed. I keep some Projects completely on externals and always point my Scratch Disks to Same As The Project. If your Project is on the internal, though your main Asset is on your external, and your Scratch Disks are pointed to Same As The Project, you might well need 5x the AV's size to do the processing.
We all tend to look at the Assets' sizes and think, "hey, I have plenty of room," when we need much more for the various files used/created in the processing of those Assets. That's why I have 5.5TB of internal drive space and even then, I have to Archive Projects to clean THAT up. AV editing, especially with PCM/WAV Audio really eats up HDD real estate in a hurry.
You may have adequate space for the storage of the Assets, but not enough (depending on where files are directed) to do the processing. Worth a shot. Please let us know if it makes an improvement.
Back in the "good old days," when a 1GB (yeah, that's correct, GB) HDD was as large as you could go, and the controller cards didn't allow for multiple physical disks, I'd have to wipe my HDD of all programs, except the OS and Photoshop, to work on large images. The only backup media then were tape drives and they were slow, clunky and not much fun to use. I could only get 1 Save of my file, before I had to copy that Save(ed) copy to tape, to continue work. Drank a lot of coffee, as it took ~ 1 hr. to Save these files to tape! Things are much better now, but still the same principles apply - you need HDD space for Assets and for processing. Don't forget that if you also have Windows' Page File set to Dynamic Management, it'll grow exponentionally, as you process, eating up space as it goes, and you don't even see this happening. Eleven GB's might just be too small to process an hours' worth of AV files.
Thanks for your suggestions and tips. I did do a full HD cleanup, and I ran a very good professional defragmentation program on it, but still had the problem. My most recent test had everything on the external 1TB HD. There was plenty of RAM of the 4GB total, CPU, pagefile, and disk space during the entire export/share process. I monitored it all the way through.
Also, keep in mind that I was able to tweak the CPU registers during the loop to cause it to exit its never-ending status, and my share/export ended successfully, and I got a good exported WMV file. So it was looping in a situation where it had plenty of CPU, and plenty of disk space. It had good consistent advancement (percentage complete bar/pacifier) throughout the process, without any stress, with plenty of disk, ram, etc. It was using 50% CPU itself, not 100%. I don't understand why the whole export would be smooth, with plenty of resources, only to get into an endless loop due to a resource issue when the very symptoms don't seem resource related. I mean PRE7's code in ImporterAVI has values set up such that it's not exiting a loop. Who did those values get set that way? If I had to guess (and this may be dead wrong), PRE7 is reading something in the AVI's headers, and/or something about the AVI's size is affecting calculations, which is messing up ImporterAVI's logic which should normally exit the loop in question. It's just a guess but that's what I think.
But putting all of the above aside, even if resources were stressed, which they weren't, a program like PRE7 should be deterministic in its behavior. I should be able to share a file on a completely inappropriate machine, have it chug through-however long it takes, and end up with an exported file. It may be completely unacceptable (i.e., taking 24 hours to complete), but the software itself should be rock-solid in its processing, where it goes from step to step, in all of its threads, in a manner which gets it to the end of the line safely. If there are out-of-resource (i.e., disk or ram) errors along the way, fine, but PRE7 shouldn't loop endlessly in such cases. Rather, it should fail/stop the export/share and display a message. It actually does this in some cases, so I know this concept is not news.
But really, there were no errors displayed here, and it's looping endlessly after a good export is at completion, and there were no signs of that the OS got anywhere near the end of the line for disk, ram or anything. So I really go back to my gut which tells me either ImporterAVI has problems, or Nero is exporting a bad AVI from its capturing efforts. But I negate the latter by the fact that other applications can import/export the very same API. If the AVI is bad, those other apps are more rock solid in dealing with, say, bad RIFF header values (RIFF being a structure used internally in an AVI file).
Since I have this 1TB, I may just free up even more main HD space just to satisfy everyone. It will still fail. It's a combination of the AVI, what the project is doing, and ImporterAVI's processing of the AVI. That's my guess.
Thanks again for your input,
I think that you are focusing on only part of the resource issue: the CPU and the RAM. I/O is also a very large part of the equation and cannot be ignored.
Now, I think that PE *should* either finish, or throw an error (would be great if that error told us something very useful, but alas... ). However, if, say the OS's Page File has expanded and is now occupying all of the remaining HDD real estate, PE just keeps plugging away, and doesn't know what the problem is. It hopes that HDD space frees up, but doesn't know that it will not. The same can also happen if the HDD fills up with the various necessary files created by PE. It doesn't know what is happening, just that it cannot find any space to write to. It just keeps trying. That is why it is recommended to have about 35-50 GB of free, defragmented HDD space, or to split the processes over several additional, physical HDDs. I keep most of 2TBs free over three internal HDDs, and set up my various "extra" files to maximize performance.
Try cleaning more room on your internal HDD. Maybe set your Page File from dynamic "Windows' management" to a static Page File, about 1.5x your RAM. Defragment the HDD, and give it another go.
I did another test with 20GB free on the main HD, and 1TB free on the external. The project and the one and only AVI clip for the project are on the external, and the export/share is to the external.
During the run, the CPU is near its max as expected (between 90% to 100%... all for Adobe which is the only main thing running). When it reaches the end, it enters that endless loop which eats about 50% CPU. During the whole run, the CPU page file was only 10% used, the commmited bytes were at 33%. The main HD did not budge one amount. It stayed at a flat 20GB. The hard drive light for the main HD was pretty much OFF the entire time. All I/O was to/from the external HD. Keep in mind this problem was first experienced just operating off the main HD, so switching to the external 1TB HD makes no difference. Below you can see the performance set data. The graph for that data had more data points and showed flat lines for everything. This makes sense. This project doesn't do much. It uses a single large AVI clip which is already on a disk, the external 1TB disk. All PRE7 needs to do is read that file little by little. The resulting WMV is about 190MB which is quite small. So PRE7 doesn't have to write that much during processing. The only thing that remains is whatever disk it might need to process the file. I have no major effects, only transitions (fades from one scene to another). So this makes sense. The project doesn't really need all that much during this share/export operation. It seems its most intense task is processing the AVI input data (i.e., ImporterAVI plug-in) and outputting the data to WMV. Once again, when it hangs at the end, and I break into the looping process and tweak that flag, it exits the loop and completes the export successfully. The counters in that loop are not incrementing a certain value in a manner that would allow it to exit. In fact, one value is 0 when this happens, and it's added to another value which, of course, does not increment, and so the loop never exits. The magic answer likely lies behind the reason that is occuring.
Here is the data gathered during the export. I show the beginning, then I edit the data since it was too much for this post, and leave a little of the remaining. When CPU drops to 50%, that's when PRE7 enters the endless loop.
Sec % CPU % Pagefile % Commit
0 95 10 33
1 91 10 33
2 96 10 33
3 95 10 33
5 92 10 33
6 94 10 33
7 95 10 33
8 98 10 33
9 98 10 33
10 94 10 33
12 96 10 33
13 96 10 33
14 99 10 33
15 93 10 33
16 98 10 33
6801 95 10 32
6802 98 10 32
6803 95 10 32
6804 93 10 32
6806 94 10 32
6807 97 10 32
6808 97 10 32
6809 97 10 32
6810 95 10 32
6811 97 10 32
6812 96 10 32
6814 99 10 32
6815 98 10 32
6816 98 10 32
6817 61 10 32
6818 52 10 32
6819 54 10 32
6821 52 10 32
6822 55 10 32
6823 54 10 32
6824 52 10 32
6825 56 10 32
6826 54 10 32
6828 84 10 32
6829 58 10 32
6830 52 10 32
6831 55 10 32
6832 56 10 32
6833 50 10 32
6834 56 10 32
I recently began having the same problem. My system does fine the entire process, no hangs, no lags - expect when it's exporting. Once it hits the final 5 seconds of exporting it hangs and never finishes. It doesn't matter if it's a large file or a small one. Was there ever any resolution to this problem? Seems like a bug in the export process....
I get exactly the same behaviour. I have Core2Duo 1.83GHz on Vista.
The burn export progresses at 100% CPU utilization at a good clip unitl 93% completion. Then CPU goes to 50% utilization and HD activity dies out. Every 10mins or so, there's little HDD activity for a few secs, but otherwise just Premiere Elements consuming 50%.
After a while (i.e. 45 mins or so), the Premiere interface stops responding and I get the Windows Vista "busy" circle. Premiere Elements 7 has to be killed at that point.
So far I've refreshed laptop BIOS, all drivers, I have 100Gb of free space.
The project has 4:3 regular definition video taken with a digital camera .mp4
No response from Adobe so far.