@ Koepi: XviD better than NanDub SBC?!

[DJ Bobo]

@ emmdeeell & Defiler
What the hell are you talking about?! I'm not a fansubber at all ¬.¬
Where was mf right where I was wrong you ass leechers?! :p

@ mf
10 threshold?! 50 strength?! nani?! now that I think about it, what the hell are those settings?! don't you mean diameter 10 and threshold 50?! (or is my sshiq version outdated?! ¬.¬)

[mf]

Originally posted by DJ Bobo
@ mf
10 threshold?! 50 strength?! nani?! now that I think about it, what the hell are those settings?! don't you mean diameter 10 and threshold 50?! (or is my sshiq version outdated?! ¬.¬)
I bet my version is pretty old (6 months I guess), but I mean diameter 7, (or was it 5? gotta check tomorrow, I'm on laptop now), threshold 10, strength 50.

[ChronoReverse]

Woohoo, filter the heck out of everything encode it to some huge file size and then release. Gotta love all the work done there.


BTW, RB has nice small even filesizes, but the crappy ME in divx3 really hurts their encodes.

[c0de_v0id]

Many seasoned encoders knows XviD is better than sbc. They just dont want to use it for the leechers' sake.

@dj bobo
I dont know why u think nandub is better. Play around with the settings, im pretty sure you will get better results with xvid. (Also XviD can go to insane bitrates where sbc can't)

[OUTPinged_]

Mmm...

[smartass mode]
It's interesting, why all group rippers think they are better than other' group rippers?

(I am exception, of course i am better than any other group' rippers)
[./smartass mode]

Here are big questions to all those "ripping masters":

1.Why the F. do i see such a big difference between raw and your encodes? (Encodes look far worse than a simple reencode of raw with no filters and default xvid settings. Worse = bigger visual diference in that case)

Why should i download 4 different fansubs in order to find the one that was encoded by a guy who isnt a "master ripper" and doesnt use tons of spatial+sharpening filters to make himself proud?

Why do you blame AJ when your rips look overfiltered too?

Do you get paid when you use spatial filters instead of temporal even when it's obvious?

And a topic remark: You can make good looking encode with any decent codec nowadays. It's a raw and a filter set that makes the encode look shitty. Mosquito noise absense in divx3/4 encodes is due to preprocessing imo and that could be done in xvid too.

("background shimmering" = high quantizer+h263matrix effect?)

[Nic]

Keep it as friendly and constructive as you can guys or ill close the thread.

[OUTPinged_]

Nic, it is impossible with the way these guys are communicating.

It's like:

-"I am best and i want to know why i dont get good result with XXX"

-"No, it is I who is best and you are lame cause i get good result with XXX"

-"You all are lame cause i know XXX sux cause i am better than all of you"

And when you ask them to prove they tell "i use a top secret technique i learned from readme.txt file so i can't tell you"

To put it short, they are raising that "mosquito noise" issue again. They don't like the way h263 quantizers work (btw, who was first to say that nonsense that h263 smooths more than mpeg?), and they want to make mpeg/old-modulated encodes that dont have mosquito noise while using noisy source.

Also, how are you going to compare divx311 to xvid? Xvid is faster and offers better compression while the only portion of divx311 that is superior is that "somewhat sharper and less mosquito noise" prefiltering advantage.

[Angrychair]

Originally posted by OUTPinged_
Nic, it is impossible with the way these guys are communicating.

It's like:

-"I am best and i want to know why i dont get good result with XXX"

-"No, it is I who is best and you are lame cause i get good result with XXX"

-"You all are lame cause i know XXX sux cause i am better than all of you"

And when you ask them to prove they tell "i use a top secret technique i learned from readme.txt file so i can't tell you"

To put it short, they are raising that "mosquito noise" issue again. They don't like the way h263 quantizers work (btw, who was first to say that nonsense that h263 smooths more than mpeg?), and they want to make mpeg/old-modulated encodes that dont have mosquito noise while using noisy source.

Also, how are you going to compare divx311 to xvid? Xvid is faster and offers better compression while the only portion of divx311 that is superior is that "somewhat sharper and less mosquito noise" prefiltering advantage.

Right. It's degenerated into 'digi-subbers suck' 'this team sucks' 'that team sucks' 'you don't know anything about encoding'.

The sad thing is how so many people jumped on me just because I mentioned I was from some little digi-subbing group and that I happen to encode better than the other people IN THAT SMALL GROUP.

As for xvid vs sbc, xvid is just the better codec.

[digitize]

Xvid is the better codec, but for those of you who are forced to use divx3 why use nandub... Im pretty sure I said it in this thread before, maybe i didn't i forget, anyway use ffvfw. Uses libavcodec as the encoder, much better motion estimation and overall better quality.

[OUTPinged_]

Digitize, you think i (and lots of others) have spent days of nandub' source and doom9 forum' browsing only to move to another bugfest only because it has better ME(=1-5% smaller fileseize)?

[digitize]

Heh, the better me is just one of the things better about it, and the build i have is bug free. And like I said the overall results are much better, no need to be an ass. And also I said those who are stuck having to encode in divx3, I was just suggesting a better solution, so go act like an asshole else where..

[OUTPinged_]

I can't go elsewhere, the flaming thread is here and all smartasses are present, me incuding.

About using libavcodec: I know the difference between divx311 and xvid. I know a difference between divx311 and libavcodec.

If i would need to make divx311 encode for some wierd reason, i will use nandub. For anything else i would use xvid.

What would i need to learn libavcodec for?

Same thing applies for any other old nandub llamah who switched to xvid.


(Interesting thing, i didnt encode a single file in nandub in last 5 months... :/ )

[Pen-Pen]

Originally posted by Acaila
I understand what DJ Bobo is talking about and I have to say that I agree with him. An encode in DivX 3 gives a completely static picture (although with the occasional block that is inherent to the codec), whereas an encode with XviD always gives mosquito noise. Using MPEG quantizer this effect becomes very visible, using H263 you'll end up with much reduced noise, but also a more unsharp picture compared to DivX 3.
The only way that I know of to reduce this is by filtering, but it won't kill all the noise before you start loosing detail, so that's not really a viable option.

So from a noise/static point of view DivX3 is superior, BUT overal video quality of XviD is much much better because it doesn't have all those nasty qualities like luma blocks, shit frames, motion trails etc.

happy to finally read something like that from someone inside Doom9, the problem doesn't come from my XViD configuration but from my love of sharp images and my hatred for mosquito noise ;)

btw, SBC rules :D

[mf]

I think calling DCT artifacts "mosquito noise" is a sign of somebody who doesn't know very much about it, no offence.

[DJ Bobo]

@ mf
Don't be picky, you call it DCT artifacts, the other calls it mosquito noise, another ringing, etc (and if I remember well, mosquito noise is the term used in the CCE documentation :p)

The same can apply to: Block noise = macroblocking = pixellation = etc

[mf]

If I talk about pimples I don't say "little red spots" either. Sometimes using a term can aid in understanding.

[DJ Bobo]

Don't make me laugh.
Mosquito noise is an official technical term.
See CCE documentation
see here: http://www.itl.nist.gov/div895/docs/MosquitoNoise2000.pdf
And I'm sure you'll see this term in many other technical documents.

Don't feel too important 'kay?

[iago]

I still have not figured what the hell the meaningless discussion in this thread is serving for. The most useless thread I've seen in the XviD forum for a long while...

[Didée]

Indeed.

How do we send'em to a chatroom?

[DJ Bobo]

@ iago
That's what I'm wondering about too! nearly nobody gave me useful tips ¬.¬

[iago]

@DJ Bobo

Man, first, I was really glad to see you step into the XviD forum, dumping that DivX5 stuff ;), but then, all of a sudden, everything turned a bit weird in this thread! Anyway, I hope from that point on the discussion switches toward a more useful route.

edit - and personally, I don't think I can be of any help to you since I (have) never encode(d) anime and I guess it's totally a different realm in terms of filtering, etc.

But I'm almost sure that with either XviD or Nandub SBC you will usually get much better results than you do with DivX5, and I agree with Acaila that XviD will deliver better overall quality than Nandub SBC.

[esby]

...
I ventured in this thread thinking to find some interresting
discussion about xvid & sbc...
If i understood well, aside from fansub wars,
the main disavantage of xvid is the 'mosquito bites' (or any terms you call them... not really the matter), which can be compensated by the use of Bframes & qpel...
I'm hoping i'm not wrong -not very versed in xvid...

For divx3.11 sbc it seems the weaknesses are the usual luma inverted block... and the pixel flip in subs...

What i can add to this:

For a small quantity of work, xvid is better.
If you are used to sbc, ready to sacrifice time, searching
for the nasty encoding problem the anti-shit didnt catch. You might get better work.
For getting ride of lb block in sbc, reencoding as a kf the frame can work, but increasing the drf ( i mean setting from 3 to 4) can help too, and not necessary witout forcing a keyframe. Some people may object that the average drf will goes up, but the drfs are an indicator, and drf of 2 is not necessary better than a drf of 2...

About anime & filtering, it's true that filtering may be important, but sometimes it's better to seek for a better source than to use chain filter of death... And i have the personal feeling that the less you filter your anime, the more natural the result looks. Of course, you are forced to filter most of the time, but this should be done with parcimony.

I forgot a side effect of xvid, if the encoder used a non stable version, we end with compatibility related issue at playback.
Of course this issue may be non existing & minor, but should be taken in account before using such or such built of xvid.

esby

[sungey]

hmm quite a "colorful" thread ....
this thread is supposed to be a place to share knowledge ... so lets start doin that ...

lately some fansubs has been using developmental xvid ...
which probably will not work with future xvid ... (it works in ffdshow though , imho its better to make sure the encode works in standard mpeg-4 playback ( xvid and divx5 ). when newer xvid appear ... users are troubled bc they have to download the newest xvid .... imho if encoders wanna use xvid bframe .. make it divx5 compatible and use DX50 fourcc .. so less trouble for users ...
make sure the DX50 compatibility is checked and use h263 ...
that way we can have an encode that works with DX50, the xvid build used to encode it and ffdshow ... isnt that nice .. ^^ .. best of all ... use xvid stable with DX50/DIVX playback (speaking from experience, many ppl have trouble with xvid playback ) .. no idea why ...

just my 2 cents ...

P/S : anyone here watch anime on XBox ?... can we install ffdshow on XBox ?

[OUTPinged_]

The persons who _release_ incompatible xvid encodes, made quite a number of people think it is "immature" and "not safe to use", comparing to divx5.

Somehow no one actually cares if a build is alpha or not when encoding releases and those who do, sometimes use "stable untested" releases :-)

[mf]

As long as nobody releases files containing RRV, what's the problem with incompatibility ?

[Defiler]

Does anyone know why DIV3/SBC encodes (ignoring the obvious issues, summarized nicely by esby) look as good as they do? By this point, XviD's motion estimation engine is vastly more sophisticated than the one in DivX 3.11a, so that's not it.. is it just the quantizer matrix that DivX 3.11a uses yielding that characteristic "SBC look"?

[mf]

Originally posted by Defiler
Does anyone know why DIV3/SBC encodes (ignoring the obvious issues, summarized nicely by esby) look as good as they do? By this point, XviD's motion estimation engine is vastly more sophisticated than the one in DivX 3.11a, so that's not it.. is it just the quantizer matrix that DivX 3.11a uses yielding that characteristic "SBC look"?
If it is, it should be extractable. Matrices are stored in the files, right ?

[esby]

About 'sbc looking':
I think they are two factors:
- the first one, since divx 3.11 was used first, sbc or not, the way
you valuate any encode is influenced by the way divx 3.11 process the data...
It may be only 'psychological', but if a codec like xvid had come first in the time scale, we might think that xvid does a better job, since we tends to be less sensible to some aspect of the video and more to some others (etc.).
- that been said, xvid offers multiples ways of doing an encode, and i don't think there are really optimized as we could say for divx3.11, meaning xvid may be a better tool in theory, the way we use nandub to produce sbc clip is more well known and create what we can call 'a looking', meaning all encodes tends to looks the same, since they are based on the same encode settings mostly now (or the same approach).
Since xvid produces more different results due mostly to the different way we can use it, we cannot said it looks like xvid, unless if we found the typical error we know in xvid ( eg mosquito bites)...

Finally i think that divx sbc looking comes from a constant way of distributing bitrate & drf according to the first pass... Meaning you'll end with the same type of sequence, since there are only keyframes & deltaframes in divx3.11... But i can be wrong too.

esby

PS: mf, what do you call 'RRV' ;) ? ( This dont tell me anything, the only thing that come to my mind is real video, but i dont want to make mistakes :) )

