AnimeSuki Forums

ArchMageZeratuL · 2008-01-08, 21:56

Today, I had an idea that some people in #aegisub judged to be interesting. After a brief discussion there, I've decided to post it here to gather the opinion of more fansubbers.

I already expect a lot of flaming, especially from the "speedsubbing sucks" groups, although this proposal would benefit everyone, not just speedsubbers.

The idea is to have some sort of client-server system (with the client integrated into Aegisub) so multiple people can work on different stages of the fansubbing pipeline of a single episode all at the same time.

Basically, there's a server that you connect to (with login and password). The server lists all active projects. You pick one, and assign yourself a specific position, for example, "timer". Then, every connected member can start working on it as work becomes available.

It all starts with the translator, of course. As he watches, he will enter lines in a text editor-like interface (with a few additions, such as F1-F12 keys to quickly switch current actor). As soon as a line is entered, it starts to "count down" (say, a minute). The translator can still change the line while the countdown is going. When the countdown is over, the line is sent to the server as "ready for the next stage".

That way, the translator doesn't have any extra work, and the next stage can start as soon as the translator has typed in a few lines. Alternatively, there can be a "flush" button, to flush the current pending lines. This is up for debate.

After the lines were submitted, the server understands them as "translation OK, waiting timing and editing". On that moment, both the editor and timer will have the line available for them. The timer will only be able to change the actual times, while the editor only the actual text, therefore their work is completely independent. As they are done with lines, they are also auto-set for the next stage, or flushed manually. Maybe typesetting could also be done in parallel at this stage.

After that, if typesetting was already done, all that is left is translation checking and QC. Translation checking can happen immediately after editing, and might be optional (server-side option).

The final stage, QCing, will likely be slightly different: the program will wait for a reasonable ammount of lines to be "ready", and, once they are, tell the user that it can has more stuff to watch. Then the user watches the fragment and hits a key whenever he sees a problem. The program then pauses the video and asks what kind of problem it is, translation, editing, typesetting, etc, and the user picks it, with optional comment. The current timestamp is marked as "in need of revision", and the appropriate person assigned to the episode is notified of such.

If you've been keeping up with my logic, it should be clear that such a system would allow an entire episode to go through the entire fansubbing process, including more than one QC, in an hour or so, if the team is all available and works at typical speeds.

Also, the server would work in a somewhat SVN-like fashion, preventing version conflicts and keeping a history of all changes.

It's up to debate how would "late revisions" work... For example, if a translator wants to change something after it's already been edited. Either way, it shouldn't be too hard.

Now, this is just mindstorming. I had the idea and decided to share with the community. This all could feasibly be implemented in Aegisub after the planned 2.10 reformation (yes, we still need to release 2.00 before, we KNOW

), but we will only really consider it if there is sufficient community support for it.

The server itself would be a lightweight cross-platform program, which would be administered remotely by clients with admin privileges. A single server could potentially host many different fansubs, and each fansub could be organized in projects, and each project in episodes. Each user would them assign themselves in a position for some project (or maybe the admin would?) in order to work on it.

There's also some question on how to share the raw - should that be done manually, or should the program deal with that in some way? That way, once the "distro" client has the raw, it could stream it to other users, so they can start working as they receive it... Although that's probably overkill.

Anyway, I'm not promising anything!

This is just an idea, for now. It MIGHT become reality someday, who knows? But how the community reacts will largely influence that.

Thanks for your time and sorry for the long post!

[EDIT] BTW, the mentioned 2.10 reformation is mostly source-wise, not interface-wise, but will allow things such as multiple subtitle files loaded at once, which is pretty much mandatory for proper Mac support.

[EDIT2] Here's the log from #aegisub:

Spoiler for Long IRC logs:

p-static · 2008-01-08, 22:21

Like I mentioned on IRC, basing this on obby (the collaborative editing part of gobby) would give you about 90% of what you're describing here. (For those of you who weren't on IRC: In Flomp, we use gobby for a good bit of the subbing process, and it works really really well. In actual practice, using a system like this, we can finish an episode in 3-5 hours.)

A few suggestions:

* Instead of the minute wait for the lines to be sent to the server, it'd probably be easier (and more useful) if the text was sent as it was being typed. Also prevents race conditions when two people are editing the same line.

* Having the server be aware of what stage a line is at is a really good idea - that should be developed further, it'd be really useful, especially if you allow the user to re-label lines that need to be redone in some earlier stage.

* gobby already has a lightweight, cross-platform server available - one more reason to use it

Tofusensei · 2008-01-08, 22:58

Great idea, impossible in implementation.

p-static... What group are you with? I'm a very experienced fansubber and I've never heard of a 3-5 hour turnaround unless you mean an uber speedsub with no editing or QC. The fastest I've ever done is 10 hours, and believe me, that's considered extremely fast.

-Tofu

ArchMageZeratuL · 2008-01-08, 23:07

Impossible?

I don't even see anything as particulary CHALLENGING...
It's just a LOT of work, but none of it is *hard*.

Or do you mean something in particular that I've overlooked?

p-static · 2008-01-08, 23:14

Yeah, it's a speedsub, but the quality is actually pretty decent. We have a fairly efficient pipeline set up, where everybody can work simultaneously, which takes off a lot of time. Releasing softsubs also helps, since we can encode in parallel with everybody working. That breaks down somewhat if we need to do any complicated typesetting that can't be reliably done in a softsub, of course, but for the most part that isn't a problem.

In the end, the speed of the process is basically TL time + timing time + edit / tl check / qc / typesetting time, since everything after timing can be done simultaneously. So with collaborative editing built into aegisub, that could be improved even more. :3

cyth · 2008-01-09, 09:45

The fansubbing community is already being perceived as a tool (even moreso than before), now you want to make it a part of an actual tool?

All hail efficiency and progress!

Ijuki · 2008-01-09, 09:54

I agree with Tofusensei.

Although, go ahead and try, if you manage to get it to work, I am more than willing to try it. Shame that every one lives in different places of the world, which slows the things downs no matter what tools you are using.

CelesAurivern · 2008-01-09, 09:57

Sounds like a recipe for chaos : D
Beside's how many real speedsub groups are still out there anyway?
Even that ninja show takes over 12 hours to hit the shelves.

comatose · 2008-01-09, 11:12

If you're willing to take the time to implement this, then go ahead. It sounds like it could, in most group, at least speed up the process somewhat.

The only problem for some groups might be a place to put this server on, but I guess they all have at least one member who stays online 24/7.

In any case, I don't like the countdown parts.

ScR3WiEuS · 2008-01-09, 11:53

i guess it would need some kinda of color code to show which lines are final and which not. but even then, i personally don't work from beginning to end, in a linear way. as i edit, i skip around the script, change stuff everywhere, etc. i guess it might work for like, translating and timing at the same time or so, but that would mean that the timer would have to time without having tled lines, something not many timers like to do. it would also have to mean that the people are able to work at the same time, and that they can communicate directly as to not interfere or change each other's work.
in short, it's an interesting idea, but not worth pursuing. i don't think anyone but speedsubbers would successfully make use of this idea. it's too risky for groups that prioritize quality over speed.

ArchMageZeratuL · 2008-01-09, 12:02

Quote:

Originally Posted by ScR3WiEuS

i guess it would need some kinda of color code to show which lines are final and which not.

Yes, I was thinking of something like green for lines already committed by you, yellow for sent, but waiting for someone to pick it, white for what's currently yours and red for those not yet available for you.

Quote:

Originally Posted by ScR3WiEuS

but even then, i personally don't work from beginning to end, in a linear way. as i edit, i skip around the script, change stuff everywhere, etc. i guess it might work for like, translating and timing at the same time or so, but that would mean that the timer would have to time without having tled lines, something not many timers like to do.

No, my idea is to do timing after translation, but only offset by a minute, on average - That is, assuming that the timer can keep up with the translator, the timing will be done 1 minute after translation. Same for editing and typesetting, if they're parallel with timing.

The whole POINT of this system is that even if you NEED a particular task before yours, you don't need it to be DONE: you can work on the partial work.

Quote:

Originally Posted by ScR3WiEuS

it would also have to mean that the people are able to work at the same time, and that they can communicate directly as to not interfere or change each other's work.

The system won't allow people to change each other's work. This will be constrained so that you are only capable of editing what you are SUPPOSED to edit.

Of course, people being able to work at the same time is the biggest issue.

Quote:

Originally Posted by ScR3WiEuS

in short, it's an interesting idea, but not worth pursuing. i don't think anyone but speedsubbers would successfully make use of this idea. it's too risky for groups that prioritize quality over speed.

It's not risky, indeed it's safer - for example, timers wouldn't be able to accidently change the script (some people on #aegisub said that has lead to several confusions before).

But, yes, speedsubbers would benefit from it the most.

Now that I think about it, I can imagine that non-speedsub groups would want to oppose this idea on grounds that they don't WANT speedsubs to release so fast... Thoughts?

dj_tjerk · 2008-01-09, 12:09

'quality' groups get a lot of their work done out of aegisub. So it's probably not gonna make a lot of difference for those groups, as aegisub isnt really what's the bottleneck for them. Though.. I like more efficient/parallel QCing (in case of more QC'ers that is.. 1 good qc'er should be fine too :P), and the 'tracking changes' stuff.

Quarkboy · 2008-01-09, 12:18

Frankly, I would think this would be best implemented in a hosted website application, ala google aps, instead of a stand alone program.

Implement the whole thing in java or perl or some web-application construction toolkit, host it with some space on a cheapy webserver and THEN you'll have the easy for anyone to use, always on, anyone can fansub simultaneously solution that might be interesting to me. Then anyone with a web browser, from anywhere, could work on the show, even at the same time as you propose.

