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-09-16, 22:16   Link #221
martino
makes no files now
 
 
Join Date: May 2006
Why can't you just put the Xvid into MKV? What's the rocket science?
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2008-09-16, 22:37   Link #222
Kristen
Senior Member
*Author
 
 
Join Date: Jul 2007
Location: Virginia Tech
Quote:
Originally Posted by martino View Post
Why can't you just put the Xvid into MKV? What's the rocket science?
Doesn't burn onto a DVD and play in a DVD player, as far as I've heard.
__________________
Kristen is offline   Reply With Quote
Old 2008-09-17, 07:01   Link #223
comatose
Senior Member
 
Join Date: Dec 2007
Quote:
Originally Posted by Kristen View Post
It is? I thought that it was that the capper decided to keep all frames and smoothen the duplicates instead of dropping them. Well, we'll see what happens this week with Sekirei.
Don't you see the choppyness when watching it as 24 fps...?
And I might have told you (= Chihiro) this before

Quote:
Originally Posted by Yumi` View Post
e) make a vfrac lossless; encode the h264 directly from it; turn it on-the-fly ( dupli().selectevery(5) ) into a cfr input to encode your useless xvid-in-avi.
Thanks, some good stuff there
comatose is offline   Reply With Quote
Old 2008-09-17, 07:48   Link #224
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by Kristen View Post
I think that it is the entire episode that is in different frame rates. I looked at the timecode file (the one with lots and lots of numbers. I think this is v2?), and it has strange jumps in numbers at places throughout the entire thing.
This is one of the reasons why I'd strongly discourage using tools like these. Even if you feed a perfect CFR show into them, the resulting v1 turns into a jumble of crap (at least in those early days when I tested them when they popped up, and as far as I've heard, this fundamental problem hasn't changed). I'll never forget how perfect 29.97fps Elfen Lied footage produced a 200-liner v1 timecode file. Bah.

Realistically, I see two ways to do VFR:

1) The best one. You have a clean original source like DVD, BluRay or Transport Stream. Then you can use Yatta to properly mark VFR parts, and Yatta automatically generates the correct timecode files. Encode, mux and be happy.

2) The less-than-perfect one. You have a Non-CFR source of some kind. My recommendation: First, check the main footage of the episode if the animation is 23.976fps or 29.97fps (this will cover 99.999% of all cases unless the capper screwed up). Then, do a filtered CFR encode to lossless in Avisynth via directshowsource(convertfps=true) as base. Check OP and ED if they have differing framerates, and if they do, make seperate directshowsource(convertfps=true) encodes for them, aswell. And finally, write the timecode file manually. Yes, manually. Stop screaming, it's not so hard.

This is an example how it's done for a really nasty case: First, a 29.97fps OP, then 23.976fps episode, a 29.97fps ED and a 23.976 preview, like for example Rental Magica. We're going to do a dual release: Normal AVI for compatibility, and a VFR MKV release to be pretty.

First, make two Conversion scripts for 23.976 and 29.970 frames per second:

Quote:
Originally Posted by ConvertTo24.avs
directshowsource(fps=23.976,convertfps=true,"Raw.a vi")
Quote:
Originally Posted by ConvertTo30.avs
directshowsource(fps=29.970,convertfps=true,"Raw.a vi")
Load ConvertTo24.avs in vdub and write down the beginning/end cut points of OP/ED. Then add filtering, logos and Karaoke, and save the result as "OP-24fps-filtered.avi" lossless. Then, load ConvertTo30.avs and do the same - but you can omit writing down the cut points. They won't be needed later. Finally, load ConvertTo24.avs again and encode it _all_ to filtered lossless named "Episode-24fps-filtered.avi".

I recommend to keep the audio, since then you can make test encodes to check that the Karaoke is timed correctly (you can always work with "zeroed" Karaoke timing, which is useful, but sometimes you need to shift the kara 2-3 frames anyway).

Now it's time to "assemble" the parts we have. This is how it's done:

Quote:
op24 = Avisource("OP-24fps-filtered.avi") # OP cut out adjusted to 24fps for the AVI
op30 = Avisource("OP-30fps-filtered.avi") # OP cut out adjusted to 30fps for the VFR MKV
ep = Avisource("Episode-24fps-filtered.avi") # Reference episode encode in 24fps
ed24 = Avisource("ED-24fps-filtered.avi") # ED cut out adjusted to 24fps for the AVI
ed30 = Avisource("ED-30fps-filtered.avi") # ED cut out adjusted to 30fps for the VFR MKV
This would be the line for the CFR AVI:

Quote:
return op24.assumefps(23.976)\
+ ep.assumefps(23.976).trim(2500,31999)\ # the trim-numbers are the cut-points
+ ed24.assumefps(23,976)\
+ ep.assumefps(23.976).trim(34500,0) # the preview part
(You need the assumefps to make sure all video parts have the same framerate, or Avisynth will complain. It would be easier to add those in the Avisource-line directly, but it would have made things unreadable up there)

That's all you need for the AVI. Congrats, you're done. Now the VFR MKV on the same source:

Quote:
return op30.assumefps(23.976)\
+ ep.assumefps(23.976).trim(2500,31999)\ # the trim-numbers are the cut-points
+ ed30.assumefps(23,976)\
+ ep.assumefps(23.976).trim(34500,0) # the preview part
Just the same, only adjust op/ed24 to op/ed30. Not really hard, was it? Now all we need to do is write the timecode file manually, and we're done. To do that, we just need to open the VFR MKV script from above in Virtualdub and write down the _framenumbers_ of the cut points. The result will look like this:

Quote:
Assume 23.976
0,2449,29.97
32000,34499,29.97
Note that the cut points will be slightly different to the AVI version, because the OP and ED now have several extra frames (since they're 29.97 instead of 23.976). Therefore you MUST open and check the VFR MKV script and check there.

The result will be a 23.976 VFRAC video. Encode it any way you like, and then mux it with the manually written timecode file. Voila, CFR AVI and VFR MKV dual release!

Last edited by Mentar; 2008-09-17 at 13:49.
Mentar is offline   Reply With Quote
Old 2008-09-17, 08:28   Link #225
Kristen
Senior Member
*Author
 
 
Join Date: Jul 2007
Location: Virginia Tech
Quote:
Originally Posted by comatose View Post
Don't you see the choppyness when watching it as 24 fps...?
And I might have told you (= Chihiro) this before


Thanks, some good stuff there
I've been heavily not involved in the Sekirei project, and I really haven't watched it, so I haven't seen it.

Mentar: I guess it's worth a shot. I'll see what I can do. Well, later on. I'm going to pay with VFR first with two losslesses, and then I'll see how that works out.
And thanks! ^_^
__________________
Kristen is offline   Reply With Quote
Old 2008-09-17, 12:11   Link #226
edogawaconan
Hi
*Fansubber
 
 
Join Date: Aug 2006
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
before anyone says "VFR in xvid" again, VFR is not video-codec related. It totally depends on the container.

and AVI sucks since it can only do VFR as 120fps (or whatever the fpses' lowest common denominator) with dropped frames (or something). And there's always MP4 for SAP... (maybe)

asking "VFR in xvid" sounds as stupid as "MKV files are huge"
__________________
edogawaconan is offline   Reply With Quote
Old 2008-09-19, 01:24   Link #227
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by Meltingice View Post
Isn't that overly complicated? Say I have a 120 fps avi raw that has the timecodes:
Assume 23.976
0,2449,29.97
32000,34499,29.97
If you do it your way, you don't HAVE a timecode file yet. And if you feed a 120fps raw into timecode-extracting tools, you'll come up with total garbage. It would NEVER come up with a clean result like this. So that's a non-starter.

But okay, simply for the sake of discussion let's stipulate that a magical fairy drops "perfect cfr2tc" in our lap which cleanly creates a proper VFRAC video with a wonderful v1 timecode file like above. Then we're running into other kinds of difficulties:

Quote:
Wouldn't it be easier to do:
-Put 120 fps avi raw into cfr2tc => Output "VFRACRaw.avi" [Output is 29.97 fps]
-Then do avisource("Path\To\VFRACRaw.avi").FiltersHere().AF X().Hardsubs() => Output "VFRACRAW[Lossless].avi"
Okay so far...

Quote:
For CFR avi:
avisource("Path\To\VFRACRAW[Lossless].avi").AssumeFPS(23.976)
src=last
a=src.trim(0,2449).SelectEvery(5,0,1,2,3)
b=src.trim(2450,31999)
c=src.trim(32000,34499).SelectEvery(5,0,1,2,3)
d=src.trim(35000,0)
a+b+c+d
=> Output is CFR 23.976 encode
Fixable quibble: This would be a jerk generator. We've just turned 23.976 footage into 29.97, which means that we've inserted one duplicate in each cycle of 5 frames. Using SelectEvery() this way would blindly remove one frame out of each cycle, and this would most likely fail to hit the dupe. Use decimate() instead.

Quote:
For VFR mkv:
avisource("Path\To\VFRACRAW[Lossless].avi")
=> Output is CFR 29.97
-Mux in timecodes into mkv
Okay.

Quote:
With the above method, you don't have to encode 2 Openings, Main episode, 2 Endings.
That's no bug, it's a feature. If you want to go for hi-quality (and that's the main reason to go VFR), you NEED to encode OP/ED twice in different framerates, otherwise the karaoke will look bad! It would be the same as encoding one Karaoke at 29.97fps and then decimating it down to 23.976. For karaoke with moving effects, this becomes very very noticeable.

Other problems we have this way: Ever tried shifting Karaoke on VFRAC, especially on non-magical real-life cfr2tc output? You CAN do it via Aegisub, but it's relatively complicated if you want to do it properly. Also, your typesetter will curse you when he has to work with 29.97 workraws on a 23.976 source, ESPECIALLY if he's ASS-based instead of AFX. All moving signs will be completely fucked up in ASS, and much more annoying in AFX aswell, due to the constant duplicates. Therefore I'd strongly advise to ALWAYS base the workraw on the genuine framerate of the main episode, and that's usually 23.976

To sum it up: Yes, your approach generally does work. You will be able to create the files properly, but you lose quite a bit of quality in the process AND you make the life miserable for your typesetter. In my opinion it just doesn't add up. It's much easier to quickly encode 2 extra OP/ED versions.
Mentar is offline   Reply With Quote
Old 2008-09-19, 18:29   Link #228
Meltingice
Klipsch
 
 
Join Date: Oct 2007
Location: Frontier
Quote:
If you do it your way, you don't HAVE a timecode file yet. And if you feed a 120fps raw into timecode-extracting tools, you'll come up with total garbage. It would NEVER come up with a clean result like this. So that's a non-starter.

But okay, simply for the sake of discussion let's stipulate that a magical fairy drops "perfect cfr2tc" in our lap which cleanly creates a proper VFRAC video with a wonderful v1 timecode file like above. Then we're running into other kinds of difficulties:
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.

Quote:
Fixable quibble: This would be a jerk generator. We've just turned 23.976 footage into 29.97, which means that we've inserted one duplicate in each cycle of 5 frames. Using SelectEvery() this way would blindly remove one frame out of each cycle, and this would most likely fail to hit the dupe. Use decimate() instead.
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).AssumeFP S(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).Ass umeFPS(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)

Quote:
To sum it up: Yes, your approach generally does work. You will be able to create the files properly, but you lose quite a bit of quality in the process AND you make the life miserable for your typesetter. In my opinion it just doesn't add up. It's much easier to quickly encode 2 extra OP/ED versions.
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
For the typesetter, we can just make a 29.97 Workraw and give them the timecodes.

Last edited by Meltingice; 2008-09-19 at 20:39.
Meltingice is offline   Reply With Quote
Old 2008-09-19, 19:42   Link #229
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 41
Quote:
Originally Posted by neothe0ne View Post
What I meant is, a lot of h264 raws these days do this:

but the actual playback should be 29.97 fps. That's taken from the timecodes I got out of Shinsen-Raws's ZTC 21 mp4.
That would be because you are converting the timecodes (from v2 to v1) incorrectly, more eloquently known as Doing It Wrong. When you are converting from the v2 to v1 type timecodes rounding errors become VERY IMPORTANT, which is why the tcConv app (from tritical's package) specifically has a max_diff parameter. The tool works perfectly fine despite what Mentar says , you just need to know how to use it. You can get a "proper" v1 timecodes file from anything if you use a max_diff relative to "how VFR" the source is.
Nicholi is offline   Reply With Quote
Old 2008-09-19, 23:12   Link #230
edogawaconan
Hi
*Fansubber
 
 
Join Date: Aug 2006
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
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.
No it's not

Code:
# timecode format v1
Assume 29.970000
0,1445,59.940059
1446,1456,29.970029
1457,1457,23.976024
1458,1458,19.980020
1459,1459,23.976024
1460,1460,29.970029
1461,1461,23.976024
1462,1462,19.980020
1463,1464,23.976024
1465,1465,19.980020
1466,1466,23.976024
1467,1467,29.970029
1468,1468,23.976024
1469,1469,19.980020
1470,1470,23.976024
1471,1471,29.970029
1472,1472,23.976024
1473,1473,19.980020
<snip>
35000,35556,29.970029
35557,35557,23.976024
35558,35558,19.980020
35559,35559,23.976024
35560,37687,29.970029
# Total Frames:  37688
a 179 KB timecode file. Outputted by cfr2tc
__________________
edogawaconan is offline   Reply With Quote
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
Old 2008-09-20, 03:33   Link #232
Mentar
Banned
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 54
Quote:
Originally Posted by Nicholi View Post
That would be because you are converting the timecodes (from v2 to v1) incorrectly, more eloquently known as Doing It Wrong. When you are converting from the v2 to v1 type timecodes rounding errors become VERY IMPORTANT, which is why the tcConv app (from tritical's package) specifically has a max_diff parameter. The tool works perfectly fine despite what Mentar says , you just need to know how to use it. You can get a "proper" v1 timecodes file from anything if you use a max_diff relative to "how VFR" the source is.
Nich, in my experience, verified by extra tests this morning, this max_diff parameter can help cut the generated v1 timecode file from a few hundred lines to maybe 10-20 lines. A "proper" v1 timecode file to me has 3-4 lines, without interjected single-frames of 119.880115 and 29.970031. Here, precision hurts more than it helps. And just to make sure - of course, the result can be used. But "works perfectly fine" is a very misleading stretch imho.

The problem I have with the approach is more in general. This "one size fits all" kind of encoding everything with 29,97 and then decimating things down creates more quality loss (see my notes to Meltingice) and technical difficulties for other parties involved than an encoder should be willing to accept, IMHO.
Mentar is offline   Reply With Quote
Old 2008-09-20, 03:45   Link #233
Meltingice
Klipsch
 
 
Join Date: Oct 2007
Location: Frontier
Fair enough. I prefer fully softsubbed stuff, so I didn't think of hardsubbed things. Point taken.
Meltingice is offline   Reply With Quote
Old 2008-09-24, 09:10   Link #234
comatose
Senior Member
 
Join Date: Dec 2007
Quote:
Originally Posted by Kristen View Post
I've been heavily not involved in the Sekirei project, and I really haven't watched it, so I haven't seen it.^
You ought to smack your encoder for not paying attention :\
comatose is offline   Reply With Quote
Old 2008-09-25, 02:34   Link #235
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 41
Quote:
Originally Posted by Mentar View Post
Nich, in my experience, verified by extra tests this morning, this max_diff parameter can help cut the generated v1 timecode file from a few hundred lines to maybe 10-20 lines. A "proper" v1 timecode file to me has 3-4 lines, without interjected single-frames of 119.880115 and 29.970031. Here, precision hurts more than it helps. And just to make sure - of course, the result can be used. But "works perfectly fine" is a very misleading stretch imho.
The 120fps files were probably made with some whacked method of adding null frames. Use it on one of your own VFR files, you will see the output timecodes should be quite clean. Unless you are claiming to have made the 120fps files yourself, it doesn't say much. But I think you can agree 10 lines which are easily verifiable if they are b0rked is much better than a zillion lines and not knowing what is going on at all, or at best guessing where the framerates actually change. The tool works as intended, but garbage in = garbage out.

Just like with playback of files which are b0rked...you can't expect much if they don't follow the rules in the first place .
Nicholi is offline   Reply With Quote
Old 2008-09-25, 08:37   Link #236
comatose
Senior Member
 
Join Date: Dec 2007
Quote:
Originally Posted by edogawaconan View Post
No it's not
Delete all the single/two frame lines, change Assume to 23.976 and merge intersecting sections of the same FPS... they're just errors.
Or at least, I've never come across a source where they WEREN'T errors (removing a crapton of them has never hurt sync)

Code:
# timecode format v1
Assume 23.9760024
0,1445,59.940059
<snip>
35000,37687,29.970029
# Total Frames:  37688
(but that 59.94 fps section is probably 29.97 fps, so decimate 1-in-2 and change the line to 0,722,29.970029)
comatose is offline   Reply With Quote
Old 2008-09-25, 10:24   Link #237
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 41
Quote:
Originally Posted by edogawaconan View Post
No it's not

Code:
# timecode format v1
Assume 29.970000
0,1445,59.940059
1446,1456,29.970029
1457,1457,23.976024
1458,1458,19.980020
1459,1459,23.976024
1460,1460,29.970029
1461,1461,23.976024
1462,1462,19.980020
1463,1464,23.976024
1465,1465,19.980020
1466,1466,23.976024
1467,1467,29.970029
1468,1468,23.976024
1469,1469,19.980020
1470,1470,23.976024
1471,1471,29.970029
1472,1472,23.976024
1473,1473,19.980020
<snip>
35000,35556,29.970029
35557,35557,23.976024
35558,35558,19.980020
35559,35559,23.976024
35560,37687,29.970029
# Total Frames:  37688
a 179 KB timecode file. Outputted by cfr2tc
Clearly the max_diff parameter will work here (a little over 4 or so)...again you just have to use it. The 20fps sections will be grouped with the 24fps ones, and those random stated 30fps ones will be grouped with the Assume at the beginning. Voila, another case of magic solved by Doing It Right . This is a clear case where using the tools correctly will most definitely work, unlike the files Mentar found.

Also as comatose said, that 60fps section was most likely just a bobbed 30fps section. So decimating/selectevery it back down to 30fps would most likely be preferable.
Nicholi is offline   Reply With Quote
Old 2008-09-26, 12:11   Link #238
edogawaconan
Hi
*Fansubber
 
 
Join Date: Aug 2006
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
my point is to negate this statement.

Quote:
Originally Posted by Meltingice
After you verify that ti's 120 fps, dump it in cfr2tc and you'll likely get a very clean set of timecodes.
__________________
edogawaconan is offline   Reply With Quote
Old 2008-09-26, 13:55   Link #239
Meltingice
Klipsch
 
 
Join Date: Oct 2007
Location: Frontier
Quote:
Originally Posted by edogawaconan View Post
my point is to negate this statement.
If it was done even semi-properly, then it SHOULD have clean timecodes...
Meltingice is offline   Reply With Quote
Old 2008-09-26, 16:59   Link #240
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 41
Quote:
Originally Posted by edogawaconan View Post
my point is to negate this statement.
Quote:
Originally Posted by Meltingice
After you verify that ti's 120 fps, dump it in cfr2tc and you'll likely get a very clean set of timecodes.
Omg you can't use defaults . Concepts!

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 .
Nicholi is offline   Reply With Quote
Reply

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 18:38.


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