It wasn't until a couple of days later that I discovered that the source actually had 10 PGCs and that PGCs 9 & 10 had audio that was 4400ms late - I assume the PTS was in error for the VOB holding those PGCs. The failure occurred when I changed the audio stream #s by one place. May I share some firsthand experience? I have no idea why, 11 days ago, an MKV to MKV remux failed at 78%. Whenever an error occurs, the bottom right box should contain something.
You'll see a tab with three big text boxes labeled "normal output" (the top one), "warnings" (bottom left) and "errors" (bottom right). Inclusion of integrated subtitle & chapter tools (involving some processing of IFO files for DVD, and MPLS files for BD (I think)) would be a very welcome addition.Ĭlick on the "job output" tool on the left. I'm fairly new to MKVToolNix, but I'm pretty happy with it. Let me give you an example: Total Commander even after 15 years of constant use, I never cease to marvel at its utility and simplicity.
The apps that make me happiest are the ones that are 'transparently' easy to use. But I will say that in 45 years of computer use, I've never seen an app as you describe (aside from MKVToolNix, apparently). I won't push the issue because you're obviously proud of the UI and it's not a big issue to me. MKVToolNix is a program in the tradition of desktop applications, not a smartphone/tablet app where different rules apply. This isn't the case with MKVToolNix as there all list boxes/tree views have context menus, similar to well-known desktop applications such as Word, Excel or even web browser (where everything actually has a context menu, not just links!). Varekai, I haven't tried all your suggested tools (though I already have and use most of them).Īll of those methods are only appropriate for cases where context-sensitive content is interspersed in non-conext-sensitive content, such as hyperlinks in otherwise regular text. Note that MKVToolNix's "Fix bitstream timing info" check box was unavailable (grayed out). Is there a better way to determine the needed audio delay than by trial-&-error? (I realize now that rerunning HandBrake in each loop was probably unnecessary and that I could have extracted the 9th program just once, at the end.) I repeated Steps 3 & 4, adjusting the audio delay until it was right.Įach time, I had to fast forward to the 9th program to see the result.īetween each step, I reran HandBrake to extract the 9th program (based on start/stop times) to verify that, indeed, I was getting what I wanted. Step 3: I reran MKVToolNix and added an audio delay. Step 2: I viewed the MKV via the MPV player and saw the audio leading towards the end of the MKV.
Step 1: I used MKVToolNix to repackage the VOB as an MKV. I wonder whether there's a better way than my work flow. I may encounter something like this in the future. The source IFO has 10 PGCs (program chains).īeginning with the 9th program, audio leads the video - programs 1 to 8 were okay.īy tedious trial-&-error, I worked out that the audio needed to be delayed by 4400ms.
0 kommentar(er)
