VFR for Fansub Encoders - how, why, WTF?

[martino]

Originally Posted by Nicholi

Hopefully there is usually a better one that isn't 120fps AVI .

MKV/MP4 where the timecode file looks like it's been output by crf2tc on defaults... >_>

Needs .ts...

[Kristen]

How do you deal with a .ts VFR?

[NicestBoat]

Originally Posted by Kristen

How do you deal with a .ts VFR?

The transport stream martino was probably talking about was one captured from DTV, those are always constant framerate(usually 29.97fps interlaced), the same as most DVDs.

It seems you once again missed the whole point of why VFR is used in the first place. In practice, studios sometimes mix telecined 29.97fps content with progressive 29.97fps or pure interlaced 29.97fps. This content is part of the same stream, running at the same framerate, and is meant to be displayed on an interlaced screen ( example: SD TV ) at 29.97fps.

As you probably know, most dvdrips/(h)dtvrips(or what you call TV raws) are progressive, not interlaced, and you may also know that from telecined content you can recover fully progressive frame through IVTC(Inverse Telecine), this process has a phase called decimation(after field matching) in which one duplicate frame in five is removed, and thus you end up with 23.976fps.
Now image a transport stream where you have a progressive OP at 29.97fps (rendered in some editing app at that framerate), and the main episode runs at 29.97fps telecined.
If one were to do the conversion/encoding manually(or in YATTA), they would leave the 29.97fps progressive OP alone and not fieldmatch or decimate it( which your group sometime ruins by using ConvertFPS anyhow ), and IVTC the main episode, write timecode files where it marks the OP as 29.97fps and main episode as 23.976fps. I hope you now understand why VFR is NEEDED in the first place.

[Kristen]

Originally Posted by NicestBoat

The transport stream martino was probably talking about was one captured from DTV, those are always constant framerate(usually 29.97fps interlaced), the same as most DVDs.

It seems you once again missed the whole point of why VFR is used in the first place. In practice, studios sometimes mix telecined 29.97fps content with progressive 29.97fps or pure interlaced 29.97fps. This content is part of the same stream, running at the same framerate, and is meant to be displayed on an interlaced screen ( example: SD TV ) at 29.97fps.

As you probably know, most dvdrips/(h)dtvrips(or what you call TV raws) are progressive, not interlaced, and you may also know that from telecined content you can recover fully progressive frame through IVTC(Inverse Telecine), this process has a phase called decimation(after field matching) in which one duplicate frame in five is removed, and thus you end up with 23.976fps.
Now image a transport stream where you have a progressive OP at 29.97fps (rendered in some editing app at that framerate), and the main episode runs at 29.97fps telecined.
If one were to do the conversion/encoding manually(or in YATTA), they would leave the 29.97fps progressive OP alone and not fieldmatch or decimate it( which your group sometime ruins by using ConvertFPS anyhow ), and IVTC the main episode, write timecode files where it marks the OP as 29.97fps and main episode as 23.976fps. I hope you now understand why VFR is NEEDED in the first place.

Yeah. So there is no short way to get Avisynth to identify which frames are teleclined and which are 29.970? That's a bit of a shame.

[D404]

Seems you actually need to do something called using your eyes.

(dvd2avi/dgindex can help too in some cases i suppose...)

[martino]

Simply put... no duplicates and you've got yourself a 29.97 section. Fairly easy to spot in an OP/ED, where there's usually always some kind of motion, whether be it animation content or (oh god no) scrolling credits.

[Mentar]

Originally Posted by comatose

Delete all the single/two frame lines, change Assume to 23.976 and merge intersecting sections of the same FPS... they're just errors.

Careful with advice like that! If you delete lines you consider "errors", you tend to introduce desynch, and depending on the amount of deleted lines, the desynch can become very noticeable.

Real-life example I used from the tests I ran on this again.

# timecode format v1
Assume 23.976000
0,0,119.880115
3693,3693,119.880129
14506,14506,119.880129
31770,31770,119.880115
33927,33927,119.880129

That's a completely 23.976fps source released as 120fps, with optimized max_diff parameter just to make Nicholi happy (and a fairly typical result even from true VFR sources with 29.97 segments). Now what happens when you delete these single-frame "error" lines? Math exercise, how much desynch have you just added?

119.88 frame = 8.34 ms
23.976 frame = 41.76 ms

So we'd have added 5x (41.76-8.34) = 167.1 ms

The result would be a disaster. You're taking quite a gamble there. "Just delete what doesn't seem to fit" is NO advice you should give.

Originally Posted by Nicholi

I think the overall lesson we've learned though, is just stay away from crappy sources. Hopefully there is usually a better one that isn't 120fps AVI .