[Edit] [ps2] about compatibility it's not really an issue, but when you end with leechers that got the fansub release you just done (you as 'group'), and that about a quarter of them are asking, "how can i play the video, xvid not playing it..." it's just quite heavy to redirect them to a working xvid build or a working ffdshow build, (Both had versions causing problems for the release i'm talking...) The pain being that problem got solved for ffdshow by using not the most recent alpha release... -- :confused:

[sungey]

Originally posted by esby
...
I ventured in this thread thinking to find some interresting
discussion about xvid & sbc...
If i understood well, aside from fansub wars,
the main disavantage of xvid is the 'mosquito bites' (or any terms you call them... not really the matter), which can be compensated by the use of Bframes & qpel...
I'm hoping i'm not wrong -not very versed in xvid...


"Bframe reduces ringing" is true, ... another way to combat ringing is by using h263 quant and boost the bitrate. Make sure the source is cleaned though ...

As far as i know .... Nandub uses h263 quant ... not very sure though. I wonder waht is RRV too ... :)

[mf]

RRV == Reduced Resolution VOPs. It's a highly experimental feature that's super-incompatible, and will most probably never show up in any public XviD builds. Files containing RRV should never be distributed in public.

[Defiler]

Originally posted by esby
I think they are two factors:
- the first one, since divx 3.11 was used first, sbc or not, the way
you valuate any encode is influenced by the way divx 3.11 process the data...
It may be only 'psychological', but if a codec like xvid had come first in the time scale, we might think that xvid does a better job, since we tends to be less sensible to some aspect of the video and more to some others (etc.).Personally, I don't think SBC looks better.. but it seems to be a very very common perception. There must be something behind it. It would be interesting to hear a technical explanation of why this is so. I'd start a thread for it (because clearly the big players have stopped reading this one..), but I know it would turn into another flamewar.