P.S. While you're at it in Aegissub, implement a chat function for basic chatting with people currently working on the same server. Or maybe even a meta-server which links all the smaller ones, thus creating a basic IRC style network with each channel being a working group (groups could talk to one another for help/advice, etc).

dj_tjerk · 2008-01-09, 12:25

Quote:

Originally Posted by Quarkboy

Frankly, I would think this would be best implemented in a hosted website application, ala google aps, instead of a stand alone program.

I'd not make that a priority..maybe optional. It's not easy to make a full GUI in Java when most people work on their own pc anyway, and various dll's/plugins are needed for most tasks (how are you going to load audio over a website, let alone video).

Quote:

Originally Posted by Quarkboy

P.S. While you're at it in Aegissub, implement a chat function for basic chatting with people currently working on the same server. Or maybe even a meta-server which links all the smaller ones, thus creating a basic IRC style network with each channel being a working group (groups could talk to one another for help/advice, etc).

Or.. just enter the channel on IRC >_> Or maybe let aegisub play an irc client and enter the chan via aegisub.. but no need to make a whole new chatting network/protocol.

ArchMageZeratuL · 2008-01-09, 12:32

I can't see why would a web-app be any better.

It would be considerably harder to code, wouldn't have access to all of Aegisub's features... and how would you typeset to video and time to audio with that?

As for the chat, a simple chat is trivial to implement, so it'll probably be there.

p-static · 2008-01-09, 12:42

That brings up another thing I had forgotten about: another *really* nice feature in gobby that should definitely make it into aegisub if this happens is a built in chat thingy.

Also, I don't really see the need to have strict restrictions on what anybody can do to the script at a given time. If you don't want somebody messing with your stuff before you're done with it, there's nothing stopping you from just asking them to hold off for a bit. ^_^

Quarkboy · 2008-01-09, 13:06

Quote:

Originally Posted by ArchMageZeratuL

I can't see why would a web-app be any better.

It would be considerably harder to code, wouldn't have access to all of Aegisub's features... and how would you typeset to video and time to audio with that?

As for the chat, a simple chat is trivial to implement, so it'll probably be there.

From a development side, yes, it would pose challenges, but from a user side I think a web-based solution would be the most platform independent (run off any web browser, if flash-based for the video you have mac, windows, and linux covered), and location independent (no need for any files to be on your computer). Plus the previously mentioned issue about who's computer is the server would be a lot easier if it could be hosted on a true web-server that's always on.

Now your timer no longer can give the excuse "But I'm on vacation at my grandmother's house for 3 weeks!" As long as grandma has internet explorer and DSL, they no longer have an excuse

.

As for the chat suggestion, the point of having a built in chat-room is to have the entire fansub development platform in one program. Timing/translation/edit/qc, and a crucial part of that is communication between the people involved. No need to reinvent the wheel of course, it might be simplest to just include a basic IRC server/client protocol in Aegissub itself. Or you could go more modern and implement it with an instant message like system like Jabber or something. Either way, I think that's a needed part of the "suite" you're proposing.

ArchMageZeratuL · 2008-01-09, 13:54

Quote:

Originally Posted by Quarkboy

From a development side, yes, it would pose challenges, but from a user side I think a web-based solution would be the most platform independent (run off any web browser, if flash-based for the video you have mac, windows, and linux covered), and location independent (no need for any files to be on your computer). Plus the previously mentioned issue about who's computer is the server would be a lot easier if it could be hosted on a true web-server that's always on.

The server could be hosted via PHP, regardless of a web interface. Aegisub already works on most platforms, with enough tinkering... Either way, it'd be far less work to fully support Aegisub on the problematic platforms than to do anything flash-based.

And that still doesn't touch the most important point - replicating all of Aegisub functionality in flash would be daunting, not to mention a waste of time... And, I don't know about you, but I'd rather do work on a "real" program.

Quote:

Originally Posted by Quarkboy

Now your timer no longer can give the excuse "But I'm on vacation at my grandmother's house for 3 weeks!" As long as grandma has internet explorer and DSL, they no longer have an excuse

.

If she has IE and DSL, that's all it takes to download and install software.

Quote:

Originally Posted by Quarkboy

As for the chat suggestion, the point of having a built in chat-room is to have the entire fansub development platform in one program. Timing/translation/edit/qc, and a crucial part of that is communication between the people involved. No need to reinvent the wheel of course, it might be simplest to just include a basic IRC server/client protocol in Aegissub itself. Or you could go more modern and implement it with an instant message like system like Jabber or something. Either way, I think that's a needed part of the "suite" you're proposing.

IRC is far more complicated than this would require. A custom made chat system would be waaay easier to implement than anything based on IRC. Perhaps Jabber would be easier, but we couldn't easily integrate that with the server so people working on a given episode share a chat room.

