Hi bilu,
I still find your results surprising, compared to my tests results. I'm with you that the better is finding a common way to use mencoder for everybody. But as I'm in PAL land, I cannot help with NTSC films. And if I find a nice way that just helps with PAL films, I won't through it away, but will post it, since it can help other people (as you do). Anyway, I'm not completely sure that the differences in our results are due to being NTSC or PAL, but don't know what the reason is.

I'm also with you with vbitrate=vrc_maxrate (lowering maxrate to 5000), but for long length films this will mean fitting just 1 film per DVD media. If you want to fit at least 2 films, you will have to lower vbitrate (with 1500 it worked for me) and maybe raise quantizers.

BTW: you could ask in mencoder news if it is possible to have working floating values for quantizers, it would be of much help.

I see you get no differences at all between vqcomp=0 or =1 when vbitrate=maxrate. I didn't reproduce that in my tests, I got differences.
And filesize differences between vbitrate=min or max are very little, taht again wasn't my case. You even get very little differences in avg and peak bitrate, but just in quantizers...

I'll keep making tests. But we could advise to employ notch-matrix, vqblur=0, naq (and scplx_mask), and vbitrate close or equal to vrc_maxrate. And for quality, use trellis+cbp+mv0. Quantizers min at 2 and max maybe at 10 (but if filesize too big it may be necessary to lower vbitrate and raise min quantizer). About vqcomp... I just would advise to test both and see results, by now. Let's see if we can come to a conclusion :roll: .

... and related to b-frames, I don't see much "enworsement", and it also helps to decrease filesize (and quality may be tweaked).

Nothing beats 2-pass encoding in this area :)
I'll try now with progressive streams, maybe B-frames are buggy with interlaced streams only. So I'll avoid them anyway, but PAL-only encoder won't need to :)

Now testing vbitrate=vrc_maxrate without naq... ;)
EDIT: Quantizers decrease even with vbitrate=9800. It never lost much quality in real life movies, will now test on anime ...
EDIT2: Tested. Still no good.

Bilu

Confirmed: B-frames work fine with progressive streams but not with NTSC. I'll try to find info on this subject. Removed every interlace-related setting before encode and it worked.

Will now repeat the vqcomp/vbitrate tests.

EDIT: Same conclusion, better to use vbitrate=vrc_maxrate. vqcomp=0 or vqcomp=1 is irrelevant.

EDIT2: A progressive stream done with interlaced parameters can do B-frames. An interlaced stream gets screwed up :roll:

@digitall.doc
Please read this whole thread:
http://www1.mplayerhq.hu/pipermail/m...er/040946.html


Bilu

Bold: Denoiser.May help with compressibility. il=d,il=i are for interlaced filtering.
Blue: needed for interlaced and NTSC encodes.
Violet: settings that improve quality at CPU cost.
Orange: May also help with compressibility. (raises quantizers)
Red: Only when using VOB sources directly.
Brown: Only with non-interlaced and non-telecined sources.
Green: Bitrate settings - using vbitrate=vrc_maxrate is recommended.

I said in the "brown" item that it was for non-interlaced and non-telecined sourced. I didn't said progressive because some guys call progressive to telecined sources (like Mencoder says :"24fps progressive detected, changing framerate...").


Bilu

I've abandoned scplx_mask=0.3:naq and quality improved a lot. Despite using naq, the spatial mask was raising quantizers even when I specified vbitrate=9800 :!:

Not anymore.... :twisted:

Bilu

@bilu,
I still have lots of tests to do (very busy at the moment, don´t have spare time). I even didn't read that thread you pointed me to (just read first post, and lost myself a little, but I want to read it thoroughly).

Well bilu, I think KVCD "philosophy" (and maybe I'm not the right person to talk about this forum philosophy, since I'm very new to this. And of course, you may already know the following) is not that. I think we try here to get the best results with 1pass encoding, and with constant quality. And with some other "flavours" (like notch-matrix, GOP, avisynth MA script,...) is what make the "miracle" :) . I don't remember many people here doing 2pass. And don't think that doesn't mean it hasn't to be done, since here people are very open-minded and accept suggestions out of the "official" (if any) line, but we're, in general, very happy with 1pass results.

