Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 10 of 10

Thread: Normalization

  1. #1
    Join Date
    July 2011
    Posts
    13

    Normalization

    please refer to http://forum.teamspeak.com/showthrea...=normalization

    obviously the normalization doesnt do anything

  2. #2
    Join Date
    December 2009
    Location
    Taiwan
    Posts
    313
    eh, few things first.

    Quote Originally Posted by tha_specializt View Post
    Well if this is really the case ... the normalization in TS3 is broken - it doesnt work at all and i dont remember it to work at any time - everyone can scream into the mic without being normalized
    1. The user(who speaks, or screams in your case) must enable the auto-adjust volume option under the advanced options in the capture tab for normalization to work.
    2. Normalization cannot handle sudden loud noises, after all, there is no way for the program to tell if it's a scream or it's just a loud gain in background noise, it takes "time" to adjust it, and in the case of a scream, by the time program determines that the sound is way too load and start to tone down the volume, the scream has already ended.

    So, I don't think this is a bug.

  3. #3
    Join Date
    July 2011
    Posts
    13
    Quote Originally Posted by willy_sunny View Post
    1. The user(who speaks, or screams in your case) must enable the auto-adjust volume option under the advanced options in the capture tab for normalization to work.
    So the OTHER users are forced to normalize THEMSELVES? Sheesh, that doesnt make any sense at all ... Nobody will ever prevent himself / themselves from being able to scream via TS3

    Quote Originally Posted by willy_sunny View Post
    2. Normalization cannot handle sudden loud noises, after all, there is no way for the program to tell if it's a scream or it's just a loud gain in background noise
    Thats just wrong - i cant even explain in how many way this is incorrect, but it certainly is. For example :
    Code:
    if(diff(amplitude(frames[i], amplitude(frames[0])) >= USER_SETTING_MAX_AMP) decrease_volume()
    Yea .... too bad im a developer myself, huh
    And now its your turn to claim "its not that easy!!1one" -- shall i proceed with real examples, then?

  4. #4
    Join Date
    December 2009
    Location
    Netherlands
    Posts
    153
    No luck with normalization here either. I'm not a developer or anything, but what I did notice that with some clients using Mumble it works perfectly, but when they turn the option on in Teamspeak it barely does a thing

  5. #5
    Join Date
    October 2011
    Posts
    48
    It's 2013, winter and everyone is coughing into the TS. Will Normalization be implemented some day or does it stay as a useless placeholder in the GUI ?

  6. #6
    Join Date
    September 2012
    Posts
    6,079
    There is no normalization in the way you would usually understand the phrase and the word is not even used anywhere in the client.
    All there is is AGC (Automatic Gain Control) which raises (or lowers) the input volume to a certain pre-determined level and the ability to increase or decrease the volume of other clients permanently (until you disable it again that is).
    Normalization as in leveling off every client in your channel to roughly the same loudness is not implemented and was never talked about or confirmed in the linked thread either.

  7. #7
    Join Date
    October 2011
    Posts
    48
    I would like to have the feature that if one client is suddenly getting a high difference in gain to his previous gain level his gain should be reduced. In other words my definition of normalization per client.

    As I understand the AGC approach is making almost the same with the difference that it is not taking the previous gain level of the user to adjust the gain but a user set gain level.

    I'm OK with that too if it would work that way. The clients are getting louder without the AGC stepping in to reduce their sudden noise.

  8. #8
    Join Date
    September 2012
    Posts
    6,079
    AGC raises or lowers the incoming voice from the microphone to a certain level which cannot be changed. It can only be disabled or enabled by each client.
    If it is enabled by all clients is does something similar to normalization in that it does measure the incoming data over a small period of time and adjusts it if necessary which is why it takes a small time and thus sudden peaks will still go through, which is how it should be, otherwise you wouldn't be able to recognize how someone speaks, ie. you wouldn't be able to tell whether someone shouted, talked normally or whispered.
    The difference with AGC is that it happens on the sender's client side once instead of each client having to do it when receiving voice data.

  9. #9
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    It seems to me that this discussion suffers from the one thing talked about here being actually two different things in the audio world.

    AGC ideally is a rather slow adjustment in volume to, yes, reach some sort of normalization.
    Its purpose is to battle nonideal manual input settings. Imagine some guy behind a mixing desk going "oh I should increase those guys volume a little, since he's less loud than the others", then pushing up the fader slowly so no one's irritated by a fast push.

    Battling loud peak spikes, like someone shouting, is another kind of beast.
    You cannot just say, well, we got a pc as a mixing engineer, just let him push those faders real super fast (well, in fact, you can with some newer approaches like Vocal Rider from Waves, but I doubt they're gonna want to share their pro audio source codes). If you just would ride those volume with a basic algorithm, you'd get a lot of nasty audio artifacts and stuff would sound "kinda weird". Don't let anyone tell you otherwise ;P

    Instead, the probably most used unit type in audio engineering should be used for such: Compression/Limiting.
    Those, for example, are used to even out a singers volume on a live gig (if you want a guaranteed icy look go ask the audio engineer to enable AGC^^) or on recordings. That sounds quite a lot like what's wanted here, right?
    Being that much faster than AGC, they do work inside single audio events, like a word. But due to that, the sound is modulated no matter what. Ideally, with good settings on a good compressor this is even wanted.
    How do those units work?
    Both units use a threshold value as trigger (there are "soft" and "hard" thresholds, actually), both use an attack time for allowing the first important audio parts through, can be short), then a limiter says stop no further and clips the audio volume, while a compressor applies a ratio. A Release time determines how fast after the audio gets below the threshold the unit toggles back. Both attack and release need to be somewhat acceptable non-zero values to not end up with the same as our super-fast volume rider.

    Since the whole stuff got technically quieter, in the end the overall volume is increased to make up for that. End-result: A thickend, more even (reduced dynamic bandwidth) signal that's also heard as louder. That's why those old songs in your collection sound much less loud, because nowadays everyones battling to be the loudest and uses compression as there'd be no tomorrow.
    It is imo possible to set somewhat-working values for all voice-style sounds for a compressor for this voicecom application at least.

    The ideal setup, it seems, would be AGC->[optional] Soft Compression-> Hard Compression/Limiting.
    I gotta admit, I don't even know if AGC is applied before or after the capture plugin event handler, however, at least it may be evident now that there's more to it than it seems on first glance and why shouts being loud does not prove AGC being bugged. One might actually think about applying those on the receiver side, since they only need to work on actually active streams, someone who's talking. If that aren't too many at once, performance might not suffer that much.

    There are, besides the less easy to zero-config issue other downsides to compression:
    Background noise gets louder in relation to voice.
    Chance of feedback with a loudspeaker setup is increased.
    Last edited by Philosound; January 24th, 2013 at 11:05 PM.

  10. #10
    Join Date
    July 2011
    Posts
    13
    instead of waiting for the teamspeak team to implement the most basic, core functionality one could fix the obvious issue by yourself :

    http://www.ntonyx.com/vac.htm

    After installing this great (yet simple) piece of software you simply need to wire up your virtual devices (TS3 output --> VAC input --> VAC output --> speakers) and enable volume normalization -- havent tried it yet but it should work flawlessy as i have already successfully used VAC in other scenarios. I will report back once i've fixed it. Note that there will be a small amount of artifical latency added to everything - but AFAIR its usually in the range of single-digit milliseconds

    If you just would ride those volume with a basic algorithm, you'd get a lot of nasty audio artifacts and stuff would sound "kinda weird"
    ... No. That'd be a defective algorithm as it apparently also boosts volume -- thats pretty much the opposite of what everybody is waiting for, for TS3 the volumes should of course only be adjusted if a speaker is too loud, thats exactly what users expect

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. TS3 Normalization
    By SightUp in forum General Questions
    Replies: 2
    Last Post: July 20th, 2011, 02:34 PM
  2. Voice Normalization?
    By Digital-Storm in forum General Questions
    Replies: 0
    Last Post: December 23rd, 2009, 06:19 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •