Before becoming a Nero MVP my main interest in the software's video encoding capabilities was limited to AVC encoding.   While working with both Nero and TMPGEnc Xpress more and more in preparation for a comparison of encoders designed to work with standalone players (DivX and AVCHD for TMPGEnc or Nero Digital, Nero Digital AVC, and AVCHD for Nero) I decided to start my comparison with SD DivX and Nero Digital encodes. I had read good things in Doom9's last MPEG-4 ASP codec comparison about the first pass speed the Ateme encoder achieves on the first pass of a 2 pass encode. Still it's one thing to read about it, and another to watch the first pass run at nearly 4x realtime on an old P4 2.4GHz computer!

So now that I've got the praise out of the way, I have some criticism to go along with it.   When I'm encoding I usually have a lot of it to do at once. When it's for work, like what I'm working on now, it really helps me plan my day if I know how long a given encode is going to take. Unfortunately the turbocharged first pass has left the encoder interface clueless about how long the second pass will take. Once it switches gears to run at slightly less than realtime for the second pass (remember - 2.4GHz P4) it never seems to completely adjust for the reduced speed, and as a result time estimates are completely inaccurate until nearly the end of the 2nd pass.

Obviously there's no way for the first pass to predict the speed of the second since they're apparently significantly different. However, it seems like it would be fairly trivial to add some logic that tells the interface to discard the first pass information and recalculate from scratch for the second pass. I'm not going to send a request to support over the issue at this time because it's really just an inconvenience. I wouldn't mind seeing it in a future release though.  

Rich Fiscus