I re-did the tests, with the same sample (slices from StarWars II, 2% of whole movie).
With your settings/command (without denoiser, avisynth script): 28094 kB
With the settings I posted: 33633 kB... buff, almost 120% your filesize. That means that the whole film would "weight" 1681650 kB, and 2129138 kB if I add the AC3 audio stream (just one :( ). Well, I could fit 2 long-lasting films like this per media, but just 1 audio track. Well, maybe with subtitles.
And related to the image, to my eyes, with your settings the image looks like it was "dirty" (sorry me for my poor english), the colors aren't bright, looks washed up. With my settings colors are brighter, and image looks to me cleaner. And now that I got rid off blocks, my main problems are improve speed and compresibility...
Any help will be apreciated,... or call me crazy if I'm trying to get what it's impossible.

Main differences between our methods, easier to check this way:

setDVDHQ.ini:
=========
vrc_eq=tex
vbitrate=1500
vrc_maxrate=5000
scplx_mask=0.5

naq
trell:cbp
mbd=2:mv0
vmax_b_frames=2
cmp=2:subcmp=2:predia=-2:dia=-2
lmin=2.5:lmax=11:vqmin=3:mbqmin=3

SETTINGS.INI
========
vqcomp=0
vbitrate=300
vrc_maxrate=9800
scplx_mask=0.3


I'll have a look now.


Bilu

@digitall.doc

This will be our framework: settings at bold are my first proposal and the rest is a common framework, so it's easier to change :)

Settings I removed for now:
vrc_eq=tex (it says "do not follow the bitrate parameter")
vrc_maxrate=5000 (I've seen scenes growing up to 7600 kbps even with my settings)
scplx_mask=0.5:naq (better results and filesizes not using naq and using a lower mask, try it)
vqmin=3:mbqmin=3 (min q=3 is limiting quality)

lmin=2.5:lmax=11
It says "you can read quantizer from 2 to 31, but you can change it so much that you can have quantizers between 0.01 and 255". Not something you'd want to mess with ;)

Don't worry so much about vqcomp=0, since you also have vqblur=0.
I got to bitrates like 7600 Kbps even using this setting :)

Strategy will be trying to see if quality fits your taste; reduce scplx_mask if it doesn't. When it matches your taste we'll try:

1) removing mbd=2:mv0
2) removing trell:cbp
3) removing cmp=2:subcmp=2:predia=-2:dia=-2

Each of them will be tried in separate. We won't remove B-frames since you're pleased with the quality. I only abandoned them because I had a weird interlaced stream.


Bilu

First of all: thanx a lot for helping me, since you found the settings that fit your needs/taste and there's no need to mess with somebody's else crazy command. You always :o :o :o :o
Also thank you for traslating some settings in a way I can better understand them.
Sorry if I don't give feed back to fast, since I'm very busy right now (my job, nothing to do with image, neither encoding,...) and have lots of things to do. I'll try to keep you regularly informed.
What does this mean: "don't follow the bitrate parameter"?, does it refer to vbitrate parameter?, since in my experience, mencoder tries to follow vbitrate (in my tests, avg bitrate was 1632, and vbitrate=1500). And from man_page, vrc_eq=tex does mean "constant quality" (try to keep CQ, I guess). Am I wrong?
I took this parameter from CCE experience (where maxrate is set to 5000), but as we are with mencoder, you're right, I'll try it and see if file size doesn't grow too much. It'll avoid some blocks, for sure.
Related to filesize, you're absolutely right: filesize almost doubles with naq. I remember you advised this some time ago, and tried it. The settings where almost the same I last posted, but vbitrate=3000, vqmin=2, without naq and scplx_mask=0.2... the filesize was 26166 kB (really low) but colors washed, and really blocky. That's why I kept naq. And raised scplx_mask to 0.5 to lower filesize. But that was with vrc_eq=tex, maybe with vqcomp=0 will be different...
I raised it to lower filesize, and quality didn't suffer much (maybe due to my different approach). I get avg Q 3.63 (with your settings is 3.95, and never got below 3) and peak Q 7.08 (5.54 with your settings). But with my CQ approach, Q is quite stable between 3 and 4, and just raises in complex scenes.
I didnt understand this at all. I don't think mencoder reads that can change between 0.01 and 255, since lmin is set at 2.5 and lmax at 11. I first thought it was for this purpose: I kind of "your Q limits are vqmin and vqmax, but if it's really needed you can go down to lmin and up to lmax". But didn't find documentation on lagrange multiplier. And believe me: with them, I get less blocks (almost none), without them some macroblocks appear.
bilu, but I "worry" about vqcomp=0, since I think this is the key dfference between our approaches: CBR vs CQ. I know bitrate raises (I tested your command), but mencoder is more "focused" in keeping low bitrates than in keeping constant quality (the Q curve raises and lowers continously) with your command. I think the key in my approach is vrc_eq=tex. Leaving it, I'm sure the better will be your way. If possible, I want "constant quality"
Don't think from my comments I won't try your suggestions, I'll try every. But I aim CQ, since, in my tests, is more sharp and clean, not so blurry.
BTW bilu, did you make a test with my command/settings. I'm curious about your opinion/result.