In the end, "reinventing the wheel" would be the easiest and most effective solution.

ScR3WiEuS · 2008-01-09, 14:11

i do agree that it sounds interesting. didn't want to diss it so badly. it might work out, but it will be hard to balance out. i'd advise you to gather some experienced subbers and try to brainstorm a bit.
i just meant that personally i wouldn't be able to use it very well in menclave, since we usually do things at different hours, and some people are too reluctant to try out new things.
@dj_terk, letting multiple QCs edit the script is a no-no, imho.
if it's just 1 excellent QC, that's fine. but good QCs are extremely rare.
as i see it, this function would only be useful to get TL/Timing/Editing done quicker.
@amz
"The system won't allow people to change each other's work. This will be constrained so that you are only capable of editing what you are SUPPOSED to edit.
Of course, people being able to work at the same time is the biggest issue."
well, tls, editors, and timers all have to have access to the same things really.
even if a tl approved a line, he might see the need to change it later, or do a second run.
i mean, the main "function" would be the possibility to work simultaneously, which is also its biggest fault. otherwise it's just the same as SVN
not to mention that if you use this to get work done faster, you might end up doing it slower. not everybody works at the same rate, so in the end, some people
would have to end up wasting more time keeping an eye on the changes than they would originally.

oh well, perhaps i just don't understand what you mean

Quarkboy · 2008-01-09, 14:11

Quote:

Originally Posted by ArchMageZeratuL

If she has IE and DSL, that's all it takes to download and install software.

I don't know about YOUR grandma, but mine gets very upset if you even move an icon on her desktop... let alone *gasp* install some software...

