Re: [Audacity-devel] Automatic Volume Feature
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2009-07-30 01:14:20
|
| From André Pinto <est...@gm...> | Wed, 29 Jul 2009 15:32:35 +0100 | Subject: [Audacity-devel] Automatic Volume Feature > On Wed, Jul 29, 2009 at 1:08 AM, Martyn Shaw <mar...@go...>wrote: > > > Hi André > > > > I've had a play with this and it seems like a good idea. A few > > comments however: > > > > André Pinto wrote: > > > Hi, > > > > > > As planed, I've been working during this week on Automatic Volume > > Feature. > > > > > > I've just committed the initial implementation. To test it you should: > > > - Uncomment #define AUTOMATIC_VOLUME in src/Experimental.h to test it. > > > - Activate and configure it on Preferences->Recording and then proceed > > > to a normal Record. > > > > > > Brief configuration options description: > > > - Checkbox: Enable/Disable Automatic Volume > > > - Best Peak Volume slider: desired max peak volume (from 0 to 100) > > > > I suggest that you change the text to 'Target level' and have it go > > from 0 to 1, with a default of 0.70 (3dB of headroom, which isn't > > much). Arguably the slider should be optionally in dB, say -10dB -> 0dB. > > but automatic volume is only monitoring the max peak and not the entire > level, "target level" would discard that detail right? but if you think it's > better for the user I'll change it. I don't think "Best" is a good word either, so "Target Peak"? I'm on Windows XP at the moment. I'll admit I have not followed this feature much, but using it with "stereo mix" I have issues (and certainly confusion as to the extent this feature is supposed to interact with the Audacity input slider). If I: * set Audacity input slider to 0.7 * turn up my Wave output to maximum * play a classical orchestral piece in Windows Media Player that starts ppp and ends up fff * press Record in Audacity the fortissimos clip severely at default settings (Best Peak = 92). There is no adjustment of the Audacity input slider at any time. If I now set the Audacity input slider to 0.2, play and record, the input slider jumps to 1.0 after 2 seconds, and stays there throughout the fortissimos, yet there is no clipping. I have extra volume compression between the pianissimo and the fortissimo that I was not expecting (I did not ask for a massive boost on the quiet passage). The highest peak recorded is -6.4 dB. Does this seem correct for "92" given the above? I completely agree that 0 > 1 is a better range for Best Peak and think an explicit dB scale would be better still. If I set Audacity input slider back to 0.7 and turn "Best Peak" down to "13", I consistently get only the first two seconds recorded. The rest is silence (New Peak Amplitude = Infinity according to "Amplify"), irrespective of the volume of the incoming audio. I do not have Sound Activated Recording on. This seems to happen because Audacity resets the input slider to 0.0 after that length of automated recording. Same happens if I set "Best Peak" to "50". So first off, can someone explain what is supposed to happen in the above three scenarios please? When this goes in permanently, I suggest it should be in the Transport Menu, and maybe due to the length it adds to Preferences, this and "Sound Activated" should be in their own tab? For both types of controlled recording, how about greying out the controls when the checkbox is empty? About the type of slider used in these two features, I don't get good feedback about it - its also in the AAC export options. I think it's very confusing to have a dynamic centrally positioned value that can make you think you are looking at a log scale. It would be OK if it actually looked like a counter or something. I can see some point in the AAC options due to limited space, and I know there is a problem seeing the set value with the normal sliders, but Leland is I think onto a solution for that. Can we not use regular sliders here that behave the same as the others (click in the scale and the handle goes there)? Gale > > > - Delta Peak Volume slider: sets the interval for max peak volume > > > acception [best-delta; best+delta] > > > > This is not obvious what it does. It's 'give-or-take' thing for the > > first control I know, but is that obvious to a user? Why not put > > 'Within' and then have the slider go 0.01 - 0.20 or something like > > that (or optionally in dB). Also don't change that invisibly, since > > somebody might set, say, 0.95 as the target within +-0.20 meaning they > > could accept 0.75 -> 1.0 and not want to be restricted to 0.90 -> 1.0. > > > I agree and I'll try to find a way to update the meter immediately and not > only after OK like it's done now. > > > > > - Analysis time textbox: monitoring time for each decision (milliseconds) > > > > I have not looked in to how this works, or why. What is your > > thinking? (but see below) > > that's just the time that we will be collecting volume information till we > do a decision (increase or decrease volume or keep it as it is now). We > can't do that all the time because that would imply much more variations > (like increasing the volume when the audio is playing some small intervals > without almost any sound) and we can't do that just once after x seconds of > monitor and then nothing more, because almost everytime we will not find the > perfect volume after the first decision, we'll need to know the effects of > that decision and then improve it more till we are satisfied (eg when the > audio is clipping you'll need to lower the volume but you can't say how > much, because the real input volume is being clipped by an unknown amount). > > > > > > > > - Number of consecutive analysis: number of changes to the volume (total > > > analysis time will be analysis_time*number_analysis. 0 value means > > > endless analysis) > > > > From what you said before, perhaps 'endless' should be the default? > > But for simplicity perhaps it should say 'Keep going for' X 'seconds', > > and set X to 2000 or so (I'm thinking one side of an LP)? I'm > > thinking that a user should set this, play their record until they are > > satisfied that the loud bits have passed, then start again from the > > beginning and do the recording as a good copy. How would they stop AV > > starting again in this situation, without going in to preferences? > > Always endless might be a good option if a enable/disable button is added to > one of the main toolbars of Audacity so the user will intuitively stop it. > But that would imply the need of having GUI thread changing "on runtime" > variables used by Automatic Volume's thread, that purposely doesn't happen > now to avoid any conflict, but if we want that "runtime feature" I guess > we'll need some lock system like mutexes (I don't know the usual way that > Audacity's handles thread conflicts...). > > > > > Some integrity validations are done to this values. > > > > > > Brief description of current behavior: > > > - Initialization of varibles is done when the Record starts. > > > - Portaudio callback function calls AVProccess. > > > Each time: > > > -- we update the max peak volume during the current analysis using > > > mInputMeter->GetMaxPeak(); > > > -- if audio is clipping we set our mAVClipped to true. > > > > you also reset mAVMax each time, whether or not there is clipping, > > which I don't think is right. Reset it if there is clipping but not > > if there isn't would be a better option? Then you remember bigger > > peaks in the music, even if they were before this analysis interval? > > So why have an 'analysis time'? > > I reset mAVMax because after a decision is made the old values doesn't > matter anymore (at least using the function that is actually implemented), > we just need the new results of that decision, the old ones are from a > different volume level... > > > > > When the current analysis time ends: > > > -- if audio has clipped or if maxpeak is above the acceptable range we > > > set the new volume to actual_volume+desired_max_peak-current_max_peak > > > (I've tried to find a better function I had no success) > > > > I have not tried any other functions but my first try would be > > double vol = iv * mAVGoalPoint/mAVMax > > > might be a possibility but it will need much more steps to find an > acceptable value, an advantage is that it is a much more subtle way to > change the volumes (in most cases). > > > > > -- if the max_peak is below the acceptable range we set the new volume > > > to actual_volume+desired_max_peak-current_max_peak (notice that desired > > > - current is now positive, the same expression is used but the condition > > > is still needed as you may see checking the code) > > > -- if the max_peak is within the acceptable range we stop monitoring. > > > > I think we should monitor for the time that is set, and not stop until > > then. I am currently listening to King Crimson's 'Lark's Tongues in > > Aspic', which starts off quiet and then gets much louder. > > > > > Status bar messages are sent each time a decision is done. > > > > Each time you do Px_SetInputVolume(mPortMixer, vol) you should > > probably do a Px_GetInputVolume(mPortMixer) and report that. Just in > > case it isn't being set to what you think. Just a thought, no > > evidence here that it isn't doing just what you ask. > > > Like was said before, audiocallback is a critical function, I can do that > verification if you find it important enough, but any unnecessary work > should be avoid. Probably moving Audacity Volume from audiocallback to meter > on update like Richard suggested might be best and would avoid the thread > problems. I'll work on that. > > > > As I said before, this is just the initial implementation. Suggestions > > > are welcome. > > > > > > I've also fixed a bug (at least I think it is a bug) with clipping > > > (mBar[j].clipping was always true after first clipping), but I've > > > noticed some strange behaviour with clipping. sometimes despite the fact > > > that the volume meters were totally fulfilled no clipping was detected > > > (probably a pre-clipped protection was already limiting the input? :s). > > > > I see what Richard said and that you fixed it. > > > > TTFN > > Martyn > > and there's still that assert in Envelope::GetValues if you don't zoom > > out far enough... |