I saw this posted on the brasilian melty server and I thought about how BL people really memed on the precarity of the translation
Never once did I consider that the translation forum would have been the source of the translation
Still, nice work.
I saw this posted on the brasilian melty server and I thought about how BL people really memed on the precarity of the translation
Never once did I consider that the translation forum would have been the source of the translation
Still, nice work.
Call me 想φαγω.
Spoiler:
Thank you Brazilian Melty community, you are my greatest ally.
I frequent here a bit however, I just had to make this account to say "Thank you" this is truly a huge service you all have did for the community.
Today I learned there is a Brazilian Melty community
The hardcore TM fans are like 90% Brazil bros.
Current BL is almost as old as Melty Brasil forum.Originally Posted by Kirishima
One is inactive, tho.
Eyy thanks
Wow, the legend himself.
The Kaleidoman himself.
I'm glad to have him aboard to stall our release
Current updated OP encode: comparison
Current OP subs: video
The fun now comes in incorporating that into the game.
For a little background info, the ideas I brought up in our little clique involves hacking in mpv support, which would in turn allow us to support any codec it supports, as well as use the ASS format for the subtitling (which is what was used for the subs in the first place). However, limitations in the way the code was written makes that difficult, which means we may be forced into using wmv for the video ourselves (which would severely impact the video quality and force us to hardsub it, far from ideal). It's a fun puzzle, but it sure would be neat if the game weren't so vehemently against it lmao
Now, let's talk about my specialty: video encoding. Here's a bit of info about what's going on with the encode as well for those who are curious:
The OP video suffers from the following problems:
1) Chroma location is wrong, causing a very noticeable chroma shift.
2) Chroma was (most likely) upscaled using point/nearest neighbour, causing it to look very blocky in a way that clearly wasn't intended (during production, it was most likely YUV444, not YUV420)
3) Compression noise and heavy banding in a lot of scenes
4) Aliasing with the anime parts as well as a lot of the backgrounds
5) Heavy shimmering (not as visible in the comparison, it's a purely temporal artefact)
6) It's just plain super busy, making compression without just reintroducing all the issues inherent to compression difficult.
For reference, the VapourSynth script used for filtering can be found here and the x265 settings for the encoded version in the comparison here (note that this may not be used in the patch depending on how things go, but I think it illustrates how much I care about video transparency as opposed to attaining smaller filesizes).
So, let's go down the script as we go:
First order of business besides obviously loading in the clip and doing basic prepwork, we set the chroma location. Chroma can usually follow a certain set of locations, and it defines the point chroma is scaled from.
The original video was set to use chromaloc=0, but the flag was simply set to chromaloc=1 by default (or rather I should say it was not set, leading every playback option to assume chromaloc=1 as that is the most common default). Easy fix, we just need to *actually* make it chromaloc=1 (or alternatively, properly tag it as chromaloc=0, but adjusting it to 1 makes it less likely for anyone else who may re-encode my encode to mess it up again).
The next fun bit is scaling. When doing comparisons between the PC and the Switch versions back in October when I did my old encode, I determined that the switch made for a better encoding source, having more detail overall and slightly less artefacting (no doubt because it used h264 for the encode as opposed to wmv). However, that came with one issue: the Switch OP was 720p. Now this means two things:
1) There's going to be less overall detail by default because this OP was (presumably) entirely edited in 1080p. Even if it was originally done in 720p and then upscaled to 1080p during mastering, we'd still lose information because this was likely just a regular downscale, not a descale.
2) We need to do our own upscale, which can come with its complications. For one, most common scalers are kinda bad at making the upscaled video look any decent, which means we need more... precarious solutions that result in a sharper image without introducing issues common with scaling (ringing, haloing, aliasing, etc.)
For this, I decided to use a mix between FSRCNNX and nnedi3 . The latter is very common in anime fansubbing encodes (which is where I hail from), while the former is used a lot less because it can be extremely prone to causing issues at the cost of looking a lot sharper. Fortunately, a friend and I had already thought up and implemented a solution to most of the issues with FSRCNNX a while ago, so I simply used that.
The idea is simple: FSRCNNX is very prone to causing haloing and ringing due to its nature of being a very sharp upscaler. This is generally very bad, because it will also sharpen artefacting as well as just generally look kinda bad for most line-art. To limit the damage it causes, we merge it with an nnedi3 upscale. Nnedi3 is a lot softer (but generally still sharper than most common scalers like Catrom (Bicubic b=0, c=1/2), Bilinear, Spline, or Lanczos), but a lot less prone to weird temporal instability as well as generally doing a good job of giving us a weak AA while we're at it. I won't go into detail why, but for now, know that it's basically the ideal "scaler" for a lot of anime-and-similar content. So, we limit how much of nnedi3 is used and how much of fsrcnnx is used for the upscaled clip, as well as add additional constrictions on the fsrcnnx clip. Read the code linked earlier if you want to see how it works internally. By nature, nnedi3 and fsrcnnx are doublers, so it still needed downscaling to 1920x1080p afterwards. For that, I simply used ssim_downsample. The chroma was simply upscaled using nnedi3.
Point is, this gave us a pretty solid upscale without all the crud common to common scalers and without being silly like a lot of upscaling neural networks tend to be. The result is an upscaled image that still looks close to how the original did without mangling the look, just at a higher resolution. As an added bonus it also fixes up some of the line-art in the process.
Catrom (Bicubic b=0, c=1/2) vs. FRSCNNX + nnedi3 vs. Bilinear vs. Spline36 vs. Lanczos (taps=4)
After that comes the most contentious part of this script. Remember how I just bashed people who use destructive NNs? Well, we're using one of those here. Meet DPIR. In simple words that really don't do what it does justice, it's a model trained to specifically handle blocking, connect lines, reinvent detail if necessary, perform chroma reconstruction, and deblur certain parts of a picture. Of course, as with all filtering, it doesn't come without its issues. It's very prone to accidentally wiping out a lot of detail if you're not careful, so it must be treated with care. Of course, another friend and I already wrote a function that tries to handle a lot of it, but that alone won't be enough here. To help prevent more detail loss from occurring while still fixing up the compression noise as best as we can, we're also doing a contrasharpen. This basically takes the original clip, the denoised clip, and tries to resharpen the denoised clip using the base clip as a reference, while making sure to not add higher pixel values than were previous removed. This can be used to "fix" detail loss caused by a strong denoise, but it's far from perfect. It's most useful for restoring slight bits of backgrounds and smaller, fine bits of detail around edges. Old implementations are pretty bad at it because they tend to also introduce haloing, but fortunately for us there have been recent rewrites for VapourSynth that handle it significantly better.
scaled vs. denoised vs. csharpened
Then comes dehaloing, but that's a rather boring topic. It's just getting rid of the high contrast edges where they shouldn't be, commonly caused by poor upscaling, downscaling, or sharpening. Left weak because a lot of glow seemed to be intentional.
Finally comes debanding, dithering, and final clean-ups. Debanding was left relatively weak because it was very easy to destroy the blurrier backgrounds, but it was left strong enough to deal with the most obvious banding.
Dithering was simply done using adaptive_grain. It applies stronger graining on darker areas of the frame because that's where human eyes are better attuned to seeing detail, so we want those to be killed during encoding the least.
Final cleaning is a weak blur on very high-brightness areas. Just like how we can see detail in darker areas better, we're nowhere near as good at seeing finer detail in super bright areas, so we can save space by carefully culling parts of it.
The end result is a much sharper picture, less compression noise overall (at the cost of some very slight detail loss in some backgrounds), more well-defined line-art, less banding, etc. One thing you may have noticed I skipped out on was the shimmering. That's because there's simply no real good solution to fixing that. Sure, there's QTGMC, but that black box of a filter is incredibly destructive and oftentimes just makes the end result worse, so I decided against using it.
tl;dr multimedia sucks and everything related to video should just burn down.
Hope this was an interesting insight into the encoding part of things. I'm also taking over editing and I've already done the song styling a while ago, so it might be fun to talk about those later. We'll see.
Last edited by LightArrowsEXE; July 24th, 2022 at 08:03 AM.
The byzantine nature of the French Bread engine is known to few.
I feel somewhat bad that I don't have a solution to some of this stuff.
Don't be. This engine is a swamp, one that swallows people whole. You can step foot into it, but don't go too deep, or you may never resurface!
The game crashes a lot after I applied the patch. Like when I try to start a match it just crashes into Windows.
Sorry, I missed this. We actually had Light up there with a similar problem. It eventually just solved itself mysteriously. Not sure what the cause is.
That said, this patch will be outdated within the week. There probably won't be any time to diagnose and fix this problem.
Since idk when this patch will be updated, I was wondering if i could get this notepad with the characters arc drives/ last arc quotes in Japanese off you.The line itself actually exists in the files, but they've disabled it in game. It seems to be a remnant of when he was developed as C-Roa, as all of his other C-Roa lines have been disabled as well.
Basically, it's old Roa stuff that's floating around in the files.
EDIT: Sorry, it appears I didn't look closely enough.
His 'old Last Arc' lines have indeed been disabled, but they just put them in again with the same lines and everything, you're right.
I'm an amateur so some things are hard to understand by ear in game.
I might compile them in a more digestible format myself later. They're scattered across a bunch of files in various locations. For now, I'll just recommend you download the MBTL extractor and retrieve the files yourself. They're generally in the SE_Category files located in each character's personal files.
I've been looking and I assume it's the se_category files from the "data" bin in the character files. How do I go about reading these as they are not in a readable format for me.
Be so funny if the Spanish, French, and Brazil translation is more accurate than official Engrish one.
Your not a TYPE MOON fan if you don't even own a TM Merch or haven't fapped to a TM character.
They shown one screenshot and from that alone I can already tell you that the Brazil version is worse than English. There are no upsides to today's announced. 100% é uma lua ruim.
Posting Permissions
Reply With Quote