[sungey]

personally i think xvid looks better ... especially in high motion..
i dont have severe ringing artifact with xvid either, in my observation i have seen some divx3 that has very bad ringing artifacts too. In terms of sharpness (even using using h263) i also think xvid is as good as divx3. To conclude, in the end, encoding quality depends on encoding method. Users just need correct settings and filters.

P/S : That's my experience with anime encoding ... i only do anime :). I do direct YV12 -> YV12 encoding with xvid ... while in ND , ND will convert the YV12-> RGB32 in order to work. Color conversion is no good :( .. just my opinion.

[Defiler]

Originally posted by sungey
To conclude, in the end, encoding quality depends on encoding method.I'm not sure that this is a stunning revelation. :D

[sungey]

eheheh :)

[DeathWolf]

After reading this thread...seeing such horrible things... i was kinda shocked. All of what i say is my little opinion of an old anime encoder who doesnt claim anything...

In my humble opinion, xvid is better than SBC in most of the case
What are the case where SBC can compete with xvid? well on very clean sources SBC tends to give oustanding results despite it being old.
But SBC hates noise... SBC hates high motion.... and SBC
performs very badly at low compressibility
So in my case, which is anime encoding, i like xvid much better for 2 reasons:

1.it gives me less work(no inverted luma block hunt)
2.it tends to give a more "constant quality", ie it acts good on high and low motion, on noisy and non noisy
3.at low compressibility(less than 60% is low for me in anime)