2008-01-08, 21:56	Link #1
ArchMageZeratuL Aegisub dev IT Support Join Date: Dec 2004 Location: Florianópolis, Brazil, Pale Blue Dot Age: 38	Parallel colaborative fansubbing proposal Today, I had an idea that some people in #aegisub judged to be interesting. After a brief discussion there, I've decided to post it here to gather the opinion of more fansubbers. I already expect a lot of flaming, especially from the "speedsubbing sucks" groups, although this proposal would benefit everyone, not just speedsubbers. The idea is to have some sort of client-server system (with the client integrated into Aegisub) so multiple people can work on different stages of the fansubbing pipeline of a single episode all at the same time. Basically, there's a server that you connect to (with login and password). The server lists all active projects. You pick one, and assign yourself a specific position, for example, "timer". Then, every connected member can start working on it as work becomes available. It all starts with the translator, of course. As he watches, he will enter lines in a text editor-like interface (with a few additions, such as F1-F12 keys to quickly switch current actor). As soon as a line is entered, it starts to "count down" (say, a minute). The translator can still change the line while the countdown is going. When the countdown is over, the line is sent to the server as "ready for the next stage". That way, the translator doesn't have any extra work, and the next stage can start as soon as the translator has typed in a few lines. Alternatively, there can be a "flush" button, to flush the current pending lines. This is up for debate. After the lines were submitted, the server understands them as "translation OK, waiting timing and editing". On that moment, both the editor and timer will have the line available for them. The timer will only be able to change the actual times, while the editor only the actual text, therefore their work is completely independent. As they are done with lines, they are also auto-set for the next stage, or flushed manually. Maybe typesetting could also be done in parallel at this stage. After that, if typesetting was already done, all that is left is translation checking and QC. Translation checking can happen immediately after editing, and might be optional (server-side option). The final stage, QCing, will likely be slightly different: the program will wait for a reasonable ammount of lines to be "ready", and, once they are, tell the user that it can has more stuff to watch. Then the user watches the fragment and hits a key whenever he sees a problem. The program then pauses the video and asks what kind of problem it is, translation, editing, typesetting, etc, and the user picks it, with optional comment. The current timestamp is marked as "in need of revision", and the appropriate person assigned to the episode is notified of such. If you've been keeping up with my logic, it should be clear that such a system would allow an entire episode to go through the entire fansubbing process, including more than one QC, in an hour or so, if the team is all available and works at typical speeds. Also, the server would work in a somewhat SVN-like fashion, preventing version conflicts and keeping a history of all changes. It's up to debate how would "late revisions" work... For example, if a translator wants to change something after it's already been edited. Either way, it shouldn't be too hard. Now, this is just mindstorming. I had the idea and decided to share with the community. This all could feasibly be implemented in Aegisub after the planned 2.10 reformation (yes, we still need to release 2.00 before, we KNOW ), but we will only really consider it if there is sufficient community support for it. The server itself would be a lightweight cross-platform program, which would be administered remotely by clients with admin privileges. A single server could potentially host many different fansubs, and each fansub could be organized in projects, and each project in episodes. Each user would them assign themselves in a position for some project (or maybe the admin would?) in order to work on it. There's also some question on how to share the raw - should that be done manually, or should the program deal with that in some way? That way, once the "distro" client has the raw, it could stream it to other users, so they can start working as they receive it... Although that's probably overkill. Anyway, I'm not promising anything! This is just an idea, for now. It MIGHT become reality someday, who knows? But how the community reacts will largely influence that. Thanks for your time and sorry for the long post! [EDIT] BTW, the mentioned 2.10 reformation is mostly source-wise, not interface-wise, but will allow things such as multiple subtitle files loaded at once, which is pretty much mandatory for proper Mac support. [EDIT2] Here's the log from #aegisub: Spoiler for Long IRC logs: 23:13:56 <@amz> I had an idea yesterday 23:14:00 <@amz> that would be very hard to implement 23:14:02 <@amz> and that you'll hate 23:14:07 <@amz> but I'll share anyway, just to spite you 23:14:21 <@amz> a synchronous fansubbing tool, allowing people to work in parallel 23:14:31 <@amz> e.g. a translator enters lines, and as he does it, the timer is already timing them 23:14:35 <@amz> and the typesetter already typesetting 23:15:01 <@amz> and the qc/tc people can already "stream" the video with the subs as they are made 23:15:10 <@amz> maybe wait until around 3 minutes are watchable, and start playing that 23:15:15 <@TheFluff> that sounds like a monstrously bad idea 23:15:16 <@amz> with an integrated qc report system 23:15:18 <@amz> etc 23:15:20 <@amz> yeah. 23:15:24 <@amz> would be great for ultraspeedsubbing, though 23:15:32 <@amz> I bet that a team could get it all done within 40 minutes 23:15:33 <@TheFluff> I'm not so sure 23:16:23 <Krade> would be a pain in the ass for version conficts 23:17:00 <@amz> what version conflicts? 23:17:05 <@amz> you wouldn't work on actual .ass files 23:17:10 <@amz> the program would automatically manage the lines themselves 23:17:21 <Krade> person A edits a line 23:17:22 <@amz> some sort of realtime svn 23:17:37 <nix> sounds crazy 23:18:07 <Krade> then person B's program refreshes 23:18:12 <Krade> then person A edits that line again 23:18:36 <Krade> then person B edits that line and when the program refreshes, bang, A's changes are lost 23:18:56 <Krade> or 23:18:57 <nix> only if full lines are updates 23:19:01 <nix> updated 23:19:10 <Krade> same thing would happen 23:19:14 <Krade> person A submits a line 23:19:18 <nix> We could split timing, translation and stiling 23:19:26 <Krade> then person B starts typing 23:19:34 <Krade> person C starts typing on the same line and submits 23:19:35 <nix> And give every line an unique ID that would never be used again in the same project 23:19:53 <Krade> then person B would overwrite C's stuff without noticing after hitting enter 23:20:07 <Krade> a pain to manage 23:20:12 <@amz> uh, Krade 23:20:15 <@amz> you've never used SVN, right? 23:20:24 <@amz> I'm proposing a system similar to how SVN works 23:20:35 <Krade> amz: I know how svn works 23:20:36 <@amz> so that no changes can be lost or carelessly overwriten 23:20:42 <Krade> I am describing svn conflicts 23:20:45 <Krade> that you'd have to manage 23:20:52 <@amz> yes, but they shouldn't happen 23:20:57 <@amz> because the program would enforce a pipeline 23:21:05 <@amz> that is, you can only edit after it was timed, for example 23:21:14 <@amz> so it would only conflict on a few special cases 23:22:28 <Krade> well, I guess you could do something like have an option that the TLer would select after he's done translating that line and would send it to the next person 23:22:34 <Krade> and it would lock him out from editing 23:22:40 <nix> Huh? 23:22:51 <Krade> I see no other way to enforce a pipeline 23:23:50 <Krade> I mean 23:24:07 <Krade> if you want to eliminate conflicts, only one person can edit a specific line at a time 23:24:08 <@amz> yes, as he enters lines, they are automatically made available for timing after a few seconds or so 23:24:17 <nix> translator: creates lines (and only translator), timer time them and at the same time editor(s) edit them 23:24:21 <@amz> he can still change them, provided that they haven't been claimed for editing 23:24:28 <@amz> here assuming that the timer won't be able to change the line contents 23:24:37 <@amz> therefore, you can edit and time at the same time 23:25:05 <@amz> after that, typesetting can happen in parallel with TC 23:25:06 <Krade> well yeah, you just need to give each line a unique ID 23:25:26 <@amz> and then one or more QCs can go through it, flagging specific lines as in "needs review by ##" 23:25:37 <@amz> yes, each line would be deal with individually 23:25:42 <@amz> dealt 23:25:52 <@amz> keep in mind, this won't use SVN, just an SVN-like process 23:25:59 <Krade> I know 23:26:06 <@amz> just making sure 23:26:23 <@amz> anyway, I'm pretty sure that it could WORK, the question is wether it'd have any USE 23:26:43 <Krade> I'm just pointing out that to eliminate conflicts, you'd need to have to make people be able to say "kay, I'm done with the text on this line, move on" 23:26:48 <Krade> just hitting enter wouldn't work 23:27:02 <@amz> well, as I've said above 23:27:08 <@amz> after they hit enter, the line starts to countdown or something 23:27:19 <@amz> after one minute of "enter hit" and no changes made to the line, it's made available 23:27:30 <@amz> at that point, the next person in the pipeline can start working on it 23:27:34 <Krade> and then someone else could claim it 23:27:36 <Krade> that would work 23:27:38 <@amz> however, until he does, the original author can still change it 23:28:28 <nix> I think for timing countdown isn't needed 23:28:37 <@amz> well 23:28:49 <@amz> if you notice a mistake soon after entering it... 23:28:54 <@amz> or think that it doesn't go with the next part... 23:28:57 <@amz> you should get some time to fix it 23:29:01 <Krade> nix: well, if the person edited that line several times in a row, the countdown would bump back to 1 minute again 23:29:03 <Krade> or 30 seconds 23:29:04 <Krade> or something 23:29:25 <Krade> so constant editing in a line would prevent it from another person taking over 23:29:26 <nix> Well we could assign roles e.g. translator, timer, editor, styler and such 23:29:37 <@amz> yes, that is part of the process... 23:29:49 <Krade> yeah, but translator overlaps with editor 23:29:50 <Krade> etc 23:29:56 <nix> and define that timer changes only timing and editor, translator only text 23:30:12 <Krade> you could divide a line into time and text, at least 23:30:21 <@amz> and style 23:30:28 <Krade> and people would be able to claim just one part of the line 23:30:32 <nix> in that case if both editor and timer submit the same line their work would be merged 23:30:43 <@amz> right. 23:30:56 <@amz> but since we're not talking about physical .ass files, "merged" is a misnomer 23:31:02 <nix> of course, this will probably work only with one timer, one translator and one editor 23:31:08 <@amz> in truth, the timer is ONLY editing the times 23:31:11 <@amz> and only submits those 23:31:26 <@amz> It COULD work with more than one timer, at least 23:31:28 <@amz> and editor 23:31:32 <@amz> they could split the work 23:31:40 <Krade> yep, it's more like one line is several atomic parts and those parts can be reserved independetly 23:32:09 <Krade> like, a person could reserve all parts of one line, but a timer is only expected to reserve the time, etc 23:32:28 <Krade> that'd be really awesome, but it'd be somewhat complicated 23:32:47 <nix> Krade, they shouldn't 23:32:54 <@amz> well, it can technically be done... the real question is whether it's worth doing it or not 23:32:58 <nix> For example, timer should only do timing 23:33:01 <Krade> Yeah, I know 23:33:29 <Krade> But imagine a timer feels like fixing an obvious spelling on a line whose text field isn't taken 23:33:35 <Krade> he could take that line and fix it 23:33:47 <nix> If he tries to do other things conflicts inside group will arise (and I'm saying this from my experience) 23:34:38 <@amz> either way 23:34:39 <Krade> Yeah, I'm not saying it's a good practice 23:34:44 <@amz> aegisub needs a "translation writing" mode 23:34:53 <@amz> something like a simple text editor with a few shortcuts 23:34:59 <@amz> such as f keys to switch between actors 23:35:20 <@TheFluff> objection your honor, creeping featuritis! 23:35:27 <@TheFluff> if you want a text editor, use a text editor 23:35:45 <@amz> if a specialized text editor will make the job faster, then use the specialized text editor 23:36:30 <Krade> how were you planning on managing the multiple editing thing? you'd need a server, sort of like a svn repository somewhere 23:36:44 * nix agrees with amz - it's a really good idea 23:37:09 <@amz> yes, you would 23:37:13 <@amz> it'd be a separate software 23:37:13 <Krade> that would also deal with authentication/priviledges for each user 23:37:16 <@amz> and somebody would have to host it 23:37:22 <Krade> hopefully a linux version 23:37:29 <@amz> cross-platform, of course 23:37:35 <@amz> nobody hosts servers on win32 23:37:40 <Krade> exactly 23:39:12 <Krade> I think it'd be pretty cool for speed subbing, but not too easy to implement 23:39:19 <@amz> I think that I'll post on animesuki and see what people say 23:39:26 <@amz> and brace for the inevitable flame war that will follow 23:41:26 <Krade> flames over what? I don't follow animesuki 23:41:43 <nix> probably speesubs - the good and the ugly 23:41:50 <@amz> yep 23:41:58 <nix> speedsubs 23:42:06 <@amz> last time fluffy said that you don't need over 20 hours to sub an ep, a whole shitstorm started 23:42:08 <@amz> right, TheFluff? 23:42:12 <Krade> it's not like it wouldn't help regular subing either 23:42:36 <@TheFluff> confirm 23:42:46 <Krade> ie: timers wouldn't be able to fuck the text on accident if you had priviledges enforced on the server 23:42:53 <@TheFluff> don't post 23:42:54 <Krade> also no uploading. ass files around in FTPs 23:43:02 <Krade> it's not just for speed subbing 23:44:46 <@TheFluff> don't post about vaporware 23:44:59 <@TheFluff> it's like shouting HAY GUYS WHY DON'T YOU COME TROLL THIS THREAD 23:45:05 <@amz> vaporware? 23:45:11 <@amz> it's not vaporware if it's just an idea that I had 23:45:41 <Krade> it's only vaporware if you announce something and then fail to deliver for a long time 23:45:52 <nix> well it's amz's idea, so it might even happen 00:16:53 <p-static> amz, you're thinking about parallelizing fansubbing? 00:18:09 <p-static> it's definitely doable 00:19:03 <p-static> in fact, the hard part's already done - have a look at gobby 00:31:07 <@amz> gobby? 00:31:23 <p-static> it's a collaborative text editor 00:31:37 <p-static> best part is, the core parts are available separately as a library 00:32:05 <p-static> we use it in flomp for almost exactly what you were describing earlier 00:37:12 <@amz> flomp? >_> 00:37:21 <@amz> is that a fansubbing group? 00:37:35 <MoeServ> yeah 00:37:45 <p-static> a very small one XD 00:38:09 <@amz> how well does it work, in your experience? 00:38:19 <p-static> surprisingly well 00:38:38 <p-static> the biggest problem is actually that the timer needs to use aegisub 00:38:50 <p-static> so everything before timing has to be done outside of gobby 00:39:43 <sho> o.O I might start using gobby :/ 00:40:56 <@amz> ok 00:41:00 <@amz> I'll post it on animesuki, then Last edited by ArchMageZeratuL; 2008-01-08 at 22:18. Reason: Clarifying the 2.10 reformation.*

