Fortune Arterial BD 1-2 Batch

Have you guys figured out what I picked up yet? I bet you haven’t! Mu-ahaha~! Don’t worry, if you hate this project, I still like it. Anyway, I plan on picking up something else to replace SG (since next release will be the end of the series) and may even pick up another series when my new comp arrives. So DO NOT DESPAIR! Keep sending us your requests! We will, eventually, probably—well, maybe—get to the series that you requested. Yes you. You there, reading this post. The one that keeps on asking us to do Ninja Turtles. (Okay, not him).

As for the clever ones of you out there, yes, we’re only doing the 720’s. The 1080p’s are just upscales so there’s no point in making a massive file (and increasing the encode time by several factors) for nothing.


Katanagatari (1) v3 [BD]


This is a very long and involved post that details our work on this episode. Future posts will not be this long, but we felt that some of our fans might be interested to know how we went about encoding this particular episode. If you simply want the torrent or DDL links, then stop here.


Warning: The 720p version has not been tested on the Xbox 360. We have tested it on the Playstation 3. We have full confidence that the 720p video will work on the Xbox 360, but if you find that you are unable to play it on the Xbox 360, please notify us immediately.
Part 1 | Part 2


OK, so we’ve finally gotten around to re-encoding the BD’s for this series. The first time around was a complete disaster. The second time around had weird corruption issues. And now, we’re doing this a third time, except this time we’re gonna get it right.

Project-Wide Goals

  1. Ensure the perception of high quality
  2. Use anti-banding filters to restore lost gradients in the source
  3. Improve image encoding and compression by specifying encoding settings for scenes that require special considerations (more on this)
  4. Use FFMS over directshow. We’ve been using FFMS since The Disappearance of Haruhi Suzumiya (1080p)—which is why there’s corruption in the 720p version
  5. Prevent all corruption

1080p Goals

  1. Make the torrent tolerable. Target file size: 2.5 gigabytes (~6000 kilobits/second)
  2. Increase the quality of gradients

720p Goals

  1. Make DDL’s tolerable. Target file size: 1.3 gigabytes (~3100 kilobits/second)
  2. Use smoothing filters on flat colored areas to wash out details and improve compression

Encoder’s Log

As you can see, Katanagatari presents a challenging issue for us: how do we encode a 43 minute gradient-heavy, highly detailed, and highly dynamic anime without going over 1.3 gigabytes for the 720p and 2.5 gigabytes for the 1080p and without sacrificing gradients or details? That is an incredibly difficult thing to do. In fact, you could say that this is the very struggle of developing lossy compression techniques. I mean, we’re having issues keeping Ore no Imouto under control, how are we suppose to do that with Katanagatari? x264 is an amazing compression library, but it can’t do magic. So if we can’t use magic, then we better figure out a way to fake it.

One of the biggest issues with Katanagatari is that some scenes are radically different than other scenes. The first two minutes of this episode features heavy amounts of grain and noise. The rest of the episode is fairly steady. Compare the above image with the one below and the one at the top.

We’re going from white text on black, to a super high-grainy image, to complex lines and fine details. It’s kinda difficult to pick a “median” crf value and hope that x264 doesn’t waste tons of bits trying to preserve the grain at the beginning and blow up the file size. By the same token, if we try to limit the file size by using a target bit-rate, x264 is going to want to use a lot of bits at the beginning in order to preserve the grain and will sacrifice the quality of later scenes in order to achieve the target file size.

So the whole issue revolves around tweaking the rate-control method and its associated constraints for specific scenes. There is an option in x264 that allows you to manipulate analysis methods for any arbitrary sets of frames; it’s encapsulated in the –zones switch. But the only thing you’re really allowed to modify is the motion-estimation, the deblocking strength, the subpixel estimation complexity, and the quantizer level. Now, modifying the quantizer would be nice, except we don’t use a constant quantizer to encode our media. We don’t want a context-blind encoding scheme that simply forces everything to be a certain “quality” regardless of the scene context, which is what a constant quantizer does.