BTW, I did some days ago a test I forgot to post.
I encoded the same sample I'm doing tests, with CCE (the same slices and the same avisynth script). With Q set at 30 the filesize was 43221 kB, and with Q at 40 (the maximum advised to get acceptable quality) filesize was 36903 kB (above my last settings).
To my eyes, mencoder quality beats CCE at 40, and maybe at Q 30. And if I raise bitrate to 3000 or 5000, maybe filesize wouldn't grow as much as those 36903, and I would get definitely rid of those blocks that still appear from time to time, and quality would be much better...
Nice mencoder

... some other thing is speed, with my settings/command mencoder is slower than CCE. But still developing and improving, isn't it?.

My new settings, still being tested but seems very good now:

Without any quantizer limits but using naq this time.
I also increased scplx_mask but difference in quality/filesize is not significative.
On my most sensitive test (low motion, clean anime) it made a big difference in quality. Of course it got bigger :)

Old settings:
Filesize -> 30.879.651 -> 11.448.379
Bitrate/QP -> 3460/6.06 -> 984/4.42

New settings:
Filesize -> 30.879.651 -> 16.962.725
Bitrate/QP -> 3460/6.06 -> 1453/3.52

I'll never leave naq again :)

Other recommended settings for quality improving (if you have the CPU): trell,cbp,mbd=2,mv0. trell makes the biggest difference and you need mbd=2 to use mv0. But on my PIII-500 it gets 50% faster without them (4fps->6fps :D )

@digitall.doc: still under investigation ;)


Bilu

The result from my last settings. Quality is much better.

Bilu

Bold: settings that may vary according to taste.
Green: needed for interlaced and NTSC encodes.
Blue: settings that improve quality at CPU cost.
Orange: Quality trigger when used with *_mask :)

I didn't include cmp=2:subcmp=2:predia=-2:dia=-2 because I think this brings speed down and quality improvements are nowhere near those provided by the "Blue" settings.

I marked naq=1 differently because I intend to use it for high-quality encodes and remove it for extras/lower-quality encodes.
I'm curious about its behavious in 2-pass, maybe it's the opposite: if we don't try to normalize per-MB quantizing, more bitrate is available :)

If you're more demanding about quality remove the denoiser and the spatial mask and use the "Blue" settings.

I still don't have an opinion about vqcomp/vrc_eq, I haven't seen side effects yet using vqcomp=0 or vqcomp=1 :?


Bilu

Hi bilu,
I'm happy to see you came closer to my settings (BTW, and I always explain that, they are your settings, before you started making tests).
naq improves really a lot the quality. It comes at a filesize expense, but it really worth it, and as we're talking about KDVD, we can afford it.
And I also agree with you about trellis, since quality improves, and it even makes filesize be less. Ah!, I tried qprd, and is not working: mencoder hungs (don't know if it was already posted in mencoder newslists, but if you have the time you could announce it, maybe a bug?, or I did something wrong).
And I wait for your feedback on CQ vs CBR. It's not I want you to change your mind, or I want to always be right, I wouldn't like you got finally to think like this. Here I'm just learning, and learned a lot of mencoder from you. But I like best the output of constant quality, and is the way I'm accostumed to from previous encoders. Just test it, and tell me if it can be improved in a way.
Of course, I'll give your last settings a try, but I think we're getting closer, and we have just to make clear if it is better the CQ approach (through vrc_eq=tex or vqcomp=1) or the CBR approach (through vqcomp=0). And a possibility of course, is that both be good ones.

I'm thinking... I'm afraid there's more experience in mencoder encoding CBR since it has been mainly used to make divx ---> now you'll see I don't have much knowledge, but AFAIK divx is CBR based, isn't it?. That's why maybe CQ with VBR has not been too tested under mencoder till now. But I tasted it, and liked it a lot, and want to take the best possible of this approach. If it doesn't worth, I'll forget it. And if I arrived to this point, was thanx to your (and everybody else in here) help.

Divx is VBR too. The 2-pass process was probably invented for MPEG-4 :)