2008-01-09, 11:53	Link #10
ScR3WiEuS My E-Penis > Your E-Penis Fansubber Join Date: Feb 2006 Location: Brussels, Belgium Age: 38	i guess it would need some kinda of color code to show which lines are final and which not. but even then, i personally don't work from beginning to end, in a linear way. as i edit, i skip around the script, change stuff everywhere, etc. i guess it might work for like, translating and timing at the same time or so, but that would mean that the timer would have to time without having tled lines, something not many timers like to do. it would also have to mean that the people are able to work at the same time, and that they can communicate directly as to not interfere or change each other's work. in short, it's an interesting idea, but not worth pursuing. i don't think anyone but speedsubbers would successfully make use of this idea. it's too risky for groups that prioritize quality over speed. __________________ penis, lol

2008-01-09, 12:18	Link #13
Quarkboy Translator, Producer Join Date: Nov 2003 Location: Tokyo, Japan Age: 44	Frankly, I would think this would be best implemented in a hosted website application, ala google aps, instead of a stand alone program. Implement the whole thing in java or perl or some web-application construction toolkit, host it with some space on a cheapy webserver and THEN you'll have the easy for anyone to use, always on, anyone can fansub simultaneously solution that might be interesting to me. Then anyone with a web browser, from anywhere, could work on the show, even at the same time as you propose. P.S. While you're at it in Aegissub, implement a chat function for basic chatting with people currently working on the same server. Or maybe even a meta-server which links all the smaller ones, thus creating a basic IRC style network with each channel being a working group (groups could talk to one another for help/advice, etc). __________________ Read Light Novels in English at J-Novel Club! Translator, Producer, Japan Media Export Expert Founder and Owner of J-Novel Club Sam Pinansky

