For those of you that are scared and have questions, don't worry. Papa Chotab is here to rock you back to sleep.

**"Why 8-bit? All anime should be 10-bit 4:4:4 HEVC with the best denoiser money can buy run on it?"**

This show intentionally has a lot of artificial noise added to it during production as an aesthetic choice. Obviously this wasn't scanned from film, so yes, it's fake grain, but it was done for a reason. So we wanted to preserve that grain because if you *don't* like it, you can always just stick to the WEB releases or download the eventual denoised monstrosity that another group will surely produce. Because we kept all of that noise, 10-bit encoding really doesn't offer much. The benefit of 10-bit encoding specifically for anime is the increased color precision is going to help you maintain gradients without them devolving into banding while avoiding what the kids like to call "bloat". Well, as you can clearly see from the file size, you can't keep big mama from bloating up this time. And because of the thick levels of grain preserved here, the are no soft gradients prone to banding. So 10-bit doesn't do anything but make a bigger number on your MediaInfo readout! If you'd like it to say 10-bit, you are more than welcome to copy and paste the readout into a document, change that 8-bit to 10-bit, and enjoy watching the show. It'll make about as much of a difference if we actually encoded this in 10-bit.

**"H.264 Level 4.1? What is this, 2006? Are we making sure this works on a PS3? What gives!"**

H.264 levels past 4.1 don't really offer anything of value except opening up an increased number of reference frames to be used during encoding, which themselves don't offer up anything of value unless you really enjoy wasting CPU cycles for very, very minimal compression gains while also telling people using a PC for playback with a GPU from the last 15 years that you don't care about them. And we do. We do care about them. Save those CPU cycles for a rainy day I say.

**"But I use Plex which needs to burn-in those fancy subtitles so who cares about hardware decoding!"**

Well, bully for you. But if you're letting Plex transcode anime this grainy then I'll need you to meet me behind the shack so you can look at the flowers because the goal of this release was to preserve all of that nice noise and you're just going to rub vaseline all over it so you can watch this in a way that's more convenient for you?! Not on my watch bucko.

**"I've encoded anime once, and I recognize the mbtree setting. People hate that! And other people like that! So why'd you go and use it? Did you even test these encodes?"**

Why yes I did you little scamp. Normally I'd never use mbtree on something this grainy but to keep the bitrate somewhat reasonable for you fine folks the settings were tuned in a way that mbtree made sense as a compromise for extra compression without going completely buckwild on the grain profile. I took the B-frame only comparisons you can find in the description to showcase this. B-frames are the most compressed frames in H.264 (not like the I-frame comparisons most people who upload here tend to use ;-) ) so if the B-frames look pretty darn good you can rest assured that the entire release will look nice on playback.

**"Okay okay. This all sounds reasonable. But what about THIS?! *points aggresively at bframes=8*".

I know the golden rule is b-frames must be 16 for anime because that's the way my father did it and the way his father did it and so on and so forth. But this ain't your grandfather's anime. I'll remind you again about the heavy noise present in this series that x264 sees as very erratic changes in high frequency detail, like what you'd find in live action film content. x264 tends to not like to use b-frames as often in this type of video because reference points are needed more frequently to track the overall look of the frame as it's changing more often than say, a flat, noiseless scene where a talking head is moving over a big blue sky and there's no motion in the whole frame. But wait, you don't just have to guess what b-frame setting to use, x264 actually tells you! Roll out Exhibit A!

> [2021-04-17][21:34:07] x265 [info]: consecutive B-frames: 14.9% 7.5% 11.2% 17.5% 9.0% 12.6% 4.9% 7.2% 1.9% 1.6% 2.9% 6.4% 0.6% 0.3% 0.4% 0.4% 0.9%

If you've ever encoded x264 before, well I hope you've seen this. This is a line from x264's output log that tells you how often it chooses to use b-frames instead of p-frames (reference frames) or i-frames (key frames). The first number represents how many frames were not b-frames in a GOP, the next number is how often 1 b-frame was used in an entire GOP, and so on and so forth all the way up to 16. As you can see, in this particular video (which is not Dragon Quest, don't have those logs anymore, stay tuned for volume 2!) there is a large drop-off after 11 b-frames where x264 doesn't find any more particularly useful. But how can this be, we set b-frames to 16! Well x264 is pretty smart these days and it knows how best to spend its time, as life is short. So for this encode, you would be able to safely pass --bframes 11 to x264 and lose a completely negligible amount of compression because x264 isn't going to use b-frames often at all in greater number in a GOP anyway. This will also decrease your encode time a bit, because x264 isn't wasting time trying to decide if it wants to use b-frames or not, since you've told it not to worry about that anymore.

tl;dr, --bframes 8 was also not chosen blindly.

I hope this answers some of the questions that might pop up here with regards to the video track.