the arrows don't move the fader fast enough to hear the noise which seems to only occur when the the fader is moved something like 10dB in one second. good idea though.

I'm not experiencing any zipper noise like you describe, no matter how fast I move the auotmated adjustments. Have you tried just playing back a track and moving your mouse rapidly around the screen, like you would be moving it when you're making volume adjustments? The problem you're having is more common in Laptop computers, because things with slower communication speeds, can reach into frequencies of the audio spectrum. So the mouse commumincation data, can be located very close to the sound Card A/D and D/A converters and the frequency of the data can bleed into the audio circuits of the sound card. A good designed sound card will use capacitors, shielding and common mode rejection circuits to elliminate outside sources from enterning the audio system. You may have something wrong with your soundcard, or it's just missing that within the design of the sound card. That's why I mentioned to move the soundcard to different slots, because moving it will put it further away from the signals bleading into the audio circuits. What type of mouse are you using PS/2 or USB? You might try using the opposite type of mouse and this may solve your problem also. It doesn't seem to be a Vegas problem.

It's definitely not the mouse. I've done some testing/recording with a simple test tone. When I record it while adjusting the volume in real-time that I get a stair-stepping of the audio that is the same size as the ASIO buffer size.

"I've done some testing/recording with a simple test tone."

Ahhhhhh ha!!!! And let me guess, The test tones that make the zipper noise are very low in frequeny? Probably around 50 Hz? This probably doesn't happen on higher frequency tones above 1Khz right? This is a common problem in digital audio. When changing volume steps, if the steps use linear steps to go from volume A to Volume B, then you will hear a zipper type of noise. Think of a sinewave that has a stair case envelope on it's amplitude. That's what you're hearing when you describe "zipper" type of noise. To overcome this, instead of using a linear function to go from Point A to Point B, you need to use logrithymic functions, which are much more unnoticeable to your ear. When you playback the file, and look at the volume envelope between points, you will see log functions between Volume envelope Point A and Volume Envelope Point B. If you turn the automatic thinning of points off and use linear functions between the volume points then you will hear the zipper noise upon playback. I'm not sure if you can define the function that is used when recording the automation, but I know you can change it upon playback. Log functions take a lot more calculations than linear functions, where it would be a significant performance hit to your system to be done in realtime. I believe this is probably what Vegas does, to save on performance, and then when you press stop, it does the log functions of the points. Welcome to the world of "Digital", ala DISCREET steps.

Nope, it exhibits the noise regardless of content (I've tried 1k, 2k and 5k tones and they all have the issue). To be clear, this only happens when I playback audio and move the volume slider- it doesn't happen when the envelope (which was recorded during this process) adjusts the volume.
Thanks for taking the time for the detailed explaination Red - I'm a Researcher at Dolby Labs and know a bit about the world of "Digital" too ;)

I did reproduce the zipper noise. I did tests using a 50Hz sinewave, a 1Khz sinewave, and a 12Khz sinewave. The severity of the zipper noise was most obvious on the 50 Hz sinewave. I got occasional clicks on the 1Khz sinewave and was unable to get any zipper noise/clicks on the 12Khz sinewave. So this pretty much correlates with what I described above for a zipper noise problem and using linear volume transistions. I also used pink noise and found no zipper noise. One other test I did was with a 0bit CD .wav file and this also reproduced no zipper noise. I would try your test using Pink noise, which is much more representative of a music signal and see if you still hear the same noise. Also try a 0bit .Wav file and see if this reproduces any noise. This would further conclude that this is due to the linear volume steps. If you hear noise, then I would bet then there's some other source causing the zipper noise. Nice to hear from a Dolby Labs rep using Vegas, I'm a Harman International employee.

I don't hear it with pink noise either, probably because the clicks are being masked. I heard it in the studio this past weekend on a keyboard track that was somewhat isolated and doubt it would be very audible in a more complex mix, but it would be nice to know if this is a bug or a "feature" ;)

ps - I tried a "silent" event (0-bit) and didn't get any noise either.

It's not that the clicks are being masked, it's that pink noise is more of a complex waveform and you will not get the major step volume difference within 1 cycle of the waveform. It's these steps that are causing the zipper noise. It's eccentially adding high frequency components to the low frequency waveform. Your keyboard sound was probably a lower frequency bass instrument with a strong low frequency fundamental resembling closer to a low frequency sinewave. If you applied a high pass filter, elliminating most of the fundamental frequency, I would bet you wouldn't hear the zipper noise any longer. I'm sure it's not a "feature", it's a design tradeoff. I'm sure they could make volume steps happen for every sample of the audio, but that would be a lot of overhead processing at the cost of performance. I would think a better approach would be instead of increasing the volume step points to the sampling frequency, would be to give the user a choise to use log functions between the volume step points, which would elliminate the zipper type of noise, that are noticeable when using linear steps.

I get it with real music

geoff

I get it too on both of my systems. Real music though...

bump - Peter?

Don't bump Peter. He's probably writing some code to fix a wee bug, will push a wrong key, and you'll have created a bigger bug !

geoff

I haven't heard it in music, this was actually one of the things I looked for during beta testing. But if it is happening in music, it will most likely depend on that particular piece of music and the amount of bass content and if you catch a crest of a waveform during a volume adjustment, so maybe why I haven't heard it. I'm not so familiar how Vegas is handling it's aumation while recording. I have experienced this same problem when designing digital hardware with realtime volume adjustments, and how we've overcome it.

"Peter?"....<g>....I think this actually may be a "Dennis?"

We are looking at it.

Peter

<bg>

Peter

Actually it is Matt, not Dennis.

FWIW:
Matt and I are the audio centric guys.
Dennis is primarily focused on Video aspects.

We all of course float as needed.

Peter

I noticed when the "smooth and thin points" is checked that it will use the "smooth fade" between volume points, thus the "smooth" part of that preference setting. I would recommend using the "smooth" fade between points even if the thinning of points preference isn't checked, instead of having it default to linear. Linear functions are not nice, when adjusting the volume and almost always cause problems on low frequency audio. It would be nice to have a user default preference check box to set the fade type used between volume envelope points, that would also be used during the automation recording. It's those damn linear functions you're using during recording making this problem obvious, where a smooth fade log function would be much more graceful, and a lot more unnoticeable.

A similar problem that I had a discussion with the Sound Forge guru's. Play a 50 Hz sinewave and hit the Stop button. Depending on where the Stop occured on that sinewave it will cause a pop noise. Speakers can't handle an abrupt linear stop like that and it always makes a pop noise if the stop occurs near the crest of the sinewave. My recommendation was to use a quick exponential fade, instead of a linear fade to zero, when hitting the stop button and this will elliminate the pop noise heard.

Summary from an audio perspective. Linear=bad, logarithmic/Exponential=Good.

If it's during automation recording (and not playback), it's because it's using the most recent fader position, and it doesn't interpolate from the last value. This is because interpolation would put it even further behind (it's guaranteed to be behind, since the only way to be on time would be to do it in the analog domain). If we did fade from the last value to the new value, it would remove the jumps in level, but it would increase the perceived latency.

Let me ask you this, did you notice this in a real-world case, or just with extreme movements during testing? What latency are you running on your audio device?

///d@