Yes, I remember I tried this once. And maybe it works with high bitrates and low quantizers,... but this also means biiiig file sizes, isn't it?. And the advantage of making KDVD (apart from quality) is manage to fit 2, or even 3 films per DVD+-R media. And I'm afraid that without naq, if you have to lower bitrate to fit films, image will get worse (at least is what happened to me). For high bitrate encoding (that is, vbitrate=vrc_maxrate=9800), maybe is not necessary... but maybe also is not necessary notch-matrix, or filtering the film, since you will just be able to fit one film per media, and you'll have lots of bits to spare in standard matrix.

But, of course, this is just my opinion, and I'm not a very knowledge person :roll:

And, as everything that is suggested here and sounds intelligent to me, I'll also test it to see if it really raises filesize so much.

As some posts before, I'll say again that I feel sad that we're the only ones posting here our results with this encoder and our settings. It would be nice if other people posted here their results with these (vqcomp=0 or =1) settings to see if we can get at a point, and find a better way to employ this tool... since it looks thst it worth th effort.

Cheers.

Time always beats 2-pass ;)

-kwag

New tests, 1-pass encoding without B-frames:

- p_mask=1 increases quality;
- naq isn't worth it (better not to use scplx_mask at all);
- vrc_maxrate does the 1-pass bitrate control, vbitrate isn't worth it;
- using scplx_mask without naq can be used as an alternative to B-frames in interlaced encodings. And it's very good at lowering bitrates since it distributes the "damage", probably the best alternative in 1-pass encodings.But be careful with anime, edges are very sensitive to quantizing;

Couln't test vqblur=1 because I was working a very small sample.
But I don't think that is what we're looking for :?


Bilu

Yes kwag, you're right. I just said that we try here to encode 1pass, and take out the best of 1pass encoding, but didn't explain why. Of course, the reason is 2pass doubles encoding time.

bilu, what are sample length (in time) and what the file sizes you get?. I explained in my previous post that I wouldn't drop naq, since it helps when you have to lower vbitrate to shrink file size. If not, there begin to appear blocks all over :(

When you state that vrc_maxrate does the 1pass bitrate control, and vbotrate doesn't worth it, what do you mean?. Does it mean that you don't give vbitrate a value since bitrate is adjusted through maxrate (so, you leave it default=800)?. I ask because I noticed that when I lower vbitrate for filesize reasons, avg bitrate lowers...

Do you know how p_mask works?. I wanted to test it, but I don't know really how it works (and I think, as a *_mask it is, it will benefit from naq :wink: )

BTW, I read the thread you pointed me at. If I understood well, it was on b_frames. And sorry me if I didn't get it, but I took no conclusion. In a post was stated that knowledge "people" dropped b-frames (but no explanation why, and I even believe that they were mainly refering to mpeg4). In other post they argumented that b-frames gave little advantage in file size,... I have different experience, filesize decreased without noticeable loss of quality. And you always can adjust b-frames quality through qfactor,... Well, no conclusion for me.

Please, take a look at filesizes and stimated file size for the whole movie, and make me know. In my first tests I was also surprised by the quality I got, but then I realised I had to lose quality if I wanted to compare mencoder to other encoder in my real life KDVD encodings (at least, 2 films per media). For 1 film we have lots of tools out their (of course, without KDVD quality :D )

If I remember correctly, the original reason was that Tmpgenc does a much better job in CQ mode than in 2-pass VBR. But later when I created CCE templates, I found the quality to be pretty much the same (1pass vs 2 pass), but 2-pass was of course much slower. :wink:

If you don't want blocks, don't use scplx_mask at all.
I compared scplx_mask+naq against no scplx_mask at all and strangely the bitrates through the encoded sample are about the same but quantizers were bigger. No matter if I tried scplx_mask=0.1, 0.2 or 0.3, quantizers allways got bigger than using no scplx_mask but the bitrates were almost unchanged. Tried with vbitrate=300,1000 and 9800 and it never helped keeping the bitrate.
But using no scplx_mask looked better of course. Try it yourself comparing small samples through Bitrate Viewer.

But one of the most effective ways to lower the bitrate by distributing the quantizer increasing is scplx_mask *WITHOUT* naq.
Not a specific value, but it would be nice if we could somewhat do a compressibility test and increase scplx_mask as needed: scplx_mask=0.2, 0.3 ....
B-frames are a better method of course, if you're doing progressive encodes.
On all my tests so far (longest samples are 5 minutes long) it didn't made that much of a difference if I used vbitrate=300,1000 or 9800 - results were almost the same.
But vbitrate=vrc_maxrate looks a tiny bit better. :)
It won't benefit from naq IMHO because it's already seems to be kind of a temporal naq :)
Well, you're right: no conclusion for you :)
It's about MPEG-2, interlaced support and B-frames. It explains why it doesn't work well with interlaced encodings:
I'm getting to these conclusions:

Low-motion movies: Reduce vrc_maxrate.
High-motion movies: Use scplx_mask without naq. Don't reduce vrc_maxrate.
Anime: Just use a denoiser. Don't even try quantizing limits.

On low-motion most stuff won't get restricted so you can specify a max rate that you can trust (unlike vbitrate).

On high-motion it's important not to limit the max rate: explosions, blasts, pursuits, whatever, consume a lot of bitrate. So the bitrate decreasing must be distribuited though the whole stream. Besides B-frames, this is the best alternative left. Using naq here would cut the downsizing effect and you'd have to force a lower maxrate again.

Anime: every quantizer looks bad on edges :roll:
Denoiser is the best choice to decrease bitrate, but still no garantees.

PS: I didn't kept the files for measuring bitrates and filesizes, but I remember my conclusions and BV comparisons well. I can repeat the tests if it's that important, but I already know the conclusions I'll get ;)

Bilu

@digitall.doc

I'd like you to do a comparison between scplx_mask=0.3:naq and no scplx_mask or naq at all, in Bitrate Viewer.

You'll notice that quantizers are much higher using scplx_mask=0.3:naq but the bitrates will be almost untouched.

I know, it sounds strange :lol:
But check it yourself to see what I mean ;)


EDIT: Maybe the problem is that I'm asking too much from the rate control with such small samples, I shouldn't try with less than 30 minutes.
But I have a PIII-500 laptop that I need for other stuff, so don't blame me ;)
If that wasn't the problem maybe I'd be doing two pass instead of one :lol:

Bilu

They talk about b-frames in interlaced coding. And I live in a PAL country, no interlaced sources at all (maybe yes when I begin to encode my TV captures, but NOT now).
So, again, no conclusion for me. I keep with b-frames, and advise them for progressive source encoding.

Well, I did get differences in smaller samples, related to filesize and visual quality, of course being better with vbitrate=vrc_maxrate.

So, do you already know what p_mask is supposed to do?. I still don't, even didn't test it at all. If I thought that naq could help, it was because it was stated in man_page (naq helps when using *_mask).

bilu, I followed your last thoughts,... and got surprising results indeed :lol: .
Even if don't completely agree with you :roll: , always test (most of) your suggestions. My main objections to your suggestions were related to good quality but with very big filesizes (you erased your tests but I kept them, and they were too big). But here are my lasts results:
- with naq and scplx=0.5 33683 kB BR 4924-1634 Q 7.07-3.63
- without naq and without scplx 35917 kB BR 4764-1742 Q 7.64-3.46 (well different bitrates, and higher max quantizer with lower avg... not what we expected at all :evil: )
- no naq scplx=0.5 18858 kB BR 3784-915 Q 9.00-7.37 --> hey, hey wait a minute, quantizers raised a lot, and bitrate lowered a lot as file size, may it be a way? (you already suggested). Maybe 0.5 too high... and was done with maxrate=5000 and avg=1500. Let's change them:
- no naq scplx=0.2 vbitrate=maxrate=9800 33364 kB BR 5599-1619 Q 4.29-3.45
BINGO!!! file size similar to the first ("gold standard") test, better quantizers,... good.

Did several tests else, with this approach: vbitrate=vrc_maxrate=9800 (even =5000 with similar quality results, and little decrease in filesize), vrc_eq=tex (keep on :wink: ), naq=0 (you were right), and variable scplx_mask values... I have realised that scplx_mask accepts more figures (I even tested =0.255, and gave different results than =0.256), what helps us to adjust final filesize... very good.

Vissually it seems to me that image gets a little blurred (what does scplx_mask do?, does it filter/blur the image or just acts on quantizers?. Do you know the answer?), but very little, and NO blocks at all. Nice.