2008-01-09, 14:11	Link #19
ScR3WiEuS My E-Penis > Your E-Penis Fansubber Join Date: Feb 2006 Location: Brussels, Belgium Age: 38	i do agree that it sounds interesting. didn't want to diss it so badly. it might work out, but it will be hard to balance out. i'd advise you to gather some experienced subbers and try to brainstorm a bit. i just meant that personally i wouldn't be able to use it very well in menclave, since we usually do things at different hours, and some people are too reluctant to try out new things. @dj_terk, letting multiple QCs edit the script is a no-no, imho. if it's just 1 excellent QC, that's fine. but good QCs are extremely rare. as i see it, this function would only be useful to get TL/Timing/Editing done quicker. @amz "The system won't allow people to change each other's work. This will be constrained so that you are only capable of editing what you are SUPPOSED to edit. Of course, people being able to work at the same time is the biggest issue." well, tls, editors, and timers all have to have access to the same things really. even if a tl approved a line, he might see the need to change it later, or do a second run. i mean, the main "function" would be the possibility to work simultaneously, which is also its biggest fault. otherwise it's just the same as SVN not to mention that if you use this to get work done faster, you might end up doing it slower. not everybody works at the same rate, so in the end, some people would have to end up wasting more time keeping an eye on the changes than they would originally. oh well, perhaps i just don't understand what you mean __________________ penis, lol

