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

[Blackdance]

A very important question was left unanswered for people like me who doesn't have such powerful CPUs: is encoding speed related in any way to output's quality? My personal answer is NO. Am I wrong? I am encoding at 2 (two) FPS, quality is excellent. Most of the time it is the quality of the input source which turns out to be low, not to talk of audio/video codecs which are not 100% compliant with DVD-Video standards, from there the differences between encodings. MeguIV is so good that these differences shows up. It takes more time to perfectly decode a stream which is far from being perfect...

 

[Vitreous]

is encoding speed related in any way to output's quality?

Given the same settings, a slower computer will produce exactly the same output as a faster one, it just takes longer.

 

[anandneemish]

A very meticulous accountant with a large abacus going through the exact algorithm will produce the exact same quality output. But this will require several hundred years.

As Vitreous said CPU power only affects how much time it takes.

The relation of CPU performance to quality is just a subjective choice. If it takes me 1 hour to produce X quality, while it takes someone else 4 hours to get the same, I may decide to use 4 hrs to get better quality.

Vitreous,
Just to report back: with your tweak on the AVIsynth config, I now get 22+ fps. I don't see a significant degradation in quality, but I am NOT an expert. As you may recall, I got 7+ fps with the default settings. Your tweak got me a 3X improvement !!! This is EPIC. Thanks again.

BTW, if you have time, could you give a plain English treatment on the diff between your setting and Rollyco's default settings? Only if you have time.

 

[Vitreous]

I now get 22+ fps. I don't see a significant degradation in quality

22fps, nice! I briefly experimented with those speed ups in anticipation of ripping blu-rays at full resolution, current settings will be too slow. Hadn't tried them properly yet, so it's good to hear that they can be so fast. Technical rippers like Rollyco and I tend to be pedantic about quality. I've long suspected that other people don't much notice the effect of a number of the slower settings.

a plain English treatment on the diff between your setting and Rollyco's default settings

I tweak my settings for every rip, I make a test rip of a few 1000 frames and adjust accordingly. But in summary:
- I use the 60fps tweak as described on my tips post
- I increase the CRF from 19.5 to 20.7 to suit 60fps (also on the tips). Sometimes a higher value if a vid contains complex scenes (typically outdoor or water). This tweak keeps filesize down
- My TGMC line is tailored for more stability and sharpness, it currently starts from this point:

TempGaussMC_beta2mod( 2,2,1, EdiMode="nnedi2", Sharpness=1.35, Sovs=1, SVthin=0.0 )

- That's a modified version of TGMC (beta2mod) - I've been updating it to improve quality of stable detail
- I then run my own post-processing script that cleans up edge noise and removes the halos from DV footage - it also has a bunch of settings that I sometimes tweak too
- The extra processing and tweaks mean 2.5x the processing time over MeguIV, so I wouldn't recommend them in general. I rip on a second machine, so I don't really mind.

 

[anandneemish]

Hi. Me again. I've encountered a couple of strange problems. Sorry in advance for the long post.

1. I seem to run into intermittent issues with Mencoder. The only way I am alerted that there is a problem is that the encoding job just quits, and my Windows 7 Action Center sends up an alert flag and tells me that an update for Mencoder/Mplayer is available.

However, on the next encode of the SAME video with the SAME settings, everything goes well, and the encode completes.

As for settings, I have run into this problem with Rollyco's HQ settings. Approximately 1 time out of 5 tries. I seem to run into this problem more with Vitreous' settings for a fast encode. meguIV quits 4 out of 5 tries.

So I am really curious as to what is going on.

2. Another problem I've run into twice is that for a very long encode (4 hour movie), the latter half of the encoded movie seems to be stuck. In other words, I can randomly access any part of the first half/first 2/3 of the movie. But for the last part of the movie, if I randomly access any part, the movie just hangs. This feels like the index got munged.

My set up is like this:

Air cooled, overclocked Q9550 (cores running at 63 deg) (possible problem here?).

Windows 7 64b Ultimate

Rollyco's meguIV 1.0.1.1
Rollyco's default AVISynth settings or Vitreous' fast encode settings

I checked the box to maintain the input resolution

Thanks for any feedback or clues as to what I may be encountering.

 

[Vitreous]

Air cooled, overclocked Q9550 (cores running at 63 deg)

System stability is an issue with long encodes, and these problems seem to be stability related. I don't know off the top of my head whether that's hot for a Q9550, but I suspect it is. Cut down the OC, or get some better cooling (maybe just try taking the side of the case off).

 

[isityours]

