meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)

[Vitreous]

- Confusion about terms core and thread. Your CPU is made up of 6 physical cores. I.e. a core describes the hardware of your CPU. Threads or processes (similar concepts for a non-developer) are different instances of a program running at the same time on your CPU. I.e. a thread describes running software. You can run as many threads/processes as you like until you run out of memory, they are not related to cores (unless you specifically ask for that - like Prime95 does - but that's not the norm). Even a single core processor can run many threads, although it won't be as effective. Dunno what you were reading from CPUZ, your system has 6 cores and as many threads as your programs launch...

- Auto on your setup will select 12 threads, which is too many usually. I must put a maximum cap on the auto values... Lowering threads manually is the way to go. I will make it save your settings, but I have little time for development atm

- Use MP4 if you're targeting hardware devices. MKV has the advantage of more robust support and better tools, but it does have less compatibility. However, for lower powered hardware devices you may need to tweak x264 settings too. I know little about this.

- Demux MKVs with MKVCleaver. Remux MP4s with something like MP4BoxGui (may be better tools - I rarely mux MP4s). Or you can mux MP4s with MeguIVit itself, in the menus under Tools>>Muxer... No quality loss in this process, and can be quite quick.

 

[anandneemish]

Hey Vit,
I have finally converted to 60fps. Hallelujah. I was blind, but now I see!!!!

Before, thinking I was saving space and conversion time, I would always check the Single option under frame rate. Nowadays, I just leave it on Double. Really makes a difference in playback quality! Awesome!!

Thanks.

 

[Vitreous]

Glad to hear it. One of my major goals of MeguIVIt was to make 60fps rips more reasonable for rippers. The more 60fps content that gets out there, the more people see the quality and so the more rips that are made 60fps - a self-fulfilling circle that gradually raises the quality of everything we download. So always happy to have a new convert!

 

[snakeboy]

Finally got my act together and installed the latest beta (meguIVit 1.0.0 beta-3). Not being totally new to this, I followed instructions but was met with the famous appcrash before I could get started.

For the record, meguIVit_0.2.1 still works fine, and yes, I'm doing all the obvious stuff like "run as administrator", even tried the compatibility with XP SP3, 2 etc. Always same result. It's win7 (ultimate) x64, i7 950, no OC.

Suggestions?

 

[Vitreous]

shank and I worked out some solutions to common problems, which shank kindly summarized here. Try those two steps.

 

[snakeboy]

Since I can't even get it started up, I wasn't optimistic, but tried all the same. "msvcr71.dll" was already present. I have some recollection of doing this previously to get 0.2.1 working I think. Still, I tried d/l'ing a fresh copy. Same problem.

I then tried the alternate avisynth.dll to no avail. Same result.

In desperation, I made a clean winXP install on a virtual machine (virtualbox) and tried running it from there. It did not work, but I at least managed to coax a different error message out of it this time which would perhaps be of some use to someone more familiar with it's intimate requirements. I got this:

Although it should be mentioned that an unmodified MeguVit 0.2.1 fires up with no complaints on the same exact virtual machine. (Did not try an encode just yet though, but at least the program actually starts up.)

EDIT: In order to eliminate the possibility that the error above is related to the fact that it's running within a virtual machine, I hooked up an old XP machine and ran it from a native install and got EXACTLY the same error message as above. And again, MeguVit 0.2.1 starts up, no problem on that machine either. Clearly it's not a virtualbox issue.

 

[Vitreous]

Just to confirm, original MeguIV and MeguIVit 0.2.1 and 1.0b3 all use exactly the same executable, just different sandbox folders (deleted of course between trying different versions). So you're saying if you delete the 0.2.1 sandbox then unzip the 1.0b3 one, then the program crashes before you see anything?

Note that MeguIV itself runs a virtual machine (it uses Xenocode). running a VM in a VM may well have problems. When you ran it on XP the error would look different than on Win7. It would help to see all the error text on both Win7 and XP. Have you tried running it on Win7 without a VM?

 

[snakeboy]

Just to confirm, original MeguIV and MeguIVit 0.2.1 and 1.0b3 all use exactly the same executable, just different sandbox folders (deleted of course between trying different versions). So you're saying if you delete the 0.2.1 sandbox then unzip the 1.0b3 one, then the program crashes before you see anything?

Correct, that's exactly what happens.
Under win7 x64 my c: drive is a SSD. Knowing this may be an issue I tried it from the D: drive which is a "normal" drive, but generated the same error message.

Note that MeguIV itself runs a virtual machine (it uses Xenocode). running a VM in a VM may well have problems.

I thought this much a possibility, that's why I wanted to verify it by running it on an actual machine running XP (pro 32bit) natively. I have done encodes on this machine previously so I know it works, but it's only an Intel E7200 Core 2 Duo at 3.06Ghz, no overclock so a LOT slower than my main workstation which is where I want to run this to get the benefit out of the i7.

When you ran it on XP the error would look different than on Win7. It would help to see all the error text on both Win7 and XP. Have you tried running it on Win7 without a VM?

Yes, the error under win7 x64 was this one:

Under XP, be it on the virtual machine or an ACTUAL machine, the error is identical. It's this one:

This machine is usually rather "sluggish" but this error message appears almost instantaneously, the moment I run the meguIV.exe executable which based on my user experience on this machine "feels suspicious". Whether or not that's relevant, I can't say.
Running the 0.2.1 executable means about a 5 second wait before the program starts up, but at least it starts up. There's no fancy hardware in the machine, 2GB ram, regular HDD etc.

I have a 3rd machine, a laptop, running 32bit XP Pro, but it's not available to me for testing purposes till later this month. I'd be curious to see it's response.

 

[Vitreous]

You said you got exactly the same error on Win7 and XP, but those errors are quite different. The second error is a Xenocode one. Rollyco used Xenocode to build MeguIV so it was a portable application, not requiring installation. A quick look shows that Xenocode is not officially supported under a VM, so neither is MeguIV(it). The only other solution I have seen suggested to that error is to delete all Xenocode entries from the registry and any Xenocode folders from C:\Users\YOUR USERNAME\AppData, then start again. Another idea is to run MeguIVit 0.2.1, then don't delete the sandbox, just extract the 1.0b3 version over the top, and then try running it.

But most importantly, have you tried running MeguIVit on Win7 without a VM?

 

[snakeboy]

You said you got exactly the same error on Win7 and XP, but those errors are quite different.

Sorry if I'm being unclear. Let me try again: Under Win7 64, I get the first error ("Appcrash"). That's Win7 64 natively installed on the i7 950 - my "main" workstation.

The Xencode error I get, I get when I run it in a XP 32 VM "inside" the Win7 64 machine.
I ALSO get the same error (the Xencode one) if I run it on the XP box natively installed.

To recap:

On the i7 I've tried it under native Win7 and get the first error message. I tried it on the i7 within an XP VM and get error 2.
On the e7200 machine which is running XP 32 native, I get error 2, which tells me it's nothing to do with the fact that it's running within a VM.

The second error is a Xenocode one. Rollyco used Xenocode to build MeguIV so it was a portable application, not requiring installation. A quick look shows that Xenocode is not officially supported under a VM, so neither is MeguIV(it). The only other solution I have seen suggested to that error is to delete all Xenocode entries from the registry and any Xenocode folders from C:\Users\YOUR USERNAME\AppData, then start again. Another idea is to run MeguIVit 0.2.1, then don't delete the sandbox, just extract the 1.0b3 version over the top, and then try running it.

I will try both of these suggestions when I get home this evening and report the results, thanks.

But most importantly, have you tried running MeguIVit on Win7 without a VM?

Yes, this was what I tried first, since I intend to use this machine which is running Win7 64 natively and has some i7 muscle to do the encoding. It's only when it did not work (error 1, appcrash) that I tried it under a XP VM in order to perhaps get it working but still have access to the i7 muscle. When that didn't work either, moved to the weaker E7200 (which is running XP 32 natively), but got the same results as I did on the XP VM under Win7.

I wouldn't dream of trying to run a VM of any kind on the e7200 machine as it barely copes with XP natively as it is...

 

[Vitreous]

OK, I see. I was dizzied by all the tests you reported.

Only interesting issue I've seen regarding that APPCRASH was a user who had mixed up 32 and 64 bit dlls (System32 for 64-bit, SysWOW64 for 32-bit).

Suspicion with start up problems is Xenocode or missing dependencies. Which are related. I'm relying on Rollyco's original dependency setup from MeguIV. I should build all the dependencies again, but I don't have time for that for now.

 

[snakeboy]

Okay, thanks for the info and here is the good news: I got it working! How? Well, I tried what you suggested above by eradicating instances of Xenocode from the registry as well as the /appdata folder. I did this on my i7 under Win7 64 native. I got the appcrash error again when running.

I then tried your second suggestion (before moving the same tests to the native XP machine). ie, I ran a copy of MeguIVit 0.2.1, did NOT delete the sandbox folder. I then extracted the 1.0b3 sandbox over it, ran it and BAM!, it loaded right up!

Now, I'm not getting too excited just yet because I've not actually attempted an encode, but at least I got the app up and running.

I then went a step further (just for curiosity really) and did the same on the native XP machine. Again, it loads right up, no complaints.
And now the punchline - I did the same again within a XP VM on the i7 under Win7 64 and once again, it loaded up just fine. So now ALL instances are working.

So, (this) problem is now officially solved. THANK YOU for your suggestions, we got there in the end. I will now move to getting an encode going to see if there are any other surprises waiting, but I feel pretty confident I'm good to go now.

Thanks again! :cheer:

 

[snakeboy]

Chapter issues:

I am currently encoding EICSB-006 (Yuzuki Urara), I have made NO trims or edits to the footage. Output file has a runtime of 1:13:38, however the generated chapters file reveals that there are 22 chapters, the last of which points to 01:18:48.566.

Having read in this thread that MegUI's chapter grabbing code could be at fault, I went with Chapter X-tractor instead. It also produced 22 chapters, the last one being at 1:18:43:83.

How is it possible to have chapters which point to times BEYOND the duration of the footage?

Now, playing the video and trying the chapter points reveals that the first one is about the only one correct. The rest miss their mark my several seconds and the offset of inaccuracy appears to increase with duration, so it can't be solved by applying a global offset to all the times to "correct for" the problem.

I am not knowledgeable enough about the construction of the DVD cells etc to speculate how this might be caused or possibly solved.

ANY suggestions? (Aside from manually creating a chapter file by stepping through the footage and noting all the "fade-to-white" times?)

 

[Rollyco]

You're having drop frame related issues. Try ChapterGrabber.

Select File > Open Disc and open your DVD
Select the right stream
Select Edit > Convert Chapter Times by FPS > 30.000
File > Save
Import your new chapter text file with mkvmerge.exe (Global tab, Chapter file field)

If you ever want to go in the opposite direction and progressively stretch NTSC timestamps, you usually do it like this:

Select File > Open Disc and open your DVD
Select the right stream
Change Edit > Current FPS from 29.970 to 30.000
Select Edit > Convert Chapter Times by FPS > 29.970
etc...

 

[snakeboy]

You're having drop frame related issues. Try ChapterGrabber.

Thanks Rollyco! Gave this one a shot exactly as per instructions. Last chapter it gives me is chapter 21 at 1:17:39.115, so STILL out of bounds for my 1:13:38 duration. !?

I assume it leaves out Chapter 22 because its less than 5 seconds in duration. Chapter X-tractor calls that a "bug"

FYI, the actual DVD itself shows only 20 chapters from it's menu. It also reports a 1:18:48 duration from the "play all". So even though I'm NOT trimming for the encode, I'm missing some frames somewhere I guess.

Playing the DVD starts at the same point and ends on the same point (visually) as the rip does. So I'm at a loss as to where the missing time has gone...

 

[Rollyco]

If you want to put all of the .IFO files in a .ZIP archive and upload them, I can take a look.

 

[Vitreous]

I can't tell you anything about DVD cells, but I have often seen chapters at or beyond the end of the playable time. They seem to be ignored at playback. Very frequent is a single chapter point at the very end of the video. You say the "play all" reports 1:18, but does it actually play video for that period of time...?

As to the ever more delayed chapters, that's interesting. It sounds like drop frames, but MeguIVit automatically corrects for drop frames and I haven't seen ever this happen. Sometimes the MeGUI chapter extraction just doesn't understand the DVD structure and doesn't find many chapters at all (especially with multiple VOB sets), but that doesn't sound like your problem. Chapter X-tractor is the most robust program I know of for chapters, but if you use it then you must also use the ChapterGrabber drop frame process that Rollyco explained [there appear to be settings in Chapter X-tractor for drop frame correction, but I can't get them to work...]

 

