Adding more "stuff" to an avs script for encodes?

[Tuff Gong]

I've been doing encodes now for about 4 years (with two of them being avc related). The entire time I have been using simple avs scripts such as:

DirectShowSource("C:\Source", fps=23.976, audio=false, convertfps=true)
Lanczos4Resize("", "") # Lanczos4 (Sharp)

Now, there have been talks about various release groups and their "special" things that they do to their encodes like adding grain or some groups' releases being darker than others or what have you. I've been doing my avc encodes, like I said, for about 2 years with my simple scripts and have had great success.  Am I missing something that's never spoken of in any of the Blu Ray guides or something like adding more plugins that will add to my encode quality or something?

*Sources are from Blu Rays, not some screener or whatever else kind of releases there are.

[RiCON]

Concerning anime BDs, some might need some filtering to clear nervous grain or anti-aliasing to disguise weak upscaling. But if the anime was made with BD release in mind, any filtering would be over-filtering, imho.

[Tuff Gong]

I kinda thought adding anything to the script would be overdoing it but some of these groups or individuals are proclaimed to have "secrets" and all I can think is what  shoot me in the face.  I almost thought I was retarded for a minute .

[Astrophizz]

AFAIK the groups that are generally considered the best are the ones that do the least filtering like niizk, thora, and kaa.  Some people like highly denoised video though.  These groups sometimes do stuff like editing on a frame-by-frame basis but that's a lot of work.

[Desbreko]

I only filter to fix problems in the source, like color banding, aliasing, dot crawl, etc., and only then if the results of the filtering have a greater positive impact than negative.

[qyot27]

AFAIK the groups that are generally considered the best are the ones that do the least filtering like niizk, thora, and kaa.  Some people like highly denoised video though.  These groups sometimes do stuff like editing on a frame-by-frame basis but that's a lot of work.

This.  In addition, the so-called 'secrets' could have more to do with their encoding settings rather than the scripts - the fact I've seen more than one group deliberately erase the encoding parameters from their files' embedded data, or refuse to tell those who ask what parameters were used, seems to confirm this.  They don't generally add the grain, they preserve it based on what's already there (although some light filtering might be a substitute, but the encode would still need to use things meant to keep the grain around).

[lych_necross]

I prefer to use the KISS principle when encoding.  The only adjustments I make is to the encoding settings.  Occasionally, I will add a debanding filter or a denoiser if the source is really noisy, but other than that nothing.  Rather than use a complex avs script on an anime to improve its perceived quality, I would rather just find a higher quality source (newer dvd release or bluray).

[Tuff Gong]

This.  In addition, the so-called 'secrets' could have more to do with their encoding settings rather than the scripts - the fact I've seen more than one group deliberately erase the encoding parameters from their files' embedded data,

I've seen little comments on mp4's before but I wasn't aware of how to go about editing those comments. Do you know where I could get the proggy to edit this information (I've yet to be able to do it with YAMB).

[Dark Shikari]

This.  In addition, the so-called 'secrets' could have more to do with their encoding settings rather than the scripts - the fact I've seen more than one group deliberately erase the encoding parameters from their files' embedded data, or refuse to tell those who ask what parameters were used, seems to confirm this.  They don't generally add the grain, they preserve it based on what's already there (although some light filtering might be a substitute, but the encode would still need to use things meant to keep the grain around).

I have yet to see a group erase parameters to try to hide good ones; it's always preventing others from seeing their idiocy.

[bigcitynights]

Here are x264 scene rules and settings from 2007:

http://www.sbytes.info/NFOwb.php?id=high.def.x264.movie.standards.rev2

Their recommended encoding settings are at the bottom.

[JEEB]

I have yet to see a group erase parameters to try to hide good ones; it's always preventing others from seeing their idiocy.

This. The SEI takes so few bytes of space, it's not justified to take it out for whatever reason. Also, straight-out copying of settings from someone's SEI isn't usually a really sane thing to do, since you never know if certain settings were selected to better contain that specific source, or if they were even selected sanely. Not to mention that the x264's defaults, together with the presets and tuning settings should already deal with most of your needs. Some do the SEI data tampering for the lulz (and usually "properly"), while the ones who used zeroes for it actually ended up making non-standard streams. *sigh*

I've been doing encodes now for about 4 years (with two of them being avc related). The entire time I have been using simple avs scripts such as:

DirectShowSource("C:\Source", fps=23.976, audio=false, convertfps=true)
Lanczos4Resize("", "") # Lanczos4 (Sharp)

Now, there have been talks about various release groups and their "special" things that they do to their encodes like adding grain or some groups' releases being darker than others or what have you. I've been doing my avc encodes, like I said, for about 2 years with my simple scripts and have had great success.  Am I missing something that's never spoken of in any of the Blu Ray guides or something like adding more plugins that will add to my encode quality or something?

*Sources are from Blu Rays, not some screener or whatever else kind of releases there are.

As far encoding goes, KISS is the main principle. If something isn't broken, don't touch it. But if you see something bad (anything that strikes your eye as something that shouldn't be there -- and couldn't be an artistic choice on that scene, such as halos from oversharpening/upscaling _{[Well hello there DTB]}, way too excessive noise _{[Well hello there Tayutama]}, striking aliasing _{[Well hello there Bakemonogatari; I've got to love those low-res CG items on high(er)-res art]}, banding in gradients etc. etc.), you might try to fix it with something that does the least amount of evil to the other parts of video (which might be very much :effort: at times). Also, asking for help when trying to fix something is generally never a bad idea, just as I found out myself some time ago with my dehalo'ing needs. And then, lastly, you have to care about actually getting the final encode to look close enough to your input, which is mostly easy by just using a good-enough CRF value, but which might need some special tweaking at times. Consulting other people on this is usually a good idea as well.

As for that script, I personally dislike DSS for its shortcomings and non-frame-exactness, so I'd switch to Haali's DSS2 or Myrsloik's and friends' ffms2 for H.264/VC-1 (although the latter might need a remux to MKV with eac3to, not sure how problematic transport streams still are for ffms2), and to dgdecode for MPEG-2 sources.

Here are x264 scene rules and settings from 2007:

http://www.sbytes.info/NFOwb.php?id=high.def.x264.movie.standards.rev2

Their recommended encoding settings are at the bottom.

As far as the "x264 scene rules" go, they're just meant to keep the worst of the pack from doing very stupid things, and they shouldn't really be kept for any reference nowadays -- since the x264 defaults are pretty good nowadays, and you'd mostly end up using command lines the likes of "--preset mumbo --tune jumbo --crf value" (with the --crf switched to 2pass bitrate VBR mode (with VBV usually) for when you have to limit yourself to some size (physical media etc.)).

[bigcitynights]

As far as the "x264 scene rules" go, they're just meant to keep the worst of the pack from doing very stupid things, and they shouldn't really be kept for any reference nowadays -- since the x264 defaults are pretty good nowadays, and you'd mostly end up using command lines the likes of "--preset mumbo --tune jumbo --crf value" (with the --crf switched to 2pass bitrate VBR mode (with VBV usually) for when you have to limit yourself to some size (physical media etc.)).

I have a couple of questions (I'm new to x264)...

I always do 2-pass encoding.

1. When doing 2-pass encoding, should I or should I not
specify --crf value?

2. What is VBV and what good will it do in 2-pass encoding?

[J_Darnley]

I have a couple of questions (I'm new to x264)...

I always do 2-pass encoding.

Why?

1. When doing 2-pass encoding, should I or should I not
specify --crf value?

If you use crf you don't need 2 passes.  You only need 2 passes when trying to hit a target size for some limited storage medium, e.g. 1 CD.

2. What is VBV and what good will it do in 2-pass encoding?

If you don't know what it is you probably don't need it.  Are you trying to encode for playback on an ipod, a bluray, via DXVA, other hardware decoder(s)?  If you are doing any of those, yes you should use vbv.  And no vbv does not help 2pass and 2pass does not help when using vbv.

[bigcitynights]

Why?

I don't know. I always used 2-pass since the Xvid days.

If you use crf you don't need 2 passes.  You only need 2 passes when trying to hit a target size for some limited storage medium, e.g. 1 CD.

File size is not that important to me, but I want it to be within
reasonable limits. For example, if I'm making a backup of my 4460 MB DVD
for me or for my friends, I want the file size to be within 800-1200 MB limit.

If you don't know what it is you probably don't need it.  Are you trying to encode for playback on an ipod, a bluray, via DXVA, other hardware decoder(s)?  If you are doing any of those, yes you should use vbv.  And no vbv does not help 2pass and 2pass does not help when using vbv.

With x264, I'm always encoding for playback on a PC.