[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 257: mysqli_fetch_assoc(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 319: mysqli_free_result(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 257: mysqli_fetch_assoc(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 319: mysqli_free_result(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 257: mysqli_fetch_assoc(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 319: mysqli_free_result(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 257: mysqli_fetch_assoc(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 319: mysqli_free_result(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 257: mysqli_fetch_assoc(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 319: mysqli_free_result(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 257: mysqli_fetch_assoc(): Couldn't fetch mysqli_result
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/db/driver/mysqli.php on line 319: mysqli_free_result(): Couldn't fetch mysqli_result
HandBrake • NO AUDIO?... Read Here! (Summary in First Post) **UPDATED** - Page 8
Page 8 of 17

Posted: Sun Apr 15, 2007 2:39 pm
by hawkman
davidhj wrote:I don't think Version 0.8.0b1 was a beta
What do you think the "b" stands for? On the download page, it clearly states, "MediaFork 0.8.0 beta 1". How much more clear could it be? It's definitely a beta, and that means it definitely has bugs. It means, use at your own risk.

Posted: Sun Apr 15, 2007 2:58 pm
by s55
davidhj - The bug was not known about until after release. We can't just magicallly know every single bug before release.

The next beta will contain bugs. We will mention the ones we know about and I suspect there may well be more. Thats why its called a BETA and has ALWAYS been advertised as such.

The only persons fault for time wasted is your own. If the newer version, which has benifited many, doesn't work for you, Use the older version or use something else. We did not force you to waste time.

Posted: Sun Apr 15, 2007 3:19 pm
by davidhj
[/quote]The only persons fault for time wasted is your own. If the newer version, which has benifited many, doesn't work for you, Use the older version or use something else. We did not force you to waste time.[/quote]

Yes you are absolutely correct-- I am obviously a relative newbie-- the software is terrific -- thank you for your efforts.. I was just.... frustrated
Regards,
David

Posted: Sun Apr 15, 2007 3:28 pm
by dynaflash
davidhj wrote:--- weird for high end developers it seems to me and caused my to waste an tremendous amount of time fooling with the software- I know it is 'free' but still seems unnecessary to put new users thru this when a bug is obviously known based on extensive threads concerning it.
We will be happy to refund your purchase price.

Posted: Sun Apr 15, 2007 3:36 pm
by petvas
dynaflash wrote:
davidhj wrote:--- weird for high end developers it seems to me and caused my to waste an tremendous amount of time fooling with the software- I know it is 'free' but still seems unnecessary to put new users thru this when a bug is obviously known based on extensive threads concerning it.
We will be happy to refund your purchase price.
ahahaahha
cool!

Seriously now, I dont think that there is anybody here who doesnt appreciate what you are doing. For me you have made the Apple TV 100 times better than it would be without Handbrake. Thank you for your great job!!!

Having said that, I would certainly be willing to pay for Handbrake if that would mean that the audio issue would just vanish!!!

Posted: Sun Apr 15, 2007 3:41 pm
by davidhj
[quote="petvas"][quote="dynaflash"][quote="davidhj"]--- weird for high end developers it seems to me and caused my to waste an tremendous amount of time fooling with the software- I know it is 'free' but still seems unnecessary to put new users thru this when a bug is obviously known based on extensive threads concerning it.[/quote]

We will be happy to refund your purchase price.[/quote]

ahahaahha
cool!

Seriously now, I dont think that there is anybody here who doesnt appreciate what you are doing. For me you have made the Apple TV 100 times better than it would be without Handbrake. Thank you for your great job!!!

Having said that, I would certainly be willing to pay for Handbrake if that would mean that the audio issue would just vanish!!![/quote]


YES YES I apologize-- I am a dumb ass newbie-- I too greatly appreciate all the developers efforts-DAVID (and I would gladly pay also)

Posted: Sun Apr 15, 2007 5:04 pm
by Cavalicious
pmoc wrote:
To me, this proves that the problem comes from x264 and its options and not from MTR although the way the DVD is ripped could have an impact on the x264 bug I guess.

Hope this helps.

Cheers, Philippe.
Have I not already provided solutions based on Ripping method...even with The Matrix. (hint...Full Disc Extraction)?

Posted: Sun Apr 15, 2007 5:06 pm
by Cavalicious
pmoc wrote:I agree with you, I've never had any audio pb with the previous version. This proves, if need be, that current audio problems are related to this beta version of handbrake. But the all purpose of a beta release is to track down the bugs and correct them before a version release, isn't it?

Cheers.
You really need to read the thread from the begining, disproved that theroy already.

Posted: Sun Apr 15, 2007 5:08 pm
by jbrjake
davidhj wrote:Version 0.7.1 RESOLVED ALL RANDOM AUDIO failures (my experience was about 15% of DVDs had audio failures with handbrake's latest versions.
I'm glad it's working for you, but let's not idealize the past, here.

Check the old forum's archive. Missing audio did not suddenly appear with 0.8.0. 0.7.1 had problems too, as did earlier versions. It is a constant struggle to correct for badly mastered DVDs with audio timecode breaks without correcting so far the entire encode loses sync and fails.

http://handbrake.m0k.org/forum_old/viewtopic.php?t=213
http://handbrake.m0k.org/forum_old/viewtopic.php?t=120
http://handbrake.m0k.org/forum_old/viewtopic.php?t=8
http://handbrake.m0k.org/forum_old/viewtopic.php?t=36
http://handbrake.m0k.org/forum_old/viewtopic.php?t=144
http://handbrake.m0k.org/forum_old/viewtopic.php?t=551
http://handbrake.m0k.org/forum_old/viewtopic.php?t=503
http://handbrake.m0k.org/forum_old/viewtopic.php?t=491
http://handbrake.m0k.org/forum_old/viewtopic.php?t=638
http://handbrake.m0k.org/forum_old/viewtopic.php?t=155
http://handbrake.m0k.org/forum_old/viewtopic.php?t=815

I could go on. Those are only choice threads from the oldest parts of the old forum. I could easily have made that list three times as long if I'd continued browsing through the 13 pages of results searching for 'audio sound missing' got me. There were many more posts about dropped audio in the even older forum, that was lost in a crash. I also did not include any other audio issues, like garbled audio, or short hiccups, or de-sync, or bad samplerate, which are probably connected somehow.

Posted: Sun Apr 15, 2007 5:49 pm
by pmoc
Well, this is what I did

1/ I ripped Matrix with MTR and DVD Fab using Main title extraction

2/ I ran the following command on DVD Fab extraction
./HandBrakeCLI -i /users/philippe/desktop/MATRIXW/VIDEO_TS -o /users/philippe/desktop/matrix.mp4 -b 2000 -2 -e x264 -m -R 48 -p -v -s 1 -6 6ch -x subme=4:bframes=6 -c 1
Believe me or not, the sound problem occur before the end of the first chapter. Thus, DVD Fab is not the solution for me.

3/ Then I ran the same command on the MTR rip: it works though there are a couple of "[19:39:57] sync: adding 50 ms of silence for track 80bd"
in the log file.

4/ Matrix is encoded fine with HB 0.7 (not to say that there is no pb with that version)

So what can I conclude? Probably that the result is not predictable whatever the DVD Rip app I use.

Bad news for me because this occurs for maybe 80% of my DVD.

Cheers. Philippe.

Posted: Sun Apr 15, 2007 8:56 pm
by MuckSavage
Just my two cents.

Ripped Sling Blade with MTR 2.6.6.

Encoded using HB .81b

x264, 160kbps AAC, Constant quality 70%.

Audio cut out at around 20%, tried twice.

Changed settings to make the audio 128kpbs.

Audio cut out at around 30%.

Re-encoded using HB .71. no sound loss, same settings as before.

Posted: Mon Apr 16, 2007 5:23 pm
by terabyteme
Update:

I downloaded handbrake 0.7.1 and I was able to successfully encode 2 movies so far that were having audio dropouts on 0.8.0b1. The movies were "Rent" & "The explorers" - I used the same settings as previously posted. I am now trying my last "trouble" movie (howl's moving castle).

Posted: Mon Apr 16, 2007 9:37 pm
by terabyteme
0.7.1 strikes again - "howl's moving castle" successfully encoded. So all 3 movies I had audio problems with in 0.8.0b1 worked fine in the older version. Interesting....
terabyteme wrote:Update:

I downloaded handbrake 0.7.1 and I was able to successfully encode 2 movies so far that were having audio dropouts on 0.8.0b1. The movies were "Rent" & "The explorers" - I used the same settings as previously posted. I am now trying my last "trouble" movie (howl's moving castle).

Posted: Tue Apr 17, 2007 2:29 pm
by dynaflash
terabyteme wrote:0.7.1 strikes again - "howl's moving castle" successfully encoded. So all 3 movies I had audio problems with in 0.8.0b1 worked fine in the older version. Interesting....
terabyteme wrote:Update:

I downloaded handbrake 0.7.1 and I was able to successfully encode 2 movies so far that were having audio dropouts on 0.8.0b1. The movies were "Rent" & "The explorers" - I used the same settings as previously posted. I am now trying my last "trouble" movie (howl's moving castle).
Well, it may be. But his is not really any kind of news. We are very aware that there are dvd's that 0.7.1 doesnt drop audio where 0.8.0b1 does. THis is all over the forums. We are aware of it, but it is no easy fix, to say the least, for reasons that are also specified all over the forums.

I will also tell you that the cli version of 0.8.0b1 also has less trouble.

I can also tell you that the gui version of 0.8.0b1 also has very few issues if you rip full disk with mtr first vs. main feature rip.

Again, we are aware of it and looking to fix it. But it will not likely come right away.

Posted: Sat Apr 21, 2007 5:14 pm
by chattermann
Been anxiously following this thread in hopes of a solution like everyone else present here. I am a developer but have no experience with Mac OS so I have been reluctant to get too involved, but with the release of 0.8.5b1 that is apparently still afflicted with audio drops I am compelled to try my hand at debugging. Let me apologize in advance for the length of this post.

First off, there has been a lot of back and forth speculation about whether the problems are with HandBrake or MTR (or any other ripping software). In my opinion it's apparent that it's a combination of both. Neither is to blame as evidenced by success in replacing either the encoder or the ripper in many cases, but because this is a HandBrake forum I would like to focus on HandBrake. This post would probably be more appropriate in the Bugs forum, but since this is the most relevant thread I'm posting here.

It's obvious that there are incompatibilities between the output of some rippers and versions of HB, and identifying those and enhancing HB to be more forgiving and robust will get us far. To minimize variables I have been experimenting with a specific point in a particular DVD rip where I have experienced audio drop with MediaFork and recent HB builds in an effort to identify what is going on at that point. Switching to the HB CLI solved the "extended" audio drop, but there was still a drop of about 1/2 second of audio at the same point where it used to drop out for the remainder of the movie with the GUI. From the verbose output of CLI it's apparent that the drop is related to "PTS discontinuity" and subsequent adding of silence buffers, but what really surprised me was that I was getting varying results on subsequent runs of the same CLI command on the same rip. Following are excerpts (complete logs are available) of the output during encoding for two such runs, the first resulting in no perceivable audio drop, and the second resulting in obvious drop of about 1/2 second.


$ ./HandBrakeCLI -i "/Users/Shared/DVDs/Toy Story 2" -o "/Users/chad/Desktop/Toy Story 2.mp4" -e x264 -q 0.7 -B 192 -c "2" -v
...
[08:05:17] sync: expecting 4907 video frames
[08:05:17] sync: first pts is 3442600
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
Encoding: task 1 of 1, 2.53 %[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] PTS discontinuity (3923077, 22733)
Encoding: task 1 of 1, 5.93 % (41.90 fps, avg 42.53 fps, ETA 00h01m49s)^CSignal 2 received, terminating - do it again in case it gets stuck
Encoding: task 1 of 1, 6.01 % (38.12 fps, avg 40.81 fps, ETA 00h01m53s)[08:05:24] reader: done


$ ./HandBrakeCLI -i "/Users/Shared/DVDs/Toy Story 2" -o "/Users/chad/Desktop/Toy Story 2.mp4" -e x264 -q 0.7 -B 192 -c "2" -v
...
[08:06:56] sync: expecting 4907 video frames
[08:06:56] sync: first pts is 3442600
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
Encoding: task 1 of 1, 2.53 %[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] PTS discontinuity (3923077, 22733)
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
Encoding: task 1 of 1, 5.71 % (41.13 fps, avg 41.90 fps, ETA 00h01m50s)^X^CSignal 2 received, terminating - do it again in case it gets stuck
Encoding: task 1 of 1, 5.83 % (41.13 fps, avg 41.90 fps, ETA 00h01m50s)[08:07:03] mux: file size, 617022 bytes
[08:07:03] mux: track 0, 400472 bytes, 279.32 kbps
[08:07:03] mux: track 1, 210725 bytes, 146.98 kbps
[08:07:03] mux: overhead, 7.61 bytes per frame
[08:07:03] thread 25273856 exited ("muxer")
[08:07:03] reader: done


Note the identical command lines. One would expect that because the input is static, the output would be identical in both cases. I am optimistic that this may direct us to the point in the code where the decision is made that results in audio drop vs. no audio drop. I have not attempted to delve into the code just yet. Would appreciate some comment from HB developers first to see if there some other reasonable explanation for this.

As a side, the hard work of all the HB developers and 3rd party contributors is much appreciated. This is a tremendous tool. Keep up the good work, and I hope to be able to contribute myself in the near future.

Posted: Mon Apr 23, 2007 12:48 am
by cknyckny
First of all - let me say how thankful I am to the developers of Handbrake/MF - it is a truly great program.

I have had audio drop outs occuring more and more recently. I have always been ripping main movie only first using MTR 14b and then encoding using h.264 for my apple tv. Many movies have audio dropouts - the last 3 I tried were Walk the line, Borat and Idlewild.

Here's my settings - using the appletv preset settings (more or less - playing around with bitrate - anywhere from 1500-2500.)

First computer:
Dual 1.8G5 1GB Ram NEC Nd-3550A DVD writer
Second:
1.83 Core Duo Macbook 512mb Ram and stock [Censored] DVD Rom

Both give varying problems although I recall Little Miss Sunshine dropping audio on the macbook while working on the G4.

Just hoping you guys are able to figure this all out. Trying to get as many of my movies into iTunes as I can.

As an aside - after reading through the pages of this thread I just ripped Borat full disk using MTR 14d and am trying an encode in the newest beta of Handbrake. Based on my 7-8FPS on the G5 I believe I will be dropping audio, just like main feature rip.

Posted: Mon Apr 23, 2007 3:46 am
by cknyckny
ok so as expected the mp4 spit out by the G5 had audio dropout. However - using the same exact variables except that I was using a macbook, I got a fine encode - audio and all.

Here was the process again: Rip full disk mode using MTR 14d to hard drive. Using newest released Handbrake beta with apple tv preset (one pass). The only thing that changed was the machine. G5 = not working. Macbook = working. That said, my Macbook was unable to make a working encode of Idlewild so I'm going to try that one on my G5 lol.

Posted: Mon Apr 23, 2007 5:29 am
by deckeda
chattermann wrote: ... but what really surprised me was that I was getting varying results on subsequent runs of the same CLI command on the same rip.
I'm not surprised. Reading this forum, you'll see that what works for some does not work for all. You might even have different results between your PowerMac and your MacBook the next time you try.

The only consistent thing so far is inconsistency (at least between users. Some never have issues with a given method.)

You mentioned the CLI adapting more gracefully than the GUI when encountering an audio problem. That's a consistent theme I think however.

Another data point, perhaps: I've ripped the following with MTR 3.0 - r14d, all as Main Feature on my Dual 2.0 G5 PowerMac and successfully converted with Version 0.8.0b2 (2007040900) or Version 0.8.5b1 (2007042000) --- those were compiles from SVN. I have yet to try the normal release, Version 0.8.5b1 (2007042001)

BORAT, Casino Royale, Flipper ('63) , Good Night and Good Luck, Happy Feet

Posted: Mon Apr 23, 2007 4:15 pm
by mrmugno
My long encode time using new beta referred me to here but:

10 hour plus encoding Pulp Fiction after main title extraction with MTR 2.6.6 where final output is simply unplayable in QTpro, VLC, WMP, etc. Don't have any information on why it won't play but at a glance, the file size seems "normal".

I assumed I would have the audio drop problem given this is a title extraction VOB from MTR, but instead the file is useless. What gives.

Soooo, I know this barely belongs here, and there is not much to be said by the experts since "unplayable" means next to nothing, but I am posting in hopes that someone else can share similar experiences but with more info.

Specs:

MBP 2 GHz
MP4 H.264 main / same as source FPS
2 Pass 1350 KBPS
anamorphic checked / no deinterlace
chapter markers and m4v output checked (perhaps this is the issue??????)

Posted: Mon Apr 23, 2007 10:00 pm
by cknyckny
Ok, so, as per the above test, I ran the movie 'Idlewild' through my G5 machine. Again, same disc, same MTR rip process and same beta version of HB used with the same apple tv default settings. This time, the G5 produced a fine version while the Macbook produced one with no audio.

My totally inconclusive tests so far running the same disk through the same process on the same software just on two different machines:
Idlewild - G5 did ok while Macbook no audio
Borat - Macbook did ok while G5 no audio

Next test is going to be 'Walk the Line' on my Macbook which the G5 wouldn't give me audio. If the macbook handles it fine then I'm officially ready to declare that opposites attract and this is the problem ;)

*edit* I wanted to re-rip idlewild at a lower bitrate since the file turned out pretty big. I changed nothing in how I encoded it last time except changed the bitrate from 2500 to 1500. Based on FPS it appears I am getting a dropped audio encode. What's possibly going on here!

**edit** turns out it just encoded really slow - audio was there the second time on idlewild.

More evidence for the DVD drive being a factor

Posted: Thu Apr 26, 2007 7:13 am
by Xcapee
I have just finished ripping The Country Bears (region 4) for the second time. The first had the audio cut out part way through, the second had audio all the way through.

They were both ripped on the same MacBook Pro, using exactly the same settings in HB 0.8.0.b1

The difference?
The one with the audio loss was straight from the DVD in the drive.
The one with good audio was ripped to HD first using 0SEx on my old DP G4. The disk was mounted over AFP to my MBP and then encoded with HB.

So either 0SEx cleans up something funky on the DVD, or the previously mentioned differences between drives and error rates are a factor.

Hope that adds some more helpful data points.

Non-encrypted

Posted: Thu Apr 26, 2007 12:38 pm
by swc_uk
Hi Guys,

Just one little bit of info for you on this. I recorded a film off my V+ PVR using a Panasonic DVD-R recorder (my home DVD player), and then tried to rip using HB (can't remember version, but downloaded three days ago, after reading about the new version on the Mac news sites).

Now, the DVD I tried to rip and encode lost audio after about two minutes or so. The DVD plays fine on my MacBook Pro and on the DVD player it was recorded from. The DVD is not encrypted and I ripped using the iPod presets (I don't think I changed anything, apart from the dimensions, to force a 16:9 ratio instead of 4:3). MTR was not involved, nor was any other software.

So, I tried to rip twice with the same results - missing audio. I don't know how long it took as I set it off and went to bed. However... I have the DVD-R and if anyone wants it for testing, I can send it.

I will try some other settings over the next couple of days, but it's interesting that this DVD was produced on a home DVD recorder and is not region encoded or encrypted. I will try another home DVD and see if that works.

Like I say, if anyone wants the physical DVD for diagnostics and testing, I can send it, if it helps.

time code breaks

Posted: Thu Apr 26, 2007 9:20 pm
by Xcapee
swc_uk, my bet is that your PVR recording has time code breaks and data errors in the stream. Try using MPEG streamclip to clean it up first, fixing time code breaks, and data errors. My guess is that it will then work fine.

Posted: Sun Apr 29, 2007 11:12 pm
by eddyg
deckeda wrote: The only consistent thing so far is inconsistency (at least between users. Some never have issues with a given method.)
This sounds like some sort of race condition in the pipeline somewhere. The fact that it varies from time to time and computer to computer.

Maybe something bad happens when the pipeline empties for some reason, or fills?

The fact that it is less likely to happen with the CLI vs the GUI gives credence to this, as it is most likely changing the timing slightly by virtue of the display events.

I wonder the the audio issues coincide with a chapter break? There are some gymnastics associated with the chapter breaks that maybe cause issues.

Cheers, Ed.

Posted: Tue May 01, 2007 9:33 pm
by DisabledTrucker
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. First off here are my hardware specs:

Code: Select all

PB G4 15" 1.25GHz 512MB Pioneer DVD-RW DVR-K05 internal Built In Texas Instruments TAS3004 44.1KHz 2chI/O sound
and my movie I am working with is The Fast and The Furious - Tokyo Drift. My current settings in HB .85.b1 are:

Code: Select all

MP4,AVC/H.264/AAC,SAS,H264M,AvgBR-2200,2pass,AR-Off,DI-On,Ana-On,5.1,44.1,160
Now I have tried this with various changes, I have used both just the HB to do the initial rip as well as MTR 2.6.6 thus far, (I just downloaded the more recent version 3.b14 and have yet to attempt using it,) as well as various settings in Video as well as Audio, including reducing the audio to just using the 2.0 (AC3) (Dolby Surround) {Current settings} and all the 5.1 encodes have the same problem. I have an iMac 24" C2D Custom I can also try this on, but haven't yet done so. I also have a Winblows system I can use, but not interested in if it can do it on that as I use DVDIdle to Nero Recode on it, (I have yet to try this movie in it as well thus far, but had no problems with the previous Fast and Furious movies on it, except that Nero's 5.1 isn't compatible with Quicktime at all.)

I would have to mention too that I've had problems in the past with Nero ripped movies having a problem with 5.1 audio when trying to play back in iTunes/QuickTime, and I feel there is a problem with the codec they are using moreso than the problem lying in the H.264/x264 codec, as this problem only occurs in playback in the iTunes/QuickTime apps and none of the other converters I've used have this problem when using other players, only when using iTunes/QuickTime for playback. I've seen rather slow speeds when encoding as well, but I attribute this to doing it on an ancient 1.5GHz G4 with barely enough memory. My average FPS is 4.52 with the encode taking about 1/2 a day. On the AMD64 I run Nero on it only takes it about 3-4 hours to do a movie from the DVD (or HDD if I use DVDDecryptor first). This is an apple to orange comparison though as the DVDIdle/Nero Recode is done entire on the AMD64 machine and the HB-HB/MTR is done entirely on the PB.

The problems with H.264 playback on iTunes/QuickTime is not a new one and is well documented in various Winblows forums, though I haven't checked on it since the first of the year, so things may have improved since then, a quick search would reveal this. Check with Nero's forums as well as Doom9 as that is where I believe I first learnt about this problem.

Though I haven't yet, I will try this time playing the movie back in another player and see if that is the problem as well in this case as soon as this conversion is finished. I'm currently not even 1/2 way through the current session I am in now so it will be a while before it completes. I hope this information helps someone in debugging this issue, as I would love for this to work with less effort and quicker on the PB than what it's currently taking me. I will also re-install Winblows and VM to see if the DVDIdle/Nero Recode does any better on here at a later point and report back on that as well, but that too will have to be after this encode is completed and I test it out as well.

To clarify, I have run this movie both straight from the DVD as well as while using MTR 2.6.6 to rip the movie. It did say there "may be problems during playback due to 0 size files during rip" but it plays back fine in DVDPlayers.