MeGUI: General Questions and Troubleshooting Thread

[hello_hello]

So question is - what should I do? The last months there were several issues regarding XP (x265 builds, recent AviSynth+, ...) so I am not sure if MeGUI should also stop to support XP. I would not prevent MeGUI to run on XP but when newer versions of tools stop to work there is nothing I can do (except to proivide a dedicated version only for XP users which I cannot efford).

Despite the illogical Octo-puss rant above (for one thing if XP was crappy people wouldn't continue to use it) I think maybe to a certain extent you should let XP users sort out any problems themselves. Only because there's not much other choice.
That's coming from someone with three PCs that'll still be running XP when I build a new one as soon as there's Broadwell CPUs available, and will possibly be running XP until the day they die. I'm toying with upgrading those PCs to Win7, but I only wish more open source/free software was able to run on a free OS as then I'd happily dump Windows. That's something else I'm still considering.

Having said that, what about when the MeGUI update window opens and displays the version number of tools on the server, could the server version number also include something like "not for XP" or "Vista and newer" next to it so XP users would know not to allow that particular update?
Is it possible to have a system where MeGUI checks for the version of Windows (I assume it already does) and the updater blocks/ignores non-XP compatible updates accordingly? Something like that?

I guess for someone downloading MeGUI for the first time it might be a little more tricky, although would it be hard to host two zip files, one containing any "legacy" versions of tools required for XP? For third party sites hosting software downloads I doubt that'd be an issue.

Anyway, just some thoughts..... I think it'd be a shame to suddenly alienate XP users completely considering (as I mentioned in the mkvtoolnix thread) it seems there's at least as many PCs still running XP as there are running Vista, Win8 and Win8.1 combined.

[Kurtnoise]

Having said that, what about when the MeGUI update window opens and displays the version number of tools on the server, could the server version number also include something like "not for XP" or "Vista and newer" next to it so XP users would know not to allow that particular update?
Is it possible to have a system where MeGUI checks for the version of Windows (I assume it already does) and the updater blocks/ignores non-XP compatible updates accordingly? Something like that?

none current MeGUI developers have an XP which is running...So, imo, this is a waste of time.

[hello_hello]

none current MeGUI developers have an XP which is running...So, imo, this is a waste of time.

I don't understand the logic.

If only we could all hang in there playing nice until Windows 10 arrives.......
I did a bit more reading and so far an upgrade to Windows 10 seems like a reasonable prospect. Especially after I read this. It changed my thinking in respect to not upgrading XP on the older PCs.
Windows 10 will be a free upgrade for software pirates, too. (http://www.pcworld.com/article/2898668/windows-10-will-be-a-free-upgrade-for-software-pirates-too.html)

So aside from the Windows 10 insider program, which I signed up for today so I could download a preview copy (I've not installed it yet) if that's what it takes I'm happy to temporarily become a software pirate to ensure a free copy of Windows 10 on any PC that can run it. Yesterday I thought it'd still be a long while before I stopped running XP on at least one PC, while today my thinking there has changed somewhat.

[Kurtnoise]

I meant that keeping XP compatibility implies a lot of work from MeGUI developers : install a VM Machine or access to an XP machine, testing each packages, each softwares, find tools which are still running on it, etc...

Meanwhile, time is limited nowadays for the devs. So, sorry, it's too much work from my point of view for an such old OS.

[hello_hello]

I'd imagined anyone updating MeGUI via the development update server would be doing so at their own risk, but by the time MeGUI and/or the tools it uses had been updated on the stable server someone such as myself would have posted here to report on any XP related issues. That's how the XP/MkvMerge problem was discovered, or how the XP/L-Smash problem was discovered.

But you may be right. Maybe it's all too much trouble, especially if the version on the stable server is only updated once or twice per year.

[Zathor]

I'd imagined anyone updating MeGUI via the development update server would be doing so at their own risk, but by the time MeGUI and/or the tools it uses had been updated on the stable server someone such as myself would have posted here to report on any XP related issues. That's how the XP/MkvMerge problem was discovered, or how the XP/L-Smash problem was discovered.
Yes, but discover is one point. Actions have to be taken then - which is here now a problem. I can stop updating mkvmerge at all, but this is not a solution. For all other solutions/workarounds effort has to be spent which is limited on my side. I would be willing to do it for a still supported/recent OS.
So likely I will update the tools as usual and will not take any actions when a tool is not working anymore on XP. If alternative builds are available these will be used.

[Barough]

After the latest update to v2.48 of QAAC so is it complaining that 'CoreAudioToolbox.dll' is missing when it's about 2 start encoding the audio. Never had this issue with QAAC earlier.........

[hello_hello]

After the latest update to v2.48 of QAAC so is it complaining that 'CoreAudioToolbox.dll' is missing when it's about 2 start encoding the audio. Never had this issue with QAAC earlier.........

QAAC 2.48 is working for me. I just tested it.

[Barough]

QAAC 2.48 is working for me. I just tested it.

Doesn't matter what i do so do i get that error message. :(

[LigH]

I wonder if there is a discrepancy between qaac.exe and CoreAudioToolbox.dll regarding 32/64 bit code.

[hello_hello]

Barough,
I hate to ask the obvious, but is it safe to assume CoreAudioToolbox.dll isn't missing? :)

Mostly, MeGUI makes a backup of the last version of tools it uses when they're updated, so you could go back to the previous version by deleting (or renaming) MeGUI\tools\qaac\qacc.exe and removing the backup extension from qaac.exe.backup. If you do that, does QAAC work again?

I used makeportable from the QAAC site to extract the required files from the QuickTime installer and they were extracted to a folder called QTfiles, which is inside the MeGUI\tools\qaac folder. ie MeGUI\tools\qaac\QTfiles\CoreAudioToolbox.dll (along with the other required files). Is your setup the same?

I've got no idea what the problem is but I'd thought I'd suggest somewhere you might start looking. I'm running XP.

[LigH]

The QuickTime installer contains only 32 bit libraries. Using the recent iTunes installer for extraction, makeportable can extract 64 bit libraries as well. Just in case someone decided to prefer the 64 bit QAAC.

[Barough]

Barough,
I hate to ask the obvious, but is it safe to assume CoreAudioToolbox.dll isn't missing? :)

Mostly, MeGUI makes a backup of the last version of tools it uses when they're updated, so you could go back to the previous version by deleting (or renaming) MeGUI\tools\qaac\qacc.exe and removing the backup extension from qaac.exe.backup. If you do that, does QAAC work again?

I used makeportable from the QAAC site to extract the required files from the QuickTime installer and they were extracted to a folder called QTfiles, which is inside the MeGUI\tools\qaac folder. ie MeGUI\tools\qaac\QTfiles\CoreAudioToolbox.dll (along with the other required files). Is your setup the same?

I've got no idea what the problem is but I'd thought I'd suggest somewhere you might start looking. I'm running XP.

I have never had QuickTime installed on my Win 8.1 Pro x64 box earlier. And why did QAAC work earlier then........ beats me. Will do some double checking regarding if QT ever been installed here and get back here again

[hello_hello]

I have never had QuickTime installed on my Win 8.1 Pro x64 box earlier. And why did QAAC work earlier then........ beats me. Will do come double checking regarding QT ever been installed here and get back here again

You don't have to have QuickTime installed but you do need the appropriate files because QAAC is just a front end. The Apple files do the encoding. You can download the QuickTime or iTunes installer and use makeportable to extract the required files, then you need to put the folder it creates in the same folder as QAAC. You can find makeportable here.
https://sites.google.com/site/qaacpage/cabinet

Are you sure QAAC has worked previously??

[Barough]

QAAC have worked just fine earlier and i haven't found a trace of any QT install nor QTFiles folder on my computer, but i've have have extracted the QTFiles and everything is ok again.

This is so damn weird.........

[ryszardzonk]

Guys what have You gained by doing this?

2551 [DGAVCIndex Indexer] removed DGAVCIndex

I was using it now and then...

[Zathor]

DGAVCDec is outdated since years.

Try the other source filters:
- DGDecIM is a direct replacement but this tool is not free
- FFMS
- L-SMASH

If a file does not work please report it here.

[ryszardzonk]

DGIndex is even more outdated by thankfully megui still reads those indexes... On the other hand L-smash reads just about anything I throw at it, but has quite a substantial drawback which load time of whole file every single time I want to use it with megui therefore I much rather prepare those indexes outside of megui with DGAVCDec GUI which allows me to quickly load file once select which parts I want, save them and than load them into megui. With l-smath I have to create full index and then create AVS script for every short part loading full index not just specific part and it takes very long that way (posts http://forum.doom9.org/showpost.php?p=1715657&postcount=7849 and following). \

Having that said please imagine that I want to encode songs from Eurovision contest final separately where there is 27 of them :(

[LigH]

DGMPGDec may be old, but not yet obsolete. It is still as complete as necessary to process a One-PGC DVD titleset. FFMS2 and L-SMASH Works don't read a set of VOBs well.

In contrast to this, DGAVCDec is really obsolete because it is incomplete, it does not even support PAFF interlacing, quite common in material produced by hardware encoders (e.g. AVCHD cameras).

[ryszardzonk]

IMHO incomplete does not equal obsolete. If fact it works well for quite a few AVC DVB-S interlaced streams and as far as I am concerned it should not be removed unless it is some burden to support it in new versions. Is it?

[Zathor]

I understand why you want to have it back. Neverthless based on the current information which I have I will not reintroduce it. So I will never say never but it is very unlikely.

If you still want to use DGAVCDec with MeGUI you have at least two options:
- revert to an older version with support (e.g. last stable build) and disable updating of MeGUI itself (not all tools, only MeGUI/core)
- create the AVS file outside of the recent MeGUI (e.g. with DGAVCDec if it has the template support or with this older MeGUI version) and load the AVS file
(- revert the change and compile a version of your own)

[hello_hello]

Could someone tell me if the behaviour of Xvid's rate control in MeGUI's Xvid encoder configuration is correct, or makes sense?

Best as I've been able to find out, the I-Frame boost setting is normally described as "I-frame boost (%)" and the default is 10. I assume this gives I-frames a 10% boost and the default would be -kboost 10.
http://www.gromkov.com/faq/conversion/xvid_options.html

MeGUI describes the setting as "I-Frame Boost 10x(%)" and the default is 100. This also gets MeGUI to add -kboost 100 to the command line.

My confusion comes from the fact that changing the I-Frame boost setting in the encoder configuration to 10 rather than 100 removes the -kboost option from the command line, which usually happens when the encoder configuration is using a default setting, so I'm not sure which is the default. -kboost 100 when you click the "load defaults" button and select Automated 2 Pass, or -kboost 10?
Does MeGUI's description of "I-Frame Boost 10x(%)" make sense?

The other parts of the rate control that seem off to me are the overflow percentages. The default values appear to be 5% for each. MeGUI changes those values to 10% when one of the profiles is selected (ie Home Theatre) which is understandable if the default for each profile is 10%, but why does it also do the same for the Custom profile? If you select automated 2 pass and the unrestricted profile the overflow settings are 5%, but switching to the Custom profile changes them to 10% while not permitting them to be lowered to the defaults again in the GUI. As far as I can see the only difference between the Unrestricted and Custom profiles should be the Custom profile allowing you to set vbv restrictions.

One last question. Is the HSV Masking "variance" setting the current method of enabling the Dark Shikari VAQ patch?
http://forum.doom9.org/showthread.php?t=135093

Edit: Two more questions.
MeGUI lets you select RAWASP as the output type for Xvid encoding. Should that actually work? At the moment the output is M4V.
When does the "packed bitstream" option come into effect? When the video stream is first muxed as an AVI? If so is that why it's having no effect now because the output is M4V and ffmpeg doesn't support packed bitstreams? (I remember reading something about the ffmpeg developers considering packed bitstreams to be evil) I'm not sure how vital having a packed bitstream is. Most of my Xvid encodes were created using AutoGK and I never had problems playing AVIs with a packed bitstream using AVI capable DVD players or Bluray players etc.

Thanks.

[Zathor]

I never use Xvid myself so I cannot help here. But I will have a look at the "load defaults". I thought I have adjusted them properly but it seems I missed kboost.

[hello_hello]

Cheers. I think if the kboost default is wrong, it's been wrong for a long time, but as I hardly use Xvid myself I'd not gotten around to asking about it.
The way the setting is labelled in the GUI as "I-Frame Boost 10x(%)" is probably wrong. At least it doesn't make sense to me. According to the -help info the default for -kboost is 10.

The overflow defaults are 5% but I don't know whether they change when using one of the profiles. I did a bit of Googling though and couldn't find any evidence to suggest they'd need to. The way I understand it the overflow percentages tell the encoder how aggressively and how much it can pad the bitrate, or reduce the bitrate, if it thinks it's not going to hit the specified bitrate/file size. I'm not sure why it'd need to do it more aggressively by default when one of the profiles is selected. Anyone with the VFW version of Xvid installed able to check if selecting a profile changes any of the other settings automatically, and if so, which ones?

A bit of research seems to indicate m4v is used for rawasp streams. I didn't know that. I thought it was just another name for the MP4 container.

More research seems to indicate the packed bitstream option (while still available according to -help) would only apply to AVI output. It seems to have no effect when the output is m4v, so I guess as now MeGUI won't let Xvid write directly to AVI, it makes the option obsolete in the encoder configuration. From what I've been able to ascertain, ffmpeg won't mux packed bitstreams anyway. It'll always unpack them first. It also appears MP4 doesn't support packed bitstreams at all. (Although for the record, it seems MKV does. MKVCleaver will remux an AVI with either a packed or unpacked bitstream and remux it as it is). It looks like the packed bitstream option should be removed from the GUI.

[Kurtnoise]

AVI and Xvid support should be dropped imo...come on, it's 2015 guys !!!

[hello_hello]

I have a calendar and I rarely use Xvid for encoding myself these days, but it's still nice to have a choice. Would Xvid support involve much work for the developer(s) given the recent updates to Xvid have been the first ones in quite a long time?

[Barough]

It's always good 2 have options available to ya. Just because Xvid isn't a top format any longer doesn't mean that it's not being used any longer.

Regarding AVI-Mux GUI..... im pretty sure it have the option to write Open-DML files so i dont understand why FFmpeg is being used to do the muxing or have i missed something regarding the use of FFmpeg

[hello_hello]

Regarding AVI-Mux GUI..... im pretty sure it have the option to write Open-DML files so i dont understand why FFmpeg is being used to do the muxing or have i missed something regarding the use of FFmpeg

It appears the new Xvid won't write AVI files larger than 2GB, so to get around that the output is m4v which is then muxed as AVI by ffmpeg (AVI-Mux GUI won't open m4v) and then again by AVI-Mux GUI to add the audio as required.

[Barough]

It appears the new Xvid won't write AVI files larger than 2GB, so to get around that the output is m4v which is then muxed as AVI by ffmpeg (AVI-Mux GUI won't open m4v) and then again by AVI-Mux GUI to add the audio as required.

Ok, then i know. Haven't tested encoding any big Xvid's here in a 'while'.

[LigH]

That means, in fact xvid_encraw should support OpenDML AVI output for optimal results. Or MeGUI may prefer to use ffmpeg with libxvid instead to encode, this way an AVI may already contain the correct FourCCs.

[Zathor]

Or MeGUI may prefer to use ffmpeg with libxvid instead to encode[...]
I have thought about that during the switch to Xvid 1.3.x. But it seems there is no mapping table available for xvid_encraw --> ffmpeg settings. I also fear that some settings wont be available at all.

[kalehrl]

I believe for a short time libxvid was available in StaxRip and I tried it but could not figure out what settings to use to get similar quality/size ratio as with xvid_encraw in MeGUI.
In my opinion, xvid_encraw is far superior to libxvid.

[LigH]

But in fact, xvid_encraw as such is just a rather simple demo encoder, mainly a CLI frontend. Analyzing its sources may enlighten you about the available parameters for applications using libxvid.
__

I was just looking for MKV support and found that, when a symbol is enabled, a file "matroska.cpp" would have to be included. But it seems that it does not exist, not even on SVN. So it was probably never programmed yet?

[LouieChuckyMerry]

Hello, and Happy Saturday! I don't know if this problem is specific to MeGUI, but as that's what I'm using I thought I'd ask here. When I'm using the following basic script:

LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\DGIndexNV\DGDecodeNV.dll")
DGSource("SourcePath")
Trim(0,FirstHalfNumberOfFramesFromPreviewWindow)
SMDegrain(TR=3,ThSAD=500,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod()
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,Lsb_In=True,Lsb=True)
# DitherPost()
Dither_Out()

MeGUI's preview window opens and, using the frame numbers at the top of the window, I can create two scripts (eg. ThisEncode-Part1.avs and ThisEncode-Part2.avs) with Trim(0,FirstHalfNumberOfFramesFromPreviewWindow) and Trim(FirstHalfNumberOfFramesFromPreviewWindow+1,0) so as to have two equal halves. When I open either of these with MeGUI's preview window the number of frames for each half is correct. However, with the following script:

LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\DGIndexNV\DGDecodeNV.dll")
DGSource("SourcePath")
Trim(0,FirstHalfNumberOfFramesFromPreviewWindow)
### Deinterlace-Match Fields-Decimate ###
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
Function FieldMatch(Clip C) {
Global PP = C.DuplicateFrame(0)
Global CC = C
Global NN = C.DeleteFrame(0)
P2 = PP.SeparateFields()
C2 = CC.SeparateFields()
N2 = NN.SeparateFields()
Global PC = Interleave(P2.SelectEven(),C2.SelectOdd()).Weave()
Global CP = Interleave(C2.SelectEven(),P2.SelectOdd()).Weave()
Global CN = Interleave(C2.SelectEven(),N2.SelectOdd()).Weave()
Global NC = Interleave(N2.SelectEven(),C2.SelectOdd()).Weave()
Global Deint = QTGMC(CC).SelectEven()
Return ScriptClip(CC, \
"!CC.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? CC : " + \
"!NN.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? NN : " + \
"!CN.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? CN : " + \
"!NC.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? NC : " + \
"!PP.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? PP : " + \
"!CP.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? CP : " + \
"!PC.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? PC : Deint")
}
TFM(Order=-1,Mode=5,PP=2,Clip2=FieldMatch(),Slow=2,MChroma=False,Ubsco=False,CThresh=12,Chroma=True)
TDecimate(Mode=1)
### Fix Line-Doubled Fields ###
NNEDI3(Field=-2)
Merge(SelectEven(),SelectOdd())
### Reduce Shimmering ###
QTGMC(InputType=1)
### Stabilize ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(DFTTest(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=400,ContraSharp=True,RefineMotion=True,Plane=0,Lsb=True,Lsb_Out=True,PreFilter=2,Chroma=False)
### Resize ###
LinearResize(640,480,Lsb_In=True,Lsb_Out=True)
### Darken-Thin Lines ###
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=20,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
### Deband ###
GradFun3(thR=0.55,SMode=2,Lsb_In=True,Lsb=True,StaticNoise=True)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

opened in MeGUI's preview window, if I use the frame numbers at the top of the preview window to make two scripts as above, then open each of these in MeGUI's preview window, the number of frames is never correct. That is, each script doesn't have half the frames (as I'd expect), but instead one "half" might have a third of the frames while the other "half" has two-thirds of the frames.

Please, would someone explain to me why this happens? Also, is there any way to correct this, to make the preview for that script frame-accurate? Thanks for your time :) .

[hello_hello]

Where are you putting Trim()?
If there's a frame rate change due to decimation etc and you add Trim, you'd want to add it before the frame rate change otherwise there'll be a different number of frames and your Trim starting in the middle won't be in the middle any more. Or change the frames you're using with Trim() if the frame count changes due to decimation, but it's probably easier just to put it earlier in the script.

Question.... Does QTGMC and SMDegrain in the same script do a better job removing noise than just letting QTGMC do the denoising?

Something like QTGMC(InputType=1, Ezdenoise=1.5) and whatever other settings you want to play with. I ask, because QTGMC stabilises everything, including any noise it doesn't remove, and it seems to me that'd make SMDegrain less effective. I've never used them both in the same script myself, it's just a thought....

[LouieChuckyMerry]

Where are you putting Trim()?

Oops, that would certainly help you answer my question (I've edited the scripts accordingly) ;) . As you can see Trim is before the decimation, which is why I'm more confused than usual.


Question.... Does QTGMC and SMDegrain in the same script do a better job removing noise than just letting QTGMC do the denoising?

Something like QTGMC(InputType=1, Ezdenoise=1.5) and whatever other settings you want to play with. I ask, because QTGMC stabilises everything, including any noise it doesn't remove, and it seems to me that'd make SMDegrain less effective. I've never used them both in the same script myself, it's just a thought....

That's a good question. I actually ran some tests with the above script but turning off SMDegrain's denoising (TR=0, ThSAD=0) and noticed no difference in the output video on my 14" 1600x900 laptop screen. I'm using SMDegrain here more for its other features, the high bit depth pipeline, motion vectors, and prefilter, and kept the mild denoising settings (TR=2, ThSAD=400) out of paranoia, er, because they were suggested by the author when (s)he was kind enough to look at a test clip for me (to be fair, this was recommended before the QTGMC line was added for the shimmering).

I know the script seems out of hand--some might say I'm suffering from filteritis ;) --but I've tested it everywhichway and removing even a single filter has a very noticeable adverse effect on the output video. This S5.E21-TestClip (http://www.mediafire.com/download/bex5825c2wtwd1r/S5.E21-TestClip.zip) is a great example. Run this clip with the above script and check out the results, I think they're amazing given the source's poor quality.

[hello_hello]

Are you sure you're using half the frames according to the preview before adding any decimation to the script and previewing that, which will change the total number of frames displayed by the preview? I can't think of a reason why it shouldn't work.

I've got to spend some time in the real world. I'll check out the sample later.

[LouieChuckyMerry]

Are you sure you're using half the frames according to the preview before adding any decimation to the script and previewing that, which will change the total number of frames displayed by the preview? I can't think of a reason why it shouldn't work.

I've triple-checked with mulitiple 29.970 FPS sources. I:

1) Create .dgi and .avs (with the above script) files with DGIndexNV.

2) Drag the .avs file onto the MeGUI GUI.

3) Find the next scene change and note the frame number at the top of the preview window.

