Losing sync after ALT-F to add effects

Well, time will tell who is right. I stand by what I said.

This problem has been there forever. And I reported it quite precisely and accurately many years ago.

To anyone who thinks it can be fixed without grouping clips, all I can is... Good luck.
 
I can get it to do something wrong now, but it's not what was originally reported. At the very least, Alt-F has a bug.

I had to add more clips before the problem looked like more than a subpixel display redraw error.

In my case with locked audio, the audio and video are both getting equally longer by a fraction of a frame for each transition added. Eventually this adds up.

Oddly, with unlocked audio it didn't happen which is odd, but I can imagine that a mix of locked and unlocked audio and multiple layers of audio tracks could produce the results you are seeing.
 
John Perkins said:
I can get it to do something wrong now, but it's not what was originally reported. At the very least, Alt-F has a bug.

I had to add more clips before the problem looked like more than a subpixel display redraw error.

In my case with locked audio, the audio and video are both getting equally longer by a fraction of a frame for each transition added. Eventually this adds up.

Oddly, with unlocked audio it didn't happen which is odd, but I can imagine that a mix of locked and unlocked audio and multiple layers of audio tracks could produce the results you are seeing.
Click to expand...

Could results vary, depending on just how one has settings configured, within SpeedEDIT settings within the PREFERENCES panel? If so, which settings, specifically, could impact the outcome on an Alt+F test scenario, with a bunch of video and audio clips in the timeline?

Too bad I emptied my project files from my system, for maintenance purposes; else, I'd quickly engage myself in testing...
 
Last edited:
I can see the default transition length having an impact if it is what I suspect, but that's pure speculation until I know how to fix it.
 
John Perkins said:
I can see the default transition length having an impact if it is what I suspect, but that's pure speculation until I know how to fix it.
Click to expand...
Ah. Now you've got me curious:
1. Would an even number of frames, vs. an odd number of frames, for the "default transition length" also have differing impact in your testing?
2. Might it be, that a project, with a certain number of clips with odd number of frames, verses a project with all even numbered frames could also have a different outcome?
3. If the answer to 2 is "quite possibly", then, would there be a different outcome with odd vs. even frames for audio clips *as well as* for video clips?

Here's hoping that all 3 scenarios above have no impact on sync timing in a project...
 
On my end, the audio, not the video is moving. Yes, I've placed the marker at the end prior to adding the effects. The video remains stationary, but the audio moves 15 frames left.

As far as preferences, I had the default effect length set to 1 second, but it has also produced the same result when it was set to 1/2 second.

I'm using insertion mode. I'm not sure what other settings might be relevant here.

Bear in mind, these project lengths are over an hour, sometimes two hours, with lots of cuts between two cameras (and therefore many fades). I don't know if the length of the project or the number of fades has an impact, but I thought I should point that out.

I should probably grab a screen shot sometime of a project that is impacted like this. But in the meantime, here's a crude representation of my timeline, using two tracks of audio, and one track of video consisting of alternating shots between two cameras.

V = Cam 1
v = Cam 2
A = Audio

- = no audio at that point on the track:

0:00. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:14:00:00
VvVvVvVvvvvvVVVVVvVVVVVvvvVVVVvVVVvv
AAAAAAAAAAAAA-----AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


