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

[no__One]

:attention: A really useful info ? :attention:

I took a quick glance at meguIVit_1.0.0_beta1 especially QuickTGMC 3.32.

What does this really change: "Changed defaults for TR2 When using source-match" compared to QuickTGMC 3.31.

I can not physically test this new version (to my great regret) because I'm out of town without access to Lightning war PC ... :notagain:

By cons, I can look back on your plugin pack which for me was a blessing ...

QuickTGMC 32-bit Plugins http://www.akiba-online.com/forum/showpost.php?p=798643&postcount=222


Before updating to QuickTGMC 32-bit Plugins:
- 60% of Rips crashed if I did not use the pre-rendering.
- 20% of theses Rips still crashed.

After updating QuickTGMC 32-bit Plugins:
- All Pre-rendering Rips crashed without exception.
- By cons, all Rips until today (about 10) were done without a hitch if the pre-rendering is not used.

Strange, isn't it?uzzled:
Regards.

 

[Vitreous]

isityours: Thanks. This is the same error someone had earlier with my rebuilt MVTools2.dll. It's as though the dll is not there. It's very puzzling and I simply cannot reproduce it on any machine nor a VM.

Edit: Actually, that's exactly the error you get if the mvtool2.dll is not there. So I'm wondering if it isn't making it into the MeguIV runtime environment for some reason... Could you check this:
- Extract the new MeguIVit 1.0 sandbox and run MeguIV
- In the menus choose File>>Open
- Change the "Files of Type" box at the bottom to "All Files"
- Browse to "C:\meguIV\Avisynth2.5\plugins"
- Is there a mvtools2.dll there? And if so what is its version number (should tell you if you hover your mouse over it, alternatively look at its properties)?

As a temporary workaround go into this location in the new MeguIVit sandbox and delete mvtools2.dll, then run MeguIV:

Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSDRIVE@\meguIV\Avisynth 2.5\plugins

It would be most helpful if you could do even a small test rip, because I'm keen to know any other major problems...

____

IceManZ: The faster presets use a default TR2=0 (no temporal smoothing at end of process). However, source-match benefits from a minor temporal smooth. So source-match now has a minimum default TR2 of 1. Can be overridden. Only affects presets "Fast" and quicker.

Regarding plugins. That's one thing I have attempted to fix in the new MeguIVit, I have patched and rebuilt all the main plugins. However, you can see from isityour's problem that this is not yet correct either. :sigh:
You also might want to look at your threading use.

 

[guy]

Just wondering if the Trim function in MeguIVit is frame-based; if so, aren't there potential issues with different FPS encodes? (eg: trim numbers should be doubled for 60fps encodes)

For most DVD/BD encodes I imagine this won't really be an issue, since (most) publishers are good at separating main and non-main content in chapters or separate .m2ts files. However, I regularly encode HDTV rips (raw broadcasts in MPEG2/TS format), which requires cuts at the beginning, end, and middle of the streams (to remove commercial breaks). Not being content with dealing with extra TS editing programs, I now just use MPC-HC to scrub through the .ts files, and AutoHotKey to grab (and double, for 60fps encodes) frame numbers and pass them directly into Megui for trimming.

Not that MeguIVit needs to be adapted to be TV-ripping friendly. I'm actually not aware of anyone else who rips Japanese TV shows using QTGMC.

 

[Rollyco]

I now just use MPC-HC to scrub through the .ts files, and AutoHotKey to grab (and double, for 60fps encodes) frame numbers and pass them directly into Megui for trimming.

Can you share that .AHK with me? I want to create something similar (pass timecodes from MPC-HC to mkvmerge), and your code could give me a nice headstart.

 

[Vitreous]

Just wondering if the Trim function in MeguIVit is frame-based; if so, aren't there potential issues with different FPS encodes? (eg: trim numbers should be doubled for 60fps encodes)