now some people will tell me to use ffvw to get rid of point1... well... ffvw is indeed very nice BUT it doesnt have a 2 pass mode as good as nandub... and that lack often makes SBC look better


about xvid's moving background i agree on the fact VHQ gives very good results and nails quite well the background

about general anime episodes size i'll say three things
1.it depends on the source: depends on the kind of anime of course(high motion, low motion, digital animation etc)
2.it depends on the source: how did the raw get ripped, we are nowadays getting such high quality tvrips, due to a.very clean digital animation b.very good capture of the vids
for example on witch hunter robin....
*almost all witch hunter robin i saw were great at 140 meg or less
*almost all raw(read unsubbed tvrips) of witch hunter robin were nice at less than 140 meg
so there is no miracle... (sorry no hikari no kiseki(j/k))
filtering can help a lot sometimes but... u cant turn an ugly raw into a good sub... and it's hard to mess up a nice raw into an ugly sub
3.it depends on the filtering as said before

we are getting more and more 175 meg and 140 meg rips recently thanks to the nice raws and encodes, not thanx to the filtering

about hdtv raws... i dont believe hdtv is that much over japan... the only real hdtv raw i could see were mahoro's


finally, i think teams should just do non Bframes, non GMC, non exp features encodes and put DIVX fourcc in order for everybody to read them without prob


