Megui cannot mux correctly

[tomcat_]

I'm not so sure if this is a MEGUI issue or something else. But here it is:

I'm using win7 64bit. I'm also using MeGUI 64bit and 32bit both installed. Issue appears in both 64 and 32bit of MeGUI.

I have the original DVD of walt disney - Dumbo and i want to make an mp4 out of it.

DVD decrypter cannot decrypt this dvd as it stuck at ifo parsing, so i have used dvdfab which had no issue in making an ISO.

After making an ISO with dvdfab, i have used dvd decrypter in IFO mode for the main movie.

Then i used the indexer from MeGUI to index the .vob file and this is when the problem starts i think. The file is indexed but at the end i'm also getting a .fix.txt file, a .d2v and a .d2v.bad.

When i'm going to avs creater via MeGUI and trying to open the .d2v megui crashes after a long time. That happens even if i use the 32bit version.

What i have done then was rename the .d2v.bad to .d2v and avs creater opens that file with no issues

I can encode the movie, sound etc and when i mux the movie i'm getting a long delay on the sound compared to video.

When i play the .mp4 the sound starts but on the video there are green screen flashes and it starts after some seconds.

Any ideas as to what's going wrong?

thanks

[tomcat_]

sorry to bring this back...but has anyone faced similar issue with the specific dvd pls?

[Guest]

Can you attach the fix.txt and both D2V files, please?

Have you tried manual processing with DGIndex? Use it directly, not through MEGUI.

[hello_hello]

Something else to try. I've not had a similar issue with d2v files but the last time I tried to encode a Disney Movie I had similar problems ripping it. I used MakeMKV (seems to work with Disney movies quite well) to rip the movie to an MKV file and then used MKVCleaver to extract the audio from the MKV. From there I opened the ripped MKV using MeGUI which it indexed with ffms and encoded without a problem. Once it was finished I used MKVMergeGUI to mux the original audio and the encoded video to a new MKV, although you could no doubt use MeGUI to re-encode/remux the audio as well if you want to and save the output as MP4 instead etc.

If there's an audio sync problem when you're done you could probably open the ripped MKV using MediaInfo to see if there was an audio delay used and apply the same delay when muxing it with the encoded video, although if the problem with your encode was the addition of unnecessary frames at the beginning for some reason you probably won't need to.

Maybe the problem's not DGIndex as such but something going wrong in your ripping process? I don't use DVDFab but does it have an option to rip just the movie to vob files rather than go via an ISO?

[tebasuna51]

I recommend also the hello_hello method to rip and recode the DVD but with a little change:
Instead use MKVCleaver to extract the audio use eac3to (MeGUI -> Tools -> HD Streams Extractor), then any audio delay is corrected without audio sync problems.

[tomcat_]

thanks for your replies...i might try some of your ideas..although it does sound advanced to me...i do use megui for a couple of years with a specific way...so anything out of it...i need to research it to understand..

please find attached the 3 files:

[hello_hello]

I recommend also the hello_hello method to rip and recode the DVD but with a little change:
Instead use MKVCleaver to extract the audio use eac3to (MeGUI -> Tools -> HD Streams Extractor), then any audio delay is corrected without audio sync problems.

Good idea. Why didn't I think of that?

tomcat, if you're familiar with MeGUI there shouldn't be too much of a learning curve.

