I'm assuming this subs are compatible with UCCUSS? https://nyaa.si/view/1144695 https://mirror.animetosho.org/view/seishun-buta-yarou-wa-bunny-girl-senpai-no.n1144942 Thanks!

@SomaHeir Should be, assuming we had the same BDMV source. I would just try it and see if it works. I resynced the subs myself with sushi from the original Vivid release. And holy crap those files are big.

Why turn on sao? It can mess up details with its blur. Is it due to choosing CRF18 artifact prevention?

>I resynced the subs myself with sushi from the original Vivid release I will wait for better release thanks for the effort

@noZA_ It tends to retain gradient better and prevent ringing. Of course, each anime is different and `limit-sao` seems like a good compromise as a generic setting between `no-sao` and leaving it on. Also, see [this](https://amefs.net/en/archives/1470.html), and although it is a rather old test from 2017 (x265 has come a long way) I've found myself to prefer `limit-sao` too. @gsk_ It seems to be the best subs available now, and I didn't see any major annoyances when watching. After starting to stream most of my anime I've came to not be picky about subs these days.

Yeah, I know HEVC has come along way in my opinion is better then h264 in majority of cases but still needs improvement especially with animation unless I'm depriving my encodes as I still get botches at times in a few scenes. I been using v3.0 (GCC 8.3.0) myself but sao is still not a good option for anime unless going to a higher CRF and I mean CRF 20 and up going from my testing and that article got the same result as I did. I don't know if sao was messed around by the devs with the new revisions they did in 3.0. I did a encode of this series and looks fine without sao. Was no need to do any ringing prevention and such so you used sao just for preventive measures. I can understand that tho in my opinion just seeing the source itself it's gonna impact the line art for certain with sao since the lines are real thin. Example, https://i.ibb.co/T4vMhbq/18774.png from the BDMV source I think it's the first episode frame number on the file itself tho I think it may not be accurate since I think I took it in AvsPmod. Her mouth could be impacted with that blur effect on. For gradient do you use dithering and a little grain? Should be good to go.

Thanks for the HEVC encode and batch!

@noZA_ Interesting. Many of my tests were done quite a bit ago (I think it was 2.5 or 2.6) on crf=20. I'll need to do further testing for the new builds but I probably won't remove `limit-sao` until I start a new project to keep it consistant. Do you mind clarifying how you apply dithering? The new x265 builds preserve gradient rather well but I'd like to test it out.

HEVC has it's own dithering process just in case you didn't know. In the CLI by adding **`--dither`** https://x265.readthedocs.io/en/latest/cli.html#cmdoption-dither but as it states I am not sure if you downscale and upscale. You can also add the above together with the dithering in some filters (only some contain dithering options) or just by itself if you prefer. However, would need to know what server frame you are using. Is it VaporSynth, AviSynth, etc. I'm only familiar with AviSynth, therefore, if you also use that you can refer to this: http://avisynth.nl/index.php/Dither_tools#DitherPost generally I simply use mode=6 or just stick to doing it within GradFun3 if you use that. And since you also mentioned smooth gradient you can also check out http://avisynth.nl/index.php/Dither_tools#SmoothGrad both are rather sensitive if your AQ and Psy settings are too low they may not even show up in the encode. I've read in such cases to use mode=0. Of course if you use any filters see if they also include dithering options in them. If it's something else you're using they might have a dithering process for those as well if you type it in the search query. Release notes for 3.0 https://x265.readthedocs.io/en/latest/releasenotes.html

I'm stupid, so can someone clarify what NC version means?

Non-Credit

I enjoyed the tech discussion quite a bit. So there are still some encoders that actually go through studying and testing. Ffs too many recent releases are a disaster, this one might or might not be improved, but it has some reasoning behind the choices. Much appreciated.

@noZA_ Thanks, I'll look into filtering. I use the source resolution (1080p) from the BD. I asked because the documentation mentioned using while downscaling. Currently using just ffmpeg or HandbrakeCLI when I'm lazy.

Yeah, I wasn't sure if you downscale and upscale using a upscaler so wasn't certain if it was relevant to you or not. I also see that your numa-pools is at 8 so I can understand if you don't do downscaling and upscaling as it can be CPU intensive and take a bit longer to encode plus any other filters to improve the quality. Dithering won't take much computation tho and should really be last if possible. >Currently using just ffmpeg or HandbrakeCLI when I’m lazy. I feel you. But my OCD for my encodes often times won't let me.

Some detail has been lost in this encode

Seed please