qprd hanged on me too.

I'll check today this vqcomp=0 vs vqcomp=1 thingy ;)


Bilu

I was writing while you were posting.
You explain so clearly things that can't be clearer.
I also thought to remove cmp=2:subcmp=2:predia=-2:dia=-2 to see what happens. I took this idea from man_page, where it says (if I remember well) quality improves. I'll try and remove.

You mean you already tried vqcomp=1 and didn't notice a difference between output?. Neither in visual quality, nor in filesize, nor bitrate, nor Q value?. Hmmm, surprising. Maybe is due to having vbitrate=vrc_minrate, could it be?. I'll test also this (buff, begining to have too much to test and too little time).
And maybe is just due to vrc_eq is not absolutely based on vqcomp, and you have to change vrc_eq to tex instead vqcomp=1 (I also wanted to test vrc_eq=tex_vqcomp=0, even it does not have any sense. Just a test to see what happens, if mencoder follows vqcomp or vrc_eq).

:lol: :lol:
And again simultaneously posting :lol: :lol:
... well, here you can see my broad knowledge on video encoding :oops:
I'm really curious about your results with CQ (vqcomp=1 or vrc_eq=tex, whatever). :wink:

I have just tested qns=3 with trellis.
Brrr, horrible, encoded at 1 fps, and looks really bad.
And it was already advised in man_page...
I'll try qns 1 or 2 to see if it does worth, and doesn't slow down encoding.

Remember that original vrc_eq is tex^qComp, so:

tex^0=1
tex^1=tex

So

vrc_eq=tex is the same as vqcomp=1
vrc_eq=1 is the same as vqcomp=0

if the vrc_eq formula is the default one.


Bilu

A benchmark I found:
http://www1.mplayerhq.hu/pipermail/m...er/039821.html

And a nice link about parameters:
http://www.ee.oulu.fi/~tuukkat/mplay...ts/readme.html

Seems to me that qns is CPU expensive and qprd is crappy.

Bilu

First test (anime low-motion)

Vqcomp=0
=======
10240 KB
avg 3792/4.62
peak 6975/13.18

Vqcomp=1
=======
10213 KB
avg 3782/4.66
peak 6972/13.38

So this test worked the opposite way :)
Will do another with live video.


Bilu

Second test (movie low-motion, high detail):

vqcomp=0
=======
14604 KB
5868/4.35

vqcomp=1
=======
14616 KB
5873/4.33

So this time won vqcomp=1, by numbers.

Having a look at the Bitrate Viewer graphics I almost couldn't distinguish each other. They are different, but difference is so little it is hard to see.


Bilu

The only thing left to test in your command-line is:

cmp=2:subcmp=2:predia=-2:dia=-2

Will have a look at it when possible, but I've read in the links I posted that larger diamonds is not necessarily good, even negative ones.

Bilu

Already tested qns with values 1 and 2, and didn't like the result.
Don't know what is it supposed to be doing, but file generated at both values look blocky. I'll drop it by now.

I still didn't have time to test your last settings, sorry.

When you compared vqcomp=0 and vqcomp=1, did you use the same vbitrate=vrc_minrate?. Since in the CBR approach, with vqcomp=0, this was your setting. But in my CQ tests, I used vrc_eq=tex (supposed to be the same as vqcomp=1 if using default vrc_eq formula) and vbitrate at least 1500 (below quality dropped a lot, and I used it to adjust filesize). I say this since I'm surprised you getting the same results with vqcomp=0 and =1.
And your comparison refers to BitrateViewer analysis, what about the visual quality to your eyes?.

If vqcomp=1 and vqcomp=0, at the same vbitrate, give the same result (filesize, avg and max bitrates, avg and max Q, and visual quality), then I'll have to say that I don't understand a word my friend. :roll:

EDIT: 2 doubts else left:
Are you still using vrc_maxrate=9800 for both vqcomp=0 and =1?, since in my tests this raised quality, no blocks, but bigger filesizes of course.
And, are you using vqmin at default (=2). The same comentary I did before applies to this one. Did you give lmin=2.5 (for vqmin=3) and lmax=11 (for vqmax=10) a try?. When I was close to my limits (in filesize) they removed many blocks.

@all

I'd like some feedback about dvdauthor, dvdunauthor and spuunmux.
Please post here if you have experience with that software.

http://www.kvcd.net/forum/viewtopic.php?p=68222#68222

@vmesquita

Would like your opinion too ;)

Seems to me that we're coming into a command-line cross-platform DVD authoring era :)

Bilu

I've never used dvdunatuthor and spuunmux, but dvdauthor and spumux are very good. This thread was created in dvdrhelp when baldrick did the first windows compile, you really should take a look:

http://www.dvdrhelp.com/forum/viewtopic.php?t=180017

There's a multiplataform GUI for dvdauthor called DVDStyler:
http://dvdstyler.sourceforge.net/
I haven't tested yet, but it looks nice. :D

Hi all,
sorry if I change back again to mencoding (BTW vmesquita, I took a look at dvdstyle screenshots and features, and looks nice. When I have this mencoder working the way I want, it will be a nice tool to test :) ).
Just to post my last test. It was with last command/settings posted by bilu, this is:
Modifications I did:
-didn't use interlaced and NTSC settings (ildct, ilme, vstrict), neither il=i/d, nor hqdn3d
-I used vmax_b_frames=2

Encoded twice the same sample, first with this settings (CBR), and second changed to CQ (vqcomp=1). But as I said in my previous post, I think is better for CQ-VBR to have a higher vbitrate (to keep Q low and as constant as possible, and bitrate changing freely. Opposite to CBR where bitrate tends to a low constant value, and Q changes freely between limits). So I set vrc_maxrate=5000 (with notch-matrix don't need else) and vbitrate=4000.

Results:
vqcomp=0:vbitrate=300:vrc_maxrate=9800
--------------------------------------------------------
file size: 43593 kB
bitrate: max 5473 / avg 2114
Q value: max 8.29 / avg 3.10
bitrate viewer graphics: Q varies between 2-4 and in demanding scenes raises at 8. Bitrate tends to be kept low
visual quality: in fast scenes appear some blocks; sometimes looks "blured"; washed colours

vqcomp=1:vbitrate=4000:vrc_maxrate=5000
---------------------------------------------------------
file size: 44097 kB
bitrate: max 5446 / avg 2139
Q value: max 4.20 / avg 2.39
bitrate viewer graphics: Q is kept between 2-3 and raised just once in a complex scene, with high bitrate
visual quality: no blocks, no "bluring"; washed colors just in some scenes

Don't know if washed colors are in my eyes, or in my mind, since for quality I just can add trellis (that is supposed to be related with quantization, don't think that has nothing to do with colors).
Speed was the same (about 7 fps) for both settings.
Nice results for both (I still prefer CQ), but this filesizes for 2% of film are a little big (trellis also lowers filesize, but at a encoding time cost). I'm still looking for a way to keep this quality and reduce filesize (scplx_mask maybe also helps, but you said bilu that little).
Any suggestion appreciated (I think we're gwtting closer, and we're understanding better how this encoder works). :wink:

Can you repeat the test on your stream without B-frames?

Bilu

Some stuff for experiments
 

Hi,

as a long time linux mencoder user, I'd like to point you to some other interesting features of mencoder (which work well in cygwin too)

I hope, at least some of you didn't know this already...

1) You can do an audio conversion pass like:

which in turn can be used to be muxed inline with the video like in:

But even if you don't use this (maybe because you are using an AC3 stream), in the end,
the audio encoding pass (which is very fast indeed) gives you a prediction
of the filesize and hints on the needed bitrate for certain filesizes like:
( that was a rather short video ;) )

This was meant for divx encoding but can be used for kvcd/kdvd too, I used the predicted value for two 700MB CDs to get a 1.4G KDVD Movie
which hit the target very close.

This value can be inserted as average bitrate (vbitrate=value), that is, if you don't use CQ (with vqscale=x)