That's not the lessons I'd learn from that. Since the recent crackdown on the japanese P2P scene, the number of good captures have gone down significantly. If you're forced to use these raws, you usually only get 1-2 which are usable for release material. And - sorry - these who show these "error lines" in the tritical tools output are the clear majority. Fact. You're not always at the liberty to seek around until you find a raw which "works" with them and is a usable release candidate.

Which is why _my_ lesson would be to rather use my manual approach which works with ALL raws. Yes, it's a bit more work, but you can depend on the fact that it will work in any case. Not just in the sunshine.

[shinjipierre]

VFR and Adobe AfterEffects

.....Let's work in a compositing program with B-frames and VFR, yay

compositing programs work on a frame-based timecode. It's a total waste of time to work with a codec that has VFR and keyframes....
Image sequences, lossless codec... that's what should to be used in there.

[Meltingice]

Originally Posted by Mentar

Careful with advice like that! If you delete lines you consider "errors", you tend to introduce desynch, and depending on the amount of deleted lines, the desynch can become very noticeable.

Real-life example I used from the tests I ran on this again.



That's a completely 23.976fps source released as 120fps, with optimized max_diff parameter just to make Nicholi happy (and a fairly typical result even from true VFR sources with 29.97 segments). Now what happens when you delete these single-frame "error" lines? Math exercise, how much desynch have you just added?

119.88 frame = 8.34 ms
23.976 frame = 41.76 ms

So we'd have added 5x (41.76-8.34) = 167.1 ms

The result would be a disaster. You're taking quite a gamble there. "Just delete what doesn't seem to fit" is NO advice you should give.

That's not even a quarter of a second... How would this become a disaster....? Also, it's not 5 consecutive frames, so there won't be an obvious 167.1ms delay... Though you obviously wouldn't want to do this if there were too many frames.

[Mentar]

Originally Posted by Meltingice

That's not even a quarter of a second... How would this become a disaster....? Also, it's not 5 consecutive frames, so there won't be an obvious 167.1ms delay... Though you obviously wouldn't want to do this if there were too many frames.

As a rule of thumb, 100ms is when audio displacement in karaoke effects becomes so visible that quality groups would fix and reencode. Also, you'll notice that lip movements aren't synchronized anymore (several shows do that), slamming doors feel "off", a shot breaks too late... don't underestimate that.

And the effect is cumulative, so things will get worse to the end. "Dropping" 1 frame may not be noticeable very much, once the second frame goes, someone with timer/encoder eyes _will_ notice. With the third some fans will realize it, but after the fourth, almost everyone will sense that things are strange. And the ED karaoke will usually make it very clear.

[comatose]

But I'm pretty sure those 119.88 frames are actually supposed to be 23.976, as I've not experienced this desyncing even after removing over 20 of them... and yes, I went over it several times to make sure it really isn't out of sync.
And uh, 23.976 frames? You only remove 119.88 frames. 23.976 frames become part of the Assume... they're only removed to make the timecodes look prettier.

I've been going under the assumption that these single 119.88 frames are actually supposed to be 23.976, and they're marked as 119.88 for whatever reason.
In any case I've double-triple-dfsjsdfkjchecked for desync in every episode where I did this, and didn't notice any (there were 13 frames in one episode)... nobody ever complained about desync either.

So far I've only had to do this with one series though, so there may be sources where doing this does actually cause desync...

[Nicholi]

Originally Posted by Mentar

That's a completely 23.976fps source released as 120fps, with optimized max_diff parameter just to make Nicholi happy (and a fairly typical result even from true VFR sources with 29.97 segments). Now what happens when you delete these single-frame "error" lines? Math exercise, how much desynch have you just added?

Like I already said before, crap in = crap out. So for files created by the few imbecilic cappers you won't get "omg perfect arithmetic!", but if you use your brain you will easily know where a REAL vfr section is and where it is not. What is this "manual approach" you keep referring to? Checking every single frame in the video to see if it's VFR or not by applying a 24 or 30fps decimation? More work...for what reason? Not knowing how to use a simple app and understanding the very modest amount of arithmetic involved with timecodes?

