VN Completed AUTISM TRANSLATIONS

[FMID]

Wow, this is incredibly impressive. It feels like I'm watching the bleeding edge of H-translations. I agree with what you've said about the quality of market leaders like GPT 3.5 and 4. Both are miles better than the normal MTL's but still come up short. Claude is probably the best I've dabbled with but it's filter has been very difficult to work around.

Apologies if this has been cleared up already but will your model ever be used for commissions? I understand the costs are very high but as a lover of nukige, the word counts would be smaller than Alicesoft titles and thus probably affordable for myself or others.

 

[denimicehockey]

Wow, this is incredibly impressive. It feels like I'm watching the bleeding edge of H-translations. I agree with what you've said about the quality of market leaders like GPT 3.5 and 4. Both are miles better than the normal MTL's but still come up short. Claude is probably the best I've dabbled with but it's filter has been very difficult to work around.

Apologies if this has been cleared up already but will your model ever be used for commissions? I understand the costs are very high but as a lover of nukige, the word counts would be smaller than Alicesoft titles and thus probably affordable for myself or others.

As someone that's worked a LOT with just about any model you can think of - Claude is the most uncensored, degenerate model I've ever worked with, when jailbroken. It far exceeds the perversions of Goliath, Euryale, LZLV.

I'll consider commissions after Sakura no Uta - it's a fire and forget thing, so if there's a VN I can extract Japanese text for, it's minimal effort on my end (outside of cloud compute costs - local models on consumer hardware can't reach this tier yet).

 

[FMID]

As someone that's worked a LOT with just about any model you can think of - Claude is the most uncensored, degenerate model I've ever worked with, when jailbroken. It far exceeds the perversions of Goliath, Euryale, LZLV.

I'll consider commissions after Sakura no Uta - it's a fire and forget thing, so if there's a VN I can extract Japanese text for, it's minimal effort on my end (outside of cloud compute costs - local models on consumer hardware can't reach this tier yet).

I imagine my potential commissions would be minimal effort but that's a conversation for a different day. Thanks for responding and keep cooking up this masterpiece, you mad bastard!

 

[denimicehockey]

I will go back through at some point and fix HM, TSU3 (possibly HR?) de-sync bug. Here's a detailed explanation of how and why it happens and how to fix it if someone wants to script up a solution:

During translation, the Japanese script is "chunked" (split up) into segments of ~50 lines of Japanese at a time (care is taken to ensure we don't chunk in the middle of dialogue or a sentence so it's not always 50). The bug happens because you had something like

JP A
JP B
JP C
JP D

EN A
EN B C
EN D

Basically a sentence, that was split across three lines in Japanese, that was consolidated into just two lines in English. I did put in directives to try to catch this and did some mitigation on it by the time Tsu 3 rolled around, but obviously it still pops up (just not nearly as often). Anyway, so what happens is the JP translated line D (EN D) comes in one line early, because the third sentence in Japanese is not there anymore. To find this you would:

Dump JP script
Dump EN script
grep out lines starting with ;m[ -- these are the actual lines that appear in the boxes in the VN.
Find the lines with Japanese text on them in the English translation - these can actually be erased, their meaning is already contained in the preceding translation, but don't do this yet
Count backwards 50 from the index with the JP text in the English translation. The consolidation is guaranteed to have happened somewhere in that range. You can either translate line by line by hand or do it dirty and look at punctuation for hints - that'll work like 90% of the time which might be "good enough". When you find the line where the consolidation happened, just split the English line across two indices bumping up all others up to the Japanese text one (and overwriting it, as again, its meaning is already contained in the preceding translation).

I fixed this for Oyako Rankan by doing an extra QC pass on the script that did other things in addition to JUST fix that bug (I was in full-on AT ANY COST mode at that point), but doing this with an LLM is very expensive. I think they're very good (and truly 100% script complete) translations, they just need the script lines synced properly and we don't need an LLM run for that (funds better used for a new translation).

Should note, this can be done without just by hand. I think Oyako Rankan had like ~120 instances of de-sync after the run finished. So at most 6000 lines out of sync on a 90000 line script. So you'd basically have to do what I describe up there by hand, 120 times. HM is like 1/3rd that length so probably six hours of work, eight with the dump and writing it back into the .ain? Could be more for HM though. Again, at that point I was not aware of the bug's existence and wasn't doing anything about it at all (OR had a half-hearted solution in place, same one I used for TSU3 - that script is roughly the same size so the fix there should be on that order of work, if done by hand).