Ok, assume that the right side of that timeline above is aligned perfectly for all three tracks (ASCII isn't letting me do it) :)

Notice the audio gap on the first track of audio. In this instance, when I add fades to my video track, the second portion of the track 1 audio will shift 15 frames left. The first portion of the audio track (and the second audio track) will not be affected. The video track will also not shift.


I hope that helps a bit visually.
 
Last edited:
I too had the same problem... and it was the audio moving, mine was a 2 hour long program with 4 cameras and hundreds (maybe thousands) of cuts. But on my project which was a dance recital I had each dance seperated so when I did the Alt-F it was easy to see that stuff had moved and it was easy to select all the audio and re-sync... granted I realized it was out of sync after I had burned a few DVDs of the final renders and had to go back to figure out what happened... and re-render the 75 videos and re-transcode the DVD...
 
"Alt+F" Can Do That? But How?

bbeanan said:
I too had the same problem...
Click to expand...
Hmmm. Is it possible Brett, that your problem manifested itself differently than did Travisr's issue?

He indicated that only the very last audio clip had a negative 15-frame offset after executing the ALT+F keyboard shortcut.

But on my project which was a dance recital I had each dance separated so when I did the Alt-F it was easy to see that stuff had moved and it was easy to select all the audio and re-sync...[/QUOTE]

So, if you can recall the pertinent details, Brett, in the above experience with Alt+F,

  • [*]how many audio clips, approximately, were shifted on the timeline, unexpectedly?
    [*]were those "shifted" audio clips part of an A/V file, or were they discrete (audio-only) clips, or did *both* types of audio clips get shifted?
    [*]which direction did those clips shift: left or right?
    [*]how many frames, approximately did those audio clips shift?
    [*]how did you have your SpeedEDIT (or VT-EDIT) Preferences set up?
    [*]can you, on a smaller scale, duplicate the "multiple audio clip shift" you encountered?
    [*]The "Inserted" Fade transitions are only for video, and not causing any audio fades, correct?


TTBOMK, JPerkins hasn't found a recent bug report (providing step-by-step details to help him duplicate your experience with Alt+F shortcut), posted on this issue, still.

If anyone can help, here's NewTek's Fogbugz site: https://secure.newtek.com/FogBugz/default.asp?pg=pgEditBug&command=new
 
Last edited:
I'm reasonably sure I fixed it, but I don't have any new workaround.

When the transitions are added, it works in sets of three. Clip A-Trans-Clip B.

Clip A in point doesn't change. Clip A length is extended by half the length of the transition.
Clip B in point changes by the negative length of the extension and the clip duration extended to match. Clip B out should end up in exactly the same place it started.
Transition is added across the newly overlapped clips.

There was a rounding error in the extension length and thus clip B in point placement which could go either way, up or down and due to an implied ripple between groups of three as the timeline verified the validity of itself it would become additive, making the error progressively more obvious. If not for the ripple it would have left tiny gaps or overlaps.

So, I can't guarantee that this will fix every instance of audio sync changes, but at least in cases where transitions are added I think it's working.

I can't repeat it any more on a 3 hour project and I could repeat it fairly easily with short projects before.

The beta guys will have to pound on it and let me know.

Thanks,
 
bbeanan said:
I too had the same problem... and it was the audio moving, mine was a 2 hour long program with 4 cameras and hundreds (maybe thousands) of cuts. But on my project which was a dance recital I had each dance seperated so when I did the Alt-F it was easy to see that stuff had moved and it was easy to select all the audio and re-sync... granted I realized it was out of sync after I had burned a few DVDs of the final renders and had to go back to figure out what happened... and re-render the 75 videos and re-transcode the DVD...
Click to expand...

Some of the ones we encountered were from editing dance recitals too.
 
John Perkins said:
I'm reasonably sure I fixed it, but I don't have any new workaround.

When the transitions are added, it works in sets of three. Clip A-Trans-Clip B.
Click to expand...


It sounds to me like there are multiple bugs then, because I'm seeing my audio track shift, not the video track. The video track starts and ends at the exact same location after using ALT-F.
 
travisr said:
It sounds to me like there are multiple bugs then, because I'm seeing my audio track shift, not the video track. The video track starts and ends at the exact same location after using ALT-F.
Click to expand...

Travisr, could you kindly give us greater detail, regarding your Preferences settings under the SpeedEDIT category? You've indicared "Insertion" mode (Is that for TIMELINE setting?), but citing that alone may not be enough detail of your PREFERENCES arrangement, to help others duplicate the outcome you're experiencing.

So, here are some queries for you, some of which may not relate to the -15 frame offset on the last audio clip), if you don't mind enlightening us on these
  • Which OS is your VT[5] running on?
  • Which specific version of VT are you running?
  • Your Host PC System is using which CPU (I'm just curious)?
  • If your proc is multi-core, are you using all of them, or fewer?
  • Is the "INSERTION" mode setting under SpeedEDIT PREFERENCES for both "Storyboard *and* "Timeline" interfaces? If not, which one?

Assuming we're not completely out of the woods, just yet (in light of Travisr's expressed concern), this has turned out to be an intriguing, yet profitable thread, hasn't it Eugene?