Or as I recall you saying you just check the OP, the ED, and a few spots of the main footage and simply assuming/guessing that the entire rest of the show is the same. This is not better, faster, or more accurate...it will result in errors. Though an encoder of your caliber will notice such errors after encoding through once and go "omigosh, gotta make a little fix for that section too now". But that has just resulted in more time...for what reason? Not to mention you have to literally teach people to pay attention to motion when QC'ing their files, if they even do that. But if you use the tcConv, and not trip balls when you see the output timecodes aren't perfect because the cappers 120fps file drops in null frames with some nonstandard method (I've used it on 120fps files which are just fine, and of course timecodes from MP4/MKV should result in perfect v1 timecodes all the time), use a modest max_diff and you will know immediately where potential VFR sections are. No guessing, no assuming the entire show to be the same, it tells you exactly what is going on. All that needs to be done by the encoder is take the modest amount of time to understand what the timecodes are telling you about the video.

So all that really needs to be done is to use tcConv...some foresight...and not be an imbecile. And it will work for all situations. It requires less effort, it requires less time, and it produces the same results. This doesn't need to be turned into some huge manual feat of effort.

[Mentar]

Originally Posted by comatose

But I'm pretty sure those 119.88 frames are actually supposed to be 23.976, as I've not experienced this desyncing even after removing over 20 of them... and yes, I went over it several times to make sure it really isn't out of sync.
And uh, 23.976 frames? You only remove 119.88 frames. 23.976 frames become part of the Assume... they're only removed to make the timecodes look prettier.

I'm not sure if we understand each other correctly. If you have a frame entry which is listed as 119.88, and then you delete it, you change its framerate to the "assume" value. And of course, this alters the duration which it's played, and logically causes desynch.

I've been going under the assumption that these single 119.88 frames are actually supposed to be 23.976, and they're marked as 119.88 for whatever reason.

Actually, I do believe in the tools' reliability here. They're no "errors", that's how they really are.

In any case I've double-triple-dfsjsdfkjchecked for desync in every episode where I did this, and didn't notice any (there were 13 frames in one episode)... nobody ever complained about desync either.

Well - first of all, changing a frame from 29-something to 23-something is much less damaging than altering 119-something to 23-something. Also, if you prepare workraws with the "deleted" timecodes first, then the timer will simply adjust to it. It would primarily cause later parts of the episode to be off, depending on how aggressively frames are deleted. It MAY very well just work out. I just think you should be aware of the inherent danger.

Originally Posted by Nicholi

Like I already said before, crap in = crap out. So for files created by the few imbecilic cappers you won't get "omg perfect arithmetic!", but if you use your brain you will easily know where a REAL vfr section is and where it is not.

You act as if the problem which so many people including me reported would only occur on fringe raws of obscure cappers. That's simply not the case. It's the RULE, not the exception. So far, I have been unable to find a SINGLE RAW which did NOT exhibit these problems.

What is this "manual approach" you keep referring to? Checking every single frame in the video to see if it's VFR or not by applying a 24 or 30fps decimation? More work...for what reason? Not knowing how to use a simple app and understanding the very modest amount of arithmetic involved with timecodes?

Again, you stubbornly act as if the tool would always yield the desired result, and as if it was only a matter of using it correctly. To my experience, it doesn't, and looking at the feedback of others (even those who use it), they confirm what I said. If it wasn't so childish, I'd dare you to roll some dice to decide on some show, and then to hand 5 120f-raws to you, so that you can demonstrate your expertise to threshold things so perfectly that clean 3/4-liner v1 timecode files drop out for at least 3 raws. But I predict that you're gonna lose.

I agree with you that tcConv makes sense in SPOTTING potential VFR sources. Point taken. But it does NOT - in my experience - create flawless v1 timecode files which you can easily use for avi/mkv double releases, and I see no reason to confuse less-experienced encoders in this thread by pretending it does. It creates unrealistic expectations and subsequently frustrations if people fail to reproduce it.

In my experience, in 95% of the raw-based cases, VFR releases only alternate between OP/Episode/ED. Random "inner" sequences which may technically be 29.97 compared to 23.976 in default rarely warrant the overhead of doing them properly - they tend to be short fades most of the time. So, I do think that an encoder able to do the OP/Episode/ED framework will be pretty far already.

So all that really needs to be done is to use tcConv...some foresight...and not be an imbecile. And it will work for all situations.

Scuse me. Nonsense. You already built up the "imbecilic capper" straw man, so you clearly know that it doesn't work for all situations. Why do you have to exaggerate so grandly? Do you get non-existent royalties from the tools? ^_^;

It requires less effort, it requires less time, and it produces the same results. This doesn't need to be turned into some huge manual feat of effort.

Well, nobody is forced to follow it. But the next time, an encoder following your approach comes up with a v1 timecode file like the one I listed above, I hope you help him write the avisynth script to trim/decimate-turn this omelett into clean CFR AVI eggs again. It's gonna be pretty hard (at least I wouldn't know offhand how to correctly deal with the 119-fps-leftovers without "rounding")

Anyway, I don't feel like turning this into a big contest. The approach I listed comes with no warranty and only limited service. But it's tried and true and might help some people who are less fortunate with the tritical tools.

[Nicholi]

Originally Posted by Mentar

I agree with you that tcConv makes sense in SPOTTING potential VFR sources. Point taken. But it does NOT - in my experience - create flawless v1 timecode files which you can easily use for avi/mkv double releases, and I see no reason to confuse less-experienced encoders in this thread by pretending it does. It creates unrealistic expectations and subsequently frustrations if people fail to reproduce it.

