What's weird is this doesn't always happen. If I start a new project, import some AVI files, start moving things around (using cut and paste or dragging), then all of a sudden I will try to move the end point of an event and the audio doesn't move with the video. However, other events still work fine, meaning, I can click and drag the end of a video event, and the audio endpoint will follow the video (as it should by default). I feel I'm doing something wrong causing this to start happening on some events.

Ron

Ron-
I understand what you are saying. I have run into this problem too and like you, I feel that it is something I am doing because it doesn't always happen. When it does happen, I thought maybe I could just "group" the audio and video tracks back together, but I haven't been able to figure out how to do that yet. I thought I followed the instructions from the manual, but it never works for me. I hope someone can give us a better explanation on how to handle these situations.

Click on the video part of the event to select it. Shift-click on the audio part to add it to the selection. Press G to group them.

If you later wish to ungroup, click on either part of the event and press U.

Hi Chienworks.

Thanks for the suggestion. I'll give that a try tonight. So, if grouping these together as you described fixes my problem, do you have any idea on how they could have become ungrouped? Is there a single keystroke on the keyboard I might be pressing accidentally to ungroup a selected event? If so, maybe that's what I'm doing.

Thanks,
Ron

Ron, is it possible you might be hitting the U key when you have the event selected? That would ungroup the audio from the video.

Chienworks,

I usually don't press any keys on the keyboard except the ALT, CTRL, Space Bar, and Enter keys. But, I'll try grouping them together the next time this happens in case I did hit U.

Also, I posted this question at Creativecow.net where a couple other people have seen this same behavior. One person responded that in happens after they cut and paste, which I do too. They claimed that closing and re-opening the VEG file brings things back to normal. I'll try that the next time it happens too.

Thanks,
Ron

even in a group, changing the length of an event won't always change the rest in the group. only if the event edges of other members of the group are aligned exactly with the one you are dragging will that happen.

it's easy to tell if this is what's happening, because when you cross that point while dragging, (the point where the event edges would be perfectly aligned), the other events will be 'grabbed' and if you continue to drag in that direction, the other event(s) lengths will change with the one you are dragging. then when you let go, the events' edges will be aligned, and next time you drag the event edge the other events will follow right away. this is a quick way to 'regroup' the event edges.

maybe something is happening when you cut/paste where the event edges get unlocked, but the grouping information is still intact. I personally haven't seen this problem, but if you are sure that:

A - the events are grouped and haven't been ungrouped (verify by selecting one event and hitting SHIFT+G and all other members of the group will be selected)
B - the edges are lined up perfectly (zoom in real tight and place the cursor on the edge of one event, then look at the other event edges)

and you are still having this problem, then maybe it's a grouping bug. otherwise it may be normal VV behavior.

if you want to see a REALLY annoying problem with grouping... see this web page. I sure wish they addressed it in VV3: http://ben.orona.com/split/splitting_headache.htm

if anyone knows a fix... I'm listening.

- ben (cheesehole!)

ben,

I took a lot at your example and am a little puzzled by your puzzlement. The events you described sound *exactly* they way I would expect them to behave.

I admit that event grouping may seem a little confusing at first, but once you understand the concepts, it's very easy to understand.

I'll try to explain some of the basics.

The first thing to remember is that every event can only belong to one group. When you drag an audio/video event to the timeline, they are automatically grouped together. If you attach it to another group of events, they immediately loose their association with each other since they now belong to the larger group (remember they can only belong to one group).

When you ungroup events, they are broken up into their elementary elements. If you want to remove an audio/video event from a larger group, just select the audio/video event and "group" them again. That will remove them from the larger group since they can only belong to one group.

Now here is where it gets a little weird. If you split a group of events, then the events immediately to the right of the split are expelled from the group and placed in their own separate group. So the events to the left of the split are still part of the same group and will move with any other events on the timeline that are part of that group. This explains the behavior that you are seeing in your example. To fix it, just group the elements to the right of the cursor so that they are in their own group.

I'm not sure how SF could make this easier. Perhaps they could have named groups so that an element could belong to more than one group. That way an audio/video event that is attached to a larger group could still be grouped to each other. Then again, maybe that would make things more complicated. How would you name all of the groups that could be created?

Also note that you do not have to group events in order to move them together. Just selecting events is good enough to move them as a group. One common method of selecting events is to right-click and select "Select Events to end". This will let you do editing near the beginning of your project and move the tail end as a group.

BTW, I'm using VF but I'm fairly sure Vegas handles grouping the same way.

Ben (cheesehole),

