Surround Sound Bug in Vegas 8

Mark Seibert wrote on 2/12/2008, 10:42 AM
Hey All,

I'm stuck, and Sony is being rather unhelpful. I have several projects that I'm tyring to work with Surround Sound, and I'm getting some really strange behaviors. I've sent examples to Sony tech Support and here's the short answer from them:

" I can see that, in the project you uploaded, the surround panner does not work properly on the second event. Making changes within this project produces mixed results.

Since the surround panner works flawlessly in other projects, this is not a bug. There is an issue with the project you have uploaded. If you are reproducing the issue in other projects, then there is clearly a workflow issue, probably in keyframing the surround panner."

They go on to suggest that I dump ALL of my work and start over...which is unthinkable. I've got 40+ tracks on some of these projects, and hundreds of hours invested. Besides, what's to say this won't just happen again.

AND this is crazy - yes, my workflow might be revealing this bug, but to suggest it's not a bug because it my workflow is nuts! Has anyone else been seeing problems with Surround Sound? Clearly I've found a bug that they really don't feel is worth their time to fix, but if enough people report this problem it might get their attention.

Comments

pwppch wrote on 2/12/2008, 10:59 AM
Is this the same issue as you posted here:

Need help with Surround Sound

or is it something different?

Peter
R0cky wrote on 2/12/2008, 12:29 PM
Peter, I too have problems with surround panning. It just doesn't work right. I have a support ticket open 071015-000085 with a description of the symptoms.

I uploaded to your ftp site a very simple project with media that demos the issue.

thanks for your help,
Rocky
Mark Seibert wrote on 2/12/2008, 12:41 PM
Yep - Same issue, except there is more information now. In short, Sony has confirmed that the bug exists, but has pretty much told me they're not going to fix it. I assume that if there are enough people that experience this problem and complain, they might reconsider. In other words...the squeeky wheel...
R0cky wrote on 2/12/2008, 3:46 PM
Surround sound panning is broken and not going to be fixed? And this is supposed to be a serious tool for sound for video? Those HD features are going to be really professional with stereo sound.
R0cky wrote on 2/12/2008, 3:46 PM
Surround sound panning is broken and not going to be fixed? And this is supposed to be a serious tool for sound for video? Those HD features are going to be really professional with stereo sound.
pwppch wrote on 2/12/2008, 5:45 PM
Who exactly told you that it was not going to be addressed?

Regardless, I am trying to help. You can offer me additional information, or I will base my investigation on what you provided to my question.

Peter
Mark Seibert wrote on 2/12/2008, 8:30 PM
I have a tech support item open, and have received no communitions from the tech support people for over a week. My last response from them indicated that they recognized this as a bug, but that they could not reproduce it. They suggested I dump ALL of my work and start over, as this is probably a problem that is cause by my "work flow." Well, that's not really a resonable solution when I have hundreds of hours into multiple projects. If I start over, what's to say this will won't just happen again. And there was no indication that this is being looked into...
pwppch wrote on 2/12/2008, 11:38 PM
So was it that somebody explicitly told you that it would not be addressed or that nobody told you explicity that it would be addressed?

Again, makes no difference. I am trying to help. I am not part of tech support. Before I can try and fix the problem I need to know what the problem is.

Peter

Mark Seibert wrote on 2/13/2008, 6:13 AM
Here's a copy and pasted quote from Tech Support:

"Thanks for replying. I can certainly your desire to work efficiently within the software. However, try as I may, I have been unable to reproduce the issue that you are seeing in a different project. I can see that, in the project you uploaded, the surround panner does not work properly on the second event. Making changes within this project produces mixed results.

Since the surround panner works flawlessly in other projects, this is not a bug."

Essentially they are saying that this bug, is not a bug. I know we don't handle software testing like that in the game industry. I have a test case that I given them and they've even agreed that it is failing in that test case...in my industry, that's a bug. Given this response - "This is not a bug," I can only assume they are not going to do anything about it.
R0cky wrote on 2/13/2008, 9:05 AM
Peter, make sure to see my post earlier in this thread. My support case includes a *.veg and media. I can reproduce this in any project. This is on a special partition with a clean, new install of XP with updates and only audio/video editing apps which is mostly Sony products and a few 3rd party plugins including Ozone, Pixelan, and waves.

The sample project I uploaded to your ftp site has zero fx, it is only a sine wave with surround panning.

thanks very much,
Rocky
pwppch wrote on 2/13/2008, 9:42 AM
Mark,

Please understand that your experiance, interpretations, frustration, and general opinion of us does not help me to help you.

I had hoped we could get past what you have gone through to date and and focus on resolving your problem.