i also have not been able to rip consistently with meguIV. if i rip 3 vids over 3 nights then the successs rate is more likely to be higher than if i make 1 rip a week. usually the problem is given as mencoder (stopped working). this can be at the start, middle or end of processing. ive never ripped over 90mins so i cant say about that but rips that are successful are usually good. (i mean meguIV doesnt make bad rips). overclocking caused fluctuation during processing which almost always resulted in failure. i just let the CPU cycle up automatically and i get a steady 95-98% usage for the duration of the rip.
i wonder if these stability issues could be relieved somewhat by creating an installable version?

 

[guy]

i wonder if these stability issues could be relieved somewhat by creating an installable version?

Possibly, but then you'll probably also have to deal with a bunch of other things that suddenly break because they're not pre-configured correctly.

Remember, what's unique about meguIV is that it's already all set up to use TGMC. You can always just install meGUI separately and install the necessary components to run the same TGMC de-interlacing, but you will have to worry about all the settings for every other component.

 

[Vitreous]

You can always just install meGUI separately and install the necessary components to run the same TGMC de-interlacing, but you will have to worry about all the settings for every other component.

Yes, I have to do this and it's easy to forget things. And you can still get crash problems (see below).

Something I should have mentioned in my earlier post is that the avisynth multithreading library has known bugs. A new integrated version has been due for months if not years, but it never turns up. This library is used with TGMC (otherwise rips would be much, much slower - it won't use all your cores effectively). Now I do most of my rips on a machine that isn't othewise used. It's very cool and stable and never crashes during a rip.... unless I do use the machine at the same time. In particular if I do anything that hits the harddrive significantly, then I get occasional mencoder crashes. I'm certain the multithreading library bugs are at fault here (despite the error mentioning mencoder).

So to minimize crashes, run cool, leave your machine alone, and maybe reduce background tasks too.

 

[anandneemish]

System stability is an issue with long encodes, and these problems seem to be stability related. I don't know off the top of my head whether that's hot for a Q9550, but I suspect it is. Cut down the OC, or get some better cooling (maybe just try taking the side of the case off).

Interestingly, on this machine while I am encoding at LOW priority with all cores pegged at 99%, I can still play most videos, run Photoshop CS5, run P2P and surf. No BSODs or perceived slowdowns. god bless multi-cores and multi-threaded OSes!!!

Currently, using Rollyco's stock settings, the rig has been encoding at 100% for the last 14 hours with 3 more hours to go. It hasn't choked yet (fingers crossed). I am really loathe to back off the the clock to stock speeds. I could have great grandchildren by the time I am done with my encodes LOL!!

These long encode sessions is EXACTLY why I would love to get Vitreous' settings working consistently and stably because the speed up is so tremendous.

i also have not been able to rip consistently with meguIV.

Thanks. Glad to know I am not the only one.

ive never ripped over 90mins so i cant say about that but rips that are successful are usually good. (i mean meguIV doesnt make bad rips).

I experienced bad encodes of long movies a couple of times. The indexing of the latter half of the encode seems to be messed up. I cannot randomly access that part of the movie. The first part works flawlessly.

As I've stated before, this is intermittent. I've also had successful encodes of the same movies.

Just to make sure everyone understands: I am NOT complaining. The work the community has done thus far is AWESOME and I am grateful to be the beneficiary.

 

[Vitreous]

Interestingly, on this machine while I am encoding at LOW priority with all cores pegged at 99%, I can still play most videos, run Photoshop CS5, run P2P and surf.

That's because when a process runs at a lower priority, it defers to other running applications. You'll be able to run anything else you like, play a game even - it will just slow down the rip (and probably increase the chance of a crash).

 

[anandneemish]

That's because when a process runs at a lower priority, it defers to other running applications. You'll be able to run anything else you like, play a game even - it will just slow down the rip (and probably increase the chance of a crash).

No crash. But some more strangeness.

So 16+ hours later, the encode of a 4 hour DVD is completed. But the last 3 minutes were lost. Same problem as before. Scroll past the point where the frames are lost and the movie hangs. Scroll before the point and the movie plays.

Using the trim function, I encoded the last 3 minutes. This was quite quick, even at the HQ settings. When finished, the last 3 minutes was 283MB which seems a bit huge for 3 minutes.

However, Windows reports the completed file to be the same length of time as the complete movie: 4:05:45. I played the movie with MPC. Same thing. MPC reports the clip to be 4:05:45 in length.

When playing the this trimmed movie, the target 3 minutes are there in the beginning of the playback. But past the point at which the movie ends, there's an additional 4 hours of nothingness.

So the upshot is that I think there may be an indexing bug or a frame calculation error.

BTW, I was not using the PC at the time the encode of the last bit was being done. So I don't think context switching caused the problem.

 

[Vitreous]

However, Windows reports the completed file to be the same length of time as the complete movie: 4:05:45. I played the movie with MPC. Same thing. MPC reports the clip to be 4:05:45 in length.

Most likely MeguIV will have muxed the full 4 hours of sound together with the couple of minutes of trimmed video. There are a couple of ways to correctly rip in chunks like this - I do it a lot. However, they are very manual processes and would require extensive detailed instructions. I started to type some out, but it's just too complicated to explain easily...

 

[Rollyco]

I would suspect an indexing problem, I've seen it once or twice before. Here's what I would try:

• Extract .ISO or re-rip DVD Video Disc to your hard drive.
  
• Run Vobblanker, and set up like this:
  [fullattach]307584[/fullattach]
  
• Load your VIDEO_TS.IFO and make sure the video titleset(s) your are going to encode are set to "Process":
  [fullattach]307583[/fullattach]
  
• Click the "PROCESS!!" button and when it's done, re-encode that last 3 minutes to see if the problem is resolved. Make sure you trim correctly as Vitreous pointed out above.

If that's still no good, the DVD was probably ripped incorrectly and needs different treatment (in a nutshell: re-rip the DVD Video Disc if you have it, or remultiplex the titleset if you only have the .ISO).

 

[anandneemish]

Thanks guys for your suggestions. I no longer have the DVD so I won't be able to do what you described.

What I ended up doing while I had access to the source was: I encoded the last 5 minutes of the DVD. This resulted in a large file with the video fragment along with 4 hours of blank space. I then cut the video after the end credits. This newly cropped file is the correct size (50-ish MB).

At some future time, I will cut the main file to remove the corrupted ending and join/append the last 5 minutes. I currently cannot cut the main file because of the possible corrupted index problem. But I'll figure it out.

What lossless splitter/joiner would you recommend? I like Boilsoft, but am wondering if there's anything better out there.

BTW, another successful run last night with another 4 hour DVD with Vitreous' fast settings.

At least on my rig, meGUI seems to be a roll of the dice. Very curious.

One more odd data point. The first 4hr DVD encoded with Rollyco's settings came out to roughly 2.7GB. This second one encoded Vitreous' settings came out to 3.6GB. I know that the content is different. But who'd thunk there would be that big a difference in file size.

 

[Rollyco]

In my opinion the best way to split and concatenate clips is with MKVMerge.

To concatenate in MKVMerge, go to the "Input" tab, click "add" button and choose your first video clip. Then click "append" to add each subsequent clip.

To split in MKVMerge, go to the "Global" tab, put a checkmark on "Enable splitting...", and set the radio button to "...after timecodes". Paste your timecodes separated by commas. You can collect timecodes easily with MPC HomeCinema: press Ctrl-G at any time to get the current timecode.

 

[Vitreous]

The first 4hr DVD encoded with Rollyco's settings came out to roughly 2.7GB. This second one encoded Vitreous' settings came out to 3.6GB.

Likely that the video with my high speed settings is noisier and sharper. Noise and sharpness do not compress well. It's noisier because some of the settings switched off are blurring and degrain steps within TGMC. It's sharper because MeguIV uses an additional setting on the TGMC line: Sharpness=0.4, which softens the image. I've updated my tips post to include this setting to make it more directly comparable to MeguIV.

In my opinion the best way to split and concatenate clips is with MKVMerge.

Definitely, MKVmerge is the tool of choice here.

At least on my rig, meGUI seems to be a roll of the dice. Very curious.

I use MeGUI rather than MeguIV. I wonder if that has introduced more stability for me? (Edited to avoid problems)

 

[Rollyco]

I update my MeGUI regularly (Options>>Update). I wonder if that has introduced more stability for me?

As the first post of this thread says, that is not safe. Do NOT update MeguIV core, data, or libs. MeguIV is a custom build of MeGUI and attempting to update core will break two features of it (perfect aspect ratios and perfect chapter timecodes).

It might be safe to update some of the external 3rd-party components such as x264, dgindex, mkvmerge, mp4box, etc.

 

[anandneemish]

In my opinion the best way to split and concatenate clips is with MKVMerge.

Cool! Thanks.

 

[Vitreous]

As the first post of this thread says, that is not safe

Ah, yes. I did say MeGUI, but most people don't realize the distinction. Post edited.

perfect aspect ratios

The aspect ratios in MeGUI are not wrong, they just default to DV rather than DVD