And with this high bitrates, quantizers keep low (but surprisingly didn't see them go under 3, even I set vqmin=2), independently what vrc:eq setting you use... but I prefer to keep at =tex, because it may be needed in other films-settings, and in my previous tests it helped more.

To sum up (too long post): better approach to use scplx_mask=0.15-0.35 (even 3 decimals) without naq. The rest, as we were using (I see you already opened a thread with this new settings, I post there some suggestions).

Keep on testing here

IMHO p_mask=1 averages between inter-MB quantizers, but I don't know if it does it spatially or temporally. Quality does improve a bit, bitrate rises a bit, may be a good thing to use with scplx_mask.

Best values for scplx_mask are between 0.2 and 0.3, I think.
0.3 is my favorite :) I've tried 0.5 but it was too much.

A little blurred is not that bad considering that you'll watch them on a TV output :) It will allways be better than VCD and at least as good as a sharp SVCD, the quality is prettty good. :)

The *_mask settings just act on quantizers.

I'd suggest 0.2 for better quality and 0.3 for better bitrates.
But for anime we should only use denoisers, even scplx_mask=0.1 is bad ;)

And as you've seen from my previous tests using scplx_mask=0.3 without naq together with hqdn3d the bitrates got allways under 3000 Kbps.
Maybe without the denoiser results are still that nice, and would be faster.
And my tests were without B-frames.

Bilu

It sounds like naq function...

Remember that you can use 0.22 and even 0.222 (maybe, this way, it can fit more to your taste)

So, if it just acts on quantizers, it shouldn't blur the image, isn't it?.
And... no, even to be seen on a TV set, I prefer not to have a blurred KDVD. Other thing is KVCD, that needs some blurring to make file smaller. But for KDVD I want the best image possible, since I don't know if the day after tomorrow I'll have a 60 inch TV set, and suffer of little image definition (that's why I encode in 16/9 aspect, the keep the best quality possible).

BTW: I did some encodings without mbd=2, without trellis and without predia and dia=-2, and speed changed from 4-5 to 5-6. Not a big difference. What would really make a difference is that mencoder accepted avs files (or better, mencoder included avisynth built-in, and encode directly from vobs, with internal avisynth filtering... a dream?). :roll:

I'm with you digitall.doc.
I also encode in 16/9 AR and I dream on buying a TV projector or a big TV set.
I'm pretty sure I'll have to live with a flat square 100Hz 32" TV set and a bit of blurring won't
be so noticable.
But when I joined the community I always aimed for best quality / fastest encoding.
That's what makeAVIS/mencoder seem to deliver.
But I also live in doubt: what if mencoder could internally read avs scripts?
Maybe it would be a bit faster than it already is.
Other doubt: most of the arguments that both you and bilu are trying right now. Do they blur?
If so there's no point in using them and avsynth filtering at the same time, right?
If mencoder could read avs internally I think I would only ask for one thing more.
And that is avisynth 4 linux. I've been working all day on a Linux box that has mplayer/mencoder.
But it lacks Avisynth scripting!!!
Hey, sh0dan :!: Can you hear me :?: Guys from Linux can use avs scripts...
Think he heard me :?: :lol:
Think he can do anything about it :?:
Hope he can surprise me one of these days :wink:

@rds_correia,
did you try mplayer/mencoder linux versions?, what about speed?.
Yes, it would be nice to have avisynth built-in mencoder, or at least mencoder compatible with avs script.

@all,
I could encode directly from vobs with vmesquita compilation, but couldn't with bilu compilation, and I know bilu is using his own compilation to encode from vobs. Have anybody met the same problems I did?. How can I solve them?

Bigger quantizers lose detail hence they blur the image.
In terms of detail a resize to a lower resolution can also be considered a sort of blur. And when you aim at lower bitrates you end up attacking higher frequencies by denoising or increasing quantizers, hence you blur.

If you don't want any blur, don't expect lower bitrates ;)
IMHO the most important is HOW you blur.

I think hqdn3d is good enough to allow me to abandon Avisynth :)

Avisynth is at the moment too dependent on Windows-specific assembly code, although the VFW part could be replace by the Linux AVIFile library.
This was my opinion the last time I checked, there are some threads on this subject in Doom9.

EDIT: The IVTC techniques from Avisynth are far superior to those from Mencoder. If you ever want to do NTSC to PAL conversions then you'll need Avisynth for sure. The only settings I'm using that lower bitrate are hqdn3d and scplx_mask=0.3, remove them for the best possible quality.

Bilu

My new default settings, work for PAL and NTSC, live movies and anime:

Most important changes: abandoned the denoiser and decreased the scplx_mask value. Quality is very good and detail is preserved even on anime IMHO. It's also faster, between 9/10 fps (PAL) on a PIII-500.