[snakeboy]

If you want to put all of the .IFO files in a .ZIP archive and upload them, I can take a look.

Thanks! (attached)

You say the "play all" reports 1:18, but does it actually play video for that period of time...?

Yes, it does. Visually, the first few frames and the last few of the DVD are identical to that of the RIP. For the record, I did not get any errors extracting the VOB's either, so it's not one of those "99% but it still plays" scenario's.

I don't know where else to look.

EDIT: Just finished a 2nd encode of this (just in case). All settings defaults this time. (1st attempt was Source Match: 2, Boost and Edge Clean) Resulting rip duration is 1:13:38.

 

[Vitreous]

A quick look and I see nothing unusual about the IFO files.

I have a possible explanation though: if one of the VOBs is corrupt or partial (through downloading or actually incorrect on the DVD) then the indexing step will skip over the missing/broken parts leaving you with a playable but shortened .d2v file. I used this feature several times to rip incomplete Share downloads.

So did the MeguIVit auto-extracted chapters have that gradually-slipping-out-of-sync characteristic, or was that only when you manually extracted chapters with Chapter X-tractor? Are the out of sync chapter points too early or too late? Also you didn't say whether using Chapter Grabber fixed the earlier out of sync chapters or not. Reason I ask is because if there was corruption then you would expect the early chapters to be correct then at some point (potentially immediately if the corruption is early on) they would slip forwards.

 

