Anri-chan 3.3 (June 5, 2011)

TheThrillness

2012-07-19 08:35:08 pm

thethrillness.blogspot.com

I never tried since using Aero fixed the issue.

Aftermath

Edit history:

Aftermath: 2012-08-03 05:57:48 am

Aftermath: 2012-08-03 05:57:42 am

Aftermath: 2012-08-03 05:55:13 am

Aftermath: 2012-08-03 05:54:48 am

Aftermath: 2012-08-03 02:16:04 am

2012-08-02 04:13:52 am

Quits halfway

Not sure if there was still any interest in switching from mvbob to QTGMC, but I'll be doing a bunch of encoding with it in the next couple of weeks and can test stuff out if you'd like. The MT mode is promising, but not worth using because of how specifically it has to be configured (seemingly). It's very unstable depending on which presets/effects you use, and seems to just crash at 1.6GB RAM usage. With SD sources it probably is more stable, but it's probably worth going with the same approach as anri does with mvbob for now.

Even with the default QTGMC settings, the picture turned out sharper than mvbob's, with fewer artifacts. After getting MT to run stably (on 4/8 cores), it deinterlaced 1080i at almost 4fps, which is quite good. Running some other effects in QTGMC (what they call sourcematch) helps reduce artifacting that was apparent on the timer, but I haven't been able to get a stable encode (and it's about 6-8x slower). I'm going to switch to the ST version and we'll see if it's a bit more stable (can't even encode audio + video at the same time currently...).

Edit: So found out most of what I was doing poorly. I was expecting to be able to run more than one core per script, but by far the limiter is RAM, so there's no big gains to be had while running a modifier like SourceMatch. Good news is that it means there's not really a reason to try to run multithreading if supporting 1080i. Running on one core, I've gotten it to about 2fps, dropping to around 1.5fps when running two instances. I'll have to tweak with optimums further, but each script is eating up about 2.5GB of RAM. In order to do that and not crash, I had to use Large Address Aware to let the newest vdub (1.10.12) to make use of more than ~1.6GB. It didn't stick with the 1.9.11 version of vdub, which means initial setup of QTGMC if it came with anri may need a few more steps to make sure that vdub doesn't crash with HD video. I've got some DVD footage I'll be testing on tomorrow so I'll see what kind of RAM usage that gets (and also what sort of MTing I can do on it).

Tonight I'll probably work on seeing if I can improve how I have the settings for parallelization, to see if I can reduce the performance reduction of each script. I'm hugely limited by only having 8GB of RAM, I'll probably be ordering 32GB this weekend (although the DVD stuff may let me try with 4 or so scripts running).

This seems to be a pretty good setting from what I've seen so far. There's a very small amount of artefacting that can come as a result of Chromamotion, but the inclusion of it is a large difference from mvbob in reducing shimmer on static objects. I'll have to check on SD material, but this ends up looking better than the "Slower" preset, while getting about 80% more speed. (1.5->2.5fps while running 2 encodes).

QTGMC(Preset="Medium", sourcematch=3, chromamotion=true)

Not sure if there was still any interest in switching from mvbob to QTGMC, but I'll be doing a bunch of encoding with it in the next couple of weeks and can test stuff out if you'd like. The MT mode is promising, but not worth using because of how specifically it has to be configured (seemingly). It's very unstable depending on which presets/effects you use, and seems to just crash at 1.6GB RAM usage. With SD sources it probably is more stable, but it's probably worth going with the same approach as anri does with mvbob for now.

Even with the default QTGMC settings, the picture turned out sharper than mvbob's, with fewer artifacts. After getting MT to run stably (on 4/8 cores), it deinterlaced 1080i at almost 4fps, which is quite good. Running some other effects in QTGMC (what they call [url=http://forum.doom9.org/showthread.php?p=1474061#post1474061]sourcematch[/url]) helps reduce artifacting that was apparent on the timer, but I haven't been able to get a stable encode (and it's about 6-8x slower). I'm going to switch to the ST version and we'll see if it's a bit more stable (can't even encode audio + video at the same time currently...).

Edit: So found out most of what I was doing poorly. I was expecting to be able to run more than one core per script, but by far the limiter is RAM, so there's no big gains to be had while running a modifier like SourceMatch. Good news is that it means there's not really a reason to try to run multithreading if supporting 1080i. Running on one core, I've gotten it to about 2fps, dropping to around 1.5fps when running two instances. I'll have to tweak with optimums further, but each script is eating up about 2.5GB of RAM. In order to do that and not crash, I had to use [url=http://www.techpowerup.com/forums/showthread.php?t=112556]Large Address Aware[/url] to let the newest vdub (1.10.12) to make use of more than ~1.6GB. It didn't stick with the 1.9.11 version of vdub, which means initial setup of QTGMC if it came with anri may need a few more steps to make sure that vdub doesn't crash with HD video. I've got some DVD footage I'll be testing on tomorrow so I'll see what kind of RAM usage that gets (and also what sort of MTing I can do on it).

Tonight I'll probably work on seeing if I can improve how I have the settings for parallelization, to see if I can reduce the performance reduction of each script. I'm hugely limited by only having 8GB of RAM, I'll probably be ordering 32GB this weekend (although the DVD stuff may let me try with 4 or so scripts running).

This seems to be a pretty good setting from what I've seen so far. There's a very small amount of artefacting that can come as a result of Chromamotion, but the inclusion of it is a large difference from mvbob in reducing shimmer on static objects. I'll have to check on SD material, but this ends up looking better than the "Slower" preset, while getting about 80% more speed. (1.5->2.5fps while running 2 encodes).

QTGMC(Preset="Medium", sourcematch=3, chromamotion=true)

nate

2012-08-03 09:44:35 am

yikes, it's too bad ram use is like that. mvbob "only" uses 500-600 megs per core for me (using sumichan). i'm still running 32-bit xp and i have a 6-core cpu but i'm actually not that limited because i can do 5 slices without swapping and that leaves the sixth core for all the source decoding.

bos

2012-08-03 10:14:21 am

Try SetMemoryMax? Though it's supposed to be default 512 MB max in 2.58. Check if this command is somewhere in the QTGMC script.

http://avisynth.org/mediawiki/Internal_functions/Control_functions

Aftermath

Edit history:

Aftermath: 2012-08-03 03:55:51 pm

Aftermath: 2012-08-03 01:31:28 pm

Aftermath: 2012-08-03 01:31:17 pm

Aftermath: 2012-08-03 01:30:20 pm

Aftermath: 2012-08-03 01:24:23 pm

Aftermath: 2012-08-03 01:24:15 pm

Aftermath: 2012-08-03 01:21:34 pm

2012-08-03 01:04:26 pm

Quits halfway

Well, I'm still on the MT version (and using 2.6), I think I'll wipe the stuff I have related to it tonight and try to switch over to the ST stuff. I have been using a SetMemoryMax value, although it's a ridiculous 2200ish. Setting it to 512 uses about 600MB, but makes fps hover around .3. 1024 is about 3fps and 1.2GB used. Using 2200 with MT on in the script gets about 4.75fps with 2.5GB used. So, it seems that 2.6 (or using the Large Address Aware thing) lets values over 512 be used, I'll see about trying to aim for the 1024 limit or something with the ST version. The main thing is that when encoding, vdub's performance tab has my "I/O thread activity" locked at 100% and processing under 10% unless I crank the RAM (well, I've never gotten it to not be I/O bottlenecked, but processing will jump to 30% or so), but I'm not sure what else I could be doing incorrectly to be hitting that so constantly.

Also, thinking about it now, each instance of mvbob uses about 1.2GB for me iirc. I'll test again when I get home from work.

Note for self: try using TR0=1.

Well, I'm still on the MT version (and using 2.6), I think I'll wipe the stuff I have related to it tonight and try to switch over to the ST stuff. I have been using a SetMemoryMax value, although it's a ridiculous 2200ish. Setting it to 512 uses about 600MB, but makes fps hover around .3. 1024 is about 3fps and 1.2GB used. Using 2200 with MT on in the script gets about 4.75fps with 2.5GB used. So, it seems that 2.6 (or using the Large Address Aware thing) lets values over 512 be used, I'll see about trying to aim for the 1024 limit or something with the ST version. The main thing is that when encoding, vdub's performance tab has my "I/O thread activity" locked at 100% and processing under 10% unless I crank the RAM (well, I've never gotten it to not be I/O bottlenecked, but processing will jump to 30% or so), but I'm not sure what else I could be doing incorrectly to be hitting that so constantly.

Also, thinking about it now, each instance of mvbob uses about 1.2GB for me iirc. I'll test again when I get home from work.

Note for self: try using TR0=1.

nate

2012-08-03 04:54:49 pm

oops, forgot to mention that was sd video, mvbob "only" using 500-600 meg.

Aftermath

Edit history:

Aftermath: 2012-08-04 05:22:56 am

Aftermath: 2012-08-04 03:59:56 am

Aftermath: 2012-08-04 03:45:47 am

Aftermath: 2012-08-04 03:44:48 am

Aftermath: 2012-08-03 08:08:42 pm

2012-08-03 07:53:56 pm

Quits halfway

Yeah, I'm hoping that SD RAM usage will just be ay lower than HD using the same scripts. One of the main things I want to find are settings that will work for SD and HD while looking good (even though the number of 1080i submissions is probably equal to 0). Assuming it's not on VHS, does anri do much processing for the nmf before getting to mvbob?

(some rambling to myself mostly)
Also, turns out that just using ChromaMotion alone won't be a good idea, because it does cause quite a bit of chroma ghosting on very thin moving objects, which will obviously get very noticable in SD material that's full-screened. The main reason I'm using ChromaMotion is to reduce "shimmering" on static parts of an image, so I'll see if I can get settings that fix both. I'm thinking that I just need to scale down what radii are being used for the various effects because the source is too clean. It's strange but some parts of the faster presets look far better, so I'll definitely be reading much more into the documentation of the plugins.

Will also need to try using huffyuv as the video codec to see if decoding lagarith is playing a big role in my I/O bottleneck.

Edit:
Ok, switched over to ST and haven't really lost any performance. I tried 2.5.8 with SetMemoryMax and it seemed 1024 applied properly since vdub took up 1.2GB RAM once encoding started. I moved up to the latest 2.6 ST build and it improved performance a bit. I'm currently running 5 scripts and averaging about 1.5fps on each (~3fps just running one) with 1.2GB RAM on each process, so at least the Large Address Aware thing isn't necessary (no performance difference either). I'll post how the video actually looks once I get it through anri-chan, but this picture shows what I'm currently trying to fix from the ChromaMotion process: http://i.imgur.com/Isokc.jpg

You can see the string from that enemy has a bit of ghosting on where it will appear next frame (just below), as well as the .x1 on the clock ghosting from the previous frame, which had a 3. Not sure if that's bad enough to be a dealbreaker or how it'll affect other games yet. Neither of these occur with chromamotion off, but otherwise there's really bad bobbing on certain static sections. For this game, they're immediately prevalent right at the start and also occur in a bunch of places when the camera is still. I'll be posting in the main doom9 thread for QTGMC to see if anyone there has ideas. There's a setting for "SrchClipPP" and I could get it to improve in-level parts, but the opening screen still looked bad (bunch of single-pixel lines), so not sure if there's anything else to adjust.

Test video (ignore the filename).

Here's the script I was running.

Code:

SetMemorymax(1024)
avisource("lkj1.avi")
#Trim(461,2579)
Trim(3569,8148)
#Trim(9459,14225)
#Trim(14842,17813)
AssumeTFF()
chop=(last.framecount/5)
trim((chop*0)+1,chop*1)
QTGMC(Preset="Medium", sourcematch=3, sharpness=0.3, chromamotion=true, TR0=1)

Yeah, I'm hoping that SD RAM usage will just be ay lower than HD using the same scripts. One of the main things I want to find are settings that will work for SD and HD while looking good (even though the number of 1080i submissions is probably equal to 0). Assuming it's not on VHS, does anri do much processing for the nmf before getting to mvbob?

(some rambling to myself mostly)
Also, turns out that just using ChromaMotion alone won't be a good idea, because it does cause quite a bit of chroma ghosting on very thin moving objects, which will obviously get very noticable in SD material that's full-screened. The main reason I'm using ChromaMotion is to reduce "shimmering" on static parts of an image, so I'll see if I can get settings that fix both. I'm thinking that I just need to scale down what radii are being used for the various effects because the source is too clean. It's strange but some parts of the faster presets look far better, so I'll definitely be reading much more into the documentation of the plugins.

Will also need to try using huffyuv as the video codec to see if decoding lagarith is playing a big role in my I/O bottleneck.

Edit:
Ok, switched over to ST and haven't really lost any performance. I tried 2.5.8 with SetMemoryMax and it seemed 1024 applied properly since vdub took up 1.2GB RAM once encoding started. I moved up to the latest 2.6 ST build and it improved performance a bit. I'm currently running 5 scripts and averaging about 1.5fps on each (~3fps just running one) with 1.2GB RAM on each process, so at least the Large Address Aware thing isn't necessary (no performance difference either). I'll post how the video actually looks once I get it through anri-chan, but this picture shows what I'm currently trying to fix from the ChromaMotion process: http://i.imgur.com/Isokc.jpg

You can see the string from that enemy has a bit of ghosting on where it will appear next frame (just below), as well as the .x1 on the clock ghosting from the previous frame, which had a 3. Not sure if that's bad enough to be a dealbreaker or how it'll affect other games yet. Neither of these occur with chromamotion off, but otherwise there's really bad bobbing on certain static sections. For this game, they're immediately prevalent right at the start and also occur in a bunch of places when the camera is still. I'll be posting in the main doom9 thread for QTGMC to see if anyone there has ideas. There's a setting for "SrchClipPP" and I could get it to improve in-level parts, but the opening screen still looked bad (bunch of single-pixel lines), so not sure if there's anything else to adjust.

[url=http://www.gamefront.com/files/22077830/explode_PJs_computer_with_XQ.mp4]Test video (ignore the filename).[/url]

Here's the script I was running.
[hidden][code]SetMemorymax(1024)
avisource("lkj1.avi")
#Trim(461,2579)
Trim(3569,8148)
#Trim(9459,14225)
#Trim(14842,17813)
AssumeTFF()
chop=(last.framecount/5)
trim((chop*0)+1,chop*1)
QTGMC(Preset="Medium", sourcematch=3, sharpness=0.3, chromamotion=true, TR0=1)[/code][/hidden]

nate

2012-08-04 11:47:09 am

be sure you're running the latest version of lagarith when you test pipeline bottlenecks.

Aftermath

Edit history:

Aftermath: 2012-08-05 01:29:11 pm

2012-08-05 12:42:32 pm

Quits halfway

I have lagarith 1.3.27, which is the latest as far as I know. Running the video from huffyuv didn't present any performance gains, so I guess that's out. Writing to another disk didn't help with HD footage, but majorly did with SD since it could write so much faster.

Just to be sure I was processing it correctly, once PJ sent me the .VOB I trimmed it in vdub and saved it into YUY2 Lagarith. From what I had been reading, the colorspace of DVD has 12 bits per pixel, with each chroma channel spread out over 4 pixels, so that would be like 4:1:1 or 4:2:0? Saving as YV12 had some quality loss, so I'd assume it's 4:1:1? Anyway, hopefully I didn't mess that up, I didn't see any guides on the KB or doom9 which mentioned colorspace. Going back to the deinterlacing, with SD footage the scripts are taking up just about 1.1GB each, is that load unacceptably high? I could try to find a sweeter spot for SetMemoryMax, but the speed difference from 512->1024 is 3-4x.

With 5 scripts (will be buying more RAM in the next few weeks T_T) I was able to get encoding at 50+fps with the following settings: QTGMC(Preset="Medium", NoisePreset="Slower", sourcematch=3, chromamotion=true, TR0=1, sharpness=0.3). I'm not sure what fps it was, but given the length of clip vs encode, it was probably right at or under 30fps total with the 8 scripts.

I added the sharpness to have the output match still scenes from my HD capture. NoisePresets didn't make any difference on my captures, but really, really helped with the composite SD captures. ChromaMotion very slightly increases the rainbow effect and blurred the fast moving digits of the timer, but helps out in so many other ways that I believe it's worth it. Dot crawling is something that probably happens with a huge amount of captures, or maybe it's something else, I'll be trying to look into seeing if I can find a consistent script to help alleviate it. QTGMC reduced the shakiness on the edges of static things though, compared to mvbob.

Mvbob does look sharper, but I'm guessing that's just because the sharpness is sitting up near 1 instead of .3. There's a big difference on my HD footage, so I'm surprised that mvbob does look so good on the SD footage.
The attachments weren't working, so I had to upload to gamefront again, QTGMC and mvbob. Both videos made use of the extra bitrate, so figured I'd just use that to show the difference.

I have lagarith 1.3.27, which is the latest as far as I know. Running the video from huffyuv didn't present any performance gains, so I guess that's out. Writing to another disk didn't help with HD footage, but majorly did with SD since it could write so much faster.

Just to be sure I was processing it correctly, once PJ sent me the .VOB I trimmed it in vdub and saved it into YUY2 Lagarith. From what I had been reading, the colorspace of DVD has 12 bits per pixel, with each chroma channel spread out over 4 pixels, so that would be like 4:1:1 or 4:2:0? Saving as YV12 had some quality loss, so I'd assume it's 4:1:1? Anyway, hopefully I didn't mess that up, I didn't see any guides on the KB or doom9 which mentioned colorspace. Going back to the deinterlacing, with SD footage the scripts are taking up just about 1.1GB each, is that load unacceptably high? I could try to find a sweeter spot for SetMemoryMax, but the speed difference from 512->1024 is 3-4x.

With 5 scripts (will be buying more RAM in the next few weeks T_T) I was able to get encoding at 50+fps with the following settings: QTGMC(Preset="Medium", NoisePreset="Slower", sourcematch=3, chromamotion=true, TR0=1, sharpness=0.3). I'm not sure what fps it was, but given the length of clip vs encode, it was probably right at or under 30fps total with the 8 scripts.

I added the sharpness to have the output match still scenes from my HD capture. NoisePresets didn't make any difference on my captures, but really, really helped with the composite SD captures. ChromaMotion very slightly increases the rainbow effect and blurred the fast moving digits of the timer, but helps out in so many other ways that I believe it's worth it. Dot crawling is something that probably happens with a huge amount of captures, or maybe it's something else, I'll be trying to look into seeing if I can find a consistent script to help alleviate it. QTGMC reduced the shakiness on the edges of static things though, compared to mvbob.

Mvbob does look sharper, but I'm guessing that's just because the sharpness is sitting up near 1 instead of .3. There's a big difference on my HD footage, so I'm surprised that mvbob does look so good on the SD footage.
The attachments weren't working, so I had to upload to gamefront again, [url=http://www.gamefront.com/files/22085198/ch2mpcm_IQ.mp4]QTGMC[/url] and [url=http://www.gamefront.com/files/22085199/ch2mpmvbob_IQ.mp4]mvbob[/url]. Both videos made use of the extra bitrate, so figured I'd just use that to show the difference.

nate

2012-08-05 08:31:09 pm

i've always believed dvd video was yuy2, yeah.

TheThrillness

Edit history:

TheThrillness: 2012-08-06 11:33:09 am

2012-08-06 11:09:40 am

thethrillness.blogspot.com

I can't remember the topic but it was when someone showed that the 4/3 statid on LQ cuts off the text. My friend has the same problem with 4/3 right now as he is encoding. He has chosen to encode 16/9 as it fixes the problem but should I tell him to just shorten his statid text instead? The game is Resident Evil on the Gamecube.

nate

2012-08-06 12:02:59 pm

video should always be encoded with the correct aspect ratio. if you encode it wrong, in the best case i will have to correct it before it goes up and hate you forever, and in the worst case i will just reject it.

UraniumAnchor

Edit history:

UraniumAnchor: 2012-08-06 12:08:11 pm

2012-08-06 12:07:42 pm

Not a walrus

A better way to fix it in your case would be to manually adjust the LQ AVS file, most likely. I forget if Anri tries to overwrite it every time, though.

Magnum66

Edit history:

Magnum66: 2012-08-06 12:10:34 pm

2012-08-06 12:10:10 pm

http://twitch.tv/Exisidis2

So Nate should Resident Evil on Gamecube be 4/3 or 16/9? If 4/3 I'll have to reencode.

It looks perfect the way it is so I imagine it's correct.

Sir VG

2012-08-06 12:13:50 pm

Fucking Weeaboo

Quote from UraniumAnchor:

A better way to fix it in your case would be to manually adjust the LQ AVS file, most likely. I forget if Anri tries to overwrite it every time, though.

If you edit the file in the program files section, it's a permanent change. If you just do the project folder, it's just for encoding that project. That's what I do with my statIDs for stuff I encode personally.

nate

2012-08-06 12:18:16 pm

usually anything originally released before about 2006 is 4:3. having said that there are a few exceptions and some games also let you pick the aspect ratio for display. i didn't think the remake for gamecube was 16:9 but it could have a widescreen mode i forgot about.

Magnum66

2012-08-06 12:21:17 pm

http://twitch.tv/Exisidis2

That's my MQ encode of my run done in 16/9. Does that look acceptable Nate?

Magnum66

2012-08-06 02:02:52 pm

http://twitch.tv/Exisidis2

Nevermind, just to be safe I'll reencode again for the billionth time lol. Putting it as 4/3 and shortening the StatID.

nate

2012-08-06 05:28:35 pm

yeah that definitely should be 4:3. chris looks like a pygmy.

honorableJay

2012-08-06 05:38:02 pm

The Dork Knight himself.

Quote from nate:

chris looks like a pygmy.

That should be an optional question for people who don't know the difference between 4:3 and 16:9 when encoding videos. Maybe you could implement a vdub comparison (similar to checking for interlaced fields and bobbing) with one window having each aspect ratio. Maybe even name it the pygmy test Smiley

TheThrillness

Edit history:

TheThrillness: 2012-08-08 10:46:10 am

2012-08-08 10:45:45 am

thethrillness.blogspot.com

I was wondering something. Recently I was upscaling some SD footage to HD (in a different program) and noticed colorspace issues from the source (the 720p file had assumed bt.709 when it ofcourse was originally bt.601). How does anri-chan select the bt.709 colorspace for SD LQ, MQ, HQ etc (as x264 would assume bt.601 since the output is SD resolution) if you were supplying a 720p bt.709 source when the bt.709 would only relate to IQ and XQ?

Aftermath

2012-08-08 10:51:39 am

Quits halfway

It encodes everything to 4:2:0, regardless of whether the input is YUY2, YV12, RGB, or any other standard.

TheThrillness

2012-08-20 08:01:32 pm

thethrillness.blogspot.com

I was pleasantly surprised that I was able to frame serve to anri (I guess since it uses frameserve compatible programs it can but still I am happy). I'd much rather do some real editing in Vegas and then just encode with anri instead of supplying frame numbers, especially if you have lots of segments and long video files.

djcj

Edit history:

djcj: 2012-09-01 09:09:15 am

djcj: 2012-08-31 11:12:23 am

2012-08-31 11:11:04 am

Quote from moooh:

yeah do indeed post this in the thread that DJS linked or you'll risk that your suggestion isn't seen by the right people.

So I'm gonna post my suggestion here:

When anri creates the AVS scripts it adds a statid to every single script. Sometimes on the low resolution
versions parts of the lines are not visible when they're too long.
I think this can be avoided by adding the statid only to projectname_source.avs.
It'll automatically be resized by the other scripts and if you want to manually change the informations you
only have to change a single script.

PS: This might however get ugly if the game is recorded at half vertical resolution and not resized in the first place.

EDIT:

Suggestion for anri-chan:
Get rid of the "-lc" command for NeroAacEnc.

Solution for half vertical resolution sources:

source.avs:
import("C:\Programme\anrichan3.3\plugins\plugins.avs")
run = avisource("video.avi") #resolution: 720x288, correct AR: 4:3
statid = nate_statid(run.lanczos4resize(640,480),"bla","n","n")

LQ.avs:
import("source.avs")
statid.lanczos4resize(320,240)++run.lanczos4resize(320,240)

[quote="moooh"]yeah do indeed post this in the thread that DJS linked or you'll risk that your suggestion isn't seen by the right people.[/quote]

So I'm gonna post my suggestion here:

When anri creates the AVS scripts it adds a statid to every single script. Sometimes on the low resolution
versions parts of the lines are not visible when they're too long.
I think this can be avoided by adding the statid only to projectname_source.avs.
It'll automatically be resized by the other scripts and if you want to manually change the informations you
only have to change a single script.

PS: This might however get ugly if the game is recorded at half vertical resolution and not resized in the first place.

EDIT:

Suggestion for anri-chan:
Get rid of the "-lc" command for NeroAacEnc.

Solution for half vertical resolution sources:

source.avs:
import("C:\Programme\anrichan3.3\plugins\plugins.avs") 
run = avisource("video.avi") #resolution: 720x288, correct AR: 4:3
statid = nate_statid(run.lanczos4resize(640,480),"bla","n","n")

LQ.avs:
import("source.avs")
statid.lanczos4resize(320,240)++run.lanczos4resize(320,240)

Attachments:

2012-09-01 09:16:53 pm

There's not going to be an anri 3.4 coming from me, so you'll have to fix the scaling yourself or hope that someone else will continue the work. But this should be easier: open up plugins\sda.avs, change line 4 to "FontSize = round(headerwidth * 0.056)".

Quote from djcj:

Suggestion for anri-chan:
Get rid of the "-lc" command for NeroAacEnc.

Any specific reasy why? Anyway, the lc switch isn't forced in a WAV64 version of anri which you can find on the first page.