Thanks for the info. I believe you are on the right track about the end point edges not being aligned. But, it's not because of a cut or paste. It's because of the video clip video and audio properties. I notice in the Explorer tab in VV, when I select a video clip I captured using VV Capture, the properties of the file show the video is a bit shorter in length than the audio. For example:

Video: 00:00:29:730
Audio: 00:00:29:830

If I were to drag a video clip with the above properties into a new project, the end points of the clip in my timeline would not match. Therefore, when I grab the video end point of the clip to shorten it, the audio will not move. Interestingly, if I grab and move the audio part of the clip shorter to line up with the video part, then begin moving the video part, they will stay 'hooked' together all the time.

Also, for some reason, VV3, SoundForge 5, and Cakewalk Sonar 1.31 show the audio properties of my video clips to be 32K instead of 44.1K. My Canon XL1s cameras are configured to capture at 44.1K, so I'm not sure if VV Capture is capturing wrong or the Canons don't sent out correctly. At one time I had another capture program that correctly captured audio at 44.1K from these cameras. I heard from other VV3 users that the 32K audio setting was an issue and would be addressed in an update of VV Capture.

Here my my config:

Windows XP Pro with all updates from Microsoft.
Dell 4300 1.6Ghz with 512MB RAM and 2 - 100Gb hard drives.
VV 3.0a
Canon XL1s DV camdorder

Ron

jimcho - thanks for the clear explanation. (See below)

>Now here is where it gets a little weird. If you split a group of events, then the events immediately to the right of the split are expelled from the group and placed in their own separate group.

well said. that's exactly what annoys me. I want the events before the 'split' in one group, and the events after the 'split' in the second group. VV already creates two groups when you split a group, but it makes no sense to split them in the way it does. choosing to consider the first two 'events' after the split as a basis for a second group is completely arbitrary. no one has given me an explanation as to when this would be useful. when I group events I expect them to be treated as a unit. that's the whole point of grouping. if I split an event, I get two new events, separated at the cursor. that is what I want when I split a group. two new groups, separated at the cursor.

>To fix it, just group the elements to the right of the cursor so that they are in their own group.
Yeah, after doing that a hundred times over a 4 hour edit session it doesn't sound so easy.

>I'm not sure how SF could make this easier.
they could implement my method, which makes more sense (to me anyway :)

>One common method of selecting events is to right-click and select "Select Events to end". This will let you do editing near the beginning of your project and move the tail end as a group.

good advice, but it gets tedious. I consider this problem to be a bottleneck in the editing process. I've started pre-rendering the tracks as one event to avoid the 'splitting headache' completely, but it would be nice if I didn't have to.

ben,

I would agree with you regarding the splitting behavior of groups. It would make more sense to expel all of the elements to the right of the cursor into their own group instead of just the ones involved in the split.

I wonder what the reasoning is for the current behavior?

I tried the Scenalyzer (www.scenalyzer.com) demo once before and remembered it was the other capture software I tried that correctly showed my captured clips using 44.1k audio. I'm going to try it again and see if it still works. VV3 Capture has always showed the audio portion of my video clips to be 32K. Maybe that's what's throwing my end points off. Anyway, I'll know more tomorrow.

Ron

why aren't you recording at 48kHz?

My choices for recording audio on the XL1s are either 12bit or 16bit audio. In 16bit, I believe the audio is at 44.1K. Maybe I'm wrong and it is at 48K. Anyhow, the only thing I can set on the XL1s for audio is 12 or 16 bit. I know my two cameras are setup for 16bit, so it should be sending either 44.1K or 48K (whichever it really uses), but VV Capture captures it at 32K for some reason. I never got a chance to test out Scenalyzer last night, but will try again tonight.

Ron

I believe this is part of the DV spec. you can choose between two settings.

16bit 48kHz (one stereo channel)
or
12bit 32kHz (two stereo channels)

I wonder why on the detail session of file properties on clips cature by VV is showing PCM,32,000 Hz, 16 Bit, Stereo on my Canon ZR20. I was expecting PCM,48,00 Hz, 16 bit how can that be?

I'm not sure why that is happening. I'm using a Cannon GL-1 and I just verified that captured clips show up in VV3.0a capture as 48kHz 16-bit stereo.

I thought that I had the problem fixed on one tape I was able to capture 48kHz 16 bit stereo but when I tried to repeat the feat the capture went back to 32kHz 16 bit stereo. 32kHz 16 bit stereo is not supposed to available on the Canon ZR camcorders are we sure that anyone have not seen this to happen?