XviD-14112002-1...

[Koepi]

_first pass_ with defaults _discards the bitstream_ and just writes a statsfile.
Tht's a wished behaviour.

I don't understand the problem. Just look at the xvid settings panel, check that checkbox off and you'll end up with a >1GB avi after first pass.

EDIT: and with bframe offset... just point your mouse into the field and wait for the tooltip to show up. I've changed the formula how bframe quantizers are calculated:
Bframe quant= (((previous+future pframe quant)/2) * quant_ratio) + offset / 100

EDIT2: you got a preview in vdub before? Then you did a "full recompress" which converts the video into RGB space. So all your old encodes suffered serious quality degradation.

(it isn't the first of april, right?)

[scorchED]

thanks a lot!
i made the mistake to load the defaults after XviD installation and forget to uncheck "discard first pass". i stupid mistake i know:rolleyes:
i ever use fast recompress - i'm not soooo stupid, you guess me.
the first pass end up into a so small moviesize so i don't need a second pass mostly in 640x352 resolution, and the picture quality is fine.
i pointed the mouse over b-frame quantizer offset i read the text, but i didn't understand it really. maybe it's because of my english.
Could you explain it in this thread, what this option is doing, please?

[The Link]

Using b-frames with Koepi´s latest build the playback freezes from time to time (it hangs ~1sec and then goes on playing). It´s always the same if I use b-frames alone or with q-pel etc.
This only happens if I do not use ffdshow for decoding. I thought the already mentioned (in this forum) b-frame decoding issues got fixed. That´s why I want to report this.
Anyway the picture quality is greate even with b-frames.

Regards,

The Link

[Gaia]

Originally posted by The Link
Using b-frames with Koepi´s latest build the playback freezes from time to time (it hangs ~1sec and then goes on playing). It´s always the same if I use b-frames alone or with q-pel etc.
This only happens if I do not use ffdshow for decoding. I thought the already mentioned (in this forum) b-frame decoding issues got fixed. That´s why I want to report this.
Anyway the picture quality is greate even with b-frames.

Regards,

The Link I have seen this sometimes but i think it has nothing to do with Xvid.

[ErMaC]

Try turning down your Post Processing settings. With the DivX5 filter and B-Frames you will sometimes get this because that's how the codec deals with too much CPU usage. B-frames take more CPU than normal so if your system is just barely keeping up in the first place then b-frames will cause problems.

[The Link]

Yes, probably my PC (P3 667) is too slow for the XviD dshow filter. Since there´s nothing to change (or am I too dumb?) in XviD dshow filter I´ll just stick to ffdshow for decoding bframes.
I should think before I post ... sorry!

Regards

The Link

[vinetu]

@The Link :
Try the filter in first post here:
http://forum.doom9.org/showthread.php?s=&threadid=37800
(just copy over current xvid.ax file in %system% folder)
your CPU is fast enough...

[scorchED]

Nobody can explain in which way "b-frame quantizer offset" influence the quants of b-frames?
i start some encoding with parameters of 100 150 and 200.

[Koepi]

scorched, now you start to annoy me.

Let me quoe myself from my post above:
Bframe quant= (((previous+future pframe quant)/2) * quant_ratio) + offset / 100
PLEASE do some maths, test 1-2 values, and see what happens.

I won't explain the use of a calculator here.

This kind of ignorance really wastes my nerves. :(

(forum rule 4 comes to mind)

Koepi

[wotef]

nicht alle können wir gerade entlang erhalten? <-- google translation

- wonder if someone could explain to me, if i encode something and saturate the codec with 100% quantizer 2 --> is there any benefit of having b-frames? or not?

how comes if i encode (say a 250 frame video, and say i set a desired filezise of 1 gigabyte, with all default settings, except the b-frame control) 2-pass with b-frames but also an otherwise identical 2-pass with no b-frames --> resulting file is smaller with b-frames enabled?

[Koepi]

hm, dr. google miserably failed - that makes exactly... _non_ sense :) (did you mean "not everybody get's it straight away"? That could be a word-by-word translation.)

To your question:

If you saturate the codec without bframes at quant 2 (you aim for 1.1 GB and get e.g. 1.0999GB), then leave your hands off bframes. Bframe decoding takes more CPU power, your i-p-frame-only encode is watchable on even older computers.
But - you can set the bframe parameters that way that they (most likely) increase the filesize: e.g. quant ratio =< 100 and offset 1 (or offset=0).

I hope this helps.

Koepi

[wotef]

thanks, koepi, ok i think i'll leave b-frames alone for the moment :scared:

erm, heh, yes, my translation was "can't we just all get along?"

fyi, futurama season 2 dvd box-set is now available :D

[Teegedeck]

Originally posted by scorchED
Nobody can explain in which way "b-frame quantizer offset" influence the quants of b-frames?
i start some encoding with parameters of 100 150 and 200.

Well, I'm very bad at maths; but just for you I took pen and paper and tried to figure it out...

It seems to come down to this: If your B-frame quantizer ratio is just 100% and your B-frame quantizer offset is 100, too, your B-frame quantizer will simply be the average of the preceding and following P-frame +1. I.e. P-frame(quant3), B-frame(quant4), P-frame(quant3).
If you raise the offset to 200, the B-frame quantizer should come out (average of the preceding and following P-frame +2): P-frame(quant3), Bframe(quant5), P-frame(quant3).

If your B-frame quantizer ratio is higher than 100%, B-frame-quant won't be just P-frame-quant+1, it will rise exponentially the higher your P-frame quants are. Say, at B-frame quantizer ratio 150%, P-frames at quantizer 3 will trigger B-frames at (theoretically) quantizer 5.5, P-frame-quant 4 will trigger B-frame-quant 7 and this effect grows stronger, the higher you P-frame quant is and/or the higher your B-frame quantizer ratio is.

Basically, B-frame quantizer offset seems to me as a way of minimizing this exponential effect. Before it was there, B-frame quantizer ratios <200% seemed pretty ineffective to me - now 200% is definitely too much.

You might even try setting B-frame quantizer ratio to 100% and just use the offset, who knows if it looks better before someone tested it? All I wrote is purely theoretical, I haven't tested it at all. :rolleyes:

Please someone correct me if I'm wrong.

[The Link]

@vinetu

Thanks! I think that´s exactly what I need but unfortunately I can´t connect to the server. :(

[scorchED]

@Teegedeck
i am very pleased with your explaination.:rolleyes: i tried too explain it myself in this direction, but hadn't time to make some calculations.

[Didée]

Alas, I have to report major problems with the builds 20.11.2002.2300(insta-build), 20112002(koepi), 21112002(koepi).

Though everybody seems to be satisfied (In particular, I wonder because Iago reported outstanding quality), for me the combination of B-frames & QuarterPel with these builds is unusable.
I get very annoying blocks popping around all over the frame, in sequences where B-frames are used. I have attached a very short avi clip that shows this problem. It is very ugly compressed (only for attaching here), but shows the problem still very well. The effect is the same even with constant quant=2.

It's not a decoding problem - ffdshow, xvid.ax, Vdub, all show the same.

As soon as I switch off qpel, the encoding is fine.
To be on the safe side, I uninstalled XviD, rebooted, and installed again. No change.

However, the special build koepi had on his side a few day ago (the one that was for B+qpel ONLY, with ?one special block-type? disabled), is the only build that works fine for me with B+qpel together. Therefore, I assume that the problem with this one block-type still isn't really resolved in the latest builds.

Nobody experienced this problem up to now? I can't believe ...

<attached: snip_avi.zip, 85kB>

[JimiK]

Yes, I also experienced this problem. I didn't mind too much because I normally don't use QPel. But of course this seems to be a bug and should be reported.
I've also got some problems without QPel, using Koepis 21112002-1 build. Codec was set to 4 consecutiv Bframes max, ratio and offset to 200%. The avs-script looks good in VDub and for encoding I used AVS2Avi. It's not an dshow problem, because it also shows in VDub in the encoded movie. Now the problem is that I cannot reproduce this, it occurs somewhat randomly. In one short encode it appeared and in the next with the same settings it was gone. But I've got many of those frames in the movie. I cannot explain how it looks, so just wait until the attachment is confirmed.
Still it's great how fast development is going on. In a way, wouldn't it be boring if everything would work from the start? :) Thanks to everybody who's involved in developing or testing.
Best regards,
JimiK

[JimiK]

this one looks weird

[Shayne]

I to have found nov 21 bug, Shoot quality is good but flashes like this make it impossible.

Qpel and Bframes 3 150

Divx 3 macro blocks is what it reminds me of

[SleepEXE]

Didée, I downloaded your sample clip and can see the artifacting in Media Player manifested as shimmering in the man's hair, and a "dirt trail" as he turns his head. But if I open it in VirtualDub where the VFW codec is used, the artifacts aren't present. I imported it into Vdub with AviSynth's DirectShowSource and the artifacts reappeared. I checked my ffdshow settings and noticed I had it set so that ffdshow handles all rendering. When I set the option "Decode using XviD", the artifacts disappeared again.

For me, these errors appear to be specific to ffdshow. Are you guys seeing something different?

I have Umaniac's Nov 20 23:00 build installed.

A curious sidenote, I had an instance a few days ago of gross block errors (like the "dirt trail" from the man's head) on a HuffYUV capture encoded with Koepi's 20021004 build. No B-frames or QPEL were used. That was the first time I have ever seen that with the XviD codec in the 11 months I've been using it, comprising some 200+ encodings. And I can't assert that it had anything to do with Koepi's 20021004 build since I've used it quite a bit (probably 30 jobs) and haven't seen the problem before. I had already discarded the source material so I couldn't test reproducing it.

This behavior actually has me a bit concerned because I often don't watch the material until long after I've discarded the source. Months of use have conditioned me to take for granted that the XviD codec won't "allow" these gross block errors. I use what are generally regarded as safe, well-tested settings...among them, not restricting the codec with extreme limits and always keeping the second pass bitrate at about 60% of the first so as not to starve the codec.

Best regards,
SleepEXE

[HarryM]

Use only qpel or b-frames, don't b-frames + qpel, don't GMC.

[JimiK]

I did a few tests and it could be that my problem (colorful macroblocks) could be related to AVS2Avi. At least in my VDub encodes I never saw those blocks. With AVS2Avi 1.15 I could "produce" blocks in different test, but in different places, although I always used the same settings. That does not mean that I'd guarantee there are no blocks with VDub. And a question to the XviD developers: is XviD deterministic? Why do I get with the same settings different sizes (only 1kb or 2kb off)? Is this a problem of Avisynth and its filters or is it an XviD "problem"? That I get a size of 10005kb in the first encode and 10006kb in the second means they're not the same, right?
Best regards,
JimiK
P.S. This is not meant as critics, but only as a bug report. And maybe it has nothing to do with XviD.

[Didée]

BTW, JimiK,

about your settings:Originally posted by JimiK
Codec was set to 4 consecutiv Bframes max, ratio and offset to 200%
Seems like a little overkill, at least for my taste.

Are you aware that these settings produce

P-quant = 2 --> B-quant = 6
P-quant = 3 --> B-quant = 8
P-quant = 4 --> B-quant = 10

Not that these high B-quants should produce the defects you showed in your screenshots, no.
But I simply think that 4-200-200 is kind of "brute-force" (quantizer at 6 where the codec tries to produce its very best quality, wohoo!).

These are not your settings for final encodings, are they?

[JimiK]

Yes, you're right. Iago wrote that he did tests with 150-150 and with 200-200 and then used the latter for his encode. But I already switched to offset:100, ratio: 150.
P-quant=2 --> B-quant=4
P-quant=3 --> B-quant=5 or 6?
P-quant=4 --> B-quant=7
Maybe that's a to conservative setting. I'm trying to get 4 ST-TNG episodes on 1CD, using 2 audio tracks, each episode 40 mins, size 480x360. So there is some compression to do. I reencoded the episode with the errors again in VDub and now they're gone. Seems really to be an AVS2Avi problem. Perhaps it has something to do with the B-frame handling that DaveEL mentioned.

Best regards,
JimiK

[HomiE FR]

Hi all!
I had some undersize problems while encoding LOTR on a 800MB CD, so I thought this would be interesting to post something to see what Koepi or any other XviD tester or developer thinks of that :
(if the post seems to long, just look at the end. I think that there is a problem between B-frames and alt-cc)

The Lord of the Rings - The Fellowship of the Ring (standard version)
DVD Zone 2 (PAL 25fps)

Software used to rip the DVD :
1. SmartRipper 2.41
2. DVD2AVI 1.76
3. Avisynth 2.07
4. VirtualDub 1.4.10 (Fast recompress)

Avisynth script used :
LoadPlugin("C:\Program Files\Video\Avisynth 2.07\MPEG2Dec.dll")
Clip=MPEG2Source("D:\DVD\LOTR\vts_01.d2v")
Start=trim(Clip,0,1315).Crop(0,79,720,418).BilinearResize(720,304)
Movie=trim(Clip,1316,245539).Crop(0,79,720,418).LanczosResize(720,304)
Credits=trim(Clip,245540,256596).Crop(0,79,720,418).BilinearResize(720,304)
Return Start+Movie+Credits

XviD settings (Koepi 21-11-2002-1 ALPHA) :

Global settings :
Motion search precision : 6 - Ultra High
Quantization type : H263
FourCC used : XVID
Maximum I-frame interval : 300
Minimum I-frame interval : 1
Enable lumi masking : OFF
Enable interlacing : OFF
Quarterpel : OFF
Enable greyscale : OFF
Use chroma motion : OFF
Global Motion Compensation : OFF

B-frames control :
Maximum B-frames : 2
B-frame quantizer ratio (%) : 150
B-frame quantizer offset (%) : 100
Packed bitstream : OFF
DX50 B-VOP compatibility : ON
Enable debug info on each frame : OFF

Quantization :
Min I-frame quantizer : 2
Max I-frame quantizer : 6
Min P-frame quantizer : 2
Max P-frame quantizer : 16

Two-pass tuning :
I-frame boost (%) : 0
Discard first pass : ON
Dummy 2nd pass : OFF
Below I-frame distance (frames) : 10
I-frame bitrate reduction (%) : 30

Hinted ME : OFF

Alternative curve compression :
Use alternative curve system : ON
Curve aggression : Medium
High distance from average (%) : 450
Low distance from average (%) : 100
Enable automatic minimum relative quality : ON
Strength (%) : 30
Enable automatic bonus bias calculation : ON

Max bitrate (Kilobit/s) : 10000
Max overflow improvement (%) : 60
Max overflow degradation (%) : 60

Credits :
Credits at end of movie : ON
Credits start at frame no. :
Credits end at frame no. :

Credits rate reduction :
I-frame quantizer : 16
P-frame quantizer : 16

2nd pass results :
Desired size : 749777 KBytes
Final size : 724196 KBytes -> 25581 KBytes undersize !!!

First I thought this could have been caused by the credits (I don't know why I thought about that but nevermind), so I compressed the credits separately. And I launched another 2-pass encode without the credits. The rest of the XviD options is totally the same : only there is no credits.

2nd pass results :
Desired size : 736591 KBytes
Final size : 711026 KBytes -> 25565 Kbytes undersize !!!

So the problem is still here, but I was stupid to think that the credits could have been the cause because the codec just take the size of the credits after the first pass (encoded with the quantizers at 16 like I set them) and then encodes the rest of the film with a size equal to the desired size - the size of the credits. So the credits are not responsible.
But I think now that the alt-curve could really be the responsible. I can't understand why, but maybe this curve compression doesn't support the B-frames yet (if this is obvious I'm sorry but I didn't know that). I'll do the same encode with the credits and with a linear scaling, and then with a "standard" curve compression, just to see if I'm right.

So just a question : does the alternative curve compression support B-frames yet ? Or is it totally normal to have such undersizes with this curve system ? I looked at DebugView during the encodes and I especially looked at the overview. I didn't see anything special, it seems that the codec did his job normally according to what was left in the overflow (just a few kbytes) but there is this huge 25000kbytes undersize. That's why I think that alt-cc doesn't support B-frames yet.

[scorchED]

i read somewhere in this forum that alt-cc has problems with predicting filesize when b-frames are used. so use only normal curve compression.

[iago]

Originally posted by Didée
Though everybody seems to be satisfied (In particular, I wonder because Iago reported outstanding quality), for me the combination of B-frames & QuarterPel with these builds is unusable.
@Didée

I didn't report outstanding quality, I just reported that "b-frames" and "qpel + b-frames" _worked well_ (based on only short test results as was stated) with uManiac's latest dev. build.

edit:

However, I can say that only "b-frames" ("Packed bitstream" unchecked / "DX50 B-VOP Compatibility" checked or unchecked) with the latest dev. builds (both Koepi's and uManiac's) have been working fine for me.

Also, since I've always had some problems when qpel activated (dunno why, perhaps due to "qpel", perhaps due to the combination of "b-frames + qpel", perhaps due to my system), I keep my hands off everything except b-frames for the time being.

regards,
iago

[Bulletproof]

For me with koepi's build I can only use B-frames. If I enable only Q-pel with default settings, quantizer at 2, I get smearing effects and that's with B-frames off.

[iago]

@Bulletproof

I agree that smearing effect is very visible whenever qpel is turned on (alone or with b-frames).

iago

[ookzDVD]

@Koepi,
Talking about B-frame offset, do you know the "internal" value before it become visible (as parameter) ?

Second, is your stable build 04102002 support YV12 ?

@Forum,
Is it save to use MPEG-Custom with B-frame ?

Thank you.

[Foxer]

Originally posted by scorchEDi read somewhere in this forum that alt-cc has problems with predicting filesize when b-frames are used. so use only normal curve compression. I included b-frame curve compression code in both normal cc and alt-cc portions of the size prediction correction code so alt-cc doesn't have any problems normal cc doesn't have. heh

[Koepi]

Heh, as usual, it's the secret of tweaking AltCC correctly I guess ;)

Ah, xvid-04102002-1 unfortunately doesn't support YV12-decoding.

Btw....:
XviD-25112002-1:
- Fresh CVS checkout. Major & minor bframe bugfixes.

Iago, you may want to check with qpel again... those trails/smearing effects could've been caused by some buggy bframe code (never mix up x and y ;) ).

Enjoy!

Regards
Koepi

EDIT: I forgot to mention that this build includes ReferenceDivX' great lumi masking code, based upon HVS. This means great quality even at high quantization levels, and much less blocking in dark areas. You should definatly give it a shot, it's working amazingly good!

[HarryM]

Originally posted by iago
@Bulletproof

I agree that smearing effect is very visible whenever qpel is turned on (alone or with b-frames).

iago

When you use much higher compressibility (65%-75%), you eliminate smearing effect.

[Foxer]

@koepi

Hmm? Secret of tweaking AltCC correctly?
Tweaking CC doesn't change size prediction's targetted size and so, should affect the resulting filesize very very little.

[Koepi]

@Foxer:

You _can_ get an impact on size predictability with AltCC, i.e.:

Agression: low
High distance: 500
Low distance: 500

in a high action movie ;)

I hope you get the idea - I just meant that with "wrong" settings you can get a different filesize as desired.

Best regards
Koepi

[iago]

Originally posted by Koepi
... XviD-25112002-1:
- Fresh CVS checkout. Major & minor bframe bugfixes.

Iago, you may want to check with qpel again... those trails/smearing effects could've been caused by some buggy bframe code (never mix up x and y ;) )

I forgot to mention that this build includes ReferenceDivX' great lumi masking code, based upon HVS. This means great quality even at high quantization levels, and much less blocking in dark areas. You should definatly give it a shot, it's working amazingly good! @Koepi,

Yes, my friend, absolutely I will try the new build right away! Especially, I'm looking forward to see the results of the new lumi-masking code!

best regards and thanks for the new binary,
iago

[Koepi]

@iago,

I'm looking forward to hear your oppinion dostum! :)

Serefe,
Koepi

[HomiE FR]

Foxer and Koepi : Sorry to bother you again about my problem but my alt-CC settings have not been set by "instinct". If you look at the settings I put :
High distance : 450 % (there is less than 1% higher than this point and the max distance within the movie was +1010%)
Low distance : 100 % (about 50% of the frames are between -50% and -100%).
Curve aggression : Medium (Koepi said it was the best choice in most cases just a few days ago if I remember right)

So I think these settings are totally safe.
Moreover I really can't understand when Koepi talks about 300 in low distance... I personally think that frames can't have a negative amount of bits (even frame dropping isn't enough :) ) and I thought that 100 in low distance already put the limit at 0 bytes for a frame (average frame size - 100% * average frame size). So setting the low distance above 100 just puts it to 100 I think... When Koepi's joking you have to think to understand the joke! :p

So now I've done the same encode with the same settings, except I chose a standard curve compression with default settings (high bitrate : 25% - low bitrate : 10% - payback delay : 250 frames) and there isn't any filesize problem !
Desired file size : 749777 Kbytes
Total file size : 749890 Kbytes (113 KBytes oversize)

So I do go on thinking that there might be a problem with B-frames in alternative curve system. I don't think LOTR is a "special" movie, so I'll try the same thing with other movies to be sure it's not caused by the source, but this is highly unprobable I believe.

[Sofus]

Hello Koepi

Just did some testing with the new build XviD-25112002-1
ReferenceDivX' new lumi masking code seem to work fine with out B-frames
With B-frames it generates lots of rough pixels, both with and without Qpel.

Settings:

Croma motion = off
GMC = off

Maximum B-frames = 3
B-frame quan. ratio = 150
B-frame quan. offset = 100
Packed bitstream = on
DX50 B-VOP com. = on

Sofus :)

[Teegedeck]

As we seem to be discussing new lumi-masking here, I've moved my original post.

We have a problem with lumi-masking and contrasts, now. :(
Apart from that, the new version is absolutely OK for me.

Some out-of-place pixels, typically white pixels in grey areas and vice-versa, not only on the edges, watch the upper-left area.

Koepi's build, H.263, constant quant=2, no B-frames, no GMC, no quarterpel.

[Sofus]

Update !

The rough pixels seen, when enabling b-frames and the new lumi masking code, seems to come from way to small file size.

Lumi masking on
B-frames off
14.1MB

Lumi masking on
B-frames on
1.36MB

Sofus

[Shayne]

@Koepi Is this correct would like to hear your response to the strange artifacts people have posted here.

Originally posted by HarryM
Use only qpel or b-frames, don't b-frames + qpel, don't GMC.

[Koepi]

I'm currently testing if those problems are solved with the correction of the x+y-mixup.

Regards
Koepi

[celeron]

well i made some tests whit this new build and the trails/smearing effect in the use of bframes+qpel its gone(well i dont see it).
But the new lumi masking in my test work very well the only prob. i see whit that its in decode, the sample plays a little slow but whit xvid.dll or ffdshow.

PS: sorry very bad english

here its a shot whit bframes(3/150/100)+chroma motion+lumi masking.

http://pwp.netcabo.pt/celeron/bf-lm-cm.jpg

And another one this time whit Bframes(3/150/100)+Qpel

http://pwp.netcabo.pt/celeron/bfqp.jpg

[NoLogo]

@Koepi

Has the code for Hinted Motion Vectors been modified in the recent releases ? Because i made some tests, particularly two: classic encode (without any special or exotic options) and the same with HMV (and only HMV) and the results are quite... dissapointing.
The first one had quant from 2 to 8 (average quant about 4.5) and the second one (HMV)... it's really nasty: quant from 2 to 21 (average quant about 11). And there's no use to see what DebugVeiw shows to realize how poor the quality is: big macroblocs everywhere.
So, maybe it's a bug, maybe it was so earlier, maybe it's my system, but i already used HMV with older builds (yours from april or may, don't exactly remember), and it was much better than it is right now.

NoLogo

PS: If you want, I can find a way to give you some short parts of both files (with and without HMV), so that you can exactly see what i mean by "nasty".

[Foxer]

@HomiE FR

I just tracked down the undersizing problem..

I had accidentally missplaced a b-frame equation in the CC application code for altcc.. :rolleyes:

The fix should find it's way into the cvs sooner or later.

[NoLogo]

@Foxer

Does this bug have any influence on the first pass ? That is to say, do I have to stop my first pass after 12 hours, or can I let it run till it's over ?

NoLogo

[serbersan]

With the last stable Koepi 04102002 Build to use internal linear scaling we had to disable alt cc and put :
high bitrate scenes % -> 0 &
low bitrate scenes % -> 0

With the lastest dev builds to enable internal linear scaling Could I use the same trick? I mean this has changed?

I'm not using any new features only taking advantage of the YU12 compression speed.

EDIT: I've read in releases notes:

This dev-api-3 binary is most likely not producing standard conform bitstreams when some of the newer features are used, keep that in mind!

Without any new features those dev-api-3 builds are safe to use in quality and conform bitstreams? I don't know if the modifications in code are only in new features code or could affect more things. Sorry for my ignorance. At least in my last encode without new features and 21112002 all was fine. I could decode it with the lastest stable decoder (04102002).

[Foxer]

@NoLogo

Nope :) It only affects the second pass.

[HomiE FR]

@Foxer : Thanks ! I'm always happy to be useful. I find the alt-CC much smarter than the standard CC, so I was quite disappointed to see these huge undersizes...