meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)
- Thread starter Rollyco
- Start date
-
Akiba-Online is sponsored by FileJoker.
FileJoker is a required filehost for all new posts and content replies in the Direct Downloads subforums.
Failure to include FileJoker links for Direct Download posts will result in deletion of your posts or worse.
For more information see this thread.
i have been having 99.9% troublefree rips on meguIVit 0.1.3 since i started using it but when i noticed 0.1.4 had been released i gave it a go (2 or 3 rips ago) and tried the x64 versions, A and B, out of interest. both the 64bit versions crashed about 15 mins into their first passes and 0.1.4 standard gave me a rip. i tried 0.1.4 again last night and it failed at around 6%. i have decided to go back to 0.1.3 (re-ripping the failed rip now). all failures were caused by mencoder as far as i remember.
EDIT: 0.1.3 just crashed on me at about 5%
EDIT: 0.1.3 just crashed on me at about 5%
Those versions are only for those who can't run the normal version. They give no 64-bit advantage whatsoever and are known to be less stable for those who don't need them. They use less stable versions of multithreaded Avisynth that seem to play nicer with 64-bit Win 7.
There is virtually no difference between the 1.3 and 1.4 versions - I just reduced the need for other dlls. Any crashes are the the same old. Mencoder crashes are usually due to bugs in the Avisynth multithreading. There is no version of Avisynth that has 100% stable multithreaded support. Background disk access seems to be the worst offender (I can almost always reproduce a crash if Share does a "Convert File" on a 4Gb ISO in the background whilst ripping).
What was the error, and when did it occur?
Sorry, didn't save the error -- but it was a generic error with little info -- similar to the last one I posted. I just completed a rip without errors using Version B. Again the original 1.3 app will not play on my 64-bit machine at all. I'll try a few more with Version B and keep reporting back.
The the multithreading crash in avisynth described above has a "Visual C++ ...." title but indicates the problem is in mencoder.exe. It is different to the other problems I've recently been solving, so the text of the error is important.
Multithreading mencoder.exe crashes are here to stay until the avisynth devs finally decide to release the official avisynth 2.6 (it's been due for several years). Wouldn't be surprised if they still mess up the multithreading. The main version of MeguIVit uses an unofficial build of 2.6 that is fairly stable (but not always - as seen in isityour's post above). The alternates use less stable versions, which have proved to be much more sensitive with the recent optimized scripts.
In summary, occasional mencoder.exe crashes are going to happen because avisynth is buggy. Crashes may be more frequent with the alternate versions (I will try to remove the need for the alternate versions). I can't fix mencoder.exe crashes but tell me if they are very regular. I do need to know about crashes/problems that don't involve mencoder.exe.
Do you mean the 1.4 version? That's the one I was interested in testing...
Sorry, let me clarify. On my new 64-bit machine 1.3 will not run. I have NOT tried the standard 1.4 but I will. 1.4x64 Version A has produced one clean rip and crashed about 20% into another. Version B has produced one clean rip and is close to completing a second without problems.
And yes I believe the last crash on version A included a menconder.exe error message.
And yes I believe the last crash on version A included a menconder.exe error message.
Troubles...
It was time that I wanted to try ReRip some of my videos. Finally, I just got my new PC and I'm determined and I'm having some difficulties. :study:
I hope you could give me some advices and I will not bore you too much.
I have selected the options your refered in your tutorial but I get always the same error (x264: [Vit] 480p 60fps Standard+Nero-AAC: [Vit] LC VBR Q0.42).
I have attached the logs for batch Rerip1 and Rerip2.
When I try to Enqueue Audio (as you could see in the log), I get the same error as if I had "Enqueued" the video.
uzzled:
Impossible then to encode audio or video (video only doesn't encode too)
I have tried with multi video files, same errors:
or
* meguIVit_0.1.3 or meguIVit_0.1.4, same errors (doesn't work in MeguIV, not a mystery, since AVI is not supported)
* K-Lite Mega Codec Pack 6.4.4 (but same errors with 6.4.0, all options set by default, I haven't made any change)
* V++ 2005+2008+2010, Net.Framework2.0->3.5SP1 have been installed.
* My specs: DualCore 2.5GhZ, 2Gb RAM, Windows SP3 up-to-date.
Pass for the Logs
:bow-pray:
It was time that I wanted to try ReRip some of my videos. Finally, I just got my new PC and I'm determined and I'm having some difficulties. :study:
I hope you could give me some advices and I will not bore you too much.
I have selected the options your refered in your tutorial but I get always the same error (x264: [Vit] 480p 60fps Standard+Nero-AAC: [Vit] LC VBR Q0.42).
I have attached the logs for batch Rerip1 and Rerip2.
When I try to Enqueue Audio (as you could see in the log), I get the same error as if I had "Enqueued" the video.
uzzled:Impossible then to encode audio or video (video only doesn't encode too)
I have tried with multi video files, same errors:
Code:
----[NoImage] TemporalSoften: Scenechange not available on RGB32
----[NoImage] (QuickTGMC.avsi, line 357)
----[NoImage] (C:\MSOCache\EnC\test-xvid.avi.avs, line 6)or
Code:
---[NoImage] Exception message
----[NoImage] nnedi2: only YV12, YUY2, and RGB24 input are supported!
----[NoImage] (QuickTGMC.avsi, line 352)
----[NoImage] (C:\MSOCache\EnC\test-xvid.avi.avs, line 6)* meguIVit_0.1.3 or meguIVit_0.1.4, same errors (doesn't work in MeguIV, not a mystery, since AVI is not supported)
* K-Lite Mega Codec Pack 6.4.4 (but same errors with 6.4.0, all options set by default, I haven't made any change)
* V++ 2005+2008+2010, Net.Framework2.0->3.5SP1 have been installed.
* My specs: DualCore 2.5GhZ, 2Gb RAM, Windows SP3 up-to-date.
Pass for the Logs
Code:
-AO@Help-Your source video in in RGB32 format, which isn't supported in some of the QuickTGMC plugins. I've updated the batch files & templates in the original rerip post to get round this. Please download the new batch files/templates and try again. Post any follow ups in that thread.
That's normal. In the new version of meguIV overall video encoding goes through 2 passes/jobs. To quote Rollyco:
Since the output of the first part is lossless, it's bound to be huge. In the first post of this thread, under system requirements it reads that you need 15-25GB free space for temporary files.
Again to quote Rollyco:
I don't know about TIVTC.dll, but if you put the dll in your ''normal'' Avisynth plugins folder it will have no effect, because meguIV and meguIVit use their own. You can access their (at virtual folder C:\meguIV\Avisynth 2.5\plugins\) through a trick (do it at your own risk):
But you probably don't have to - it looks like meguIVit version B works normal for you. Try a full length rip, secure enough disc space for intermediate files and wait. And hopefully after you can inform us that everything worked fine.
I have just tried out meguVIT, previously I have always used the stock MeGUI. Some questions popped up:
Firstly, I'm wondering for meguVIT, under the One-Click encoder, whether it's possible to provide our own .d2v files. Usually when creating my own .d2v files I will cut out advertisements and unnecessary stuff. Currently it is not possible to load .d2v files, but one has to load the .VOB files along with said adverts and stuff.
Second, how do I manually update x264? Mediainfo on the output file shows that the x264 revision is r1538... Which is pretty old considering the latest is 1745 now. I searched for x264.exe in the meguVIT folder, and replaced that with the latest. However upon starting the encoding process the x264 file automatically got replaced with the older one. Also, I'm curious as to why the x264.exe is only 17kb in size... Was it UPX-ed?
Lastly (Not meguVIT specific, but rather ripping in general)
Has anyone encountered videos where the black bars at the side vary in size? This is frustrating since there's no "one crop value to fit all". The worst kind is a video I have where the video varies between letterboxed content (16:9 aspect ratio, with black bars above and below to make it 4:3), and full 4:3 content. I was thinking of using the autocrop filter, but I'm not sure if autocrop varies the crop value according to the size of the black bars. Preview mode seems to show that it doesn't.
Firstly, I'm wondering for meguVIT, under the One-Click encoder, whether it's possible to provide our own .d2v files. Usually when creating my own .d2v files I will cut out advertisements and unnecessary stuff. Currently it is not possible to load .d2v files, but one has to load the .VOB files along with said adverts and stuff.
Second, how do I manually update x264? Mediainfo on the output file shows that the x264 revision is r1538... Which is pretty old considering the latest is 1745 now. I searched for x264.exe in the meguVIT folder, and replaced that with the latest. However upon starting the encoding process the x264 file automatically got replaced with the older one. Also, I'm curious as to why the x264.exe is only 17kb in size... Was it UPX-ed?
Lastly (Not meguVIT specific, but rather ripping in general)
Has anyone encountered videos where the black bars at the side vary in size? This is frustrating since there's no "one crop value to fit all". The worst kind is a video I have where the video varies between letterboxed content (16:9 aspect ratio, with black bars above and below to make it 4:3), and full 4:3 content. I was thinking of using the autocrop filter, but I'm not sure if autocrop varies the crop value according to the size of the black bars. Preview mode seems to show that it doesn't.
The one-click encoder is very limited in what it will accept as input. That's one of the things I've been working on, to allow it to accept avi, mpg, d2v, m2ts etc. But it's tiresome work because the one-click code in MeGui is a hacky mess, so it won't be done soon.
You shouldn't. Rollyco has tweaked the MeGui executable - updating the MeGui core would remove the changes, updating other files will break things. MeguIVit currently only updates plugins so it doesn't affect this behaviour. When I finally get round to releasing the next MeguIVit, it will be with a new MeGui executable and all the latest updates (but getting further updates is disabled on my version for exactly the same reasons).
Yes, I have come across this 4:3 / 16:9 mixed content problem and tried to solve it. I just used trim to do the different crops. Autocrop will not work - it just samples every few hundred frames across the entire vid and chooses the most conservative crop. A clever use of runtime functions in an AviSynth script would probably do it. But the problem lies later on: you now have two aspect ratios in the same vid - I couldn't get MPC-HC or VLC to properly acknowledge an AR change mid-video. I tried changing the SPS values mid-stream, they were either ignored or broke things. Coincidently, the DivX h264 codec definitely does acknowledge AR changes in the bitstream - you need to adjust an advanced setting - but the players still mostly ignore what the decoder is telling them anyway.
That's a pity. I think the alternative is probably to manually trim the .avs file. I find it a waste of time and space encoding the ads as well. :/
Hmmm I'm not sure if you understood me correctly. I want to update the x264 encoder executable, not the MeGUI core file. Is the x264 executable part of MeGUI.exe?
At this point I'm tackling videos where the black bars vary in size across different scenes, but the aspect ratio stays consistent. Like you said trim would probably work, except that it involves eyework scanning through the whole video and applying the correct crop values. At this point I don't even want to think of tackling mixed 16:9/4:3 aspect ratio videos. I'm considering cropping the letterboxed parts, then interpolating to 720x480 with NNEDI3. With the 4:3 aspect ratio parts, pad them into pillarboxed. I have always wondered why would the post production team degrade video quality by applying letterboxing... :evil:
I understood you. My experience of updating only small parts of the MeGui package has been negative. You would hope that you could just update the x264.exe like a new version of a plugin, but it's not quite that simple. The x264 configuration dialog (where you set things like CRF, AVC Level etc) is part of the MeGUI core. The x264 presets also come separately and need to certainly match the core (for the dialog) and preferably x264 (for the command line). At the very least this means you are will not be able to use the latest features of x264 without changing core, and at worst it means you will be sending invalid commands to it. It might work, but it's not a great idea long term...
If having different sizes of black bars means that the AR of the video is consistent, then when you remove them surely the AR won't be consistent any more...? Which may answer your latter question...
Or are you saying that your vid has the inconsistent AR and by removing the bars you will fix it?
I thought you were using MeguIVit? But that log file looks like it's from MeguIV (it uses TempGaussMC rather than QuickTGMC). If you did use MeguIVit then you didn't follow the instructions, probably the bit about selecting a preset.
Although the process works with the initial file (VTS_01_1.VOB) it will merge all the files in the set (i.e. VTS_01_02.VOB, VTS_01_03.VOB, etc). Compare the large output avi and the vob files to see if all the VTS_1_ content is in there. However, it will not append vobs from other titles on the DVD, which means any VTS_02_, VTS_03_ files will need to be ripped seperately.
However, it should have done a second pass to convert the large avi file into a sensibly sized mkv. I don't know why it hasn't. Have you changed any MeguIV settings? If you press the "Queue" tab, are there any jobs marked as "Waiting"...?
Only one word.
:cheererfect!:cheer:
Thanks a lot M. Vitreous.
Your new batch files / templates have done wonders. I tested three videos (in progress) and so far no problems to report. Everything works perfectly.
I will continue my tests and I'll give you my observations.
:cheer
erfect!:cheer:Thanks a lot M. Vitreous.
Your new batch files / templates have done wonders. I tested three videos (in progress) and so far no problems to report. Everything works perfectly.
I will continue my tests and I'll give you my observations.
Hmmm. I think I understand you. However from what I see of your Presets (your presets, not x264's built in presets), you make heavy use of x264's built in presets. For example the profile [Vit] 480p 60fps standard has:
Code:
program --preset slow --crf 20.7 --psy-rd 1.0:0.10 --output "output" "input"I think that as long as we are using x264's preset system, even if x264 might change, the presets can still be use. Of course the settings within the presets themselves might change, but it would not affect the configuration dialog's ability to use the presets...
I apologise if I was unclear. I was referring to two sets of scenerios. The first, illustrated here, is not true pillarboxing, but very small black bars found on some videos like so:
In this scene
A crop value of "crop( 6, 0, -6, 0)" is needed to remove the black bars at the left and right.
For this:
crop( 2, 0, -2, 0) is probably more suitable.
In either case, I will use a Spline36Resize(720,480) after cropping to keep the AR consistent. I could probably use the bigger crop value, but I don't like throwing away those 4 lines, even if they are probably 4 lines of unimportant edges...
This is getting confusing. The point is it's better that your Megui core is consistent with your x264 so the settings you make actually work. A made-up example of what can happen:
- You select "Fast Decode" tuning
- The (out of date) megui core thinks that tuning implies Deblocking=false
- But the up to date x264 thinks it implies Deblocking=true (they've improved deblocking speed)
- So the deblocking checkbox in Megui is very likely to work incorrectly and you may or may not get the deblocking you expected.
I seen real examples of this even when my files are close to the same date (lesser settings, but the same idea). This kind of problem isn't sure to happen, but it illustrates the reasons why you should keep Megui all updated together. In any case, have there been any major improvements in x264 since the version in MeguiIV (lots of minor stuff is all I recall)?
That will ensure AR of the output is consistent, but it will change the AR of the source material. However, I didn't realize you were referring to such tiny borders, in which case the slight AR change in the source will be barely noticable. I had pictured borders 20 wide on one scene and 60 wide on another. Cropping both, then resizing to 720x480 would create major distortion in that case.
One question bothers me. :study:
What the main advantage in using MKV container instead of MP4 knowing that greater compatibility / greater number of devices support MP4 ?uzzled:
Still testing and happy to report ... Nothing to Report :gayprance:
:tea:
My PC runs at full speed and compared with meguIV, I take a nice little boost (on average, +7 fps on 640:480 video (XviD), still not tried 720x480 DVD)
Used Profil: [Vit] 30fps Slower + Light EdgeClean.
Next: [Vit] 60fps Slower + Light EdgeClean with 720x480 DVD
:yahoo:Thank you for the time you spend answering me and all the information that will allow me to progress in this wonderful world of JI RiP Attitude ...:yahoo:
What the main advantage in using MKV container instead of MP4 knowing that greater compatibility / greater number of devices support MP4 ?
uzzled:Still testing and happy to report ... Nothing to Report :gayprance:
:tea:
My PC runs at full speed and compared with meguIV, I take a nice little boost (on average, +7 fps on 640:480 video (XviD), still not tried 720x480 DVD)
Used Profil: [Vit] 30fps Slower + Light EdgeClean.
Next: [Vit] 60fps Slower + Light EdgeClean with 720x480 DVD
:yahoo:Thank you for the time you spend answering me and all the information that will allow me to progress in this wonderful world of JI RiP Attitude ...:yahoo:
Alright, I get what you mean now. Perhaps it would have been better to keep the x264 configuration dialog separate from the MeGUI core... Although with my barely existent C# knowledge I don't even know if that's possible! As for improvements in x264, the x264 team seems to love keeping their changelog as cryptic and technical as possible, thus making it hard for layman to tell how the output might change. I do think that there will be speed and quality improvements (with 10-bit output being the major one in the pipelines) and I like to squeeze as much quality in as possible.
It helps too that the border size changes with different scenes, and not within the same scenes. Still it's annoying that I can't just use one crop value for the whole movie.
I would just like to apologize if I may have offended or irritated you in any way, and I really greatly appreciate you taking the time to answer my questions.
It's not so strange. Everything depends on the encoding profile you've chosen and the complexity of the video. From my point of view,That seems ok, I get more or less, on average, the same figures.
Otherwise, to make sure you do not have a process that diverts your resources. The easiest way is to consult the task manager.
Right click on taskbar and select "Task Manager".
Hope this helps.
Otherwise, to make sure you do not have a process that diverts your resources. The easiest way is to consult the task manager.
Right click on taskbar and select "Task Manager".
Hope this helps.