View Single Post
Old 2008-09-20, 03:23   Link #231
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by Meltingice View Post
There is nothing wrong with Tritical's tools. They work fine. If you don't believe me, get a random .avi raw and pray that it's 120 fps. After you verify that ti's 120 fps, dump it in cfr2tc and you'll likely get a very clean set of timecodes.
I just pulled 3 random 120fps raws from my p2p host and gave the latest version (v1.5 to my knowledge) a try - for every single one, cfr2tc failed, and so did tcconv, no matter what threshold I chose. It was still littered with single-frame entries of 119.880115 and 29.970031. For me, a "clean set of timecodes" looks like the one I wrote manually.

Quote:
No we haven't. The OP/ED was originally 29.97. All I suggested was deleting one out of every 5 to make it 23.976. The input is originally 29.97. I screwed up that code, actually. It should be:

For CFR avi:
avisource("Path\To\VFRACRAW[Lossless].avi") #The original source has been changed from 120 fps to 29.97 from cfr2tc, therefore, our input is now 29.97.
src=last
a=src.trim(0,2449).SelectEvery(5,0,1,2,3).AssumeFPS(23.976) #Dropping one out of 5 frames to to change it from 29.97 --> 23.976.
b=src.trim(2450,31999).AssumeFPS(23.976) #This was originally 23.976, so no problem here.
c=src.trim(32000,34499).SelectEvery(5,0,1,2,3).AssumeFPS(23.976) #Dropping one out of 5 frames to to change it from 29.97 --> 23.976.
d=src.trim(35000,0) #This was originally 23.976, so no problem here.
a+b+c+d
=> Output is CFR 23.976 encode.

I'm using AssumeFPS, not ChangeFPS. I'm only changing the timestamps, not adding/removing frames. (Not removing until SelectEvery)
And that's exactly what I've marked. These lines are technically dangerous, since what you're doing here is "blind decimation" - you remove one frame from progressive 29,97 footage, but the way you listed it here isn't checking which frame is the duplicate. You just blindly drop one, and if you fail to get the right one, you have jerkiness - one dupe survives, and one "live" frame is missing. This CAN work, but it's unsafe. I'd simply recommend to use decimate() from the decomb package, since it does the very same, but it DOES check for the dupe.

Quote:
It doesn't cause jerkiness. It only causes it at the places where it should have been 29.97 but got converted to 23.976. Original 23.976 --> AssumeFPS(29.97) --> AssumeFPS(23.976) = No change
You didn't undestand my point. For simplicity, let's assume that the video in the background doesn't interest us at all - blankclip() - and we've got a karaoke which lets the romaji glide from the left to the right (e.g. the ED karaoke from Eclipse's Fate/stay night).

Now, if you encode this karaoke at 29.97 and subsequently decimate it down to 23.976 for the avi (which was your initial suggestion), then THIS KARAOKE EFFECT will jerk. Very obviously so, since one out of 5 frames will be dropped, but there's no duplicate.

If on the other hand you'd load the very same karaoke script on a 23.976 footage and encoded it anew, it would NOT jerk. It would cleanly glide without problems.

See what I mean?

Quote:
For the typesetter, we can just make a 29.97 Workraw and give them the timecodes.
You haven't typeset much in the past, am I right? For an ASS typesetter, it's extremely helpful if he can use continuous motion. However, having duplicates in the video will screw up the continuous motion, so either he'll have to accept the jerkiness in the post-decimation result or curse you and split the typesetting in many many cycle5-parts.
Mentar is offline   Reply With Quote