4) Make two copies of the .avs file, appending the names with "Part1" and "Part2", then add "Trim(0,LastFrameOfFirstScene)" to Part1 and "Trim(FirstFrameOfSecondScene,0)" to Part2, both immediately after the "Source" line.

5) Open each in MeGUI and note that they're not of equal size :confused: .

Perhaps I'm missing something (wouldn't be the first time). Do you think this is a bug or just a vagary of the script?

[hello_hello]

It still sounds like you're going about it the wrong way. If you open a 29.970 video with (as an example) 100,000 frames, after normal TDecimate() you'd be left with 80,000 frames.
So if you put Trim() first (directly after the source), you'd need to use Trim(0,50000) for the first script and Trim(50001,0) for the second script.
If you put Trim() at the end, it'd be Trim(0,40000) for the first script and Trim(40001,0) for the second.

From the way you describe it you're finding the "after decimation Trim", but then putting it before the decimation. If you want to use Trim directly after the source line, preview the script without any filtering, work out where the halfway point is, make two copies of the script and add Trim to each, then follow Trim with your filtering/decimation.

You may find the total frame count differs by a frame, depending on whether you split the script before decimation or split it after (if the split point isn't on an even multiple of five frames before decimation), so I assume splitting the script after decimation would be more likely to give you exactly the same total frame count as you'd get from just encoding the whole thing as a single script. If that makes sense.....

PS. I kind of tried your script on the sample, but I don't have all the required plugins and I was getting a few errors which would have taken some time to sort out (things like a missing function in a script which probably require an additional plugin to fix), so I deleted Stab() and fiddled with a few things to make it work, but I think I saw the gist of it. It definitely looks better than the original video which is fairly horrible. I forgot you were probably working with animation. No nasty artefacts from using QTGMC on it yet?

[hello_hello]

Zathor,
I think I found a little bug or rounding error in MeGUI's aspect error calculations. I have the acceptable aspect error set to 0%.

I created a couple of custom input pixel aspect ratios to use in the script creator and combined with anamorphic encoding and "resize to selected mod", any resizing will result in an aspect error of between 0.00003% and 0.00005% being displayed. It doesn't matter how you resize (any mod or dimensions) MeGUI always shows a small aspect error.

As an example, I created two custom aspect ratios of 1.363636, which MeGUI then displays as 15:11, and 1.818181, which is displayed as 20:11 (I thought I'd try spending some time in the world of mpeg4 pixel aspect ratios). They both result in a small aspect error when anamorphic encoding is enabled with resizing.

According to my calculations, if I use the 15:11 aspect ratio with a PAL DVD, I should be able to resize it to exactly 720x528 with zero aspect error, and that's what MeGUI shows, so I assume the small error in the aspect calculations only applies to anamorphic encoding and resizing.

Thanks.

[LouieChuckyMerry]

It still sounds like you're going about it the wrong way.

Man, good thing I wasn't driving a motor vehicle. Honestly, it really made sense in my head, as sad as that seems :rolleyes: . Anyway, thanks again for the kind help, hello_hello, it's now clear. And I'll edit my templates, thus eliminating at least one way to embarrass myself in the future...


PS. I kind of tried your script on the sample, but I don't have all the required plugins and I was getting a few errors which would have taken some time to sort out (things like a missing function in a script which probably require an additional plugin to fix), so I deleted Stab() and fiddled with a few things to make it work, but I think I saw the gist of it. It definitely looks better than the original video which is fairly horrible. I forgot you were probably working with animation. No nasty artefacts from using QTGMC on it yet?

I thought (ha ha ha) that this was only the case for using QTGMC to deinterlace animation? The QTGMC here is being used in progressive mode to reduce the shimmering, after the deinterlacing-field matching-decimating and doubled-line fixing (I get about 7% of the credit for the script, mostly the neatness ;) ). I've not noticed any artifacts yet, but I've only watched two episodes in their entirety so there might be some yet. Given how impressively QTGMC reduces the shimmering, I'd happily live with the occasional blip (which given the source's low quality might not even be QTGMC's fault).

[hello_hello]

I thought (ha ha ha) that this was only the case for using QTGMC to deinterlace animation? The QTGMC here is being used in progressive mode to reduce the shimmering, after the deinterlacing-field matching-decimating and doubled-line fixing (I get about 7% of the credit for the script, mostly the neatness ;) ). I've not noticed any artifacts yet, but I've only watched two episodes in their entirety so there might be some yet. Given how impressively QTGMC reduces the shimmering, I'd happily live with the occasional blip (which given the source's low quality might not even be QTGMC's fault).