2) it also has a builtin crop-detection, used like this:


Use more frames if you want to be sure you get the crop value correct.

You get something like that:

if you have cygwin installed with fileutils, you can get it
automatically with (if you wrote the output to /tmp/f):

This would set CROP to "506:384:2:0"

You get the vf value which you can insert and use with scale and expand like so (CROP is the Variable above):

Note: scale=..:-3 means scale according to original aspect ratio

You can build really nice scripts with this options...

Also have a look at this thread: http://www.kvcd.net/forum/viewtopic.php?t=7771

You got me some ideas (haven't had time to test all mencoder filters myself ;) )

Happy mencoding,

Neturmel

bilu,
I already did, was my first test, encoding both tests without b-frames.
File size was bigger for both, and I had the problem I described some posts before with PowerDVD: it doesn't play smoothly, it plays aprox 3/4 second and suddenly makes a little jump forward.
This way it was very difficult for me to evaluate quality, but without b-frames is supposed to be better... but also for both tests (vqcomp=0 or =1)

Now I wanted to encode directly from vob file, and try mencoder internal filters, instead of using avisynth and makeavis.
How do I tell mencoder to encode several vobs files and output just 1 stream (sorry, too lazy to read man_page)?
And in my first test mencoder hung: it gives a VDec error and says encoder is not compatible with output format. What am I supposed to do to make mencoder encode from a vob file (if any thing is to be done)?.
Thanx bilu.

@digitall.doc

This should work out of the box, vob files should be encoded without any problem.

Maybe a bug in the/your win32 version ?
Have you installed all mplayer codecs ?


To do several vobs: Just pipe the file names to mencoder:

("-" at the end instead of a filename)

Greetings,

Neturmel

neturmel, thanx for the support.
I'm using bilu compiled version, and is working for him.
I suppose I have all mplayer codecs needed, since he encodes directly form vobs.
Now that I remember, I encoded with previous versions directly from vobs. Maybe you're right, and I've got something missing.

What's "cat" for?, Do I substitute "*" with vob file name, or is it to feed mencoder with all *.vob files in a folder?.

@digitall.doc

"cat *.vob" would feed all VOB files in the current directory to output which is the input for mencoder via "|".

If you just did a plain "cat *.vob" without the pipe and the following mencoder command, you
would be presented with a nice ascii printout of all vob files in your command shell ( which is quite lengthy and unreadable ;) )

You can use all kinds of wildcard there e.g. "cat VTS_02_*. vob" which would
feed all vobs of VTS_02.

Hope this helps...

Neturmel

Now got it :wink: .
Still didn't test since I'm waiting bilu feedback, to see how he manages to encode from vob with his compile (the one I use).