Real quick before you get confused, there are three predominate, mutually exclusive rate-control methods in x264:

  • Constant Quantizer (QP): Specifies a blind quality level. Basically takes a frame and encodes it according to the specified quantizer level, without taking into account scene context. So basically, let’s just say that I have an extremely dynamic video with lots of still scenes and lots of fast scenes. If I used QP for this type of video, x264 would encode all scenes at the same quality level.
  • CRF (Constant Rate Factor): Specifies a certain perceived quality threshold. Takes a frame and calculates how important the details of this frame are in relation to other frames around it. If this frame is a part of a scene that is extremely short or extremely fast (lots of camera movement), then the quality of this scene is reduced because your eyes probably wouldn’t be able to appreciate the details of this scene anyways. The inverse is also true: if a frame is a part of a scene that is still or long, then the quality of that frame is cranked up because your eyes will be viewing this scene for a longer period of time. If you’re CRF value is X, then fast scenes will have a QP value of X + K, while slow scenes will have a QP value of X – J, where X, K, and J are in the set of rational numbers. Remember, lower values for CRF and QP mean higher image quality, with 0 being lossless. Let that sink in for a bit.
  • Bit-rate Constrained: This specifies a target bit-rate, and thusly a target file size. This can be used in a single pass (a bad idea) or in two passes. The first pass analyzes the video and determines what type of frames to insert at certain points of the video, while the second pass actually encodes the video. Nothing really to be said here. It’s one of the simplest rate-control methods, yet one of the hardest to properly implement.

So in order to overcome these limitations, we simply split up the encoding job into separate pieces based on the scenes in question. Now, that answer may sound obvious at first, but there isn’t any documentation or technique of concatenating two or more x264 raw bit-streams. So we did some experimenting and found a way to concatenate the raw bit-streams together, but it requires particular attention to the frame-type specified.

Without getting into details and extending this rather long post, I’m just gonna say that some scenes were encoded at lower quality settings because your eyes can’t tell the difference. Specifically, we altered the AQ-Strength, the deblocking strength, the rate-control methods and their associated constraints, and the motion-estimation methods for each scene in question. This is basically how we’ve managed to export a rather reasonable file size.

Of course, given that we were limited to a certain file size, both of our releases are bit-rate starved. The 720p is most definitely the most bit-rate starved, but if you look closely at the 1080p version, you may see some slight banding. But for the most part, both releases should look pretty damn good.

Now, onwards with Ore no Imouto (4).

Maria+Holic Alive (2)

God damn. This episode caused a lot of problems.

Being a SHAFT production, there were about a billion signs all over the place. And if you’re wondering why everything is delayed this week, it’s because I spent several hours fixing the audio issues with the raw. The audio at the beginning of the episode was 0.251 seconds too late, but by the end of the episode had shifted to being .2 seconds too early. WTF is going on with that? Furthermore, the encode turned out to be gigantic (~513 MB).

Argh! This was a very frustrating episode to deal with.

Oh BTW, Strike picked up Fortune Arterial: Akai Yakusoku [BD], so I hope people are looking forward to that. Also, I’m encoding Katanagatari (1) BD as I write this. I hope to have that episode done by the weekend.

Torrent (DDL)

Kore Wa Zombie Desuka? 1-2 BD

I’m a zombie?  But I had such a bright future of encoding ahead of me!  … Right.  Anyway!  Moar boobs in HD coming your way.  As I’ve explained before, if the subs move, it’s because they’re in the way of important details that I don’t think anyone should miss!  That aside, I think this is one of the cutest pics of Sera EVAR!

Now if only she would wear that maid outfit… In fact screw the maid outfit, or clothes in general.  If only she would get naked.  *cough* Anyway, if your first plan fails, BREAK DANCE!!

Personally, I woulda gone with the whole “I’ve lost my clothes, can you get naked?” routine.  Wayyy more effective.  >.>  <.<  What?  It makes the person who’s naked feel less awkward.  Ugh, that I have to explain this to you guys…  That aside, big thanks to helios for taking care of the 1080’s and double checking the scripts before release!


Kore Wa Zombie Desuka? (1) DDL

1080p | 720p

Kore Wa Zombie Desuka? (2) DDL

1080p | 720p