Well allow me to bold here stating that it seems you did not even know how to use the tool until I made the post just awhile ago talking about max_diff and you PM'd me on IRC. So sorry, but in this case it seems "your experience" with the tool is unfortunately as altogether meaningless as someone who just started encoding yesterday talking about their "grand experience using AviSynth" we've all heard.

Originally Posted by Mentar

Again, you stubbornly act as if the tool would always yield the desired result, and as if it was only a matter of using it correctly. To my experience, it doesn't, and looking at the feedback of others (even those who use it), they confirm what I said. If it wasn't so childish, I'd dare you to roll some dice to decide on some show, and then to hand 5 120f-raws to you, so that you can demonstrate your expertise to threshold things so perfectly that clean 3/4-liner v1 timecode files drop out for at least 3 raws. But I predict that you're gonna lose.

The desired result is to see timecodes in a humanly understandable way. Constantly increasing v2 timecodes is meaningless to us, clearly. v1 timecodes tell us an exact range, and the framerate of that range. THATS ALL WE NEED (and our brains of course!). As to "rolling the dice" I was in fact thinking of the same thing...because it seems you are entirely baffled about how to interpret timecodes. Please give me these unusable files so I can succinctly tell you how easy it is to just use tcConv + your brain.

The simple matter of the case is, your "manual" method is error prone. It specifically denotes errors will come up because you are making assumptions as to the framerate of the source. I don't know why you think this error-prone method is somehow better than simply knowing what the timecode ranges in the source are. The only thing I can surmise is because you have never properly used the tool until just recently. Or thought about how to use it.

As I already said, takes less time, takes less effort, and you will know the first time around whether the source is entirely a single framerate or not. Instead of simply assuming it is. I don't do coin tosses and just say "oh well most shows are CFR 24fps, so if I see a few scenes that are 24fps thats good enough for me". I'd rather just know what the framerates in the source are and that be the end of it. Also I don't see how your method is any better for new encoders...it seems to be saying "No don't understand how timecodes work, and no don't understand how timecodes are manipulated between a v2->v1". So teaching newbie encoders how things work is confusing, but making simple assumptions which are wrong about the source is good. It's not like they have to fucking take a 10 week course to understand simple concepts and how the tools they are using work.

Yes I know the tool isn't perfect because people make shitty files. This isn't a new concept to encoders anywhere, they learn to deal with crappy sources. They don't throw old tools completely out the window (unless they are in fact broken) and adopt some insane "manual" method just because things don't proceed exactly as planned :3. Sorry, it's just whack and is more work for almost the same results (because yours is more error prone and requires being checked afterwards).

Originally Posted by Mentar

Well, nobody is forced to follow it. But the next time, an encoder following your approach comes up with a v1 timecode file like the one I listed above, I hope you help him write the avisynth script to trim/decimate-turn this omelett into clean CFR AVI eggs again.

Yes, lol, silly me. Telling newbie encoders that maybe understanding the tools they are using was a bad thing...lol! It's too komplex for them. Requires years of rigorous training atop a mountain pondering the meaning of time.

[Mentar]

Originally Posted by Nicholi

Well allow me to bold here stating that it seems you did not even know how to use the tool until I made the post just awhile ago talking about max_diff and you PM'd me on IRC. So sorry, but in this case it seems "your experience" with the tool is unfortunately as altogether meaningless as someone who just started encoding yesterday talking about their "grand experience using AviSynth" we've all heard.

I tried the tool with its defaults in the past, and it failed. I tried the tools again, this time based on manpage, and it failed. I contacted you about it, and after alot of sneering... it still failed for me. Those were the experiences I referred to. I never claimed to be an experienced expert in using it, I was listing MY EXPERIENCES WITH IT. Got it, champ?

The tool failed for comatose. The tool failed for edogawaconan. The tool failed for Meltingice. Only you are there, who pretends that it "works in all situations", you just must not be "imbecilic". And if it doesn't, it's the cappers' fault.

Whatever

The desired result is to see timecodes in a humanly understandable way. Constantly increasing v2 timecodes is meaningless to us, clearly. v1 timecodes tell us an exact range, and the framerate of that range. THATS ALL WE NEED (and our brains of course!). As to "rolling the dice" I was in fact thinking of the same thing...because it seems you are entirely baffled about how to interpret timecodes. Please give me these unusable files so I can succinctly tell you how easy it is to just use tcConv + your brain.

Okay. So you tell me that I shall provide some 120fps raws, and you list the proper max_diff parameter in return in order to create clean v1 timecode files which only filet out the true VFR parts without garbage. No strange off-time single frames, no list of half a dozen 10-frame "VFR" exercepts which are actually only fades. The resulting v1 file is short and can be easily taken to create the CFR AVI via trimmed decimation in avisynth.

Is that correct?

I just don't want you to weasel out later on and suddenly pretend that the results are "good enough" when you fail to deliver.

