DisabledTrucker wrote:Okay, I didn't read but the first 7 pages and the last 3 pages of this thread but I thought I would add my 2 cents worth anyways.
You may want to read more... (Particularly my posts on page 11 and 12).
I have a 24" Custom C2D iMac also. If I get done with my 2-pass encode of Smokin Aces before falling asleep, I'll run Tokyo Drift. Or, may have to wait till tomorrow.
My 24" has a 2.33GHz, 2GB, 250G HDD, nVidia 7600GT. I did read page 12, my last three pages are 12,13,14. The encode I was doing earlier is only ~85% complete at this point, I will try it tomorrow myself on the iMac after I get back from an appt around lunch time, as well as on the PC Machine tomorrow while I'm gone to the appt. I still think the problem lies in the way iTunes/QuickTime handles the codec and not necessarily the encoder itself. I derive that from the problems that I've had with doing the same encodes on Nero Recode using the same settings, (well as close to the same as possible being two different apps,) but the H264 codec is basically the same and it was having a problem with playback using 5.1 audio in the streams it created as well, but only with QuickTime/iTunes. It's actually in QuickTime though if it is since QuickTimes the actual player that contains the codecs, iTunes just calls them. I should also mention that my versions of QuickTime are all Pro versions with the MP2 add on, not sure if the rest of you are using the same version or not in that reguards. So I don't know if that is the problem as well or not. The version of QuickTime I was using, (there's an update that come out today that it just installed and is currently awaiting a reboot to finish it,) is version 7.1.something or other.
I also know I read one or more of the posts that said something about encoding levels slowing while increasing processor usage, what I also read was that the lower encode levels with decreased processor usage was during subsequent encodes, which tells me that HB didn't clean itself up and that it cached it's encode files the first time and used them on subsequent times. Which would also explain as to why the one person showed they had the same error in his log occured more on the subsequent conversions than it did on the initial one. One may also want to check to see that the code isn't conflicting somehow or trying to access the QuickTime codecs while doing the encode. Not to say there is anything wrong with the code, but there could possibly be a leak or conflict there somewhere causing this problem, I'm not sure. It may not show up on the older titles but be more prominent on the newer ones where the encryption may be causing it to do that. It would be interesting to find this out though, could find out they are using a rootkit in their DRM scheme to cause the software to error like that in ripper software.
The reason I provided my information is that the vast majority of posts that I read were concerning the iMac C2D's along with a G5 or so, I didn't read anything about the G4's with the exception of a single MacPro Dual Proc version of it. I'm only using a single processor in my Powerbook, the others were all reported to be dual proc's, that I had read. This was just to confirm that it also occurs in the single G4's as well. Albeit I've not as of yet used the MTR 3.14b1, I see the same problems as reported here as well. I have though confirmed that the sound is playing in the ripped DVD on the HDD though even though MTR complained about 0 size files after the rip. What I didn't mention previously was that using HB .71 only to convert the DVD, I got sound but it was choppy as hell and the video skipped tremendously. It had a great picture though when it wasn't skipping, the new version has an excellent picture but no sound at all. Much like the problems that were occuring in the Nero Recodes I did with 5.1 audio. I understand they have overcome it, maybe there is something somewhere saying what they did to fix this, but I've not delved deep enough into it as of yet to see what that may be at this point.
As I mentioned they had the problem the last I used it prior to New Years before they fixed the problem, or at least claimed to have fixed it. Maybe looking at the code for it, one can determine what they did in that to fix the problem and use it in this app to fix it as well. For all I know they may have rewrote their library file(s) to fix the problem, it would be well worth the effort of the developers to look into this though. Who knows they may have done something different in the x264/h264 compilation to address and fix this issue. I just don't know at this point, but it would definately be worth a look by the developers to see what they did differently in this to fix their problem and try to adapt it for their program as well. I believe the linux version is still available there in source form they should be able to obtain it and look at it. I think I still have the latest linux version, but I don't know if it contains the source or not, I'll have to bring up the other system to look and see what I have still if they need it, just let me know.