The frame numbers used are source-based so it doesn't matter about the output frame rate. In the tooltips I suggest to drop vids into the MeGUI file indexer as that will handle split VOBs properly. But for other sources, frame numbers from the source in MPC will be fine (if a tiny bit inaccurate).

I would like to add a trimming GUI - all the code I've added supports collections of trims. But it's a matter of getting the MeGUI preview code hooked up....

On a different, but slightly related point: One-click supports muxing the source audio directly into the output for certain sources, e.g. no need to re-encode the AC3 found on most DVDs. I added support for trimming in that case as I like the idea of no audio re-encode. And looking at the AAC file sizes, there isn't much compression gain compared to the final output size. Is there a reason to re-encode to AAC/mp3...?

 

[no__One]

In my case, I use the AC3 conversion -> AAC/MP3 more from habit than for any other reason.

Although, I know little equipment (TV, set-top box, IPod like,...) accepting MKV (H.264 + AC3) natively. At least, my equipment does not support it.:notagain:

While MKV (H.264 + AAC/MP3), Everything Happens In The Best World.
Regards.

 

[Vitreous]

Although, I know little equipment (TV, set-top box, IPod like,...) accepting MKV (H.264 + AC3) natively. At least, my equipment does not support it.

While MKV (H.264 + AAC/MP3), Everything Happens In The Best World.

Figured it might be compatibility. I always playback on PC so I never notice such issues. Guess I won't change my ripping style then...

 

[youmeus]

Guys, when using the argument trim it encodes whatever frames you put there. But it also encodes the entire audio track of the clip in question and dumps it in the beginning when muxing. Is it possible to easily encode only the audio corresponding to the frames selected in trim?
I have some AVI files I'd like to reencode but haven't been able to find a useful utility to trim DivX and generic MPEG-4 content in AVI files... so I thought the trim could be used as an alternative if only the audio is trimmed too.uzzled:

 

[Vitreous]

OK, here's the second beta of MeguIVit 1.0. Read the post for the first beta if you haven't already.

[EDIT] There's a new version, go to this post for the latest working beta.

Mostly internal fixes and tweaks in this one. Some notables:
- x264 profile is automatically updated to match input file, requested resolution and output fps. One less setting to worry about. The profile names have been tweaked for this, it chooses the appropriate "Default" profile automatically. You can manually override the selection - there are some higher quality and fast-decode versions in there.
- Proper support for "Target Filesize" on the first One-Click screen, which allows you to make a rip of a given size. This now works properly with all settings, including trimming. It affects quality of course - in what way depends on the size you choose. I know Akiva for one uses this setting.
- As noted earlier, the "Keep original track" setting is now supported properly for audio, including trimming. So you can keep the AC3 on DVD rips if you wish.

This version uses an older mvtools2.dll that solves isityours problem above. I am still interested if anyone can report success with beta1 because it uses a patched mvtools2.dll that should be more stable.

Download MeguIVit 1.0 beta2a

Installation:
- Download MeguIV from the first post in this thread
- [IMPORTANT] Delete any already existing "Sandbox" folder in the same folder as MeguIV
- Extract the MeguIVit zip file, which creates a new "Sandbox" folder
- Run MeguIV (which is now transformed into MeguIVit)

Still to do:
- Allow choice of both horizontal and vertical resolution of output. MeGUI's method of selecting horizontal only is not very useful
- MeguIVit presets - save your favorite processing settings


____

youmeus: Are you talking about trims in the new MeguIVit I have been posting or something else? [Edit] Try the beta2a version above, it may fix your problem.

 

[no__One]

My solution may sound stupid but it has the merit of meeting my requirements (at least, in part).
I use mkvtoolnix. Certainly, your files Avi, MP4 or any video file will be converted into MKV but you can do a trim (Audio / Video) very easily.
I hope that you will achieve your goal more easily.
Regards.

 

[guy]

The frame numbers used are source-based so it doesn't matter about the output frame rate. [...] I would like to add a trimming GUI - all the code I've added supports collections of trims. But it's a matter of getting the MeGUI preview code hooked up....