If there is a bug I want to identify it and get it fixed.

If you want to persue this further, please email me SonyPCH.

I leave it to you.

Thanks
Peter
Mark Seibert wrote on 2/13/2008, 11:00 AM
Hi Peter,

I have posted this here in the hopes that someone will take notice and maybe try to get this on the list of things to be fixed in future versions since I was unsuccessful using the tech support channels. I am not trying to rant, or vent. If I have done anything to make you feel that way, I publically apologize for the misunderstanding. I will be happy to contact you directly to see if there is anything I can do to help get this fixed.
jbolley wrote on 2/13/2008, 11:14 AM
Mark,
Peter is trying to help you.
We don't have access to your tech support ticket. Can you tell us what doesn't work like it should?
I have had success using vegas 8 and surround sound in a simple project. We must be doing things differently.

Jesse
Mark Seibert wrote on 2/13/2008, 11:44 AM
Hi Jesse,

I appreciate both your help and Peter's.

My experience has been that simple projects seem to work fine. However, I have a number of projects with 40+ tracks of video and audio. At some point along the way in editing something goes wrong and simple panning in 5.1 starts to produce strange results. For example, the sound of a missile that I had that flew from the left rear channel to the left front channel started playing back differently. The key frames and panner icon show the panner moving correctly, but the sound does not move correctly. I have taken this file and deleted everything except this one event and you can clearly see the pan icon moving, but the Master bus shows something VERY different, and the speakers playback correctly what is shown on the master bus (Not what is in the track panner).

If I give you the support ticket number, will that help? Can I post this .veg file that fails someplace so that you can get it and the source data (It’s very small). What else can I provide that might help?
pwppch wrote on 2/13/2008, 4:04 PM
Mark,

We have tracked down the projects that exhibit the problem.

The cause of the problem is that the trim (static) setting for the surround panner is not at center. It is located near the left front speaker in Mark's project.

All of our gain stages that involve automation use both the trim or static value as well as the envelope or key frame automation.

If you center the surround panner's trim value, the problem goes away.

Technically this is not a bug. It is doing exactly what it was told to do. This is a UI issue that we need to address to make it obvious what is really happening. We are discussing this in engineering to solve this for a future release.

When our CS tech guys try to reproduce the problem they could not because the trim setting was centered by default. I do not blame this on them in anyway. This one is on engineering to come up with a better solution to the workflow of surround pan key framing.

Please let us know if this solves your problems.

Thanks
Peter


ChristoC wrote on 2/13/2008, 11:16 PM
I am another who has continuously had this problem, and support have eventually acknowledged it's a bug after I sent demo's, but have done nothing for over 12 months since I reported the problem with V7, so I've abandoned using Vegas under automation, and instead use a proper DAW.

Peter, it's not till you wrote "All of our gain stages that involve automation use both the trim or static value as well as the envelope or key frame automation" that I now unhappily understand what is occurring in my case, and that one setting is fighting with another.... the left hand doesn't know what the right is doing.

What a balls-up - there's nothing I can find in the manual regarding trim/static values versus envelope/keyframe - the user assumes automation over-rides all other settings.

Hope you can get it fixed soon.
jbolley wrote on 2/14/2008, 8:58 AM
Wow. Nice deduction guys.
Peter. Thanks for tracking this down. I can understand how it would be hard to find!
So do I understand that having a 'null' initial keyframe will allow this to work?
What are some workarounds? I'm still wrapping my head around this one but am very impressed with the work of Peter and the forum! Thanks everyone.

Jesse
pwppch wrote on 2/14/2008, 9:08 AM
No, a "null" frame is not the solution.

You need to reset the static (trim) value of the surround panner to center.

1. Open the large Surround panner for the track. You do this by double clicking on the surround panner of the track. Notice that the 'thumb' on the panner looks like a little gear or a diamond. If it is a gear, then the track is in automation mode. If it is a diamond, then it is in trim mode.

2. If the track is in automation mode, turn off automation on the track. You do this by clicking on the "gear button" of the track and unchecking "Show Automation Controls". If you look at the Surround Panner, you will see that the gear thumb is replaced with a diamond. Note that the diamond is located very near the left front speaker.

2. Double click on the diamond thumb. This will reset the Surround "trim" - the static surround pan value - the center of the surround panner. THis does NOT affect any keyframes you have for surround panning.

3. Turn the automation for the track back on in order to record surround pan automation.

4. Play.

You can find some information on this in the help file: In the index look for "Automation". Locate and click on the topic "Audio Track Automation".

We are looking at providing a more detailed description of all of this.

Peter