The simple matter of the case is, your "manual" method is error prone. It specifically denotes errors will come up because you are making assumptions as to the framerate of the source.

Assumptions like "in general, the framerate of anime is either 23.976 or 29.97 (I'm not counting 60fps credits, since they should be handled as 29.97 anyway). Yes, I plead guilty to that. That's newbie encoder level stuff, Nich.

What I do is that I force a "rounding" of things here. And yes, if there were true 29.97 parts in the middle of the episode while forcing it to 23.976, it would lead to jerking. But in real life, as even you admitted, this almost never happens. And the advantage of this approach is that it's stable and easy to implement.

Yes I know the tool isn't perfect because people make shitty files. This isn't a new concept to encoders anywhere, they learn to deal with crappy sources. They don't throw old tools completely out the window (unless they are in fact broken) and adopt some insane "manual" method :3. Sorry, it's just whack and is more work for almost the same results (because yours is more error prone and requires being checked afterwards).

Now what? Again you alternate between "it always works" and "it fails with shitty files". Now what? How about you make up your mind?

Yes, lol, silly me. Telling newbie encoders that maybe understanding the tools they are using was a bad thing...lol! Don't understand how things work kiddies, do it the manually way. Superiar!

So far you've been all talk. You better succeed in your claim to always produce clean v1 timecode files. So is the bet on?

Your loud sneering really makes me wonder how many VFR dual releases of fansubs you've made in the past.

[TheFluff]

Hate to interrupt this highly entertaining flamewar but I think both of you have kinda missed the other's point.