Wasn't it you I was conversing with in the QTGMC thread a while back regarding using it for animation? Ah, yes it was (http://forum.doom9.org/showthread.php?p=1713474#post1713474). The bottom pic was courtesy of QTGMC in progressive mode, although if I remember correctly I played with a Simpson's sample at the time and it looked okay. I think I'm remembering that correctly, but if it's doing the job and not causing problems, you might as well use it.

For "video" artefacts don't stand out because they usually only happen for a tiny part of a single frame where there's movement and I'd normally only notice by accident when looking closely for something else, but for animation with large blocks of flat colour if there's artefacts they'll be more obvious. Maybe there's a QTGMC setting you could tweak. I haven't tried as I rarely encode animation myself. If you're not seeing any problems though.... don't worry about it.

[LouieChuckyMerry]

Long story truncated, after encoding Seasons 1-8 I decided to switch to 10-bit x264, so I figured I'd take the time to try and improve my script before starting over. It's weakest link was the deinterlacing-decimating (turns out the first season is bad tape transfers and the following seasons aren't much better, frequent patches of field-blending and inconsistent pulldown patterns the norm). After posting here (http://forum.doom9.org/showpost.php?p=1726753&postcount=1) I was incredibly lucky when someone with way more knowledge than I happened to be encoding the early-season Simpsons as well (http://forum.doom9.org/showpost.php?p=1726958&postcount=15). (S)he did all the grunt work regarding the deinterlacing-field matching-decimating, evolving from the questionable use of QTGMC for deinterlacing-decimating to the final script above. It's surely not a perfect approach, but for an automated method, given the horrible source quality, I think it does a really really good job. Someday when I'm bored I'll attack frame-by-frame ;) .