Install MakeMKV and use it to rip the DVD. Extracting just the movie with the appropriate audio stream (if there's more than one) shouldn't be hard to work out. The first time I opened a DVD using MakeMKV I was successfully ripping it about a minute later.

Open the ripped MKV file using MeGUI's HD Streams Extractor as suggested by tebasuna51 (from the Tools menu), use it to extract the audio from the MKV, then open the MKV file for encoding with MeGUI as you'd normally open a vob file, except use the extracted audio as the audio for MeGUI to add to the encode or convert etc.

Usually I extract the audio from the ripped DVD/MKV file manually as I just encode the video using MeGUI then add the audio manually (without converting it) when the video encoding is done, but there's probably no reason why you can't just open the MKV file and encode it in exactly the same way you'd open a vob file and encode it, skipping that step entirely. Maybe I've just added unnecessary confusion to the process with my method....


tebasuna51,
For some reason I thought when MeGUI extracts the audio from MKV files the appropriate audio delay mightn't be applied automatically (if there is one), but I just tried opening an MKV (h264 and AAC) which I know has an audio delay and when the audio was extracted the correct delay amount was written to the audio file's name just as it would be when indexing vob files, so I guess I got that wrong.
When you index video with ffmsindex (at least using MeGUI) does it always write the appropriate audio delay to the file name or does it depend on the container or audio type? For some reason I had it in my head ffms doesn't do that.... probably for no good reason.

If that's the case, would there be any reason why tomcat couldn't just open the ripped MKV using MeGUI in the same way he'd open a vob file for encoding, let MeGUI encode the video and audio as it normally would, and bypass the need to manually extract the audio from the MKV first as I originally suggested?

[Guest]

Looks like the classic "crap at the start of the VOB" case where starting the project in by a few GOPs may fix it. You'll have to do the indexing manually with DGIndex. Open the VOB, hit > a few times and then [. Then save the project, make your script, and open the script in MEGUI.

[7ekno]

^^ This ...
It's a common protection on Disney DVDs ;)

7ek

[tebasuna51]

tebasuna51,
For some reason I thought when MeGUI extracts the audio from MKV files the appropriate audio delay mightn't be applied automatically (if there is one), but I just tried opening an MKV (h264 and AAC) which I know has an audio delay and when the audio was extracted the correct delay amount was written to the audio file's name just as it would be when indexing vob files, so I guess I got that wrong.
When you index video with ffmsindex (at least using MeGUI) does it always write the appropriate audio delay to the file name or does it depend on the container or audio type? For some reason I had it in my head ffms doesn't do that.... probably for no good reason.

You are right. Seems a new (for me) MeGUI feature.
In the past the FFMSIndex method sends only a job with the video process. Of course ffms can't extract audio.

But now MeGUI send two jobs, and the first one is the audio extraction with MkvExtract, and names with delay reached previously with MediaInfo.

When container is other than mkv (avi, mp4, m2ts, ...) MeGUI don't extract the audio, only send the job to index the video.

[hello_hello]

Ripping a DVD using MakeMKV and just opening the MKV to convert with MeGUI as you would a vob file should work perfectly then.

tebasuna51,
For the record I think MeGUI has been extracting the audio using MKVExtract for a while (when indexing MKV Files). I just hadn't paid much attention to it.
I just tried indexing an Xvid/MP3/AVI (given you mentioned it) and MeGUI does give you the same option to select the audio track when indexing, however it didn't extract the audio but it did add the audio to be encoded via a script. Something I'm sure it's also been doing for quite a while but I forgot about it as I generally do the audio side of it manually.

Also for the record.... I opened a small AVI with VirtualDub and resaved it while adding a one second audio delay, then used the new version for re-encoding. The resulting encode had the same one second audio delay. Seems it might be pretty safe to encode any type of video with MeGUI and not have to worry about manually applying audio delays. Which I guess is as it should be. The script created for encoding the audio looked like this:

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFAudioSource("E:\test.avi", track=1, cachefile="E:\test.avi.ffindex")
# detected channels: 2 channels
# detected channel positions:

Oh.... but of course in between test indexing jobs MeGUI wanted to update a couple of components which included ffms (version 2.17). Before the update I could happily index AVIs. After the update.... not if the AVI has an audio delay. All I'd get is an audio decoding error in the log file. I rolled back to the previous ffms version (r683 according to MeGUI) and I was back to indexing AVIs with audio delays again. Guess I should file a bug report in the MeGUI thread.

[tomcat_]

i've been a bit lazy...and on the already ripped .vob i run HD extractor and i got the mkv, ac3 and .sub files. Then i run the process normal with d2v (with no issues) and ended up with an mp4. However, it was still out of sync + some seconds missing from the beginning of the movie.

I will try to rip the dvd with the makeMKV and then follow my normal conversion process, and i will report back.

I was just wondering, what is the difference between makeMKV for ripping and DVDdecrypter or DVDhab HD?

[Guest]

However, it was still out of sync + some seconds missing from the beginning of the movie. The author of DGIndex gave you the likely explanation, but you don't seem interested.

[tebasuna51]

I just tried indexing an Xvid/MP3/AVI (given you mentioned it) and MeGUI does give you the same option to select the audio track when indexing, however it didn't extract the audio but it did add the audio to be encoded via a script.
Yes, and this is a problem. Most the times we want extract the audio and reuse it. Recode the audio is a undesired workaround.

There are a MeGUI tool, AviMuxGUI, than can detect delay and extract AVI audio.

And, yes, the last version crash when the audio have delay.

[tebasuna51]

...
I was just wondering, what is the difference between makeMKV for ripping and DVDdecrypter or DVDhab HD?

Seems remove the problem with first incorrect GOP's.

But you can use also the workaround suggested by Neuron with your old rip.

[Hotpocketdeath]

This reminds me of an issue I had with The Stand. I had problems with the audio being out of sync.

I did find a solution to this, as well as other DVD's with issues being ripped with IFO mode in DVD Decryptor.

In IFO mode, look for the "Cells" beside the chapter numbers. If Chapter 1 has a bunch of cells, then they probably contain crap information. All I do is uncheck any "cell" with a duration of less then 1 second, or just keep the last cell in the chapter only, it's usually the only one with a long duration to show it actually has the needed information.

Doing this fixes the IFO errors I've seen on some movies and it did fix the audio sync problem I had with "The Stand"

[tomcat_]

The author of DGIndex gave you the likely explanation, but you don't seem interested.

i didn't mean to offend you, but there are a few suggestions which are new to me, so i'm trying not to get lost.

I have tried your suggestion, however at the end i'm getting a msg regarding "a field order transition was detected" asking me if i want to correct it or correct it later. if i press yes then i'm getting a d2v and a .bad file.

i pressed no, and went ahead to use the d2v with the avs script creator. when it finishes the encoding will let you know the results...

when i pressed yes and i used the .d2v then i cannot load it to avs creator as it hangs...

*edit*

ok that did work, although source is anime it looks like picture and audio are synchronized.

[tomcat_]

This reminds me of an issue I had with The Stand. I had problems with the audio being out of sync.

I did find a solution to this, as well as other DVD's with issues being ripped with IFO mode in DVD Decryptor.

In IFO mode, look for the "Cells" beside the chapter numbers. If Chapter 1 has a bunch of cells, then they probably contain crap information. All I do is uncheck any "cell" with a duration of less then 1 second, or just keep the last cell in the chapter only, it's usually the only one with a long duration to show it actually has the needed information.

Doing this fixes the IFO errors I've seen on some movies and it did fix the audio sync problem I had with "The Stand"

that did work as well...thanks all for your help...i got many mp4s working now with different methods..:)