pwppch wrote on 2/14/2008, 9:14 AM
There is really nothing to fix. The trim + automation behavior is by design. We don't consider this a bug, but a user interface issue.

Yes, it can be confusing, but there are many users that would hate us if we removed this aspect of gain stages on tracks and buses.

We are reviewing the user interface for the surround panner and are looking at ways for your assumption to be avoided.

Peter


Mark Seibert wrote on 2/14/2008, 9:15 AM
Hey All,

We’ve finally gotten to the bottom of the surround sound bug, and it turns out it really was user error – with the caveat that this error even stumped the Sony Tech support people for several weeks. They have now acknowledged this as a confusing UI issue that they need to look into on future releases. Since there have been other people reporting this problem, I’m posting the solution in the hopes it might help.

The surround sound panner has two modes 1) the automation mode, and 2) the trim “offset” mode. Only one of these can be seen at a time, and the “offset” that can be set in the trim does not get visually represented in the visualization of the automation. Because of this, it is possible to have automation that shows sound being panned to a specific location, while the trim offset is actually forcing it to come from some place else.

Here is the example of exactly what happened to me. The surround sound automation panner showed the sound to be centered. However, the trim somehow got set to be mostly positioned to the Front Left. No mater how I panned the sound in the automation, the sound persisted to come mainly from the Front Left…as it should have based on the trim setting. The problem was that I was unaware of this trim offset setting. To toggle the display mode between trim and automation, you need to toggle the switch on the track automation control – make sure that “Show Automation Controls” is unchecked. Now you will see the trim setting.

I hope you find this helpful!
R0cky wrote on 2/14/2008, 10:50 AM
I got a response on my support ticket today with the same explanation as above and yes it did fix my problem too.

I read the manual up, down and sideways and never figured this out. I agree it's a UI issue but some examples and better explanation in the manual would help a lot. You can update the manual with out having to put the code through a lot of regression and other test cases......
ChristoC wrote on 2/14/2008, 11:05 PM
Admitedly the Help does say "When Show Automation Controls is not selected, the controls adjust static (trim) levels." which is an incredibly misleading statement; is not the corollary: "When Show Automation Controls IS selected, the controls DO NOT adjust static (trim) levels."??? - a fair enough user assumption.

What it does NOT SAY is that this static control REMAINS ACTIVE during automation, which I must say is at complete variance to any other mixer software I have ever encountered... and it's quite obvious that Sony Support have not been conversant with this aspect either; in my case I reported this over a year ago.

In my opinion you should disable the static control when Autom is active - it is impossible to adjust both at the same time anyway - I can't see any workflow reason why it was 'designed' like this in the first place.
pwppch wrote on 2/14/2008, 11:40 PM
We are happy with the overall design and it provides flexability that other hosts do not. It is unlikely we will change our approach.

We get many postive responses from users on our approach here. They find it both flexible and powerful. Taking it away would be unacceptable to many users and it would adversly affect projects that take advantage of this feature. Backward compatability is important.

The simplest example of the workflow is you can adjust the overall 'trim" of the automation by adjusting the trim setting rather than having to edit the overall envelope automation.

We are looking at improving the UI and workflow to make the behavior clear. Our doc group is reviewing how the topic is presented in both online help and in the users manual.

FWI: You actually can adjust both at the same time - though not from the GUI. You can have trims active in the GUI but an external control can be adjusting the Automation. It is subjective as to how useful this is. We actually at one time considered exposing both on the GUI, but early feed back told us it was confusing and that our final approach was solid. (We now know that the GUI needs to be looked at again.)

Hey, we are not perfect. This kind of feedback and discussion helps to make things better in the product and our support of the product.

Thanks
Peter

MarkWWWW wrote on 2/15/2008, 5:31 AM
I'd like to register my vote for keeping the current system of trim and automation separately controllable but both always in operation.

But clearly the only-being-able-to-see-the-one-you-are-currently-adjusting nature of the GUI is leading many people to end up in a place they don't want to get to with no idea why. It seems to me that having a "ghost" of the trim pointer visible (but not adjustable) when you are in the automation mode, and conversely having a "ghost" of the automation pointer visible (but not adjustable) when you are in the trimming mode might be the easiest way of making the situation clear to the user. (The "ghost" could be made semi-transparent so as to make it clear which indicator was currently active.) This small change, together with a more clear explanation in the manual and helpfiles, should hopefully prevent anyone else from encountering this problem, or at least give them enough clues to realise what has happened and how to solve it. (I say it's a small change, but obviously I don't know how the code that drives the GUI is written and it might be that there's a lot more involved in making this sort of change than I am aware of.)

Mark