AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > General Anime > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2008-05-20, 15:02   Link #21
Heibi
Ancient Fansubber
*Fansubber
 
 
Join Date: Aug 2004
Location: KS
Quote:
Originally Posted by NoSanninWa View Post
I see. Maybe things are different with the way your group relates, but that doesn't work for me. I'm an editor and it always drives me crazy when my timer or typsetter "help" edit the script. It isn't always about fixing errors. It is also that when I'm editing, I don't like my style to be messed with. Otherwise I'm not editing, I'm just proofreading. I feel that if someone else wants to edit something, they should just put it in a QC report and let me decide if I agree with them.
Egos are checked at the door during edit sessions at our meetings. I have the biggest one. Even after I've edited it, it can be changed. When something looks weird we discuss it and come up with the best solution. I even mark the line in some way if I think it is in some way strange(wording, arrangement etc). We've had the same people working on fansubs for years(since 1992 in some cases). Living in the same town helps on this. We even invite people who come to our meetings to particpate in our edit watching sessions.

Come on down or up or over to Wichita, NoSanninWa, and join the fun for a day or so.

Heibi
Central Anime
Heibi is offline   Reply With Quote
Old 2008-05-20, 15:03   Link #22
NoSanninWa
Weapon of Mass Discussion
*Fansubber
 
 
Join Date: Feb 2003
Location: New York, USA
That sounds nice actually.
__________________

There's not that fine a line between willing suspension of disbelief and something just being stupid.
NoSanninWa is offline   Reply With Quote
Old 2008-05-20, 15:20   Link #23
cyth
ふひひ
 
 
Join Date: Dec 2006
Age: 28
Quote:
Originally Posted by Arm View Post
Even with 10-20 errors, it should only take 24mins(of watching the episode) + 5mins for fixing the lines.
Yes, well, when you get to a point when you take less time on average for rough-timing than for fine-timing, fine-timing becomes a chore you'd rather not do. Especially because you have to watch through the whole episode just to fix those 20 errors. At least you get to watch the episode though.

@TheFluff: There's one instance TPP can't compensate with its current features. This can happen when your rough-timed script has dialogue ending before a keyframe or very shortly after it (which warrants a line cut-off). Normally, a correctly specified value for Ends after thres. should compensate for the lead-out interval and cut it off, however, when you have the same line sitting in next line's Make adjacent subtitles continuous threshold, TPP first extends the end time of the first line to the start time of the second line, which throws it out of its original interval, but the dialogue still demands for the line to be snapped to the keyframe. See what I'm getting at here?

Eclipse's past releases didn't seem to have all of these fixed (sorry, I didn't watch any of the new ones), but if you figured out a workaround for it, I'll gladly take it. I think this has a lot to do with TPP not being designed for bigger values (I use 600 for making adjacent lines continuous, and 150/350 ms for lead-in/out (4-4/5-10 in TPP for 23.976 FPS video)).
__________________
cyth is online now   Reply With Quote
Old 2008-05-20, 16:55   Link #24
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by Toua View Post
@TheFluff: There's one instance TPP can't compensate with its current features. This can happen when your rough-timed script has dialogue ending before a keyframe or very shortly after it (which warrants a line cut-off). Normally, a correctly specified value for Ends after thres. should compensate for the lead-out interval and cut it off, however, when you have the same line sitting in next line's Make adjacent subtitles continuous threshold, TPP first extends the end time of the first line to the start time of the second line, which throws it out of its original interval, but the dialogue still demands for the line to be snapped to the keyframe. See what I'm getting at here?
Yes, and one solution is to set the "ends after" threshold to at least greater than (leadout+link_threshold*0.5)/(1000/framerate) assuming you have the bias slider in the exact center; I prefer to have the bias slider around 3/4ths to the right though so I'd use 0.75 instead of 0.5. Another solution is to account for what the TPP will do when rough timing and simply place the line end marker a bit before the keyframe and let the TPP's lineout plus keyframe snapping take care of extending it to the keyframe.

Quote:
Originally Posted by Toua View Post
Eclipse's past releases didn't seem to have all of these fixed (sorry, I didn't watch any of the new ones), but if you figured out a workaround for it, I'll gladly take it. I think this has a lot to do with TPP not being designed for bigger values (I use 600 for making adjacent lines continuous, and 150/350 ms for lead-in/out (4-4/5-10 in TPP for 23.976 FPS video)).
I know, it's because I'm lazy.
I dunno what exactly amz had in mind when designing it but the larger the thresholds are the harder it is to avoid mistakes.


@ChrissieXD: your thresholds are way too high.

This is a bit off-topic, but some TPP tips and related maths:
- Always set "ends after" to greater than leadout/(1000/framerate). Since keyframe snapping happens last, this allows it to undo the leadout and avoid a bleed caused by you timing the line end right at the keyframe.
- By the same logic, "starts before" should be greater than leadin/(1000/framerate).
- As mentioned above, "ends after" should also be greater than (leadout+link_threshold*0.5)/(1000/framerate).
- Remember that the maximum possible autoadded total leadout in milliseconds is leadout+ends_before*(1000/framerate), since keyframe snapping is applied after leadout.
- Likewise, the maximum possible autoadded total leadin is leadin+starts_after*(1000/framerate).
- To some extent it is possible to compensate for imperfectly calibrated settings by considering the effects of the TPP when rough timing; see above. In fact you should always consider the effects of the TPP when rough timing.

My own settings for 23.976fps are leadin 120, leadout 240, linking 320, starts before 3, starts after 3, ends before 5, ends after 8. This doesn't satisfy the line linking requirement outlined above but I try to compensate for it by timing line ends near keyframes a bit earlier.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2008-05-21, 06:03   Link #25
sangofe
Senior Member
 
Join Date: Feb 2004
Quote:
Originally Posted by blakbunnie27 View Post
I'm doing a bit of a research on fansubbing and how it affects the world w/ active money transactions. And I thought I'd start by figuring out how much time each person spends in doing his/her job w/ fansubbing.

I translate and...
I spend about 2-3 hours TL an episode if the anime isn't comedy or philosphical crap based.
Otherwise, takes about 4-5 hours depending on the amount of hard-to-tl crap in there.

How much time do you spend doing your job? (time, qc, edit, kara, etc)

20 mins to 3 hours per episode timing.
Most lines I've timed in an episode was about 600, least, about 150.

QC I guess I spend about an hour per episode.
sangofe is offline   Reply With Quote
Old 2008-05-21, 06:34   Link #26
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 30
I never really measured it, but I think I take 30-60 minutes to time an average (1:30) OP/ED song for karaoke. I often end up modifying the timing in one way or another for the effect, however.

Developing a karaoke effect can take anything between a few hours to several weeks on and off. How much time I'll take depends on whether there is a specific deadline (usually only the case for series running on TV) and what kind of effect the song warrants. For example, all the different ef endings didn't take much individual effort in creating the effect, just a few hours each, but I spent considerably more time for the final episode ending. My karaoke for the first Gundam 00 OP took about a week to make, with a few hours a day, iirc. The second Gundam 00 OP took much longer, but it was under continuous improvement. (Four different versions of the effect were used. Each of those required its own adjustments to timing.)
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2008-05-21, 07:18   Link #27
Kristen
Senior Member
*Author
 
 
Join Date: Jul 2007
Location: Virginia Tech
Quote:
Originally Posted by TheFluff View Post
Yes, and one solution is to set the "ends after" threshold to at least greater than (leadout+link_threshold*0.5)/(1000/framerate) assuming you have the bias slider in the exact center; I prefer to have the bias slider around 3/4ths to the right though so I'd use 0.75 instead of 0.5. Another solution is to account for what the TPP will do when rough timing and simply place the line end marker a bit before the keyframe and let the TPP's lineout plus keyframe snapping take care of extending it to the keyframe.


I know, it's because I'm lazy.
I dunno what exactly amz had in mind when designing it but the larger the thresholds are the harder it is to avoid mistakes.


@ChrissieXD: your thresholds are way too high.

This is a bit off-topic, but some TPP tips and related maths:
- Always set "ends after" to greater than leadout/(1000/framerate). Since keyframe snapping happens last, this allows it to undo the leadout and avoid a bleed caused by you timing the line end right at the keyframe.
- By the same logic, "starts before" should be greater than leadin/(1000/framerate).
- As mentioned above, "ends after" should also be greater than (leadout+link_threshold*0.5)/(1000/framerate).
- Remember that the maximum possible autoadded total leadout in milliseconds is leadout+ends_before*(1000/framerate), since keyframe snapping is applied after leadout.
- Likewise, the maximum possible autoadded total leadin is leadin+starts_after*(1000/framerate).
- To some extent it is possible to compensate for imperfectly calibrated settings by considering the effects of the TPP when rough timing; see above. In fact you should always consider the effects of the TPP when rough timing.

My own settings for 23.976fps are leadin 120, leadout 240, linking 320, starts before 3, starts after 3, ends before 5, ends after 8. This doesn't satisfy the line linking requirement outlined above but I try to compensate for it by timing line ends near keyframes a bit earlier.
Heh. Thanks for the advice, but I'm pretty comfortable with my present timing methods. I don't usually compensate for TPP when rough timing, because I find the pink lines to be incrediby frustrating to deal with with rough time. I usually time to just audio, and then fine time to video. Just a personal preference, and it creates the same result. Just requires that I go through it quickly after I'm done. But, I do feel safer with this method.

Also, I did the math.
For starts before, it's 140*23.976/1000, or about 3.3. That round up to 4, since you say it should always be higher. That's my setting.
Ends after is [(500+510)/2]*23.976/1000. That comes out as 12.1, round that up to 13. My setting.
So, my settings are what you said.
The problem is, as I think somebody else said, is that TPP is designed for smaller values. My groups use higher values, so it messes up with them.
__________________
Kristen is offline   Reply With Quote
Old 2008-05-21, 08:38   Link #28
dj_tjerk
Ana-chan~
 
 
Join Date: May 2006
Location: Netherlands
I always account for those 'pink lines' while timing. It saves me about 30 scenebleeds an episode... And even though I style while checking my timing, stopping everytime to fix the keyframe snapping, really gets on my nerves.
dj_tjerk is offline   Reply With Quote
Old 2008-05-21, 09:58   Link #29
Kristen
Senior Member
*Author
 
 
Join Date: Jul 2007
Location: Virginia Tech
I guess a lot of it is a matter of preference. I like to be extremely accurate for rough timing, and I don't want TPP to mess up more than it already does. A lot of times when I've tried to compensate for something like that, I got disastrous results. I think it was in Kamen no Maid Guy where I timed it with compensation, and the result after TPP had one of the lines ending 2 seconds before it should have or so. I've never had more issue than a couple of scene bleeds when doing it to strict audio. XD
Ah well.
__________________
Kristen is offline   Reply With Quote
Old 2008-05-21, 23:20   Link #30
chaos4ever
Retired
*Fansubber
 
Join Date: Aug 2004
QC: iirc, 6hrs as a newbie; eventually got it down to about 2 hrs on a 24 min episode. 3-4-ish hours for an episode rife with errors. (2x pass: first for editing, second for timing/typesetting/encoding/karaoke)

TS: a sign can take anywhere from 15 minutes to 10 hours. Lately, episodes have taken about 10-20 hours or more to typeset. it really varies on the number and types of signs that need to be typeset in AFx

Last edited by chaos4ever; 2008-05-23 at 23:08.
chaos4ever is offline   Reply With Quote
Old 2008-05-22, 09:06   Link #31
pichu
Senior Member
*Fansubber
 
 
Join Date: Jul 2004
Here goes for me for a 24min episode...

TL (C->E) = 2h
Timing = 1-2h
Karaoke Timing = 20min X 2
Karaoke Effects (AFX) = Who cares... usually about 1 hour; 5h to render per kara
Logo (AFX) = 1h to 10h
Typesetting (AFX) = 20m to 40h (average of about 5 signs an hour, do your math)
Encoding = meh, i give up; i don't have a dual quad core. 10h minimum on my system.
__________________
A small tool I made, and Learn how to make fansub karaoke in After-Effects: AFXKRK
pichu is offline   Reply With Quote
Old 2008-05-22, 09:19   Link #32
martino
makes no files now
 
 
Join Date: May 2006
Encoding: From 1 minute (automated bash/batch scripts FTW) to 20 minutes user time (depending on how much manual fixing needs to be done on the raws -- not talking about IVTC here), then anything from an hour up to double digits computer encode time (lossless, final H.264, etc).

Encoding (IVTC -- .TS/.VOB): 30 minutes to 2 hours user time. Rest same as above.

Typesetting: From minutes to hours... even for a single sign. ~_~

Karaoke Timing: 30 up to 90 minutes for the usual 1:30 song.

Quality Checking: Episode length * 1.5 (I only do single pass).

EDIT: Encoding (filterchain): Hours up to days. n_n
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"

Last edited by martino; 2008-09-24 at 14:54. Reason: added ivtc for completeness' sake
martino is offline   Reply With Quote
Old 2008-05-23, 20:07   Link #33
comatose
Senior Member
 
 
Join Date: Dec 2007
Quote:
Originally Posted by TheFluff View Post
Encoding: [...] 2-4 hours computer time for an average episode
Can you please share some of your scripts and your computer specs? I'm curious as for what you're using to get 4 hours tops.

Also, can you describe the steps you take to bring a TS file to 1280x720 H264? (the order in which you do things) :3

Me -
Encoding: 5 minutes to an hour (compensating for Levels) of user time where I'm actually working :X (when dealing with a Share raw)
If it's a TS, it sometimes takes longer because I don't have much experience with them and might have to mess with settings/different filters to get it right.

KTiming: 30 min to 2 hours, depending on the syllable count.

Editing: 60 min to ~4 hours, depending on the translator... sometimes they leave really weird lines that you can't be sure you edited correctly. After editing a line (or a few lines one after another), I go back 10 lines before the first line and watch it to make sure the flow is right. For the same reason, I do another pass of the entire episode.

TS: Like martino, minutes to hours. Depends on how and if the sign moves.

Last edited by comatose; 2008-05-23 at 20:24.
comatose is offline   Reply With Quote
Old 2008-05-23, 23:27   Link #34
Raijenki
Random Walker?
*Fansubber
 
 
Join Date: Jul 2006
Location: Brazil
Age: 22
Send a message via MSN to Raijenki Send a message via Skype™ to Raijenki
Timing: 35 min ~ 1 hour and 40 mins
- My timing speed depends on some factors like:
  • People Bothering During the Timing
  • Size of script
  • Difficult of script

Karaoke Timing: 15 minutes up
- For some reason, I got pretty fast on it. If it's a simple song, 15~20 min I should be done with it.

Typesetting: 1 hour up
- That's depends if there's too many things to TS or not. I can use AFX or ASS, depending on their complexity level.

Encoding: ?????
- Err... I don't encode. Last time I tried to, I had to wait 28 hours :P
Raijenki is offline   Reply With Quote
Old 2008-05-24, 11:09   Link #35
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by comatose View Post
Can you please share some of your scripts and your computer specs? I'm curious as for what you're using to get 4 hours tops.

Also, can you describe the steps you take to bring a TS file to 1280x720 H264? (the order in which you do things) :3
2-4 hours is for a SD resolution video with little filtering (removegrain, temporal softening, maybe fft3d or hqdn3d, limitedsharpenfaster) which is encoded to lossless (1-2 hours), then to h264 (1.5 hours) or xvid (1 hour). My CPU is an Intel Q6600 though.

For handling of transport streams:
1) create .d2v with DGIndex and demux audio
2) load d2v into YMC (YATTA Metrics Collector), cut out commercials with the cutting GUI
3) depending on the quality of the IVTC, do (or do not) collect IVTC metrics with TFM/TDecimate in YMC and save result as a YATTA project
4) load the project so created into YATTA, set cropping/resizing, set filtering, set audio file and delay, fix IVTC if necessary (possibly use pattern guidance), save project and all project overrides, save audio .avs
5) use audio .avs to encode final audio (if you want to keep the audio from the .ts you can do so but you'll have to cut it manually)
6) comment out all heavy filtering from the YATTA-generated avisynth script and encode a workraw
7) encode the YATTA-generated avisynth script to lossless (if the filtering is extremely light you can skip this step and go straight for x264)
8) encode lossless with x264
9) mux
10) release
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2008-05-24, 16:47   Link #36
D404
Banned
 
