NO AUDIO?... Read Here! (Summary in First Post) **UPDATED**
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
-
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
-
- Posts: 6
- Joined: Sun Apr 15, 2007 6:11 pm
Ripping all of my movies with MTR 2.6.6, full disk extract. Encoding with HB .85b1.
Some fail, actually not very many I've noticed lately. Maybe just me. Anywhoo.
It seems that the ones that DO fail, I throw the CLI version at and it encodes them with no problems. What I have noticed that is different, however, is that the CLI version encodes slower.
The GUI version will go at about 20-25 fps for me. (iMac 20" 2.0ghz dual core). While the CLI version will only rock out around 14-18fps. It also takes longer, obviously, but again, it never drops audio.
Not sure if it helps, but there it is.
Some fail, actually not very many I've noticed lately. Maybe just me. Anywhoo.
It seems that the ones that DO fail, I throw the CLI version at and it encodes them with no problems. What I have noticed that is different, however, is that the CLI version encodes slower.
The GUI version will go at about 20-25 fps for me. (iMac 20" 2.0ghz dual core). While the CLI version will only rock out around 14-18fps. It also takes longer, obviously, but again, it never drops audio.
Not sure if it helps, but there it is.
Thank god. Err. Thank eddyg. Same diff.bhaal wrote:the latest SVN GUI version produces a rip with audio all the way through for at least one DVD that (Face-off PAL version) dropped audio halfway through before.
Eddy submitted a patch to try to fix this stuff. Good to have some indication it's working.
Here are the changes for those who are interested:
http://handbrake.m0k.org/trac/changeset/738
And here's his explanation of how it works/what the problem really is (short answer: it *is* caused by incorrectly mastered DVDs despite what 90% of the people in this thread have claimed):
http://handbrake.m0k.org/irclogs/handbr ... 2_pg1.html
I think the reason that the issue was so difficult to diagnose was that a number of things could lead up to the situation where the audio was more than 1sec out of sync with the video. And that is when we would in the past stop encoding audio forever.jbrjake wrote: And here's his explanation of how it works/what the problem really is (short answer: it *is* caused by incorrectly mastered DVDs despite what 90% of the people in this thread have claimed):
http://handbrake.m0k.org/irclogs/handbr ... 2_pg1.html
There are multiple threads that run independently, so scheduling is a contributing factor. Bad DVD mastering also can cause this issue. Mostly bad DVD authoring in my opinion, hence it striking at the same place on the same DVD every time.
I'm glad it appears to be working for people.
Cheers, Ed.
-
- Posts: 6
- Joined: Thu Jul 26, 2007 2:31 am
-
- Posts: 6
- Joined: Thu Jul 26, 2007 2:31 am
Just an update I got finding nemo to encode as well without an audio drop outs which I had also previously had problems with. I had been encoding everything 29.97 framerate and it seems like going down to 23.976 helped. I also had upped the audio bit rate so I don't know if that contributed to the improvement. I'm using MTR 2.6.6 with full feature extract and the CLI version of handbrake 8.5b1.not_too_shabby wrote:I got alice in wonderland to encode by change the framerate from 29.xx to 23.98 and the audiorate up to 220 from 192. I used the same MTR ripped files in both cases.bhaal wrote:Just a quick update to note that a main feature rip for Capote works with no issues
I am here to report good news also. I have been doing extensive testing for the past 2 days. I am finally done.nightstrm wrote:So far, so good here... I've been able to successfully rip a disc that gave me drops out using both the GUI and CLI. Very good work eddyg, there are going to be a lot of happy campers out there when the next beta is released!
My tests were as follows:
All MTR extracted. Tested both Main Feature and Full Disc. Tested both CLI and GUI.
Results were consistant:
Main Feature extraction -> still drops, but less & more random (cli & gui) 'cept once came out okay.
Full Disc -> Success for both cli & gui, every time.
Pan's Labyrinth, Cars
Yes, that's 8 encodes all the way through (using iPod-Hi-Res preset or cli equivalent).
Whew, glad that's done.
No audio CPU drop only in H.264
The bottom line for me after "countless" h.264 encoding is that it is mp4/h264 that can sometimes cause the drop in CPU and then subsequently the audio. It can happen with older or more troubling new Sony disks. It happens with MTR Full or Main and MTR 3. The only solution I have found, is not various versions of HB or MTR, but encoding with ffmpeg instead of H.264. In fact, at times that fails too with an mp4 container, in which case I switch to avi/ffmpeg and it works or also with passthrough. Jaws is a perfect example of the later. There is something screwy that happens with H.264 sometimes. I hate to sound dogmatic about it, but I have tried countless methods. And I can also say, if I revert to VisualHub as a last resort the same H.264 issue occurs--cpu drops then audio. I wish someone would take a look more specifically at the codec or how H.264 is used.
Thanks
Thanks
The differing results with ffmpeg video are likely due to how the encoder responds to the poor mastering on a problem disc rather than the encoder itself. Obviously you can phrase it as a 'problem' with either but given the feedback from the devs it seems that the x264 encoder is simply making the best of a poor source rather than it being an inherent problem with it.
-
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
Re: No audio CPU drop only in H.264
Um...So what part of This IRC Log are you not understanding. eddyg clearly states what the problem is and how he fixed it (which is implemented in svn).jackwg wrote:The bottom line for me after "countless" h.264 encoding is that it is mp4/h264 that can sometimes cause the drop in CPU and then subsequently the audio. It can happen with older or more troubling new Sony disks. It happens with MTR Full or Main and MTR 3. The only solution I have found, is not various versions of HB or MTR, but encoding with ffmpeg instead of H.264. In fact, at times that fails too with an mp4 container, in which case I switch to avi/ffmpeg and it works or also with passthrough. Jaws is a perfect example of the later. There is something screwy that happens with H.264 sometimes. I hate to sound dogmatic about it, but I have tried countless methods. And I can also say, if I revert to VisualHub as a last resort the same H.264 issue occurs--cpu drops then audio. I wish someone would take a look more specifically at the codec or how H.264 is used.
Thanks
Re: No audio CPU drop only in H.264
Cavalicious wrote:
I am not a programmer and do not understand the full discussion or implications of the IRC Log. Thanks for showing it to me though. And I don't know what you mean by "it is implemented in svn." What is that and or where is it?
If however, it is being argued that it is faulty mastered discs then I still do not understand how a faulty disc works with one encoder over another. Doesn't the concept of garbage in garbage out apply here? How does ffmpeg do what h264 can't? Or better yet, why can't h264 be made to handle what ffmpeg can?
Anyway, thanks for the help.
Most of it! I have just joined this discussion. I offered my exhustive use of the HB/MTR in a brief summary based on the front page "summary" by you quoting another that said "Now, if indeed, on the same machine, same drive, h.264 drops audio but ffmpeg doesnt, that is a clue for us and we will look into that as soon as we have time." That is clearly the case for many here including myself. I was just adding my experience to that.Um...So what part of This IRC Log are you not understanding. eddyg clearly states what the problem is and how he fixed it (which is implemented in svn).
I am not a programmer and do not understand the full discussion or implications of the IRC Log. Thanks for showing it to me though. And I don't know what you mean by "it is implemented in svn." What is that and or where is it?
If however, it is being argued that it is faulty mastered discs then I still do not understand how a faulty disc works with one encoder over another. Doesn't the concept of garbage in garbage out apply here? How does ffmpeg do what h264 can't? Or better yet, why can't h264 be made to handle what ffmpeg can?
Anyway, thanks for the help.
-
- Moderator
- Posts: 1804
- Joined: Mon Mar 26, 2007 12:07 am
Re: No audio CPU drop only in H.264
1. bhaal responded to this above.jickwig wrote:Most of it! I have just joined this discussion. I offered my exhustive use of the HB/MTR in a brief summary based on the front page "summary" by you quoting another that said "Now, if indeed, on the same machine, same drive, h.264 drops audio but ffmpeg doesnt, that is a clue for us and we will look into that as soon as we have time." That is clearly the case for many here including myself. I was just adding my experience to that.
2. bhaal response was pretty much the same as Point (3) in the summary.
3. You yourself said that ffmpeg didn't always give you audio. Thus your marriage to the quote in the summary is irrelevant.
1. You can ask eddyg if he is willing to break down his findings for you.jickwig wrote:I am not a programmer and do not understand the full discussion or implications of the IRC Log. Thanks for showing it to me though. And I don't know what you mean by "it is implemented in svn." What is that and or where is it?
2. http://handbrake.m0k.org/?page_id=9
1. No, its not being argued anymore. See IRC Chat Log.jickwig wrote:If however, it is being argued that it is faulty mastered discs then I still do not understand how a faulty disc works with one encoder over another. Doesn't the concept of garbage in garbage out apply here? How does ffmpeg do what h264 can't? Or better yet, why can't h264 be made to handle what ffmpeg can?
2. Re-read point 3 in Summary
Let do our best not to rehash the arguments that are littered in 20 some odd pages within this thread. You may want to read them, as you will become well informed, one way or another.
-
- Posts: 4
- Joined: Mon Jul 30, 2007 7:18 pm
Sure, follow the steps here: http://handbrake.m0k.org/trac/wiki/CompileGuideNobody Special wrote:Would it be possible (and kosher) for someone to compile a build that implements eddyg's svn?
The developers don't really want SVN builds posted or distributed.
Thanks a lot. I'll also say after never checking on the svn before, I was very impressed with the new look HandBrake has, very nice.nightstrm wrote: Sure, follow the steps here: http://handbrake.m0k.org/trac/wiki/CompileGuide
The developers don't really want SVN builds posted or distributed.
-
- Posts: 5
- Joined: Thu Aug 02, 2007 3:04 pm
-
- Posts: 5
- Joined: Thu Aug 02, 2007 3:04 pm
While decontaminating the chapters, (on 2 DVD with bug), that goes very well.yannick.val wrote:Sorry, I am french.
I am testing, If the chapters are deleted, I do not have the problem of cut of sounds.
Conversion do not be to finish, but I keep you informed in 2 hour.
I will test with chapters and version HB 785.
I keep you informed.