Nicholi's method isn't flawed. It works. It doesn't matter how many times the video switches framerates or if segments are "odd" framerates, it won't desync video/audio, kill kittens, cause hair loss or have any other untoward sideeffects. What it does do is make it slightly more annoying to release a CFR version in addition to the VFR version since the slight scene timing differences between VFR and forced CFR might cause scene bleeds in the subtitles (this is usually fixed in a few minutes with Aegisub's timing postprocessor and going through the signs manually though). Other than this there aren't any disadvantages really. None. Yes, you can keep the single odd "120fps" frames and other single-frame zones and it'll still work. Just set a suitable max_diff and you'll be perfectly fine.

Mentar's completely manual method on the other hand has the advantage that it can let the rest of the team assume that the source is CFR (if and only if the framerate switches are limited to OP/ED sequences), and that it won't require any adjustment of signs or subtitles since the timing should be the same (no odd framerates to worry about). There is however one big drawback, namely all the manual cutting and splicing. If your show only has one or a few framerate changes it's not much to worry about, but if it switches frequently you'll quickly go insane.

Obviously the best way is a hybrid; examine the autogenerated timecodes, find out how many "real" framerate switches there are, and if there's only one or a few you might want to do it manually, but if there's a lot you might as well say fuck it and let the tool to the decimation for you instead of doing it yourself with Avisynth.

Personally I tend to opt for the completely automated way since I am lazy and checking a few signs in Aegisub is less effort than generating and splicing together ten or so losslesses of varying lengths in different combinations for different releases.

[Nicholi]

Impossible sample 1 from Mentar, some ugly 120fps AVI file.

Original v2 timecodes.
So what needs to be done to correctly use the tools described to convert your lossless vfrac file to cfr without errors? Using the timecodes is the answer. The timecodes represent exactly what is going on in the video stream and how long each frame is being played on screen. However we start with these v2 timecodes. Obviously since no one is a human computer you have no idea whats going on in the v2...unless you can calculate the timelength of every frame and remember them all at once .

Step 1: Convert to v1 to understand whats going on in the video stream. No special max_diff is needed here, and the AssumeFPS is told be to 23.976fps.

tcConv.exe newtimecodesv-avi.txt newtimecodesv-avi_V1.txt 24000/1001 0.1

Step 2: Interpret results. Now we have some v1 timecodes, what do they look like though?

Spoiler:

# timecode format v1
Assume 23.976024
0,0,119.880115
1,1,29.970031
3693,3693,119.880129
3694,3694,29.970030
14506,14506,119.880129
14507,14507,29.970030
31770,31770,119.880115
31771,31771,29.970031
33927,33927,119.880129
33928,33928,29.970030

They seem a little odd? Yet this is what is being used on playback. All it is is a reinterpretation of the v2 timecodes in a form that we can easily read and understand what is happening. This is the "clean" representation of the timecodes file in v1. So, are those really 120fps frames in that file? One could double check by going back to the v2 timecodes file and finding the timelength of the frames.

Line 1 of the v2 timecodes is 0.000000. Which is start time of frame 0.
Line 2 of the v2 timecodes is 8.341667. Which is the ending time of frame 0, and the starting time of frame 1. Meaning frame 0 runs for a framelength of 8.3ms, which is the timelength of a 120fps frame.
Line 3 of the v2 timecodes is 41.708333. Which is the ending time of frame 1 and the starting time of frame 2. Showing us that frame 1 has a timelength of (41.7 - 8.3) 33.4 which is approximately the timelength of a 30fps frame.
And so on... The rest of the frames are 24fps and using the same math would only show the 120fps ones are 8.3ms and the 30fps ones are 33.3ms. The next 120fps frame would be represented by lines 3695-3696.

So we have the v1 timecodes now and they show us exactly what needs to be done in order to play the file as is. But we want the file to be CFR, and in this case since the rest of the stream is 24fps that should be the framerate we want everything to be. There is a peculiar pattern to notice about these timecodes. After every 120fps zone occurs (for 1 frame) a 30fps zone occurs in the frame immediately after it (for 1 frame). What happens if we add the timelength of a 120fps frame and the timelength of a 30fps frame (8.3 + 33.3)? It comes out to approximately 42ms, which is the timelength of a 24fps frame. Meaning we combine the 120fps frame and 30fps frame into a single 24fps frame in our AVS, to achieve our goals.

Step 3: Make AVS.

AVISource("VFRAC.lossless.avi",audio=false)
Trim(1,3692)+Trim(3694,14505)+Trim(14507,31769)+Trim(31771,33926)+Trim(33928,0)
AssumeFPS(24000,1001)

It probably would be preferable to blend the two together but I'm just dropping one of the frames (the 120fps one) in this example.

And we are done! With that simple trim statement the vfrac file is now a perfect 24fps representation of the original file. There is no desync, there are no corners cut, there is no guessing or assuming. If you don't use the timecodes....how would you know what to do at all? One would simply guess that its 24fps? Well that would be fine and dandy, and it would only have erroneously added five 24fps frames through the entire show (a total of 208ms by the time it starts getting to the ED). I suppose one might say that is bearable... but why do it the wrong way at all? All you need to do is use the timecodes, which tell us exactly what needs to be done.

Not too much work in this case. Although it is clear the capper is doing some strange things (when is 120fps not strange, lol). Saying this is a crappy raw is far from some kind of copout though... it is what it is...crappy :3. You just have to work around it, as shown. Though likely better raws could be chosen which do have Mentar's so called "clean" v1 timecodes...because the capper wasn't a complete imbecile in those cases.

Prove me wrong.

Impossible sample 2 from Mentar, some really fucked VFR mp4 file.
Original v2 timecodes.

Just like before we have a v2 timecodes file which is an exact representation of how to play every frame of the video...but for some reason my brain can't store 40k timelengths at once.

Step 1: Off to v1 land! Again in this case no special max_diff is needed.

tcConv.exe ffmpegtimecodes-mp4.txt ffmpegtimecodes-mp4_V1.txt 24000/1001 0.1

Step 2: I b analyzin, they hatin. This time, our v1 timecodes file sort of looks like a nightmare.

Spoiler for small excerpt:

# timecode format v1
Assume 23.976024
0,30,29.970030
35,1174,29.970030
1183,1312,29.970030
1321,1620,29.970030
1721,1735,29.970030
1760,1769,29.970030
1794,1798,29.970030
1859,1863,29.970030
1872,1881,29.970030
1910,1924,29.970030
1945,1949,29.970030
1954,1998,29.970030
2163,2207,29.970030
2216,2220,29.970030
2241,2585,29.970030
2594,2603,29.970030
2716,2720,29.970030
2723,2723,29.970031
2724,2724,19.980020
2725,2729,29.970030
2733,2733,29.970031
2735,2743,29.970030
2780,2784,29.970030
2787,2787,29.970031
2788,2788,19.980020
2790,2790,29.970031
2791,2791,19.980020
2793,2793,29.970031

However again, this is simply reinterpreting the information in the v2 file now displaying as ranges and framerates. The information is just as accurate (barring super high max_diff's which inherently cause errors) as the v2. This is what is going on in the file. It doesn't look clean in this case...again because THE FILE ITSELF ISN'T CLEAN. Crappy raws are crappy, need more be said?

The quickest solution would be to find a capper that actually knows what they are doing, which clearly this one doesn't. For some reason it seemed Mentar actually believed this raw was 24fps and the ED was 30fps. However looking at the timecodes that is clearly not the case. Even double checking with the v2 timecodes (as in sample 1) if one somehow thought they are magically different. You will find all the 30fps zones are full of frames with timelength of 33.3ms, these are not 24fps frames. The video source made by the capper is playing these frames at 30fps. That doesn't necessarily mean they are 30fps...but that is how he/she/it made it. Another reason why it is a good idea to judge your raws on more than just visual quality.

I actually had to ask Mentar for the source itself because he seemed so lolsure of himself. However I think he might have just mistook it for another raw and perhaps gave me the wrong one (one of the crappier ones, lol). This part is by no means in relation to turning the VFRAC to CFR, but I was just curious to see wtf is going on in this crappy source. You would need to have the video itself to see what the same. So after analyzing the video itself in relation to our humanly understandable v1 timecodes (what do you know they still have a purpose?!?!), I found that all the 24fps ranges (the assumed ones which are actually not listed) are only on pans or other scenes of "full motion". The rest of the source marked as 30fps were static scenes or the very end/beginning of a pan and included at least 1 duplicate. Meaning the capper left the entire source 30fps except for small sections of full motion. Not even full scenes mind you...must have been using some weird filter to only decimate during full motion. Sorry Mentar...this is not what I would call even a decent raw . I think the raw qualifies itself as complete shite and that is why it is fucked. You won't find any encoders who know what they are doing that would say otherwise....the raw is crap, you can't expect any hail mary out of it even with your "method". The capper is tripping ballz.

Back on track though. If there were absolutely no other raws available which were even relatively close to this madness in video/audio quality, one could still do the VFRAC->CFR. You would just have to painstakingly write all the conversions for the 30fps ranges.

Also there is another quirky pattern in these timecodes to note. Every 19fps range (which is only 1 frame) is always preceded by a 1 frame 30fps range. What is the sum of the timelengths of these 2 frames? (50 + 33.3) 83ms. Which is the timelength of two 24fps frames. Meaning these two small sections (a single 30fps frame followed by a single 19fps frame) would round off anyways as they are played at 24fps, and can be ignored from the v1 timecodes. So for all the other 30fps ranges, one would have to do the following.

Step 3: AVS

AVISource("VFRAC.lossless.avi",audio=false).AssumeFPS(30000,1001) #changefps needs to know the framerate beforehand, all the conversions are from 30fps
main = last
main.Trim(0,30).ChangeFPS(24000,1001)+main.Trim(31,34)+main.Trim(35,1174).ChangeFPS(24000,1001)+main.Trim(1175,1182)+main.Trim(1183,1312).ChangeFPS(24000,1001)+.....shitlong
AssumeFPS(24000,1001)

ChangeFPS is being used because the frames should always be in static areas so dropping them is fine, but ConvertFPS could be used instead to blend the frames together. Clearly this would take an immense amount of time to do by hand, although it could be scripted in some fashion with the v1 timecodes to output a trim statement, like above, for only the 29.970fps zones in timecodes. In a somewhat similar fashion to TheFluff's mad script. TheFluff's script also should work, however AviSynth will probably start killing itself with the huge trim statement his uses. Also his doesn't optimumly take care of those 30fps+19fps sections in ours which will just round out to 83ms in the end anyways. In his it simply drops one and duplicates the other, whereas it would be better if both were kept.

Also you could just start from the base source again with DSS and convertfps=true, which "should" still keep all your subs in sync. But then you'd be encoding from the source and not your already filtered vfrac lossless file/etc, so sort of cheating/meaningless.

The above shows how you would have to convert your VFRAC to CFR properly using the tools and not guessing as to what is in your source and leaving in errors. As Mentar suggested, maybe his method would be best for newbie encoders that are just learning and for everyone who never plans on doing it right in the first place. Because as he concedes the method is flawed in that it makes the rather large assumption that everything inside a segment are the same (the main part of the show, the OP. the ED). But if the job is to be done right, you have to use the timecodes. This 2nd sample here is an insane worst case scenario of a shitty raw. In no way would someone do that, but apparently Mentar thought it was impossible to come up with the solution because v1 timecodes are somehow flawed if they aren't "clean". There's no way to easily go from VFRAC to CFR with it, unless you have a quick script to handle it accordingly (or cheating with DSS convertfps). If you set that source to 24fps you'll be full of loads of non-synched audio/video :3. I have no idea how he thinks it can be done without using the timecodes.... since the framerate is changing so violently.

Prove me wrong, again <3. There is no such thing as "clean timecodes". They represent what is in the source, if the source is random shit made by the capper...the timecodes cannot be clean. They represent what is in the source, so if the source has randomly interweaving 30fps and 24fps ranges...wtf do you expect? Those ranges will then be in the v1 timecodes. I don't know how many ways/times it can be said. Tools + brain = profit.

tl;dr, don't use shitty raws.

[Mentar]

Nich, you clearly have too much time on your hands

Okay, I'll try to make this short and sweet. I commend you for at least reporting the factual results correctly, even though I disagree with almost all conclusions you draw. So I'll try to briefly point out where we agree and disagree, and then hopefully leave it at that.

What I reacted to was primarily this comment of yours:

Originally Posted by Nicholi

So all that really needs to be done is to use tcConv...some foresight...and not be an imbecile. And it will work for all situations.

Well, what you did in your last note was to inadvertently prove with amusing clarity that this was a vast exaggeration.

Let's look at my example 1: A 120fps avi which contains 24fps footage flat. Nicholi's output of v1 timecodes is the same I got, however, in MY opinion, such a v1 timecode file is NOT clean. Why? Because it requires you to INTERPRET the result, and you better pray that you make no accidental error with it. This is how a clean v1 timecode file should have looked:

# timecode format v1
Assume 23.976024

And that's it. It didn't. Sure, you can - as you put it - "use your brain" and try to reverse-engineer the results and conclude that "hey, this could have been 24fps flat", and then start to manually decimate some problem frames. This time, we have only 6 offending spots. But what happens when this brilliant "working for all situations" tool crashes and burns? You demonstrate that impressively in example 2:

Let's be honest here, shall we? Your approach just _fails_. As you wrote in your avisynth file for the second example:

Originally Posted by Nicholi

[...]
[...]+main.Trim(1183,1312).ChangeFPS(24000,1001)+.....s hitlong

In other words, you weren't even able to produce a proper CFR file at all. Pretty sad result for your "always working" tool, isn't it? But hell, one can always blame it on the capper ... which led you to delve into this dramatic tirade of yours:

Originally Posted by Nicholi

Not even full scenes mind you...must have been using some weird filter to only decimate during full motion. Sorry Mentar...this is not what I would call even a decent raw . I think the raw qualifies itself as complete shite and that is why it is fucked. You won't find any encoders who know what they are doing that would say otherwise....the raw is crap, you can't expect any hail mary out of it even with your "method". The capper is tripping ballz.

Well, I'm sorry to inform you that you're kinda mistaken. This very "shite" raw was used for the [SS-Eclipse] release of Zero no Tsukaima S3 episode 06. With my method. With ease. With the result being perfectly fine.

The encoder wasn't me, but I've just gotten his relevant files. I'll assume you know how to properly do the avisynth scripts to create the directshow(changefps=true)-based Files for 24fps and 30fps, so I'll omit those. Here's the timecode file...

Assume 23.976
31572,34211,29.97

... and the final combination file for the VFR MKV, including the cutting points.

a=main.trim(0,31571).assumefps(29.97)
b=AVISource("C:\Anime\ZnT\ED\Ep6\znt_ED_06_rendere d_30fps.avi").assumefps(29.97)
c=main.trim(33683,34045).assumefps(29.97)
a++b++c

My approach creates the CFR AVI implicitly, so it already exists, it's the filtered 24fps version.

So, your approach crashing and burning in flames by your own admission, and my approach resulting in a perfectly fine release you can download and watch... would you kindly adjust your sneering tone a little bit? Please?

************************************************** ************************

Now here's my summary how to interpret the factual results:

1) The Tritical tools do NOT always produce v1 timecodes you can use for double releases. Don't be disheartened if they don't.

2) Just because a raw fails on Tritical tools, it doesn't mean it's unusable. Rather, if you iron it flat via directshowsource(changefps=true), it will usually still yield some perfectly fine video. And you can normally still go VFR easy by using your eyes and the manual approach I outlined.

