VFR for Fansub Encoders - how, why, WTF?

[xhatebreedx]

One question please:
I tried converting a 120 fps raw into 24fps with cfr2tc, but the output avi has no sound. Then i opened the 24fps avi with vdub and loaded the wav from the 120fps raw, and the compressed it in Lame MP3 160 CBR, but the result was'nt good. The video was not jerky at all, but the sound was not in sync with the video.

Can someone tell me what to do please?

Its painful to compress every time the 120fps raw with divx at a high bitrate and in the same time, decimating by 4 or 5, so as to get a 24 or 30 fps raw, in order to load all the textsub filters and then recompress it with x264.

[TheFluff]

Your problem is that you're trying to encode VFR when you really expect CFR. Don't use cfr2tc if you intend to encode to CFR! The output .avi you get with cfr2tc will ONLY synch with the audio if you mux it to MKV (or MP4) with timecodes.

If you want to encode to CFR, what you want to do is simply decimate the original 120fps raw by 5 in Vdub or Avisynth and encode that.

[xhatebreedx]

If i decimate by 5 and let it direct stream copy, the ending becomes really jerky (it originally had one useless frame every 2 frames) but okay, i guess i have to split the raw into two parts (opening/episode and ending) and decimate them seperately.
But i want to ask if that is the common method in handling the 120fps raws, in order to make a fansub in 24 or 30fps. (im always talikng about compressing into avi)

[TheFluff]

Eh... you completely missed the entire point about VFR. If you decimate the parts separately with different "decimate by" parameters, you WILL get two files with two different framerates. If you splice them together, you have something with a non-constant framerate: VFR. Unfortunately, VFR doesn't fit into AVI (except as 120fps, but you don't want to do that).
Hence, if you encode a VFR source material (your 120fps raw for example) to AVI, the result WILL be jerky SOMEWHERE. The ONLY way to avoid the jerkiness is to use cfr2tc, encode the result with subs and then mux to MKV (or MP4) with timecodes. Period.
If you don't want to use MKV, then tough luck. Your AVI will be jerky. Simple as that.

[[darkfire]]

sylf heres the timecode

# timecode format v1
Assume 29.970030
0,0,23.976024
1,1,119.880120
2,3162,23.976024
3164,8573,23.976024
8575,8575,23.976024
8576,8576,119.880120
8577,16877,23.976024
16879,16879,23.976024
16880,16880,119.880120
16881,23908,23.976024
23910,23910,23.976024
23911,23911,119.880120
23912,30785,23.976024
30787,30787,59.940060
30788,30788,119.880120
30789,36176,59.940060
36177,36177,119.880120
36178,36178,23.976024
36179,36179,119.880120
36180,37639,23.976024
# Total Frames:  37641

[TheFluff]

Try removing that last comment and see if that solves anything. Some (slightly retarded) timecode parsers doesn't actually support comments, only that format line at the beginning.

[Sylf]

Also, try changing the second line to
Assume 119.880120

Also, those bunch of 120fps sections look really iffy. And there are so many segments that are just 1 frame long. And why is it that there are some frames missing in the time code file? (like frames 8574, 16878, etc) Is that normal? It might be better to edit the file by hand, and only use VFR for the section that really needs it, rather than trusting the output of cfr2tc 100%.

[raziel666]

Now, here's the stupid question of the week. I was experimenting the other day with a 120fps raw, and I succeeded in using avi2tc (yatta) and muxing the audio to the decimated raw with the timecode file (yatta again). The really silly question, regards the subtitles: From what I understand, I should do the audio timing on the audio alone (obviously) and then for scene / final timing I should use the video, the timecodes file and then export from Aegisub enabling VFR. Is this true?

[TheFluff]

Yes, that's correct, assuming that you want to hardsub. Use the decimated raw and the timecodes file in Aegisub, then hit file -> export and keep only "VFR transformation" checked. The default settings should be left alone.

If you want to softsub you just skip the exporting step and mux the subtitles as they are, after final timing.

[Hichigo]

another point people tend to forget is that most encoders now dont try and compress their encodes due to the fact more prefer to keep it as HQ as they can pos have. With the vast improvements on computer specs and internet connection speeds the mass majority of encoders dont see a need in compressing it and sacraficing quality just for users to download the files that little bit quicker.
with hte advances in codecs, filtering and HD raws ppl tend to keep as close 2 the orig source as posible.
another factor is alot of groups try and release their encodes in HD 720 or greater. the higher the res the greater the biterate needs to be to sustain the quality. which in turn means a higher biterate which results in a higher file size.

[Sylf]

I think you're in a wrong thread, and even in any thread around, you're missing some points, or using some terms in very vague manner.

First of all, this thread is talking about variable frame rate encoding methodology, not about codec trends or video encoding trend in general.

Second, "no need for compressing video" is not true at all. Uncompressed avi can amount to a multi-gigabyte monster file. Even the lossless compressed video comes out to 3 to 5 gigabytes per 24 minute episode of anime, depending on a show and codec used. Maybe what you meant is that encoders don't see the reason to compress the video as much as they did in the past.

Anyway. I'd say more if this was in a proper thread, but... at least take the conversation elsewhere.

[taduyducvn]

i Got a quite strange time code file when I extract it from my MKV File,

its like this:

assume 23.976

0,1,0.104987

2,2,1.#INF00

3,3,0.332226

4,4,1.#INF00

5,5,0.131752

6,6,1.#INF00

7,7,0.255102

8,8,1.#INF00

9,9,0.309598

10,10,1.#INF00

11,11,0.125156

12,12,1.#INF00

