[TheFluff]

Originally Posted by neothe0ne

But wouldn't converting that to 29.97fps not drop any frames, assuming the source framerate was 29.97fps before making it VFR? I haven't noticed any by doing things this way.

If the source framerate is 29.97fps it's CFR and you should not be having this discussion in the first place. If the source is VFR you shouldn't say it has "a framerate", because it doesn't and it's much easier once you've come to terms with that.

Originally Posted by Kristen

See, my process is Raw----(Filters)---->Lossless--->h.264. Once we have the script, we go from that lossless--->XviD.
However, the VFR will pose issues, since after encoding without convertfps, it came out as 26 minutes, and the timecodes brought it back to the regular 24:30. That's when timecodes are muxed in.
If I had that lossless, I couldn't go to XviD .avi from it, since the timecodes could not be applied, as I found out above. So as such, it would require an entirely new encode, which is 3:30-4:00 (That's hours) for a lossless, and another 1.5 for XviD (Since I run on a dual core, not a quad.) However, I'd probably be encoding it while I sleep, so I'd have to get everything done in one step, so it would be filtered XviD, which takes 9 hours on this PC.

If you're doing two versions (one VFR and one CFR) from the same lossless you have a few options:
a) make two losslesses, one converted to CFR and one VFRaC
b) mux the lossless to mkv with timecodes and use ffmpegsource() or somesuch for the VFR release and directshowsource(convertfps=true) for the CFR release
c) if the source only has two framerates and only switches at one or a few points (like for an OP/ED), you can encode one lossless per framerate section and splice them together with the appropriate framerate conversions.

Originally Posted by Kristen

From what I've hear, 29.970 also causes jerkiness in convertfps, just this time in the 23.976 fps places.

Quotes such as this show that you still haven't understood anything at all about the actual issues here. Hence I will try to explain again.

The absolutely most important thing you must understand here is that THERE IS A VERY IMPORTANT DIFFERENCE BETWEEN FRAMES AND TIMESTAMPS.

Consider a frame. It's a picture, right? Video is just pictures, displayed one after each other. Each picture has a timestamp; a number (usually in milliseconds) that describes at what time (relative to the first frame) it should be displayed. This makes sure all frames are displayed in the correct order and at that the video is played at the correct speed. Usually, it is assumed that all frames are displayed for the same amount of time; that they all have the same duration. This is CFR, constant framerate.

Now, consider a very short "video", in which the letter B moves across the frame (each letter is a "pixel"):

Frame 1:
B A A
A A A
A A A

Frame 2:
A B A
A A A
A A A

Frame 3:
A A A
A B A
A A A

Frame 4:
A A A
A A B
A A A

Frame 5:
A A A
A A A
A A B

Frame 6:
A A A
A A A
A B A

Frame 7:
A A A
A A A
B A A

Frame 8:
A A A
B A A
A A A

Let's say each frame is displayed for one second each (one frame per second). Now, let's say we wanted to convert the video to 1.25fps, that is to say display each frame for 0.8 seconds instead. How do we do this? The simplest way would be to just run the video faster, making its total length 6.4 seconds (0.8 * 8) instead of the original 8, but if we had audio too that would make it go out of synch with the video. Instead we need to insert some extra frames. Two extra, to be specific, since that would make the video 8 seconds again. Where do we get those extra frames from? We duplicate some existing ones, of course. But that gives us another problem: since we aren't duplicating all frames, the duplicate frames will last for twice as long as they're supposed to, making the travel of the letter B uneven (or "jerky").

This is what happens with anime too; if you force a conversion to another framerate the result will have jerky motion. If the source has uneven frame durations (i.e. it's VFR), forcing it to be CFR WILL introduce jerky motion, unless all source framerates are evenly divisible with the target framerate (this is the case with 119.88fps; it is an even multiple of both 23.976 and 29.97).

Originally Posted by Soichiro

do the XviD as VFR

what does this mean exactly

Originally Posted by neothe0ne

I don't understand the problem, actually. The way I understand tc2cfr to work, it losslessly adds dummy frames to get the 120fps avi, because if it was re-encoding, it would take hours, not minutes.

This is correct but I don't get why you'd use it at all.

Originally Posted by neothe0ne

I'm assuming that Synergy only animates in 29.97fps (I don't recall having any problems with SS-Eclipse's (TheFluff's?) Hayate no Gotoku! releases.) If that's so, the 120fps raw you're left with could be converted to that 29.97fps lossless and your process would appear to work fine still. This would only add about 5 minutes to your encoding time, if everything is working the way I'm thinking.

Again, if it's constant 29.97fps, why the fiddling with 120fps? Also, Avisynth doesn't "get" dropframes and will deliver all 120 frames per seconds as if they were actual frames, making the encode time 4-5 times longer since it's 4-5 times more frames to encode.

Originally Posted by neothe0ne

Also, if Synergy actually did animate parts in 24fps, 24fps -> 30fps is a much better solution than 30fps -> 24fps, especially considering how much of ZTC looks jerky in 24fps.

It's pretty much just as bad actually.