3) In our private talks, Nicholi criticized that my approach fails to properly deal with 30fps parts within the episode. I'll readily concede that he's correct in this aspect. Therefore, in an "improved" version, it would be advisable to run the Tritical tools to check for 30fps segments in my approach too, and to handle them the same way as the OP and ED. However, since this would have significantly complicated the already-difficult method I outlined, I didn't include it.

In conclusion: What we're having here is a little e-pen*s battle between a theoretician demanding exact results and rejecting material which doesn't reach the required standards (Nicholi) and a pragmatist who accepts to cut certain corners to reach decent results (me). In my opinion there is no such thing as a "right" or "wrong" position. I personally respect Nicholi alot, since among lots of other things, he was the main driving force behind developing the FreeVFR theory for Yatta, and he's definitely one of the leading experts in the VFR field. What I disagreed with was that he claimed that the theoretical-exact approach via Tritical tools "works in all situations". Because, in those cases I tried them (my "experience"), they failed for me. This is why I balked and disagreed.

Nowadays, I have more and more difficulties digging up excellent raws from the japanese p2ps. Therefore, we have to work with less-than-perfect raws often enough, whether we want it or not. And here - let's agree to disagree - I believe that my approach is more realistic and still leads to fine results.

[TheFluff]

Originally Posted by Mentar

1) The Tritical tools do NOT always produce v1 timecodes you can use for double releases.

in what way are the timecodes unusable?

[Mentar]

Originally Posted by TheFluff

in what way are the timecodes unusable?

Nich's example 2 with a 10k v1 timecode file wouldn't realistically be usable to create the
CFR avi via decimation. At least I wouldn't be willing to write a 100+ lines file full of trims and decimates. See the "shitlong" part of the avs.