I abandoned the denoiser after some underwater scene encodes from "The Abyss". These scenes are very sensitive to denoisers.

These settings aim at quality, not at bitrates. To aim at better bitrates increase scplx_mask until 0.3, but not in anime.

On anime you can only count with denoisers, but don't expect much more than a 200/300 Kbps gain.


Bilu

By quality (and not bitrates) do you mean low quantizers and high or low bitrates?.
So p_mask averages inter-MB quantizers, hmmm... do you understand what does that mean? If you know how, please, put it in plain words (english, spanish, portuguese, don't mind, since the definition sounds chinese to me :? , since I'm not an expert on this :cry: ) I see you employ it at maximum value, what does it on quantizers/bitrate/filesize?. Did you test it together with naq (if you think is of a help)?

Well, now we are almost using the same command (instead of vqcomp=1 I use vrc_eq=tex: the same). I use also cmp and subcmp=2, don't know if it really helps (did you test them?). And was using mbd=2 (you use default=1, don't you), have to test differences with and without. And also was using predia and dia=-2 (from man_page: adaptive and faster): did you make a test?.

Sorry if I ask too much, but I have lot of things to do now, and if you already did the tests I avoid to repeat them (even I still think we get different results due to different sources).

bilu, do you have any clue to make your compilation work with vobs in my PC? (nice question, isn't it? :lol: ) since with vmesquita compilation it works (with no filter, up to 17 fps 8O 8O , no trellis no mbd=2 of course).
Please, make me now if you think in a way to solve this (didn't try yet amnon compilation you advised me... the only solution?)

New version, and maybe the last :)

By using mbd=2 and no denoisers I can use scplx_mask up to 0.25 with acceptable quality in anime. Trellis brought no noticeable improvements to the ringing problem I was having in anime with scplx_mask, so I won't use it.

So this one now works on every source I have :)

Bilu

It averages P-frame quantizers, don't know if it does it spatially (averaging MBs on a certain region of the frame) or temporally (averaging the macroblocks in the same region for a certain number of frames).
But it increases quality, bitrate and filesize a bit. A good thing to counterbalance the effect of scplx_mask, but not as bad as naq.

I won't use naq anymore because it renders the *_mask parameters useless. :roll:

cmp and subcmp make encoding slower and don't improve as much as trellis or mbd=2, at least that's what I read in the mailing list.
Bigger diamonds don't necessarily increase PSNR and sometime decrease it, and it's slow. Also read in the mailing list.

What errors do you have?
Have you tried more than one VOB source?

Bilu

The error I get is a Windows warning screen (I don't remember now the exact text, something about a number 000e45g0x0 or something, and the text software exception error at other number) and when I accept it closes the cmd window. Right at the begining of encoding (after displaying all mencoder messages)
About the source, I tried several vobs from the same film. But I don't think it's a matter of source, since with this source I managed to encode with no problem with vmesquita compilation...
I would like to test it with vobs, and begin to try different mplayer filters, to see how to get similar results to avisynth...
Don't know if you can help. Is it possible I have a library or something missing you already have, and that's why I can't use it?. But, again, don't think so since with vmesquita's I could. It must be something in the compilation you did, maybe you didn't include something... is it possible?.

How about trying to compile yourself? :)
Follow the instructions I posted and post any doubt you have.

This way it should be compatible with all your CPU features for sure! :lol:


Bilu

Yep, that would be a good solutions, and your explanations were clear enough. But I don't have that time now, and I'm afraid that if rds met some trouble, it will take me a lot of time. :roll:

... everything is so quiet around here...

As I always do, everytime a new tool is recomended, I don't mind to test it...

