OP4 Yuugure no Aka

So I had my say on the whole process of our first fansub. It was an interesting process and good fun but it wasn't without mistakes. There were a few things I learnt that I hope we don't repeat again in future.

The thing that I noted when I started on this was how sort of possessive I got. As I said before the translation was done by Yume but in our QC (quality check) process we ended up doing some rewrites. This helped make me feel more instrumental in the project, when I could suggest something and have it acted upon. It was good that I could question any line and Yume would go ahead and check it out without any fuss, even if it was the tenth time I had queried that line in the last five minutes. He probably got sick of my constant questioning. Just a note, the idea of QC used here may differ wildly from your ideas so bear in mind my previous entry.

Anyhow with that said, you feel it becomes part of your work and as such I didn't want to put my name on it unless I was comfortable with the standard. It is probably laughable but I felt as though my name was a stamp of approval and I had to make sure everything was good enough for my perfectionist standard.

In keeping with this my first real annoyance and our first real problem was with the way we handled the iteration of scripts. At first we had scripts flying about all over and just as you make notes on what to discuss and change with Yume, he'd got further on in and also gone back and changed lines. So I was basically making new notes from new scripts each day. I think we finally got an understanding when I became frustrated and commented on how disrupting it was. Still when I was sent the final script, we were still working from slightly different versions, something I didn't find out until later on. There were a few problems that came about to this specifically which I'll raise later.

This is the first lesson then. Don't start work on QC until you have a script locked down in place.

So once you have a script locked down and distributed the exact same copy to both, the next step is to check for errors. We went about it raising questions as we went along. If something didn't fit we made a note. In the process of this we raised questions about spelling, grammar, sentence structures and all sorts. Something may just sound wrong out of context, so it helped me greatly to ask Yume for more explanation to help me. This leads to him to evaluate how close he is and whether or not he fully understood it. It also lead to me thinking about it in a different way and opening up other meanings he may not have got off the bat.

No matter what it was or how small, you have to raise a flag and go about working out why something is what it is. On the basis of not understanding why a sentence was structured like it was, trying to understand what was being said or just wanting to know other possible translations for a word, we came across errors in translation or alternative translations which may fit better. If not it helped to rework the current line to be clearer or more apt.

The second lesson then is never be afraid to question anything, no matter how silly, small or insignificant it may seem.

When I was watching through the release we made, there was still quite a few errors that I saw. Not a great many but enough to irritate me as I wanted to be perfect. I think that's due to one main factor. We were striving for a release before Christmas Day so we didn't really watch the final encode to allow us that final pass. It shows as some of the things we would have picked up on are missed. You have a structure set in place and having deviated it highlights problems that arise. It's a one-off and I doubt we'll see something similar happening again but it's probably best we went through such a thing now rather than on a later release when we should have learnt.

I guess it's an obvious thing but that is the third lesson. Don't go skipping steps to rush a release out.

The way we worked our way through, it was very collaborative. We both made notes and consulted each other where we thought changes should be made. Where we had errors creep in, was when we made changes away from this collaborative process. This meant when we went back later there were things we made changes to but didn't note to the other. It is a lot faster to work solo when doing this and make changes as you go, without the need to justify things to the other. Some things can be cut and dried but even the most simplest things can turn out to be a problem.

I'm not so sure where I stand on this. As I say it's quite a bit faster solo but easier for errors to creep in. However, should everything be undertaken together and slow the process right down? Drawing things out can be just as bad as rushing things. Not sure what lesson to take from this but I'm sure this is something to work on as you go through more subbing.

So only a few things and it's probably common sense, but without a guideline in place it can all become muddled. I'm pretty sure for whatever we tackle next we'll be much more in tune with what is needed. Not only that, we'll probably be doing something which is shorter in length even if it is episodal. There is less stagnation and it's easier to manage and feel like progress is being made when you are getting continual releases. We'll see how it goes when Yume does decide on a new project and whether or not we get more people on board to help out.