2008-01-08, 22:21	Link #2
p-static Junior Member Join Date: Jan 2008	Like I mentioned on IRC, basing this on obby (the collaborative editing part of gobby) would give you about 90% of what you're describing here. (For those of you who weren't on IRC: In Flomp, we use gobby for a good bit of the subbing process, and it works really really well. In actual practice, using a system like this, we can finish an episode in 3-5 hours.) A few suggestions: * Instead of the minute wait for the lines to be sent to the server, it'd probably be easier (and more useful) if the text was sent as it was being typed. Also prevents race conditions when two people are editing the same line. * Having the server be aware of what stage a line is at is a really good idea - that should be developed further, it'd be really useful, especially if you allow the user to re-label lines that need to be redone in some earlier stage. * gobby already has a lightweight, cross-platform server available - one more reason to use it

2008-01-08, 22:58	Link #3
Tofusensei Senior Member Join Date: May 2003 Location: Tokyo, Japan	Great idea, impossible in implementation. p-static... What group are you with? I'm a very experienced fansubber and I've never heard of a 3-5 hour turnaround unless you mean an uber speedsub with no editing or QC. The fastest I've ever done is 10 hours, and believe me, that's considered extremely fast. -Tofu

2008-01-08, 23:07	Link #4
ArchMageZeratuL Aegisub dev IT Support Join Date: Dec 2004 Location: Florianópolis, Brazil, Pale Blue Dot Age: 38	Impossible? I don't even see anything as particulary CHALLENGING... It's just a LOT of work, but none of it is hard. Or do you mean something in particular that I've overlooked?

2008-01-08, 23:14	Link #5
p-static Junior Member Join Date: Jan 2008	Yeah, it's a speedsub, but the quality is actually pretty decent. We have a fairly efficient pipeline set up, where everybody can work simultaneously, which takes off a lot of time. Releasing softsubs also helps, since we can encode in parallel with everybody working. That breaks down somewhat if we need to do any complicated typesetting that can't be reliably done in a softsub, of course, but for the most part that isn't a problem. In the end, the speed of the process is basically TL time + timing time + edit / tl check / qc / typesetting time, since everything after timing can be done simultaneously. So with collaborative editing built into aegisub, that could be improved even more. :3

2008-01-09, 09:45	Link #6
cyth Banned Join Date: Dec 2006 Age: 38	The fansubbing community is already being perceived as a tool (even moreso than before), now you want to make it a part of an actual tool? All hail efficiency and progress!

2008-01-09, 09:54	Link #7
Ijuki aka Raw Provider Join Date: Aug 2004 Age: 37	I agree with Tofusensei. Although, go ahead and try, if you manage to get it to work, I am more than willing to try it. Shame that every one lives in different places of the world, which slows the things downs no matter what tools you are using.

2008-01-09, 09:57	Link #8
CelesAurivern Mein Kampf :D Fansubber Join Date: Feb 2004	Sounds like a recipe for chaos : D Beside's how many real speedsub groups are still out there anyway? Even that ninja show takes over 12 hours to hit the shelves.

2008-01-09, 11:12	Link #9
comatose Senior Member Join Date: Dec 2007	If you're willing to take the time to implement this, then go ahead. It sounds like it could, in most group, at least speed up the process somewhat. The only problem for some groups might be a place to put this server on, but I guess they all have at least one member who stays online 24/7. In any case, I don't like the countdown parts.

2008-01-09, 12:09	Link #12
dj_tjerk Ana-chan~ Join Date: May 2006 Location: Netherlands	'quality' groups get a lot of their work done out of aegisub. So it's probably not gonna make a lot of difference for those groups, as aegisub isnt really what's the bottleneck for them. Though.. I like more efficient/parallel QCing (in case of more QC'ers that is.. 1 good qc'er should be fine too :P), and the 'tracking changes' stuff.

2008-01-09, 12:32	Link #15
ArchMageZeratuL Aegisub dev IT Support Join Date: Dec 2004 Location: Florianópolis, Brazil, Pale Blue Dot Age: 38	I can't see why would a web-app be any better. It would be considerably harder to code, wouldn't have access to all of Aegisub's features... and how would you typeset to video and time to audio with that? As for the chat, a simple chat is trivial to implement, so it'll probably be there.

2008-01-09, 12:42	Link #16
p-static Junior Member Join Date: Jan 2008	That brings up another thing I had forgotten about: another really nice feature in gobby that should definitely make it into aegisub if this happens is a built in chat thingy. Also, I don't really see the need to have strict restrictions on what anybody can do to the script at a given time. If you don't want somebody messing with your stuff before you're done with it, there's nothing stopping you from just asking them to hold off for a bit. ^_^