And I did with QuEnc.
Film: Star Wars II, 5% slicer
- First QuEnc test: I didn't really know what bitrate was for, so I used bitrate=9800, plus: Notch matrix, 16:9 aspect, High quality, trellis, GOP=15
Result: perfect!!... bitrate max 7661, avg 2383, Q max 3.48, avg 2.60 (almost flat, like vqscale=2.60),... but filesize=122740 kB (2454800 the whole film, 1 film per media)... not that good
- Second QuEnc test: bitrate=1620, rest of values as previous test.
Result: bitrate max 3071, avg 1522, Q max 12.40, avg 4.34. Filesize=78412 kB (better). But it fails badly in fast scenes, with lots of blocks.
- I compared with a mencoder test: filesize 78566 kB (almost equal), bitrate max 4740, avg 1525, Q max 4.35, avg 3.56. And a lot better visually (almost don't see a block).

Why don't I post there?: I want people test and take their own conclusions.
And QuEnc gave me several lessons:
- You almost don't need to test filesize: just set avg bitrate and final filesize seems to be close to desired. We still have to improve mencoder method to be as simple.
- Really easy to use interface: we DO need a GUI for mencoder. I have some knowledge on VisualBasic, but don't think that's the way to generate a command line and run mencoder... at least I don't know how. Mencoder command-line is rough for everybody, that's why very little people seems to be using/posting on it. And now that we came to some general settings, we would just need few variables to be set in the GUI. Any help?, or some idea to design myself a GUI with (bad) VisualBasic.
- It integrates very well avs files. I hope mencoder developers will include it soon.
- Even with those too big quantizers (up to 12.40), when quantizer decreases it get as low as about 2.90. But with mencoder and scplx_mask, didn't go under 3 (even with vqmin=2)
- Fast, fast?. I got a speed about 7.25 fps, and with mencoder 5-6 fps: not a big difference.

To sum up, maybe mencoder looks far complicated compared to QuEnc: yes it is. But its complexity is due to the several variable you can define... and this means at last better quality. I prefer to have more values to take out the best from ffmpeg engine, and that's what mencoder offers me. If we manage to design a nice GUI with some basic settings, and a window to tweak more of them, surely more people would be using mencoder.

At least, for me, mencoder is giving better quality now.

Would you mind to try with Avalon's GUI?

Let me just chime in here...
Haven't been looking into mencoder yet, but I'd like to know if it IS possible with mencoder to encode with a max/min bitrate, which is respected by the encoder... I remember ffvfw lacks this feature.

It respects min and max, just not average ;)

EDIT: QuEnc works with filesize well because it sets vrc_minrate=vrc_maxrate=vbitrate. It's CBR :!:

They still complain about undersized files when using VBR.


Bilu

I didn't know. In the graphic I got in BitrateViewer I could see more oscilations in Q value than in bitrate value (I set 1620 and it oscilated between 1000 and 2000). I expected from a constant bitrate a straight bitrate curve, but I see it's not that.

Bilu, what about designing our own GUI for mencoder, with general settings as we have agreed, and more settings to modify and adjust than in QuEnc?. Yes, I know, I know, I shouldn't propose it since I cannot help much,... but I love the idea :wink: Have you read in mencoder forums if they're thinking about including support for avs files?.

And about average bitrate, mencoder doesn't respect it, but tends to it. The problem is for predicting filesize, but we have several tools for that...

Don't mind at all to test anything. Mencoder compilation was also advised by bilu, to solve my vob encoding issue (still to be solved :roll: )
The problem is I don't like at all to test applications that come with an installer (registry entries and so on). Even mencoder compilation comes with an installer!!.
It's just a question of taste, I prefer plain applications/compilations in which I decide what things I install/execute and what not.
Thanx a lot, anyway.

:arrow: :wink: exact!

Hi inc,
nice to see you here :D .
From some of your posts I guess you're also testing mencoder. What do you think of the settings we've tested here?. And what about the settings you tested, and your results?.
We would like to know how you work with mencoder, and learn from you :) .

Yea guys...I found some interesting info..check this out, if you have not already done so...its about conversion from DVD to MPEG4, but can be applied to mpeg2 as well....one interesting idea is the settings recommended by D Rich Felker that the author mentions....

http://users.uoi.gr/ch02029/ffvfw/encoding-tips.txt

Has anyone tested encoding with the "vhq" setting enabled? I was curious how this changes the speed of the encoding process...

@poerschr

that's the same file as this:
http://www.mplayerhq.hu/DOCS/tech/encoding-tips.txt

It's old but still useful, and has been quoted here several times.
It has some very good info on it about *_mask settings and others.

vhq is the same as mbd=1, and it's maintained just for compatibility reasons.


Bilu

bilu,
from your posts I guess you make use of bat and ini files, not GUI at all.

What do you think about designing one that fit our needings?. Any idea?.

If I have the time to learn WxPython, then I'll do a GUI :)

WxPython= cross-platform GUI, same used in BitTorrent client.

I've been out of time for everything these days...

Bilu