You are not completely understanding time remapping and your slider. If you cange or animate the slider value the video will speed up or slow down depending on where the keyframes are and it will not behave in a way where you could have video running at 50% speed and then gradually speed it up to 100% or gradually slow it down to a still frame by animating a slider.
Please tell us what you are trying to achieve. Pre-composing, sequenced layers, or video, time remapping always works exactly the same way. It sets the current frame at the time value given it. Not the frame value, the time value. Without knowing what you are trying to do I can't point you to the right solution.
1 person found this helpful
Ah, I am not trying to change the speed of the precomp. I am simply using time-remapping to allow me to choose which frame to display of the precomp.
Sorry, my example with the Slider was unnecessary. This problem persists without the use of a slider or even expressions. The reason I mention it is because it presented me with a solution to the problem (by adding a half-frame).
In this case, I am animating a character's face. The sequence is a series of mouth positions, imported from an AI file. I am animating the mouth by adding hold keyframes, either indirectly using a slider on a null layer, or directly using time-remapping on the precomp itself.
In both cases the result is inconsistent; I add a keyframe for frame 2, and the precomp displays the artwork for frame 3. Not all the time, but sometimes. And sometimes it's not a problem with previews inside the GUI, but is a problem in the final render, or vice-versa. It is not a matter of my mis-use of time-remapping. This is a bug, and has been present since CS6, and not before.
When I talk about the conversion between "frames" and "time", I am talking about the fact that AE is seconds-based (or some other term that means the same thing), not frame-based. So if you want to deal with frames, you have to convert frames to time values. In this case I am doing that by multiplying an integer by the duration of a frame in seconds.
There's nothing wrong other than your expression:
refers to the footage item in the project window, not the layers as they are used in your (pre-) comp. Naturally, if there is a framerate mismatch somewhere or you already have offset stuff in the nested comp, the reference to the original, unmangled source will yield a result that does not align with your comp time. I'm not arguing that there may be otehr issues with the crappy cache system introduced in CS6, but treally, you should start by fixing/ hardening your expression first.
Try this for your expression:
sv = Math.floor(effect("Slider Control")("Slider"));
tc = thisComp.frameDuration;
Now, as long as the pre-comp frame rate matches the nested comp frame rate you can easily go from one of your mouth positions. 4 on the slider to 4.99 will give you frame 4 of the pre-comp. For this to work your pre-comp and your comp must have the same frame rate.
I'm not sure that entering keyframes for the slider is any easier or faster than simply typing numbers into the Time Remapping field but this will give you the results you are looking for.
When I do this kind of thing I usually take the audio track into Premiere Pro, select the metadata panel, analyze the audio, and then bring the audio into AE. This puts markers on the audio track for each word with the word clearly visible in the audio track. You can then precisely drop in your phoneme keyframes by simply reading the track and entering the correct values. If you have an accurate text file of the audio track the accuracy of speech analysis in Premiere Pro is amazing. This will give you something like this to work with in your timeline. For me it cuts editing time by about 60%.
Here's a tutorial on Speach Analysis in Premiere Pro. It will save you a lot of time.
Sorry guys, I think I have done a poor job explaining this bug. It has nothing to do with lip sync, or expressions.
Mylenium seems to express some knowledge of the problem - that being the image caching feature introduced in CS6. I did notice *less* of these problems with CC. So it means that Adobe is aware of it and trying to fix it. But I think something remains unstable in there.
When I considered the upgrade to CS6, I did a number of tests -- rendering out lots of our old work, to see if anything didn't render correctly. And wow, was that something. Most renders showed some kind of glitch -- all in our layer sequences (eyes, eyebrows, mouths, anything time-remapped basically).
With CC, I did the same test, and the renders were all perfect, as they were in CS5.5. So I figured they must have fixed the problem, and they did to a large extent.
But now after using CC for a few weeks, I am seeing these problems crop up again.
AE has no problem with 'image sequences', that is, a series of still images files, which are treated by AE as actual footage. It seems to have issue with the sequencing of layers in a sequence, that is taking 20 layers, and using Keyframe Assistant - Sequence Layers. I think this is because of the way AE treats Comps differently from Footage. Footage is composed of discrete frames, with nothing inbetween each frame. Comps however are treated with floating-point time. Which is great when you *want* to 'slow down' a Comp, because it can do so smoothly. But when that Comp contains a layer sequence, I think this floating-point time makes AE confused, because the Comp doesn't contain nice, infinitely-scalable interpolated keyframe animation, but instead discrete pieces of artwork with no interpolation possible. My solution to this problem -- and it works -- is to add a 'half-frame' to the calcuation. This I think reduces the likelyhood of incorrect math going on with the image cache, because it's less likely to 'round down' to the previous frame.
I seem to remember a bug where the out point of a layer was not precise so when you sequenced layers you ended up with layers that did not line up with the frames of the composition. As far as I know that bug was fixed long ago.
The sc = Math.floor(effect("Slider Control")("Slider")); function changes 4.3 or 4.9 to 1 so you are always dealing with full frames. You could just as easily use Math.round but the frame values would switch to the next digit at .5. I only added this value so that you could use the slider and set the range between 1 and 20 to reveal those frames without having to carefully go in and exactly position the numbers or click and type on the frame number.
I cannot recreate your bug. Create 21 layers, set each layer to 1 frame, sequence layers, pre-compose, and use the expression that I gave you to time remap the pre-comp. The frames line up perfectly every time. One thing that I forgot to mention before is that when yousequence layers and nest them, it's important to turn on Preserve Frame Rate when nested in the Advanced Tab of the Composition Settings. Turn that off and you'll get slightly different interpretation of the frames than you would get if you rendered the pre-comp and replaced it in the main comp with the render.
I would love to see a short project, just a 20 layer file set up the way you are describing where frame 10 on the slider was not frame layer 10 or where a transition between frame 2 and frame 30 did not provide a single frame transition between the frames using my system.
Here's a sample project that demonstrates the technique and shows no blended or out of sequence frames. Just run the render cue and put the render on your desktop to view the differences between footage and a nested comp with sequenced layers.
I'm trying to make an AEP that consistently has this problem but I'm having trouble. Will keep trying.
In the meantime, is there any known way to force-disable the use of the new image cache system?
OK, I have successfully narrowed it down to a simple comp. I made two comps in here, one which is simply using time-remapping directly, the other which is abstracting it with a slider. Both have the same problem at the same place.
Scroll through the animation frame by frame. On my machine, at frame 77 it shows the number 2, when i have chosen frame 3. You may see a problem elsewhere, or nowhere. Flushing the cache sometimes makes things change around, restarting AE, etc.
I will mention that I have only tested this on Mac OS. So if you are on Windows, I am not sure you will have the same issue.
And, if there is some way to disable the cache, even if it means very slow performance, I would be interested to know it.
I have confirmed the same problem on my Windows 8 machine at home, running the same version of AE (220.127.116.114).
Also, I don't even have to use time-remapping to see this bug. If I'm inside the comp that contains the image sequence (called 'numbers sequence'), I see the artwork for frame 3 while the playhead is at frame 2.
Try going to the advanced tab in your nested numbers comp and selecting Preserve Frame Rate when Nested, purge your caches, turn off disk cache, clean Database and Cache in the Preferences > Media and Disk Cache section and give it a try. I can't find any frames where the number displayed does not match the number of the last keyframe entered.
Without Preserve Frame Rate When Nested checked occasionally I see a problem.
Was not aware of the 'preserve frame rate' option. Interesting. However, doing all these things, I still see the artwork for frame 3 while the playhead is at frame 2. I've never seen this problem so consistently before. If I solo the layer for frame 2, i can see the '2'. If I turn off solo, i see '3'.
As soon as I move or edit the '2' artwork in any way, I can see it it as '2'. But if I Undo that change, it goes back to '3'. Crazy!
Preserve Frame Rate When Nested has fixed all my problems.
Not sure why I'm still seeing weird stuff in that test comp, but in all the other projects I was testing, it is now working without any glitches.
I do still consider this a bug, though- - because this was not happening before CS6.
I hit this bug all the time, including today (in CC OS X). Trying preserve frame rate -- although all my comps are 23.976. Maybe this is related to drop-frame?
The solution of checking "preserve frame rate" and clearing cache did work.
There is absolutely no difference in the footage if you select drop frame or non-drop frame time code. Drop Frame time code counts in real time, Non Drop Frame Time Code does not, but the frames don't change, the playback time does not change, the footage does not change, the only thing that changes is the timer counter display. Drop Frame time code was invented so that the time code on the video matches the clock on the wall so the folks in Master Control would know when to do the station breaks by reading the timecode....
I am having the exact same issue when using this technique to animate a characters mouth! I've found a few work arounds although these seem as temperamental and inconsistent as the issue itself.
My best sucsesses has been with turning motion blue on and off the problem layers. For some reason this seems to wake AE up for a second and realise it's some how referencing the wrong layer. And as the mouths don't move in the comp the the motion blur doesn't really effect the end product. Like I said though this hasn't always worked. (I've have had similar success by putting the layer in 3D space)
Preserving frame rate and purging the cashe hasn't worked for me. Although I realise now that the last post on here was a couple of years ago. Does anyone have a better soloution now?
I'm using AE CC 18.104.22.168