Join Date: Aug 2006
Quote:
Originally Posted by TheFluff View Post
5) use audio .avs to encode final audio (if you want to keep the audio from the .ts you can do so but you'll have to cut it manually)
Just on a side note for those interested, one method to cut the audio (normally aac for these broadcasts) is to use mkvmerge to cut the audio at the right times (real simple to figure out it from frame info, but youll have to account for vrf scenes if you have to make it vfr, etc. blah blah). Then just extract the parts which you wnat to keep, and join via binary concatenation (e.g. 'copy /b file1.aac+file2.aac new.aac').

I personally use a perl script to automate this :F.

P.S. Please excuse my horrid English and communication skills. lol.
D404 is offline   Reply With Quote
Old 2008-05-24, 18:31   Link #37
Mentar
Sore wa himitsu desu!
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 45
One of the reasons why I dislike releases with "original" AAC audio: The AAC extracted from the TS is generally too low-volume. I've had cases in which a normal 2-pass normalization yielded a gain of 7 dB, and over 4 dB is the norm. For many laptops, this is way too quiet, and using pre-amplification or even adaptive normalization in ffdshow audio isn't something you really want to do.
Mentar is offline   Reply With Quote
Old 2008-05-24, 18:49   Link #38
D404
Banned
 
Join Date: Aug 2006
Hmm, I've never really taken laptops into consideration...
D404 is offline   Reply With Quote
Old 2008-05-25, 00:32   Link #39
Skyw4lker
Junior Member
 
Join Date: Dec 2005
Quote:
Originally Posted by Mentar View Post
One of the reasons why I dislike releases with "original" AAC audio: The AAC extracted from the TS is generally too low-volume. I've had cases in which a normal 2-pass normalization yielded a gain of 7 dB, and over 4 dB is the norm. For many laptops, this is way too quiet, and using pre-amplification or even adaptive normalization in ffdshow audio isn't something you really want to do.
Finally an encoder who's aware of this issue for laptop/notebook users. I hope more encoders will take this into consideration when encoding with AAC.
Skyw4lker is offline   Reply With Quote
Old 2008-05-25, 20:41   Link #40
dragon5152
Junior Member
*Fansubber
 
Join Date: Aug 2007
Send a message via AIM to dragon5152 Send a message via MSN to dragon5152 Send a message via Yahoo to dragon5152
Quote:
Originally Posted by Skyw4lker View Post
Finally an encoder who's aware of this issue for laptop/notebook users. I hope more encoders will take this into consideration when encoding with AAC.
It's not so much AAC's fault as it is how it's capped or something (I dunno, but you can't just blame AAC for it). I think it might have something to do with DRC? or is this only in DVD audio? I'm not sure...

Now, to the topic at hand... How long eh?
Well, lets see... If it's just a TV cap from share...
10-30 minutes to decide filtering on it (generally consisting of a denoising+contrasharpening).
Run it through filtering, maybe an hour if I use fft3dgpu or a few hourse for dfttest+emc (external motion compensation). I tend to like fft3dgpu more because not only does it offload to my 8800GTS (fast shit) but you can specify the different sigma values for sigma,sigma2/3/4.

Final encode for xvid may take 20 minutes, x264 for SD 45min to an hour. HD maybe 2 hours.

Now for a DVD/TS raw...
Save d2v with dvd2avi 2-3 minutes
Load YMC and collect info with telecide/decimate/other crap 10-20minutes.
Load in yatta and do magic (for DVD, half hour to an hour tops, for TS raw two hours tops if I really care about it)
Figure out filtering add on another 10-20 minutes.
See above for the other crap.

So yea... if I use yatta I can spend about an hour on something after that it's kinda set and forget. Once you get a type of rhythm down in yatta, you can knock out episodes with proper IVTC in a half hour. Only thing that prevents that for me is I have to go through looking for fades to black/white, that tacks on another 10 minutes
dragon5152 is offline   Reply With Quote
Reply

Tags
fansubbing, time

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 13:54.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.