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.

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.

[/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

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.

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!!!

[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)

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.

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.

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.

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).

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).

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.

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.

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.

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.)

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.

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.

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)

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.

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.

Last edited by cknyckny on Thu Apr 26, 2007 10:53 am, edited 1 time in total.

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.

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.

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.

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.