I keep reading about these extremely complicated schemes you people set up in order to store all your Chinese child pornography cartoons, with ZFS arrays spanning terabytes in the double digits, and of course running on AMD© Ryzen™ Threadripper® CPUs℠. Let’s not talk about the hoops you jump through to ensure uptime by securing your power delivery, network, and of course security from random Chinese ssh hacker bots. Today, I have good news for you. I have solved the anime storage problem for good, and by “good” I mean “for the next decade”. Forget 100% of the bullshit tedious file system and networking tasks that have given you lots of anxiety and very little anime. Actually forget about partitions; you should just
mkfs.bcachefs /dev/sda raw without even a partition table. Sell 👏🏻 your 👏🏻 NAS 👏🏻
What you need:
Once you buy your hardware, start with downloading your paedophilic animu in a stupidly undercompressed format, like for example Coalgirls or raw rips with FLAC audio or some shit. These are encoded with a CRF of 13 or something. For the record, a CRF of 18 in x264 is considered practically lossless, because most humans can’t perceive a difference even if they pixel peep.
Now to compress the living shit out of it. Let’s start with audio, because that’s simpler. FLAC’s sole usefulness is for archival of raw audio for posterity. If you just want to listen care-free, you should use Opus, Vorbis, or AAC instead; Opus typically has better quality under XXXtreme compression. I can hear your audiophile counter-argument already, but I ignore it because it’s placebo effect and you deserve gas chambers. My suggested settings are 64 Kb/s at 60 ms frame size. High frame size sacrifices latency for quality. 64 Kb/s is the bitrate sweet spot, and I can’t hear improvements above it. Vorbis quality 3 is 4 times the size at the same perceived audio fidelity. You can try 32 Kb/s and 48 Kb/s Opus, but in both instances I can hear compression noise (hissing) so I suggest sticking to 64. The trade-off isn’t worth it as you’ll only save a few megabytes.
Video is more complicated. I recommend keeping the bit depth for colour that the original has, unless you have compatibility issues with depths larger than 8. You should use x265, not x264; it’s much slower, but you’re really going to feel the quality difference after we’re done. Compared to x265, VP9 is slower, with less compatibility, and less quality. Theora is a meme. VP8 is a meme. As of 2020, AV1 is so slow that it’s also a meme; let’s talk again in 2030.
medium preset is fairly good, though if you have tons of horsepower you could try up to
placebo is a meme, and
veryslow isn’t worth the performance tradeoff in my experience. You’ll see most of your gains by going to
slow, so if you have the cores, stick to that. There’s a tune for animation, as in traditional animation, which improves results and sometimes encoding time for flat video, as animation tends to be. If you’re encoding a Pixar film with lots of 3D and moving parts, don’t tune for animation.
I recommend you use a CRF of 25, which should correspond roughly to an average bitrate of 1100 to 1200 Kb/s. You can of course specify it manually, but that would leave high-intensity scenes starved for bitrate. Alternatively, you can try two-pass encoding, but that would double the encoding time of an already laborious process, so you should stick to CRF. CRF is by its very nature unpredictable for file sizes; I tested everything from 23 to 27, and 25 was the best balance.
At CRF:23, tune:animation, and preset:medium, even pixel peeping high motion shots, I had difficulty telling differences, though I could see them. If I did not pause frames and compare the images by overlaying them, I would not be able to tell the differences. In other words, while you’re actually watching video of sexualised prepubescent cartoon children, and not a frame-by-frame slideshow, you won’t notice any difference, therefore I consider those settings to be effectively lossless.
I used these settings on a comically bloated Attack on Titan episode (E12: Wound), weighing a stupid 1.7GB:
ffmpeg -i input.mkv -map 0:v:0 -map 0:a:1 -map 0:s? -c:v libx265 -tune animation -preset medium -crf 25 -c:a libopus -frame_duration 60 -b:v 64k output.mkv
The result is a file weighing 189MB: the target is a 200MB file. I consider the quality more than acceptable. For reference, the FLAC audio for the episode alone was 261MB, reduced to about 11MB in Opus, with imperceptible loss in quality. If you want, you can step up the target to 300MB, which should be more than enough per episode to satisfy even the most discerning pixel-peeper. This should correspond to 96 Kb/s in audio and a CRF of 21 or 22, but you should do your own testing to be sure. I think it’s a poor balance as you gain 50% in size but barely perceptible improvement in quality.
I don’t know how much anime you watch, but let’s assume you’re super hardcore, like 10 series every season. There’s 4 seasons in a year. Most seasons have 12 episodes, and we’re using up 200MB per episode.
10 × 4 × 12 × 200 = 96,000, so 96GB a year.
1,000 ÷ 96 = 10.41(6), so it’s going to take you about a decade to fill up the $100 portable SSD, at which point NAND flash will have become even cheaper, so you can buy another $100 portable SSD at several times the capacity. Naturally, the proposition is even more insane with hard drives, which would take about 40 years to fill up at the same price, by which point we might have achieved technological singularity, and yet somehow btrfs will still not be stable. bcachefs pls upstream soon.
With this, I can safely say that anime storage (and video storage overall TBH) is a solved problem. If all you need your NAS for is to store anime for your personal consumption, the very fact that you have a NAS at all is overengineering and a waste of money. You’re better off spending all the money you’ll spend on storage on a better CPU instead, so that you can encode video on a slower preset with higher quality. Hell, you can run this to the endgame and store your anime in the Cloud™ in Backblaze or something, though in my opinion local storage is more economical.