13,13,0.132275

14,14,1.#INF00

15,15,0.136799

16,16,1.#INF00

17,17,0.133511

18,18,1.#INF00

19,19,0.136054

20,20,1.#INF00

21,21,0.139276

22,22,1.#INF00

23,37,0.370370

38,38,100.000000

......

388,392,0.236072

393,393,33.333332

394,395,0.348432

How to write it in AviSynth?

[TheFluff]

@taduyducvn: PLEASE. STOP. CROSSPOSTING. And for the love of $deity, you don't HAVE to post once every five minutes!

[taduyducvn]

hic. sory, but since you have read this page, pls answer my question. Thanks

[raziel666]

Hi. Recently I've been working with a 120fps raw that's been giving me a hard time. I'm trying to get decimated raw with avi2tc, but I get this message:

Exit Code (12): A problem was encountered
cfr2tc v 1.4 by tritical
Frame parsing progress: 100.00% (131812)
Timecode file created successfully
Frame modification progress: 19.39%
Number of data chunks does not match frame count

Does anyone know something about this? Is there any other way of getting a decimated raw? Thanks a lot.

[Nicholi]

I wouldn't really bother using tritical's app unless you plan to actually encode a VFR file, and it doesn't sound like you are. If you are just going to a constant framerate, decimate the file yourself. It is 1000x easier. SelectEvery(X) is your friend, depending if the show is 24fps or 30fps.

[Quarkboy]

Okay, I have a specific technical question I have no answer to.

I have some variable frame rate mkv raws (capper, NodameFLeakcGekh, fyi),

which I want to decimate to 23.976 (since almost all of the show is that frame rate except a few bits ofthe ending).

However, the base framerate of the mkv is something really odd, 30.30 fps.

I.e. if I open the mkv using "Directshowsource("raw.mkv",convertfps=true)" I end up with a video at 30.30 fps.

This is further backed up by extracting and inspecting the timecodes from the mkv.

First question: What the hell is with this framerate?

Second Question: I'm currently decimating using 2 steps (after the DSS above)
tdecimate(mode=1,cycle=5,cycler=1)
tdecimate(mode=1,cycle=91,cycler=1)

(yes, that's not a typo... cycle=91) If you do the math carefully, you see that that gives you exactly 23.976 fps. (actually, the orignal framerate is 3000/99, so then:
(3000/99)*(4/5)*(90/91)=1080000/45045=24000/1001=23.976

Is there something I'm missing here?

[Nicholi]

Well the weird framerate is probably a jap raw capper problem in general. Whether AVI, MP4, or MKV they do krayzie shit . Most likely some weird rounding which didn't correctly set it at 29.970, what it should be.

Anyways, why aren't you just forcing the framerate when you use DSS?

Directshowsource("raw.mkv",convertfps=true,fps=23.976)

Would be much simpler in my mind.

Also since you said only a few bits are actually a different framerate, I pose another "almost simple" method. Extract the timecodes and video via mkvextract, convert the timecodes to v1 type (so you can understand them), and just decimate over the ranges which aren't 23.976 in the extracted video. Mostly simple, ne n_n!

[Mentar]

Quarkboy, you really don't want to toy around with tdecimate() on stuff like this. If you want to force CFR for your target, Nicholi's solution is BY FAR the most reliable and simple method to do it.

If you want to keep the VFR alive, transform the source to lossless avi and extract the mkv timecodes. With Aegisub you have a reliable tool for typesetting and timing in VFR environments without problems. And AFX really doesn't care about what framerate the video actually is, so you can easily work on the lossless avi (which is CFR by definition) regardless of the fact that when remuxed with the timecode file it turns VFR again.

Things have become really convenient today. The old times when you had to painstakingly write timcode files by hand are long gone

[martino]

I have written a little shitty program, which can open a v1 timecode file (providing that the "#" comment and assume lines have been removed beforehand from it) and shift them by a certain number of frames. Whether this could be of use to anyone, I wonder. Maybe if you wanted to use AFX for karaoke and then keep the rest of the episode at vfr (using the output from avi2tc). I have tested it with a RAW in the format OP-EP-ED and it worked. Though this program only shifts the frame numbers when the sections start and finish. You have to do the rest yourself, which is calculating the lengths of the sections before/after and so on, adding the timecode identification line, adding assume fps and joining multiple sections together if you did it in more steps. I hope you know what I mean...

Currently no documentation is available with it. I will write something later on (also, I have no clue what the hell is the whole GPL thing about, but I stuck it there just in case ). And a word of warning, don't use this unless you know what you're doing...

Simple instructions:
1) Remove all the stuff that the program can't handle (for example):

# timecode format v1
Assume 29.970000

# Total Frames: 8666

So that all that will be left will be the frames and fps, for example:

5,64,23.976000
410,425,23.976000
466,469,19.980000
515,518,23.976000
524,603,23.976000
609,624,23.976000
630,637,23.976000

2) Open file
3) Input the number of frames that you want to shift it by (you will be asked this after opening the file)
4) Save it
5) Add in all the rest mentioned earlier on through notepad or whatever you use. I presume that if you got here successfully then you should know what you're doing.

http://www.filefactory.com/file/6fb06f/
Current version: 0.9.0
Some updates might be coming up, though don't expect anything major, most likely just documentation. Also, if there are any suggestions then I could put those on my To-Do list, but keep in mind that your requests cannot be overcomplicated.

Also, feel free to laugh at my stupid attempt. I'm not good at programming...


Special thanks go to TheFluff and Mentar for putting up with my stupid questions and clearing up some stuff in my head.