[John-michael Seng-wheeler]

[Tim Kolb] “I think the main issue is that while the rest of the universe was working to advance their software, QuickTime was left to go to seed…
“

That is defiantly true, but in this case there was a very noticeable drop in quality.

I jumped from CS3 to CS5 and at the same time switched computers. (both were windows.)

The exact settings I’d used before (usually 5Mb/s) were suddenly producing complete crap.

[John-michael Seng-wheeler]

What happens if you conform the clip to the frame rate that VLC reported?

To do this right-click on the clip and select Modify > Interoperate Footage… and under “use this frame rate” put in 23.365755.

[John-michael Seng-wheeler]

I stopped using Quicktime H.264 three years ago for this vary reason.

Way back in CS3 it worked… I don’t know when or why things went south.

If they MUST have a Quicktime and it MUST be H.264 then I think your only option is to push up the data rate till the image doen’t look bad.

Try 25Mb/s and see if that works.

[John-michael Seng-wheeler]

[Tim Kolb] “RED Cinema’s decoder is a single thread wide too”

Which is why Premiere runs multiple instances of the decoder (On windows it’s called ImporterREDServer.exe) at once, one for each virtual core. I asume it feeds frames sequentially to each.

I had two shots each with a bad frame in from a Red One once. I first found the problem ’cause AME would crash rendering the dailies to MPEG-2 for the director to have on DVD. When I went through the footage in Premiere, if I tied to play past the bad frame everything would lock up for a while and then one of the copies of ImporterREDServer.exe would crash and I’d keep on editing. It would still work until I got down to about six copies left, at which point everything got weird and premiere would crash, leaving the rest of the ImporterREDServer.exe programs running. If I then restarted Premiere I’d have one per core again plus all the orphaned ones from before… This Craziness was all with Premiere CS5.

[John-michael Seng-wheeler]

Yeah, that’s what’s causing the problem. By selecting “stereo” as the record option you’re telling the Zoom that the XLR is a stereo source (which it isn’t, it’s a balanced sorce.) If, on the other hand, you select “Mono” you’ll probably get audio that defaults to playing out of the left speaker only, which you’ll have to fix the same way you have to fix the audio you have now, ether the fill left effect or modify > audio channels.

I’ll take a look through the manual and see if there’s a way to record a single mono channel.

[John-michael Seng-wheeler]

If you’re using an XLR to XLR, then the problem is definitely something wrong with the zoom. Which model do you have? I can read through the manual and look for a setting that might cause this.

[John-michael Seng-wheeler]

I’m confused. Can you explain in more detail?

Also, which version of Premiere and PC or MAC?

[John-michael Seng-wheeler]

So I did a little digging, and it turns out my original suggestion does in fact work.

Dynamic link your project over to AME, start it rendering, Close and then re-open Premiere.

Done! AME will no longer pause. No guarantees that playback with H.264 while AME’s running will be smooth though. I don’t edit H.264 so I can’t test. ProRes plays fine though, even on my 5 year old MBP.

I’m still interested in how long it takes to start the encode. Does it vary by how many clips you have in your project?

[John-michael Seng-wheeler]

[Errol Lazare] “To clarify, AME will only stop when I start editing,”

You mean when you hit play in Premiere correct? AME will stop encoding when you hit play in Premiere and restart the moment you stop playback. I hardly see this as making it imposible to edit… At the most I’m only playing back the timeline 50% of the time. Yes, AME will finish slower then if I waited and let it do it’s thing, but I’m also getting work done so in the end I come out ahead.

You’re right though, There should be an option to disable this behavior. It would depend on the footage you were cutting and the computer but it is possible to encode and playback at the same time. Go try it. hit play in Premiere and then un-pause AME. Unfortunately the next time you hit play in Premiere it will pause again. I understand why this is the default behavior, but you’re right, it should be an option. This was also a big complaint with FCPX when it came out… that the “background rendering” wasn’t really background rendering because it would stop during playback.

Yes, FCP7 and Compressor will run at the same time, but on the other hand, nether program is using the full power of the computer. Compared to AME, Compresser is very slow. AME will probably finish faster even if it’s pausing all the time. I think it’s time for a race!

All that being said, it still shouldn’t take 15 minutes for the encode to start.

JM

[John-michael Seng-wheeler]

Well, hold on. Yes, AME pauses when you’re Scrubbing or Playing back in premiere, but from reading Errol’s description I took it to mean he couldn’t do anything in Premiere without AME pausing.

And anyway, the time to link over to dynamic link over to AME and start encoding shouldn’t be taking 15 minutes…..unless it’s a really really complex project.