[snakeboy]

So did the MeguIVit auto-extracted chapters have that gradually-slipping-out-of-sync characteristic, or was that only when you manually extracted chapters with Chapter X-tractor? Are the out of sync chapter points too early or too late? Also you didn't say whether using Chapter Grabber fixed the earlier out of sync chapters or not. Reason I ask is because if there was corruption then you would expect the early chapters to be correct then at some point (potentially immediately if the corruption is early on) they would slip forwards.

This may help: Chapter 1 is at 00:00:00 so this is chapter 2-5.
I got the actual value by stepping in AvsP to the point where the chapter break actually is.

ACTUAL: MEGuViT: Chapter Grabber:
00:27:521 00:26:026 00:25.974
01:25:878 01:35:228 01:35.037
05:11:077 05:45:279 05:44.589
05:50.277 06:32:826 06:32.041
...
01:04:00:506 01:08:47:865 01:08:39.621 (Chapter 19)

I used chapter 19 as the "last" one because it's the last one that fits within the duration of the produced rip. Chapter 20 is detected to start at 01:16:06.808 which places it out of bounds for the rip duration.

Here are the chapters as they were detected:

[hide]
MeguVIT:
00:00:00.000 : en:Chapter 01
00:00:26.026 : en:Chapter 02
00:01:35.228 : en:Chapter 03
00:05:45.279 : en:Chapter 04
00:06:32.826 : en:Chapter 05
00:08:54.202 : en:Chapter 06
00:09:48.723 : en:Chapter 07
00:18:21.970 : en:Chapter 08
00:20:01.269 : en:Chapter 09
00:28:05.320 : en:Chapter 10
00:29:22.731 : en:Chapter 11
00:37:57.113 : en:Chapter 12
00:39:57.467 : en:Chapter 13
00:47:44.333 : en:Chapter 14
00:49:02.345 : en:Chapter 15
00:58:54.970 : en:Chapter 16
01:01:26.823 : en:Chapter 17
01:07:35.559 : en:Chapter 18
01:08:47.865 : en:Chapter 19
01:16:15.946 : en:Chapter 20
01:17:48.439 : en:Chapter 21
01:18:48.566 : en:Chapter 22