[hello_hello]

Yes, and this is a problem. Most the times we want extract the audio and reuse it. Recode the audio is a undesired workaround.

Seeing the OP has his problem sorted for now, I might sidetrack the thread a little, although it's relevant.

I'm in PAL-Land but yesterday I encoded an NTSC 29.970 fps DVD. I ripped it using my usual method and also using MakeMKV. Encoding the vob files was easy, but trying to encode the MKV was where the fun started.....

As I don't really know what I'm doing I used AutoGK to start a conversion to AVI in order to see what it thought of the video. I generally trust AutoGK. After the analysis it declared the video to be a hybrid, mostly FILM. It ran a second analysis and then declared the video to be pure film. When it was done I had a 23.976fps AVI which looked great.
Using MeGUI to encode the vob files produced the same result and the final encode had the same frame rate, number of frames and the same duration as the AVI AutoGK created.

Encoding the MKV created by MakeMKV was a whole other story though. After indexing with ffms MeGUI considered it to be progressive but the number of frames and the duration was wrong. According to MeGUI the MKV frame rate was 24.193fps. I tried manually adding IVTC which helped, and even tried adding ChangeFPS or AssumeFPS to the script but while that fixed the duration the video seemed to still have around 1000 frames more than it should have. In the end I just gave up using ffms. Oddly enough though, when I switched to DirectShow to decode the MKV everything was fine. Once I added IVTC to the script I ended up with the same number of frames as when encoding the vob files and the final frame rate of the encoded video was 23.976.

So not having had to work with 29.970fps video much, and after my little essay, I guess my question is this.... is it likely there were issues with the original mpeg video which carried over to the MKV MKVMerge created and ffms just couldn't work properly, or should I be wary of using ffms to decode MKVs containing mpeg2 video and stick to encoding vob files as much as possible?