Thanks a million, Travisr, for your patient and revealing interaction with us, and John Perkins, for your speedy and amazingly constructive response to the Email on this. What a moment, in VT Editing history.
:boogiedow
 
Last edited:
Quiet1onTheSet said:
Travisr, could you kindly give us greater detail, regarding your Preferences settings under the SpeedEDIT category? "Insertion" mode alone, as you've indicated, my not be enough detail, to help others duplicate the outcome you're experiencing.

Also, specifically,
  • Which OS is your VT[5] running on?
  • Which specific version of VT are you running?
  • Your Host PC System is using which CPU (I'm just curious)?
  • If your proc is multi-core, are you using all of them, or fewer?

Assuming we're not completely out of the woods, just yet (in light of Travisr's expressed concern), this has turned out to be an intriguing, yet profitable thread, hasn't it Eugene?

Thanks a million, JPerkins, for your speedy response on this. What a moment, in VT Editing history.
:boogiedow
Click to expand...

I'll tell you what I know off hand. My system is encoding right now, and I don't want to mess with it.

I'm running VT[4], the most recent version (I think it's 4.6).

I'm using Windows XP.

I'm not sure of the CPU or processors.

I'm not using ripple editing.
 

  • [*]Which OS is your VT[5] running on? Answer: Win XP Pro
    [*]Which specific version of VT are you running? Answer: VT[4] ver. 4.6, Build 6016 possibly

    Remaining Queries:
    [*]Your Host PC System is using which CPU (I'm just curious)?
    [*]If your proc is multi-core, are you using all of them, or fewer?
    [*]Is the "INSERTION" mode setting you've selected under SpeedEDIT PREFERENCES for both "Storyboard *and* "Timeline" interfaces?
    [*]If not, which one?


Noteworthy, Travisr, is your use of VT[4] ver 4.6 (build 6016 probably), as that's likely a core reason for your results which likely can't be duplicated by someone using VT[5], as John Perkins, I'll assume is, and that, perhaps, on an 8-core machine, if he's as cool as I suspect he is.
:cool:


This case is a classic example of that which illustrates just how critical it is, for folks to file bug reports to NewTek's Fogbugz site with complete and detailed info, not only about how to duplicate the problem they're citing (with the expected result, vs. the result they got).

But also, they need to give the engineers at NewTek, a decent understanding of just what hard/software versions are being used, which OS they're running, what configuration their system is in; (Antivirus programs installed?), yada, yada, yada...[/B]

Else, years could go by, and a particular bug is erroneously deemed "a limitation within the software", and is passed off as unfixable due to incorrect assumptions on the part of end-users, and indeed, the matter doesn't get fixed -- for *years*.

Again, I'd *love* to have seen Scorp's bug reports on this baby. I want to believe his was thorough enough, but who knows? But as for resurrecting those after all this time -- they're likely buried beneath requests for making ToasterCG "custom text-positioning" behave!

:D
 
Last edited:
The problem I had is the one that Travisr described, not what John described.

It was not a problem that got incrementally worse, it was a 15 frame audio shift every time, from the first time to the last.

Though I do think I've encountered what John described as well, resulting in the little triangle arrows implying that I had a clip overlapping something when I didn't intentionally.
 
ScorpioProd said:
The problem I had is the one that Travisr described...
Click to expand...

Ah. Just like his, eh? Well -- we've finally got collaboration between 2 users for -15 frame audio offset with Alt+F in this thread.

'Wonder what underlying, key software version and system hardware similarities exist betwixt the two...

:rolleyes:
 
ScorpioProd said:
Anyone who thinks this is a new problem must not have done this type of editing with this software before.
Click to expand...
Perhaps John P. missed it earlier, not having seen the bug reports on it or perhaps, for the reason you cite above, ScorpioProd.

On the other hand, it's possible some missed the problem's presence, until it was too late, as was clearly the case with BBeanan (reference post #29 above). I don't think anyone in this thread indicated they thought the problem was new, however.

I've seen forms of this problem many times when I used to cut on VT[4], but couldn't get useful help in the forums, in my attempts to get my brain around just what was going on, because, invariably, the shifting clip issue with Alt+F was treated by more than a few, as though it wasn't a bug, although my "ignorant sensibilities" suggested otherwise.
:D

Q1
 
Last edited:
You must log in or register to reply here.
Back
Top