Chapter Grabber:
CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 1
CHAPTER02=00:00:25.974
CHAPTER02NAME=Chapter 2
CHAPTER03=00:01:35.037
CHAPTER03NAME=Chapter 3
CHAPTER04=00:05:44.589
CHAPTER04NAME=Chapter 4
CHAPTER05=00:06:32.041
CHAPTER05NAME=Chapter 5
CHAPTER06=00:08:53.134
CHAPTER06NAME=Chapter 6
CHAPTER07=00:09:47.547
CHAPTER07NAME=Chapter 7
CHAPTER08=00:18:19.769
CHAPTER08NAME=Chapter 8
CHAPTER09=00:19:58.870
CHAPTER09NAME=Chapter 9
CHAPTER10=00:28:01.954
CHAPTER10NAME=Chapter 10
CHAPTER11=00:29:19.210
CHAPTER11NAME=Chapter 11
CHAPTER12=00:37:52.565
CHAPTER12NAME=Chapter 12
CHAPTER13=00:39:52.679
CHAPTER13NAME=Chapter 13
CHAPTER14=00:47:38.613
CHAPTER14NAME=Chapter 14
CHAPTER15=00:48:56.469
CHAPTER15NAME=Chapter 15
CHAPTER16=00:58:47.911
CHAPTER16NAME=Chapter 16
CHAPTER17=01:01:19.460
CHAPTER17NAME=Chapter 17
CHAPTER18=01:07:27.459
CHAPTER18NAME=Chapter 18
CHAPTER19=01:08:39.621
CHAPTER19NAME=Chapter 19
CHAPTER20=01:16:06.808
CHAPTER20NAME=Chapter 20
CHAPTER21=01:17:39.115
CHAPTER21NAME=Chapter 21
CHAPTER22=01:18:39.122
CHAPTER22NAME=Chapter 22


Chapter Xtractor:
Chapter 1 = 00:00:00:00
Chapter 2 = 00:00:26:00
Chapter 3 = 00:01:35:13
Chapter 4 = 00:05:44:93
Chapter 5 = 00:06:32:43
Chapter 6 = 00:08:53:66
Chapter 7 = 00:09:48:13
Chapter 8 = 00:18:20:86
Chapter 9 = 00:20:00:06
Chapter 10 = 00:28:03:63
Chapter 11 = 00:29:20:96
Chapter 12 = 00:37:54:83
Chapter 13 = 00:39:55:06
Chapter 14 = 00:47:41:46
Chapter 15 = 00:48:59:40
Chapter 16 = 00:58:51:43
Chapter 17 = 01:01:23:13
Chapter 18 = 01:07:31:50
Chapter 19 = 01:08:43:73
Chapter 20 = 01:16:11:36
Chapter 21 = 01:17:43:76
Chapter 22 = 01:18:43:83
[/hide]

If there was corruption in the ISO/VOB's wouldn't the chapter's only go out of sync after the point in the footage where the damage is? It's out of sync almost immediately (Chapter 1/2).