Also, I ran tests with variations of the above script--without NEEDI3, without QTGMC, etc.--and it just looks better as is. Somehow the NEEDI3-QTGMC combo does wonders with regards to the line-doubled fields and shimmering (I tested QTGMC with various presets, and the default was noticeably better than faster options). Now that you've reminded me that QTGMC denoises by default, and since I'm only about halfway through Season 2, I'll double-check my SMDegrain denoise settings to make sure they're not too strong. I ran tests before but what's a little extra paranoia, er, due diligence.

Ahhh, there might be an extra couple, but MinimumPluginsForSimpsonsSuperScript (http://www.mediafire.com/download/0pg4vbzykgi77a3/MinimumPluginsForSimpsonsSuperScript.7z).

[AW-]

After 100's of MKv rips, one day I did a mkvmerge update on two computers and both will not do SAR resize.
I have same setup on two machines, If i set it to (704, 480) with force SAR 10:11 or in the custom command line --sar 10:11 It will come out 704 x 480 instead of 704x480 ~> 704x528.
All Sars are the same thing. I reinstalled and the same thing again...hmm

[Information] Log
-[Information] Versions
--[Information] [7/21/2015 6:36:03 AM] MeGUI: 2525
--[Information] [7/21/2015 6:36:03 AM] Operating System: Windows 7 Premium Edition x64 SP1 (6.1.65536.7601)
--[Information] [7/21/2015 6:36:03 AM] .Net Framework: 2.0.50727.5420
--[Information] [7/21/2015 6:36:03 AM] .Net Framework: 4.0.0.0
--[Information] [7/21/2015 6:36:04 AM] AviSynth: 2.5.8.5 (21-12-2008)
--[Information] [7/21/2015 6:36:04 AM] AvisynthWrapper: (02-01-2009)
--[Information] [7/21/2015 6:36:04 AM] Haali Matroska Splitter: 1.13.138.14 (14-04-2013)
--[Information] [7/21/2015 6:36:04 AM] Haali DSS2: (14-04-2013)
--[Information] [7/21/2015 6:36:04 AM] ICSharpCode.SharpZipLib: 0.85.5.452 (07-08-2008)
--[Information] [7/21/2015 6:36:04 AM] LinqBridge: 1.0.0.0 (28-05-2009)
--[Information] [7/21/2015 6:36:04 AM] MediaInfo: 0.7.72.0 (07-01-2015)
--[Information] [7/21/2015 6:36:04 AM] MediaInfoWrapper: 0.7.61.0 (06-01-2013)
--[Information] [7/21/2015 6:36:04 AM] MessageBoxExLib: 1.0.2218.28317 (19-12-2008)
--[Information] [7/21/2015 6:36:04 AM] SevenZipSharp: 0.64.3890.29348 (02-01-2011)
--[Information] [7/21/2015 6:36:04 AM] 7z: 9.20 (18-11-2010)
-[Information] Update detection
--[Information] [7/21/2015 6:36:04 AM] Using cached update config and server: http://megui.tmebi.de/stable/
--[Information] [7/21/2015 6:36:04 AM] No package requires an update
-[Information] Log for job63 (video, Bla blaClip.avs -> )
--[Information] [7/21/2015 6:38:26 AM] Started handling job
--[Information] [7/21/2015 6:38:26 AM] Preprocessing
--[Information] [7/21/2015 6:38:26 AM] Avisynth input script
---[NoImage] LoadPlugin("C:\Program Files (x86)\MeGUI_2418_x86\DGMPGDec 1.5.5\DGDecode.dll")
---[NoImage] #LoadPlugin("C:\Program Files (x86)\MeGUI_2418_x86\AviSynthPlugins\Tdeint.dll")
---[NoImage] LoadPlugin("C:\Program Files (x86)\MeGUI_2418_x86\AviSynthPlugins\TIVTC.dll")
---[NoImage] #LoadPlugin("C:\Program Files (x86)\MeGUI_2418_x86\AviSynthPlugins\mt_MaskTools.dll")
---[NoImage] #LoadPlugin("C:\Program Files (x86)\MeGUI_2418_x86\AviSynthPlugins\mt_masktools.dll")
---[NoImage] MPEG2Source("C:\DVD\Bla bla (1978) NT D5 CG\Bla bla\Clip\Clip.d2v", cpu=0)
---[NoImage] #import("C:\Program Files (x86)\MeGUI_2418_x86\AviSynthPlugins\Srestore.avs")
---[NoImage] #tdeint(order=-1)
---[NoImage] #tdeint(order=1)
---[NoImage] #srestore()
---[NoImage] tfm().TDecimate()
---[NoImage] #greyscale()
---[NoImage] #AssumeFPS("film")
---[NoImage] Crop(8, 0, -8, -6)
---[NoImage] BicubicResize(704, 480)
--[Information] [7/21/2015 6:38:26 AM] resolution: 704x480
--[Information] [7/21/2015 6:38:26 AM] frame rate: 24000/1001
--[Information] [7/21/2015 6:38:26 AM] aspect ratio: 4:3 (1.333)
--[Information] [7/21/2015 6:38:26 AM] custom command line: --sar 10:11
--[Information] [7/21/2015 6:38:26 AM] Job commandline: "C:\Program Files (x86)\MeGUI_2418_x86\tools\x264\avs4x264mod.exe" --level 3.1 --preset slow --tune film --pass 1 --bitrate 1800 --stats "C:\Program Files (x86)\MeGUI_2418_x86\logs\1011.stats" --deblock -3:-3 --keyint 240 --bframes 5 --ref 9 --vbv-bufsize 14000 --vbv-maxrate 14000 --ratetol 3.0 --rc-lookahead 60 --merange 32 --subme 10 --partitions all --trellis 2 --no-dct-decimate --no-fast-pskip --sar 10:11 --output NUL "C:\DVD\Bla bla (1978) NT D5\SBla bla\Bla blaClip\Bla blaClip.avs"
--[Information] [7/21/2015 6:38:27 AM] Process started
--[Information] [7/21/2015 6:38:27 AM] Standard output stream
---[Information] [7/21/2015 6:38:44 AM] avs [info]: AviSynth 2.58, build:Dec 22 2008 [08:46:51]
---[Information] [7/21/2015 6:38:44 AM] avs [info]: Video colorspace: YV12
---[Information] [7/21/2015 6:38:44 AM] avs [info]: Video resolution: 704x480
---[Information] [7/21/2015 6:38:44 AM] avs [info]: Video framerate: 24000/1001
---[Information] [7/21/2015 6:38:44 AM] avs [info]: Video framecount: 1364
---[Information] [7/21/2015 6:38:44 AM] avs4x26x [info]: "x264_64" - --level 3.1 --preset slow --tune film --pass 1 --bitrate 1800 --stats "C:\Program Files (x86)\MeGUI_2418_x86\logs\1011.stats" --deblock -3:-3 --keyint 240 --bframes 5 --ref 9 --vbv-bufsize 14000 --vbv-maxrate 14000 --ratetol 3.0 --rc-lookahead 60 --merange 32 --subme 10 --partitions all --trellis 2 --no-dct-decimate --no-fast-pskip --sar 10:11 --output NUL --frames 1364 --fps 24000/1001 --input-res 704x480 --input-csp i420
--[Information] [7/21/2015 6:38:27 AM] Standard error stream
---[Information] [7/21/2015 6:38:28 AM] raw [info]: 704x480p 10:11 @ 24000/1001 fps (cfr)
---[Information] [7/21/2015 6:38:28 AM] x264 [info]: using SAR=10/11
---[Information] [7/21/2015 6:38:28 AM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
---[Information] [7/21/2015 6:38:28 AM] x264 [info]: profile Main, level 3.1
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: frame I:10 Avg QP:17.84 size: 62706
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: frame P:262 Avg QP:20.70 size: 27645
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: frame B:1092 Avg QP:24.80 size: 4595
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: consecutive B-frames: 1.2% 1.6% 7.9% 3.5% 4.4% 81.4%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: mb I I16..4: 11.7% 0.0% 88.3%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: mb P I16..4: 13.6% 0.0% 0.0% P16..4: 82.5% 0.0% 0.0% 0.0% 0.0% skip: 3.8%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: mb B I16..4: 1.5% 0.0% 0.0% B16..8: 28.9% 0.0% 0.0% direct:13.6% skip:56.0% L0:18.7% L1:32.4% BI:48.9%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: final ratefactor: 19.94
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: direct mvs spatial:99.4% temporal:0.6%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: coded y,uvDC,uvAC intra: 83.1% 79.4% 55.3% inter: 27.9% 16.6% 7.9%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: i16 v,h,dc,p: 24% 29% 33% 14%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 28% 10% 7% 8% 7% 8% 7% 9%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: i8c dc,h,v,p: 49% 24% 20% 7%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: Weighted P-Frames: Y:3.1% UV:0.0%
---[Information] [7/21/2015 6:38:44 AM] x264 [info]: kb/s:1812.35
---[Information] [7/21/2015 6:38:44 AM] encoded 1364 frames, 80.00 fps, 1812.35 kb/s
--[Information] [7/21/2015 6:38:44 AM] Postprocessing
---[Information] [7/21/2015 6:38:44 AM] Deleting intermediate files
--[Information] [7/21/2015 6:38:44 AM] Job completed


If you need any other settings info I may have left out, please ask. I'm sure it's something trivial I over looked.

Thanks in advance.

[LigH]

Useful ressource: http://members.optusnet.com.au/squid_80/sources/

To possibly build a custom binary of xvid_encraw, one may be interested in:

xvid_encraw_src.zip (http://members.optusnet.com.au/squid_80/sources/xvid_encraw_src.zip) containing a Matroska output module (and a HVS module);
AviWriter_src.zip (http://members.optusnet.com.au/squid_80/sources/AviWriter_src.zip) containing an OpenDML AVI writer based on VirtualDub sources

according to a message from the xvid-devel mailing list.

squid_80 used to be a member here; last posts in Sept. 2011

[tebasuna51]

After 100's of MKv rips, one day I did a mkvmerge update on two computers and both will not do SAR resize.
I have same setup on two machines, If i set it to (704, 480) with force SAR 10:11 or in the custom command line --sar 10:11 It will come out 704 x 480 instead of 704x480 ~> 704x528.
All Sars are the same thing. I reinstalled and the same thing again...hmm

I don't see the problem.
Using --sar 10:11 don't force a pixel resize to 704x528 at encoder time, the resize is make at play time.

Use a mkv output, not NULL like in your log, and you can see the display size like 704x528.

[AW-]

I don't see the problem.
Use a mkv output, not NULL like in your log, and you can see the display size like 704x528.

http://i.imgur.com/NarocrU.jpg
Is there another format setting other than this one.

Screen shots and viewing still 704 x 480

Even tried typing .mkv in "Video Output" after the file name and still says NULL in logs....hmmm

Thanks again

[LigH]

A "NUL" output is usually the result of only a first pass of a 2-pass encode. If you want 2-pass, either put both the first and the second pass into the queue, or use the auto 2-pass option.

[AW-]

I've been using the automated 2nd pass, Thought that would be ok?
http://i.imgur.com/LOE1pn8.jpg

I always create my scripts with AvsPmod, Thought I'd double check the other settings as well.
http://i.imgur.com/iNlFtdG.jpg

I also tried Disabled 64 bit mode,

http://i.imgur.com/Mj5mXos.jpg

Thanks

[tebasuna51]

Screen shots and viewing still 704 x 480

Maybe is a player (what?) problem.

Use MediaInfo to put a repport of your mkv output. You must see someting like:

Width : 704 pixels
Height : 480 pixels
Pixel aspect ratio : 0.909
Display aspect ratio : 4:3

The display of 704x480 internal pixels must be 4:3 (704x528 screen pixels)