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

Last time I checked it was impossible to get proper non-ITU aspect ratios in the MeGUI One-Click encoder without modifying the source code.
 
Rollyco said:
Last time I checked it was impossible to get proper non-ITU aspect ratios in the MeGUI One-Click encoder without modifying the source code.
Click to expand...
You can set the AR in the One-click advanced settings. Just did a tiny test and it seemed to work. Autodetect defaults to ITU formats though - to get non-ITU, you have to make the correct selection yourself

But it does make me think: idol videos are shot on DV, then encoded to DVD. If the source has been at 720x480 the entire time, doesn't that mean the ITU aspect ratios are strictly more accurate as we're still basically watching DV footage? Was watching that Tachibana sisters video in MPC. Using the numpad 4 and 6 to scale the AR, the girls look a little more sensibly proportioned at 1.36 than 1.33...

Although I still like the exact 16:9 and 4:3 ratios as they're nicer for fullscreen.

Edit: Just took a snap of a scene with a basketball from a Ran Hazuki vid and scaled to standard 16:9 and ITU 16:9. Measured the ball aspect in pixels - should be 1 (it's a sphere!). Correct in standard 16:9, stretched in ITU. Tells us that Imouto are encoding their DVDs with correct PAR (though others might not be).
 
I don't I've ever seen an ITU idol DVD, and I've been paying close attention to the issue for a year or so.

I believe that 1.36 AR sometimes looking more natural in your Tachibana sisters video is an optical illusion, perhaps because of their unique facial bone structures. In many sections of the video 1.36 just feels squashed to me.
 
Aren't we also assuming that the cameras used for the videos have the same standard focal length lenses (field of view)? Because any video shot using a particularly short focal length (where a wider field of view is compressed into the same recording sensor) or a fisheye adapter will look distorted, since the aspect ratio is corrected for the container, not for the lens.
 
Hi-speed TGMC Substitute

Updated version of QuickTGMC now available

Posting this here mainly for guy and his Blu-Ray ripping adventure (can't PM him). Maybe someone else will find it useful. This is a very fast substitute for TGMC. In its normal mode it can do a 60fps DVD rip at more than half realtime speed, in its hi-speed mode it can rip faster than realtime. Depends on your machine of course. Obviously quality suffers, but not as much as you might expect. I'm not posting detailed instructions, this is those who know how to use plugins in MeguIV / MeGUI, or who can work it out for themselves.

If you want to use the hi-speed mode then you need to add these plugins to your plugins folder:
- TDeInt plugin
- Yadif plugin (bottom of page)
You also need to update a path in the script where indicated.

"QuickTGMC" script
[HIDE]
Save as QuickTGMC.avsi in plugins folder
Code: 
#------------------------------------------------------------------#
#                                                                  #
#               QuickTGMC 1.0, by Vitreous, 2010                   #
#                                                                  #
# Deinterlacer using motion-compensated temporal gaussian blurring #
# Substitute for TGMC designed for speed.                          #
#                                                                  #
#------------------------------------------------------------------#
#
# Version History:
# 	v1.0:  Released

# Requires (first three are needed for TGMC already):
#	MVTools
#	RemoveGrain
#	MaskTools V2
#	Choice of: NNEDI2 or TDeInt+Yadif

# Sharpness     (0.0 ...)     : How much to resharpen the temporally gaussian blurred clip
# EdiMode       (0,1)         : Mode used for interpolation, 0 = NNEDI2, 1 = combined TDeInt/Yadif
# Blocksize     (4,8,16,32)   : Block size for motion compensation
# Overlap       (< Blocksize) : How much to overlap blocks for motion compensation
# SubPel        (1,2,4)       : Sub-pixel accuracy (1 = 1 pixel, 2 = 1/2 pixel, 4 = 1/4 pixel)

# To use EdiMode=1 (TDeInt/Yadif) you must update LoadCPlugin line below to point to your plugin path

function QuickTGMC( clip Input, float "Sharpness", int "EdiMode", int "BlockSize", int "Overlap", int "SubPel" )
{
	Sharpness = default( Sharpness, 0.5           )
	EdiMode   = default( EdiMode,   0             )
	BlockSize = default( BlockSize, 32            )
	Overlap   = default( Overlap,   Blocksize / 4 )
	SubPel    = default( SubPel,    2             )

	_lambda = (100*BlockSize*BlockSize)/(8*8)
	_lSAD = 400
	_pNew = 25

	#**** UPDATE THIS PATH TO SUIT YOUR MACHINE IF USING EdiMode=1****#
	LoadCPlugin( "C:\Program Files\AviSynth 2.5\plugins\yadif.dll" )

	dbob = Input.bob( 0, 0.5 )
	edi = (EdiMode == 0) ? Input.nnedi2(-2) : merge( Input.Yadif(1), Input.TDeInt(1) )

	srchClip = dbob.temporalsoften( 1, 255, 255, 28, 2 ).merge( dbob, 0.25 )
	srchSuper = srchClip.MSuper( pel=SubPel, sharp=2 )
	bVec = srchSuper.MAnalyse( isb=true,  blksize=BlockSize, overlap=Overlap, truemotion=false, global=true, lambda=_lambda, lsad=_lSAD, pnew=_pNew )
	fVec = srchSuper.MAnalyse( isb=false, blksize=BlockSize, overlap=Overlap, truemotion=false, global=true, lambda=_lambda, lsad=_lSAD, pnew=_pNew )

	ediSuper = edi.MSuper( pel=SubPel, sharp=2, levels=1 )
	mdegrain = edi.MDegrain1( ediSuper, bvec, fvec, thSAD=5*8*8, thSCD1=180, thSCD2=98 )

	tgmc = mdegrain.merge( edi, 0.25 )
	return tgmc.mt_lutxy( tgmc.removegrain(11),"x x y - "+ string(sharpness) + " * +", U=3,V=3 )
}
[/HIDE]

Usage:
[HIDE]
For basic usage simply replace TempGaussMC_beta2 line in your Avisynth script with:
Code: 
QuickTGMC()
This will give decent quality, probably sufficient for many people. It suffers on scenes of motion where some distortion or bluriness can occur, but often only noticable when the movie is paused.
______

You can alter the sharpness of the output:
Code: 
QuickTGMC(Sharpness=0.3)
Default sharpness is 0.5, which is a bit sharper than MeguIV, and a bit less sharp than my rips.
______

For very high speed rips:
Code: 
QuickTGMC(EdiMode=1)
This will use a combination of Yadif and TDeInt rather than NNEDI2 for interpolation. This will leave some minor interlacing artefacts. It's especially suited to Blu-Ray as the huge resolution requires speed, but is less sensitive to interlacing artefacts anyway.
[/HIDE]
 
Thanks, will give it a go later.

You can PM me if you add me as a friend :evillaugh:

Also check the Blu-ray thread in the main JI section for an M2TS to play with.
 
QuickTGMC seems to be running well. I get about a 56% speed increase, which should cut the processing time (to HFYU) to about 12 hours on my computer.

I'm just going to go straight for 1280x720p and not bother with 1080p. As it is, the HFYU will come out to 80GB anyway.

(Besides, if you really need 1080, you can always support Tomoe and get a copy of her blu-ray!)
 
guy said:
I'm just going to go straight for 1280x720p and not bother with 1080p
Click to expand...
Fair choice, the difference between 1080 and 720 is there - but it's really not all that much. Make sure you use the double rescaling trick from my other post, it's a big speedup with no ill effects at all.

Edit:
guy said:
which should cut the processing time (to HFYU) to about 12 hours on my computer.
Click to expand...
Ouch, I just realized that you mean first pass only. Well worth it for the first JI Blu-Ray rip + Tomoe, but this is going to be a record! Go for it!
 
Graphics

Hello, trying my first encode. Can anyone tell me how I can make that bar of graphics with the information about the specs of the encode? They look really good and always follow the DVD cover art in the HQ video posts. Thanks! (And if we can get this info added to the first post of this thread, I think it'd be really helpful for newbie encoders!)
 
snowxue said:
Can anyone tell me how I can make that bar of graphics with the information about the specs of the encode? They look really good and always follow the DVD cover art in the HQ video posts.
Click to expand...
They're in the full list of emoticons. They're pretty easy to use, like such:
Code: 
[noparse]:mp4: :h264: :aac:[/noparse]
Which would come out as:
:mp4: :h264: :aac:
 
Ok,

I like the people who ripping this videos, making the convertion to Matroska. It's a high definition format, and don't weight than ISO image. People hang up a ISO image, but is not good idea.

Thank you!
 
More strangeness with meguIV

Hi. Me again.

There was a period when everything was working well. No mencoder problems as previously reported. I was able to transcode successfully with Rollyco's default settings and Vitreous' fast encode settings.

Life was good.

Just recently, on one transcode, the FPS processed number started dropping slowly, and the time remaining started to increase (instead of decreasing). What was strange was the CPU usage had dropped to approx 25% across all four CPUs instead of being pegged.

On the disk which I specified to be the scratch pad, I ran into CRC errors when copying another file. So I figured that the disk was starting to go wonky. I took it offline just to be safe until I can get another empty disk to offload the data.

I switched the temp drive to another disk with enough space. I completed one transcode with no problems.

Then suddenly, I ran into the same problem again.

The transcode would start normally. And soon all CPUS would be at near 100% usage. But a few hours later, the usage would all drop to about 25% and the remaining time to completion would steadily grow.

Has anyone else seen this before?

Thanks.
 
Good point guys.

I have not yet experienced CRC errors with another drive. The drive that had a file stuck during a file move ... I spun it up on an external USB adapter. Darn file move and copied without problem.

However, I think my days of OCing the system may have come to a roost.

With meguIV stressing out everything for long periods at a time, even with superior ariflow, I may have cooked parts of the memory. I will definitely give memtest a run. Just to be safe.

Thanks!
 
Passing Memtest isn't a guarantee that your memory is stable, but failing is certainly an indication that it's not :)
 
Agreed. Successful memtests don't guarantee anything. A better gauge would be to run through a battery of stress tests such as when I first OC'ed this rig.

Anyhow, this machine ran through a single pass of Memtest which resulted in no errors. I know I should have run more passes, but since I am impatient, I decided to try the two failed transcodes again.

Guess what. Both ran perfectly.

Huh?

At this point, my only guess is that the two failed transcodes happened because the machine had been up for a long time [I keep this machine on all the time] and lord knows what was in main memory. To run memtest, I had to re-boot several times. I think this may have been the solution to making meguIV run smoothly.

Note to self. In the future if meguIV fails, re-boot first.
 
C:\meguIV\Avisynth 2.5\plugins\mt_masktools-25.dll
Version: 2.0.36.0
MD5: 6c1c4acce88ccae66f67c76011462023

You can copy files out of (and into) the virtual sandbox with a little trick: open a file save dialog in meguIV and copy and paste files from physical folders (like your desktop) to virtual folders (like C:\meguIV). Or vice-versa.
 
You must log in or register to reply here.
Top Bottom