I think my method only works without B-frames, tried with them and it sucked :(
Have you tried other players than PowerDVD?

You've already posted my method ;) it's the one I post whenever I post my settings. About multiple files, the Windows equivalent should be "type *.vob | mencoder ..." although I think that not all Windows versions support "type *.*" and you have to specify a filename on these :?


Bilu

@digitall.doc
I get this everytime, but it works.
This is because the first driver in the built-in codecs.conf is MPEG-2 PES and not libmpeg2. So the first one has to fail.


Bilu

@digitall.doc

Remade the test with a NTSC telecined source, using vmax_b_frames=2.
One using vrc_maxrate=5000/vbitrate=1500 and the other using vrc_maxrate=9800/vbitrate=300 using vqcomp=0. Both sucked.

Made the same test with vqcomp=1. Both sucked too.
I'll continue to avoid B-frames.

Will now test using your method but without B-frames.


Bilu

Without B-frames both look good. But using vbitrate=vrc_minrate worked much more VBR and yours much more CBR :?

My method:
6837 KB
avg 3143/3.55
peak 4240/4.85

Your method:
6424 KB
avg 2952/4.85
peak 3875/9.70

Both using vqcomp=1, the same as vrc_eq=tex.
The one made with your method looked blurrier and in BV it looked much more CBR: from some point it started quantizing between 4.5 and 6.5 .The bitrate didn't get much lower than using my method, but it sure seems like it was trying.

Maybe that's the Mencoder behaviour: when it thinks it can actually achieve that average bitrate it tries harder, while such a lower vbitrate ends up being ignored.

My tests were made with interlaced samples, that was the main difference from yours. I'll make now the same tests over progressive PAL, but for NTSC I already have my conclusions :?


Bilu

I know bilu, but it's not working for me.
Don't know if I've got anything missing, but I was able with vmesquita compilation to encode from vob, and now I can't. Maybe I'll try and test again with previous version, to see if there's something wrong in my system...
Still didn't test either since it's not encoding from vobs. Hope I'll solve this issue. :(
I get the same messages you posted from mencoder, but then a windows message appear and crashes...

Try the builds from Amnon82 at Doom9.

http://forum.doom9.org/showthread.php?s=&threadid=72559

Bilu

Yes, I think I posted earlier, with mediaplayer 8 didn't happen. Anyway, my gold standard will be burn on DVD+RW and test on my standalone. But now I'm very concerned in finding the best way to make mencoder work.

And now, as I was afraid, I don't really understand a single word...
Well bilu, your results are just opposite to mine. Before analysing them: did you encode (my method) with vbitrate=1500 or vbitrate/4000?. Since I tried vbitrate=1500 before in order to get the smaller filesize, but the comparison I did with your method was done with vbitrate=4000. I ask you since I see that vqcomp=1 gives a smaller filesize, and in my test was bigger.

But your results keep me astonished. They're just opposite to mine. I don't know if it's a question of vbitrate I stated before, or NTSC interlaced source, or is due to different sources (you vob internally filtered in mencoder, and I avisynth script), but I say again, just opposite.
It's not just visual quality (it depends upon everybody's eyes and test, subjective 100%, at least for me), but bitrateviewer give opposite results.
As I told you, in my tests avg and max Q were far big for vqcomp=0 (I prefer this to "my" vs "your" method, since "my" is already yours, and feels like a contest...), and made lots of spikes, varying a lot, while BR was more stable. And in my tests, vqcomp=1 gave a far steady Q curve, with low avg and max Q value, and oscillating bitrate... :roll:
Again, don't know if is due to different source, or if you used vbitrate=1500 instead =4000, but they're too different. I would like to send you, or post here, the encoded tests and bitrateviewer screencaptures so you could see what I'm not able to explain to my poor english :oops:
Even, from a theoretical point of view, and from man_page, vqcomp=0 means CBR and vqcomp=1 means CQ, taht is in line with my results, but opposite to yours.
Don't know if I did anything wrong in my tests. Anyway, I'll redo my tests, since I want to understand how this encoder behave.

Won't it be dangerous? :twisted:

Don't take serious, just joking :lol: . I will give a try.

Thanx

I did your method with vbitrate=1500 and vrc_maxrate=5000.
Will now try with vbitrate=4000 and vrc_maxrate=5000.

Bilu

Again with B-frames, both sucked :roll:

Without B-frames, vbitrate=4000, vrc_maxrate=5000

vqcomp=0
=======
6801 KB
avg 3127/2.19
peak 4271/3.82

vqcomp=1
=======
6806 KB
avg 3129/2.17
peak 4271/3.48

The bitrate and quant curves look just.... equal :?

Tests were again made with the same NTSC telecined source.
I wouldn't want something that just works on progressive sources.

Will now test vbitrate=vrc_minrate vs vbitrate=vrc_maxrate, seems they both provide good results ;)


Bilu

Bilu

Without B-frames, same telecine source:

vq1-> vqcomp=1
vbmin -> vbitrate=vrc_minrate
vq0-> vqcomp=0
vbmax -> vbitrate=vrc_maxrate

minrate=300
maxrate=9800

vq1_vbmin
=======
6837 KB
avg 3143/3.55
peak 4240/4.85

vq1_vbmax
=======
6843 KB
avg 3146/2.15
peak 4281/3.10

vq0_vbmin
=======
6807 KB
avg 3129/3.54
peak 4240/4.85

vq0_vbmax
=======
6843 KB
avg 3146/2.15
peak 4281/3.10

The *_vbmin curves seem the same, and the *_vbmax curves also seem the same. The vqcomp parameter seems completely irrelevant.

The vbmin curves are different from the vbmax ones. Bitrates don't change that much but quantizer are much higher in vbmin.

I'll make other tests but I feel that vbitrate=vrc_maxrate will be my favorite from now on: little difference on the bitrate with much smaller quantizers :)


Bilu