Good to know. Trimming GUI would certainly be nice, but I personally don't need it right away as my AHK scripts handle the task pretty well. (Megui's native AVS trimming GUI is frame-accurate, and passing in frame numbers from MPC usually gets it within 25 frames of the in- and out- points, which makes setting trim points pretty easy.)

One-click supports muxing the source audio directly into the output for certain sources, e.g. no need to re-encode the AC3 found on most DVDs. [...] Is there a reason to re-encode to AAC/mp3...?

Also if people need to downmux multi-channel to stereo for compatability reasons.

The other reason I can think of (coming from encoding raw HDTV) is if there is a significant sync delay between audio and video streams; I prefer allowing the audio encoder to trim or insert silence to the beginning of the audio track in order to zero the sync, rather than specifying audio delay in the container (since not all players will honor audio sync delay flag). But again I doubt it's an issue for typical DVD/BD encodes.

 

[isityours]

thanks vit.

re:1.0 beta1

wasnt sure what: Browse to "C:\meguIV\Avisynth2.5\plugins" meant (i dont see that folder on my computer) but opening
Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSDRIVE@\meguIV\Avisynth 2.5\plugins
gave me a mvtools2.dll version of 2.5.11.2. removing that and making a test rip was successful but MPC-HC showed the vid length as 97 mins and the MKV file came out at 96MB (maybe the audio?).

re: 1.0 beta2a

successful out of the box (test rip attached).

re: 1.0 beta2b

gave me the same error message as 1.0 beta1 but the error was on line 27, not 23, this time.

will continue to play with 1.0 beta2a, see if i can get it to crash etc.

 

[Vitreous]

wasnt sure what: Browse to "C:\meguIV\Avisynth2.5\plugins" meant (i dont see that folder on my computer)

You have to browse from within MeguIVit, because it runs in a virtual machine [i.e. it uses folders that are not on your actual machine]. So use "File>>Open" from within MeguIVit itself, then browse (change to view all files). You will find that C:\meguIV is definitely there. I am still very interested about the version of mvtools2 that appears within this "virtual" folder in my original beta. Because I've patched a dozen plugins in there and only mvtools is giving these strange problems.

Good to see that beta2a is working. You're probably right about the audio not being trimmed in the first version - stretching out the rip. I've been adding lots of little details and forget which made the beta and which didn't. May explain youmeus' question...

The next thing you might want to try is tweaking the thread counts for speed. Depending on how your CPU is loaded you may get a couple more threads out of it. Tweaking the secondary threads can help too - sometimes more goes faster, sometimes taking it down (even to 1) can allow an extra main thread. In any case there may be scope for faster rips.

 

[isityours]

You have to browse from within MeguIVit, because it runs in a virtual machine [i.e. it uses folders that are not on your actual machine]. So use "File>>Open" from within MeguIVit itself, then browse (change to view all files). You will find that C:\meguIV is definitely there.

that was how i intended to do it when i tried the first time but it didnt show up (that i noticed). trying it again now, beta2a shows the version as 2.5.11.2 but beta1 shows it as 2.5.10.0, as does beta2b.

The next thing you might want to try is tweaking the thread counts for speed. Depending on how your CPU is loaded you may get a couple more threads out of it. Tweaking the secondary threads can help too - sometimes more goes faster, sometimes taking it down (even to 1) can allow an extra main thread. In any case there may be scope for faster rips.

forgot to mention that beta2a is giving me between 90-95% usage (on the test rips ive done) which is just about right for me...not too stressful, across all 8 cores (4x2). i will play around with them though and give you feedback if possible.

 

[youmeus]

youmeus: Are you talking about trims in the new MeguIVit I have been posting or something else? [Edit] Try the beta2a version above, it may fix your problem.

Sorry I wasn't clear. Yes, it is in relation to MeguIVit v1.0.1.1.
If I, for example, want to encode just a selective part of a .VOB file and trim to one of your preset scripts like so:

SetMTMode(3)
<input>
SetMTMode(2)
QuickTGMC( Preset="Slower" )
<crop>
<resize>
EdgeClean( Radius=2.5 )
Distributor()
trim(10000,10500)

It starts by encoding the entire audio track in the file and after the mux comes out with that audio dumped in the beginning of the container.

 

[Vitreous]

... beta2a shows the version as 2.5.11.2 but beta1 shows it as 2.5.10.0, as does beta2b...

That's very strange uzzled:
Beta2a doesn't have that version (2.5.11.2) in the zip file, it uses an older one (2.5.10.1) - so how did that new version get in there? Did you delete the sandbox between tests?

Whereas beta1 and beta2b do have 2.5.11.2 in the zip file but the version you're seeing, 2.5.10.0 is from the original MeguIV. Which looks like a packaging problem. It looks like this particular file (mvtools2.dll) isn't getting copied into the runtime environment (until you used a different sandbox...??).

____

Sorry I wasn't clear. Yes, it is in relation to MeguIVit v1.0.1.1.

MeguIVit has not reached that version number yet. By looking at your script I think you are using One-Click in MeguIVit 0.2.1.

Audio processing in One-Click does not use the Avisynth script so script edits don't affect audio. To trim audio you have a few choices:
- Update to MeguIVit 1.0 beta2a in this post and read the instructions in this post. MeguIVit 1.0 provides a simple trim option that works with the audio.
- Process the audio manually in MeGUI (make a cut file with "Tools>>AVS Cutter", then use "Tools>>Audio Cutter"), then do the final mux manually.
- Rip the entire vid and trim the resultant MKV in MKVMerge.

I would suggest the first option unless you need multiple trims.

 

[no__One]

Mr Vitreous,

A little request / question:

For the moment it is impossible to encode directly from ISO. Otherwise we lose the functionality of the chapters.
Indeed, meguIVit necessarily want to extract chapter informations directly where the VOBs are stored.:notagain:
Does it seem you possible to implement a redirection of folders and save this file where the encoding takes place?? uzzled:

This would avoid for those (like me) who want to keep intact DVDISOs for Re-Seed of having to keep ISO + VOB files extracted for encoding purpos.

Regards.

 

[Vitreous]

IceManZ,

I don't really understand your post. Are you saying that the new MeguIVit has broken chapter functionality. Or is this a request to solve a problem that you have always had?

The chapters are stored in the IFO, which is stored with the VOBs. What are you actually suggesting?
Edit: After reading your edit - are you asking for encoding directly from the ISO file itself to avoid having to extract the ISO contents?

 

[isityours]

That's very strange uzzled:
Beta2a doesn't have that version (2.5.11.2) in the zip file, it uses an older one (2.5.10.1)

just before i create more confusion, i think i made a mistake when writing that info. just now i deleted the folders and their respective sandboxes and extracted them afresh to confirm. the results were:

beta1 - 2.5.11.2

beta2a - 2.5.10.1

beta2b - 2.5.11.2

i was being rushed out the door when i wrote that but it was a careless mistake in any case. apologies.

 

[isityours]

Mr Vitreous,

A little request / question:

For the moment it is impossible to encode directly from ISO. Otherwise we lose the functionality of the chapters.
Indeed, meguIVit necessarily want to extract chapter informations directly where the VOBs are stored.:notagain:
Does it seem you possible to implement a redirection of folders and save this file where the encoding takes place?? uzzled:

This would avoid for those (like me) who want to keep intact DVDISOs for Re-Seed of having to keep ISO + VOB files extracted for encoding purpos.

Regards.

the original meguIV never had the ability to rip from (physical) DVD or ISO as far as i know. when i prepare DVDs for ripping i use
DVD disc >> ISO (backup) >> right-click drag on ISO file to harddisc i use for ripping and use 7zip to "Extract to...". this leaves the ISO intact and gives me VOB files inside a new folder. i then rip and delete everything together when finished. i dont understand the need to "destroy" an ISO file.