Btw, thanx to all great developpers of these great video tools we are all using(ie thanx to the xvid team, vdubmod team, avs team, filters developpers, and many other)

Special salutations to some friends like anrp, sung and Alltimestoned;)


PS: i agree on the fact fansub has turned badly.... too many ego fansubbers.... too many high ass encoders.... but there are still many good guys left:)

PS2: AJ is the most evil thing

@mf
i agree on most of what you say exept on the part about size:)
keep on doing good job;)
btw, wolf rain's raws are particularly good, you choose a good pick;)

@DJ-Bobo
i dont know about your high quantization noise but try just some small filtering like a 2dcleaneryuv at low level... either you messed up really badly a setting, or try another xvid release?
(btw what anime are you trying to encode so hardly?)

@Angrychair
/me has many friends in ishin
i'm sure you do good work, dont worry about people critizing you;)

@emmdeeell & Defiler
they are far from being the worse

@all
stop flamming, love the world:)

[esby]

Just a word about Whr,

I don't think the very low size is really coming from the raw quality itself...
It's just coming from the 'high compressibility' of the anime.

esby

Of course heavy filtering will tends to give high compressibility too,
but for Whr, we used various multiples sources,
and that just means the filtering was not to blame for the low size of the raws.
On another humorous note, it's very '*easy*' to turn a good raw into an ugly subbed, it just means bad color choice for the subs :)

[DeathWolf]

yeah esby i agree on that one, that's what i meant, it is a very compressible anime:)

[Kamui-Dash]

Originally posted by Defiler
Personally, I don't think SBC looks better.. but it seems to be a very very common perception. There must be something behind it. It would be interesting to hear a technical explanation of why this is so. I'd start a thread for it (because clearly the big players have stopped reading this one..), but I know it would turn into another flamewar.

SBC looks better than xvid on series which got alot of low motion scenes, since its alil sharper which makes it really nice for Shoujo series.

XviD has better motion compensation which makes it better for action series imo. For alil sharpness sacrifice and u'll get better overall encode.

Libav is really nice, I prefer this instead of those two just mentioned. But thats just me :D

[Defiler]

Originally posted by Kamui-Dash
SBC looks better than xvid on series which got alot of low motion scenes, since its alil sharper which makes it really nice for Shoujo series.If this was all there was to it, you could get the same results by changing the quantizer matrix in XviD.. I think something else is going on.

[Kurosu]

@Defiler

Originally posted by -h
I can't say with certainty but I believe the only potential obstacle to a MSMPEG4v2/MSMPEG4v3/WMV1 -> MPEG4 convertor is the storage of the DC component for intra blocks (MS may be more precise than MPEG4 allows - 9 bits versus 8).

Originally posted by temporance
I looked into this sort of conversion a while back and decided it wasn't possible to do for all DivX 3.11 content. From memory there are some issues with edge padding that would cause prediction drift. There's also an issue with filesize due to different VLC tables and prediction algos.

I *think* it means the DC and low frequencies coefficents are encoded differently, maybe with more precision, than in a regular MPEG-4 encoder as XviD. The quantization matrix has a very little role in this therefore, as those DCT coefficients go through a different processing (both in encoding and decoding).