>>=2

Debanding debanded video only to encode it in 8bit

dead

I certainly should’ve written that post few years in advance, back when I had motivation for this.

As you could’ve guessed from almost a year of inactivity and the post title, the re-encoding thing is dead.

It would be sad if the post only had like one sentence about current not-so-fortunate status, so I’ll write about how it all started.

My shitty android tablet can actually handle both 10-bit decoding and somewhat complex ASS subs hardware-wise, but software had (and still have) a number of flaws that can only be bypassed by using hardsubs and 8-bit video. Obviously there was an established (?) and respectable (?) group (?) called DeadFish that already solved the problem but I couldn’t just go ahead and use their encodes as I was unlucky to be literate enough to know they suck in a number of ways:

  • They are kinda slow because doing it by hand would always cause delays
  • They keep doing dumb mistakes because doing it by hand would always cause mistakes and because they are dumb
  • They keep using x264 from the last decade, what the fuck
  • They reencode audio most of times if not always (e.g. they would reencode 128kbps AAC to 128kbps AAC, which, in case you didn’t know, would degrade audio a bit)
  • Despite being cheapfags that almost always use 128kbps bitrate with audio they don’t hesitate to bloat video really hard (sometimes making it twice as big as source)
  • Their encodes are banded even at high bit-rates because it’s not like they know how to encode
  • They somehow manage to do other unexplainable stuff like reencoding hardsubbed 8-bit 720p video into slightly bigger and less hardware-compatible 8-bit 720p video
  • Given a multiple sources they would pick the worst because why not

After I actually started encoding things I noticed that the first point wasn’t true because they have an army of minions ready to encode at any time of the day but whatever.

Few hundreds of lines in unreadable scripts and couple of British pounds later I somehow got to the point where I had the system that Just Worked. All I had to do is adding regular expressions to the list. Releases got automatically downloaded, reencoded and uploaded.

During a year or so I fiddled around with scripts, improving some things and experimenting, but after that it was a few years of doing nothing except adding new seasonal shows. Not unexpectedly, once nyaa died and I had to actually fix stuff to work with new nyaa or other trackers I couldn’t be assed to do so. Luckily, fanusbbing was pretty dead anyway and there was no need to continue.

RIP

About versions

It probably goes without saying that different versions of releases should be easily distinguished by a filename or torrent name. Most fansubbers put CRC in filename because it’s nice to have a way to check file integrity and it would change when content is changed e.g. new version made. However, CRC can’t really be used as verison number because CRC is kinda random, while version number should increase, so some other version scheme is used.
Fansub groups usually use “vN” version scheme with N being non-negative integer:

  • v1 (which is omitted in the filename) for finished release
  • v0 for nearly finished release which can’t be finished soon (poor quality video source with no proper source available yet, few unimportant signs that would take a good while to typeset, some staff member unavailable etc.)
  • v2, v3, v4 – versions with some more errors fixed

There are exceptions, though – you can find few v1.5 releases, GotWoot used [GotSpeed] tag to release Mirai Nikki v0.

[RightShiftBy2] won’t stick with “vN” version scheme because there are 3 different ways to make a new version, which should be labeled differently:

  • Fansub group released another version  – source for reencoding changed a bit
  • Source is the same, but process of reencoding is somewhat different. It could be done to fix unreasonably low CRF (which leads to unreasonably big file size) or to fix subtitle rendering error
  • Release of another fansub group used – source for reencoding significantly changes. I am trying to stick to one group whose job on particular series I like the most, but better group may suddenly pop up later (kdfss is a good example), so switching groups may be unavoidable. Different tags will probably be used in such cases (like [FastShiftBy2]/[FineShiftBy2])

So here is version scheme:

  • vN.M will be used as version number, which means M-th reencode of source vN
  • v1.0 is default, so it wont be in filename
  • vN.0 files will be labeled with vN (which is initial release of vN reencode, see zero-based_numbering)
  • v1.M files will be labeled with v.M
  • Otherwise file is labeled with vN.M

Few examples:

  • [RightShiftBy2] Isshuukan Friends – 05v2 – first reencode of [Kaylith] Isshuukan Friends – 05v2. It is v2 even though [RightShiftBy2]’s v1 was never released.
  • [RightShiftBy2] Gokukoku no Brynhildr – 04v0 – first reencode of [DameDesuYo] Gokukoku no Brynhildr – 04v0. No v1 because DDY never released v1.
  • [RightShiftBy2] Gochuumon wa Usagi Desu ka – 04v.1 – second reencode of
    [Vivid-Taku] Gochuumon wa Usagi Desu ka – 04
    with fixed main dialogue font.
  • [RightShiftBy2] Anime Mirai 2014 – Harmonie v.1 – second reencode of [Watashi]_Anime_Mirai_2014_-_Harmonie with fixed ending KFX.