Thread: [Audacity-quality] bugs in 'Click Removal'
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2013-12-12 01:17:59
|
I was trying to do some click removal. I usually use Repair, but I tried Click Removal, and no matter what parameters I gave it, it seemed to do nothing, so I debugged it, and indeed it does nothing. Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop conditional is: while((s < len)&&((len-s)>(windowSize/2))) { Var s is 0. I am using a ~9ms selection, so len is 386 samples. That makes the first clause is true, but windowSize is hard-coded to 8192, so the second clause fails. http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks says it may not work well with clicks 10ms or longer, but it apparently does nothing if len is shorter than 4097 samples, and doesn't tell the user it did nothing. So then I tried a selection that's 8332 samples, stepped through EffectClickRemoval::RemoveClicks(), and again it does nothing (it never executes line 268 that modifies the 'buffer' var), despite a prominent spike, no matter where I set the parameters. This is old code. Has it ever actually worked? Should we just drop it in favor of Repair? Btw, http://wiki.audacityteam.org/wiki/Click_Removal#Click_Removal_steps says "sound like static electricity". Don't you mean "radio static", as static electricity sounds a lot like clicks to me. - V |
From: Steve t. F. <ste...@gm...> - 2013-12-12 01:32:50
|
I've never had much practical success with Click Remover, but it is not totally useless. As an example, generate 10 seconds of silence, then somewhere near the middle use the Draw (pencil) tool to raise the value of one sample to about +0.5. Then select the entire 10 seconds and apply Click Removal with the default settings. The "click" is removed. Steve On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: > I was trying to do some click removal. I usually use Repair, but I tried > Click Removal, and no matter what parameters I gave it, it seemed to do > nothing, so I debugged it, and indeed it does nothing. > > Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop > conditional is: > > while((s < len)&&((len-s)>(windowSize/2))) { > > Var s is 0. I am using a ~9ms selection, so len is 386 samples. That > makes the first clause is true, but windowSize is hard-coded to 8192, so > the second clause fails. > > http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks > says it may not work well with clicks 10ms or longer, but it apparently > does nothing if len is shorter than 4097 samples, and doesn't tell the > user it did nothing. > > So then I tried a selection that's 8332 samples, stepped through > EffectClickRemoval::RemoveClicks(), and again it does nothing (it never > executes line 268 that modifies the 'buffer' var), despite a prominent > spike, no matter where I set the parameters. > > This is old code. Has it ever actually worked? Should we just drop it in > favor of Repair? > > Btw, http://wiki.audacityteam.org/wiki/Click_Removal#Click_Removal_steps > says "sound like static electricity". Don't you mean "radio static", as > static electricity sounds a lot like clicks to me. > > - V > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-12-13 01:33:19
|
Okay, thanks. Not a very compelling use case, I think. In some dramatic cases, it works. Isn't Repair always better, such that we can just remove Click Removal? If not, it definitely needs more code to alert the user in cases where it does nothing. And btw, there's a general principle that commands should be verbs, so e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find Silences' (or even 'Label Silences' or 'Mark Silences'). - V On 12/11/2013 5:32 PM, Steve the Fiddle wrote: > I've never had much practical success with Click Remover, but it is > not totally useless. > As an example, generate 10 seconds of silence, then somewhere near the > middle use the Draw (pencil) tool to raise the value of one sample to > about +0.5. Then select the entire 10 seconds and apply Click Removal > with the default settings. The "click" is removed. > > Steve > > > On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: >> I was trying to do some click removal. I usually use Repair, but I tried >> Click Removal, and no matter what parameters I gave it, it seemed to do >> nothing, so I debugged it, and indeed it does nothing. >> >> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop >> conditional is: >> >> while((s < len)&&((len-s)>(windowSize/2))) { >> >> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That >> makes the first clause is true, but windowSize is hard-coded to 8192, so >> the second clause fails. >> >> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks >> says it may not work well with clicks 10ms or longer, but it apparently >> does nothing if len is shorter than 4097 samples, and doesn't tell the >> user it did nothing. >> >> So then I tried a selection that's 8332 samples, stepped through >> EffectClickRemoval::RemoveClicks(), and again it does nothing (it never >> executes line 268 that modifies the 'buffer' var), despite a prominent >> spike, no matter where I set the parameters. >> >> This is old code. Has it ever actually worked? Should we just drop it in >> favor of Repair? >> >> Btw, http://wiki.audacityteam.org/wiki/Click_Removal#Click_Removal_steps >> says "sound like static electricity". Don't you mean "radio static", as >> static electricity sounds a lot like clicks to me. >> >> - V >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Steve t. F. <ste...@gm...> - 2013-12-13 03:02:56
|
On 13 December 2013 01:33, Vaughan Johnson <va...@au...> wrote: > Okay, thanks. Not a very compelling use case, I think. In some dramatic > cases, it works. Isn't Repair always better, such that we can just > remove Click Removal? Repair works very well, but imagine that you have 500 LPs to transfer to CD and you want to reduce the vinyl crackle. There is no way that you are going to go through selecting 128 samples at a time. Steve > > If not, it definitely needs more code to alert the user in cases where > it does nothing. > > And btw, there's a general principle that commands should be verbs, so > e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find > Silences' (or even 'Label Silences' or 'Mark Silences'). > > - V > > > On 12/11/2013 5:32 PM, Steve the Fiddle wrote: >> I've never had much practical success with Click Remover, but it is >> not totally useless. >> As an example, generate 10 seconds of silence, then somewhere near the >> middle use the Draw (pencil) tool to raise the value of one sample to >> about +0.5. Then select the entire 10 seconds and apply Click Removal >> with the default settings. The "click" is removed. >> >> Steve >> >> >> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: >>> I was trying to do some click removal. I usually use Repair, but I tried >>> Click Removal, and no matter what parameters I gave it, it seemed to do >>> nothing, so I debugged it, and indeed it does nothing. >>> >>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop >>> conditional is: >>> >>> while((s < len)&&((len-s)>(windowSize/2))) { >>> >>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That >>> makes the first clause is true, but windowSize is hard-coded to 8192, so >>> the second clause fails. >>> >>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks >>> says it may not work well with clicks 10ms or longer, but it apparently >>> does nothing if len is shorter than 4097 samples, and doesn't tell the >>> user it did nothing. >>> >>> So then I tried a selection that's 8332 samples, stepped through >>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it never >>> executes line 268 that modifies the 'buffer' var), despite a prominent >>> spike, no matter where I set the parameters. >>> >>> This is old code. Has it ever actually worked? Should we just drop it in >>> favor of Repair? >>> >>> Btw, http://wiki.audacityteam.org/wiki/Click_Removal#Click_Removal_steps >>> says "sound like static electricity". Don't you mean "radio static", as >>> static electricity sounds a lot like clicks to me. >>> >>> - V >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2013-12-13 15:28:10
|
| From Steve the Fiddle <ste...@gm...> | Fri, 13 Dec 2013 03:02:49 +0000 | Subject: [Audacity-quality] bugs in 'Click Removal' > On 13 December 2013 01:33, Vaughan Johnson <va...@au...> wrote: > > Okay, thanks. Not a very compelling use case, I think. In some dramatic > > cases, it works. Isn't Repair always better, such that we can just > > remove Click Removal? > > Repair works very well, but imagine that you have 500 LPs to transfer > to CD and you want to reduce the vinyl crackle. There is no way that > you are going to go through selecting 128 samples at a time. +1. So there is no way we can remove Click Removal until we have something better that works on the entire audio or significant lengths of it. As far as I know, no one ever tried this patch to make Repair work automatically to fix "clipping": http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html . The patch is stale now, but despite my reservations in the topic I assume it could be a useful approach for clicks and clipping that were only "here and there" in the audio. See below. > >> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: > >>> I was trying to do some click removal. I usually use Repair, but I tried > >>> Click Removal, and no matter what parameters I gave it, it seemed to do > >>> nothing, so I debugged it, and indeed it does nothing. > >>> > >>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop > >>> conditional is: > >>> > >>> while((s < len)&&((len-s)>(windowSize/2))) { > >>> > >>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That > >>> makes the first clause is true, but windowSize is hard-coded to 8192, so > >>> the second clause fails. > >>> > >>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks > >>> says it may not work well with clicks 10ms or longer, but it apparently > >>> does nothing if len is shorter than 4097 samples, and doesn't tell the > >>> user it did nothing. > >>> > >>> So then I tried a selection that's 8332 samples, stepped through > >>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it never > >>> executes line 268 that modifies the 'buffer' var), despite a prominent > >>> spike, no matter where I set the parameters. If I generate white noise of 0.01 amplitude and raise a sample to 0.5 with Draw Tool, Click Removal at default settings removes the spike if I have a selection of about 6000 samples, and I can remove the spike with a selection of about 5000 samples if I reduce "Threshold" or make sure the click is more or less in the centre of the selection. If the left edge of the selection is only a few hundred samples to left of the click, the click is not removed whatever the selection length. Repair can remove the click if the left selection edge is only a few samples to left of the click. Still, most users will probably select "all" or centre the selection over the click. Vaughan wrote: > > If not, it definitely needs more code to alert the user in cases where > > it does nothing. Is it easy to detect that the effect did nothing? Or could we workaround it by warning if the selection is < 4097 samples and suggesting to "Drag a larger selection centered over the click(s)"? Would the effect still work if (windowSize/2) was relaxed to e.g. (windowSize/4)? Gale > > And btw, there's a general principle that commands should be verbs, so > > e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find > > Silences' (or even 'Label Silences' or 'Mark Silences'). > > > > - V |
From: Steve t. F. <ste...@gm...> - 2013-12-13 16:15:36
|
On 13 December 2013 15:27, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Fri, 13 Dec 2013 03:02:49 +0000 > | Subject: [Audacity-quality] bugs in 'Click Removal' >> On 13 December 2013 01:33, Vaughan Johnson <va...@au...> wrote: >> > Okay, thanks. Not a very compelling use case, I think. In some dramatic >> > cases, it works. Isn't Repair always better, such that we can just >> > remove Click Removal? >> >> Repair works very well, but imagine that you have 500 LPs to transfer >> to CD and you want to reduce the vinyl crackle. There is no way that >> you are going to go through selecting 128 samples at a time. > > +1. So there is no way we can remove Click Removal until we have > something better that works on the entire audio or significant > lengths of it. > > As far as I know, no one ever tried this patch to make Repair > work automatically to fix "clipping": > http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html . > > The patch is stale now, but despite my reservations in the topic > I assume it could be a useful approach for clicks and clipping that > were only "here and there" in the audio. I've tried it, but unfortunately I did not find it very effective. There may be some mileage in the approach but I think it would need a lot of work. Steve > > See below. > >> >> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: >> >>> I was trying to do some click removal. I usually use Repair, but I tried >> >>> Click Removal, and no matter what parameters I gave it, it seemed to do >> >>> nothing, so I debugged it, and indeed it does nothing. >> >>> >> >>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop >> >>> conditional is: >> >>> >> >>> while((s < len)&&((len-s)>(windowSize/2))) { >> >>> >> >>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That >> >>> makes the first clause is true, but windowSize is hard-coded to 8192, so >> >>> the second clause fails. >> >>> >> >>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks >> >>> says it may not work well with clicks 10ms or longer, but it apparently >> >>> does nothing if len is shorter than 4097 samples, and doesn't tell the >> >>> user it did nothing. >> >>> >> >>> So then I tried a selection that's 8332 samples, stepped through >> >>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it never >> >>> executes line 268 that modifies the 'buffer' var), despite a prominent >> >>> spike, no matter where I set the parameters. > > If I generate white noise of 0.01 amplitude and raise a sample to 0.5 > with Draw Tool, Click Removal at default settings removes the spike if > I have a selection of about 6000 samples, and I can remove the spike > with a selection of about 5000 samples if I reduce "Threshold" or make > sure the click is more or less in the centre of the selection. > > If the left edge of the selection is only a few hundred samples to left > of the click, the click is not removed whatever the selection length. > Repair can remove the click if the left selection edge is only a few > samples to left of the click. > > Still, most users will probably select "all" or centre the selection > over the click. > > Vaughan wrote: >> > If not, it definitely needs more code to alert the user in cases where >> > it does nothing. > > Is it easy to detect that the effect did nothing? > > Or could we workaround it by warning if the selection is < 4097 samples > and suggesting to "Drag a larger selection centered over the click(s)"? > > Would the effect still work if (windowSize/2) was relaxed to e.g. > (windowSize/4)? > > > > Gale > > >> > And btw, there's a general principle that commands should be verbs, so >> > e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find >> > Silences' (or even 'Label Silences' or 'Mark Silences'). >> > >> > - V > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Peter S. <pet...@ya...> - 2013-12-13 16:23:16
|
Steve wrote: > Repair works very well, but imagine that you have 500 LPs to transfer > to CD and you want to reduce the vinyl crackle. There is no way tha > you are going to go through selecting 128 samples at a time. +1 When I started out with Audacity for my LP transcriptions we didn't even have Repair - I used to find the clicks and hand-draw the repairs - (extremely tedious and very time consuming - but effective). I did try Audacity's Click Removal and never got any satisfactory results (probably empirically explained by Vaughan's recent delve into the code). Thankfully Koz gave a steer to Brian Davies' excellent ClickRepair - which, for me, remains the benchmark - Bill favours this app too I believe, but IIRC Gale prefers Goldwave. Gale wrote in reply to Steve: >So there is no way we can remove Click Removal until we have >something better that works on the entire audio or significant >lengths of it. +1 to that - and +1 to a tool that works on the *entire* audio, not just "significant lengths of it". I do seem to remember various folk trying to work up improvements to Click Removal a while back - did those attempts just drift off into the long grass? Peter. Peter Sampson Tel: +44 (0)1625 524 780 Mob: +44 (0)7732 278 299 From: Gale Andrews <ga...@au...> To: audacity-quality <aud...@li...> Sent: Friday, December 13, 2013 3:27 PM Subject: Re: [Audacity-quality] bugs in 'Click Removal' | From Steve the Fiddle <ste...@gm...> | Fri, 13 Dec 2013 03:02:49 +0000 | Subject: [Audacity-quality] bugs in 'Click Removal' > On 13 December 2013 01:33, Vaughan Johnson <va...@au...> wrote: > > Okay, thanks. Not a very compelling use case, I think. In some dramatic > > cases, it works. Isn't Repair always better, such that we can just > > remove Click Removal? > > Repair works very well, but imagine that you have 500 LPs to transfer > to CD and you want to reduce the vinyl crackle. There is no way that > you are going to go through selecting 128 samples at a time. +1. So there is no way we can remove Click Removal until we have something better that works on the entire audio or significant lengths of it. As far as I know, no one ever tried this patch to make Repair work automatically to fix "clipping": http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html. The patch is stale now, but despite my reservations in the topic I assume it could be a useful approach for clicks and clipping that were only "here and there" in the audio. See below. > >> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: > >>> I was trying to do some click removal. I usually use Repair, but I tried > >>> Click Removal, and no matter what parameters I gave it, it seemed to do > >>> nothing, so I debugged it, and indeed it does nothing. > >>> > >>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop > >>> conditional is: > >>> > >>> while((s < len)&&((len-s)>(windowSize/2))) { > >>> > >>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That > >>> makes the first clause is true, but windowSize is hard-coded to 8192, so > >>> the second clause fails. > >>> > >>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks > >>> says it may not work well with clicks 10ms or longer, but it apparently > >>> does nothing if len is shorter than 4097 samples, and doesn't tell the > >>> user it did nothing. > >>> > >>> So then I tried a selection that's 8332 samples, stepped through > >>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it never > >>> executes line 268 that modifies the 'buffer' var), despite a prominent > >>> spike, no matter where I set the parameters. If I generate white noise of 0.01 amplitude and raise a sample to 0.5 with Draw Tool, Click Removal at default settings removes the spike if I have a selection of about 6000 samples, and I can remove the spike with a selection of about 5000 samples if I reduce "Threshold" or make sure the click is more or less in the centre of the selection. If the left edge of the selection is only a few hundred samples to left of the click, the click is not removed whatever the selection length. Repair can remove the click if the left selection edge is only a few samples to left of the click. Still, most users will probably select "all" or centre the selection over the click. Vaughan wrote: > > If not, it definitely needs more code to alert the user in cases where > > it does nothing. Is it easy to detect that the effect did nothing? Or could we workaround it by warning if the selection is < 4097 samples and suggesting to "Drag a larger selection centered over the click(s)"? Would the effect still work if (windowSize/2) was relaxed to e.g. (windowSize/4)? Gale > > And btw, there's a general principle that commands should be verbs, so > > e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find > > Silences' (or even 'Label Silences' or 'Mark Silences'). > > > > - V ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Audacity-quality mailing list Aud...@li... https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Steve t. F. <ste...@gm...> - 2013-12-13 16:34:13
|
On 13 December 2013 16:23, Peter Sampson <pet...@ya...> wrote: > Steve wrote: >> Repair works very well, but imagine that you have 500 LPs to transfer >> to CD and you want to reduce the vinyl crackle. There is no way tha >> you are going to go through selecting 128 samples at a time. > > +1 > > When I started out with Audacity for my LP transcriptions we didn't even > have Repair - I used to find the clicks and hand-draw the repairs - > (extremely tedious and very time consuming - but effective). > > I did try Audacity's Click Removal and never got any satisfactory results > (probably empirically explained by Vaughan's recent delve into the code). > Thankfully Koz gave a steer to Brian Davies' excellent ClickRepair - which, > for me, remains the benchmark - Bill favours this app too I believe, but > IIRC > Gale prefers Goldwave. > > > Gale wrote in reply to Steve: >>So there is no way we can remove Click Removal until we have >>something better that works on the entire audio or significant >>lengths of it. > > +1 to that - and +1 to a tool that works on the *entire* audio, > not just "significant lengths of it". > > I do seem to remember various folk trying to work up improvements to Click > Removal a while back - did those attempts just drift off into the long > grass? Paul L on the forum has been doing some interesting and quite promising things with click detection and removal (using Nyquist). As far as I'm aware that project is ongoing. Steve > > > Peter. > > Peter Sampson > Tel: +44 (0)1625 524 780 > Mob: +44 (0)7732 278 299 > > From: Gale Andrews <ga...@au...> > To: audacity-quality <aud...@li...> > Sent: Friday, December 13, 2013 3:27 PM > Subject: Re: [Audacity-quality] bugs in 'Click Removal' > > > | From Steve the Fiddle <ste...@gm...> > | Fri, 13 Dec 2013 03:02:49 +0000 > | Subject: [Audacity-quality] bugs in 'Click Removal' >> On 13 December 2013 01:33, Vaughan Johnson <va...@au...> >> wrote: >> > Okay, thanks. Not a very compelling use case, I think. In some dramatic >> > cases, it works. Isn't Repair always better, such that we can just >> > remove Click Removal? >> >> Repair works very well, but imagine that you have 500 LPs to transfer >> to CD and you want to reduce the vinyl crackle. There is no way that >> you are going to go through selecting 128 samples at a time. > > +1. So there is no way we can remove Click Removal until we have > something better that works on the entire audio or significant > lengths of it. > > As far as I know, no one ever tried this patch to make Repair > work automatically to fix "clipping": > http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html. > > The patch is stale now, but despite my reservations in the topic > I assume it could be a useful approach for clicks and clipping that > were only "here and there" in the audio. > > See below. > >> >> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> >> >> wrote: >> >>> I was trying to do some click removal. I usually use Repair, but I >> >>> tried >> >>> Click Removal, and no matter what parameters I gave it, it seemed to >> >>> do >> >>> nothing, so I debugged it, and indeed it does nothing. >> >>> >> >>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the >> >>> loop >> >>> conditional is: >> >>> >> >>> while((s < len)&&((len-s)>(windowSize/2))) { >> >>> >> >>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That >> >>> makes the first clause is true, but windowSize is hard-coded to 8192, >> >>> so >> >>> the second clause fails. >> >>> >> >>> >> >>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks >> >>> says it may not work well with clicks 10ms or longer, but it >> >>> apparently >> >>> does nothing if len is shorter than 4097 samples, and doesn't tell the >> >>> user it did nothing. >> >>> >> >>> So then I tried a selection that's 8332 samples, stepped through >> >>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it >> >>> never >> >>> executes line 268 that modifies the 'buffer' var), despite a prominent >> >>> spike, no matter where I set the parameters. > > If I generate white noise of 0.01 amplitude and raise a sample to 0.5 > with Draw Tool, Click Removal at default settings removes the spike if > I have a selection of about 6000 samples, and I can remove the spike > with a selection of about 5000 samples if I reduce "Threshold" or make > sure the click is more or less in the centre of the selection. > > If the left edge of the selection is only a few hundred samples to left > of the click, the click is not removed whatever the selection length. > Repair can remove the click if the left selection edge is only a few > samples to left of the click. > > Still, most users will probably select "all" or centre the selection > over the click. > > Vaughan wrote: >> > If not, it definitely needs more code to alert the user in cases where >> > it does nothing. > > Is it easy to detect that the effect did nothing? > > Or could we workaround it by warning if the selection is < 4097 samples > and suggesting to "Drag a larger selection centered over the click(s)"? > > Would the effect still work if (windowSize/2) was relaxed to e.g. > (windowSize/4)? > > > > Gale > > > >> > And btw, there's a general principle that commands should be verbs, so >> > e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find >> > Silences' (or even 'Label Silences' or 'Mark Silences'). >> > >> > - V > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Vaughan J. <va...@au...> - 2013-12-14 01:15:24
|
On 12/13/2013 8:34 AM, Steve the Fiddle wrote: > On 13 December 2013 16:23, Peter Sampson <pet...@ya...> wrote: >> Steve wrote: >>> Repair works very well, but imagine that you have 500 LPs to transfer >>> to CD and you want to reduce the vinyl crackle. There is no way tha >>> you are going to go through selecting 128 samples at a time. >> >> +1 >> >> When I started out with Audacity for my LP transcriptions we didn't even >> have Repair - I used to find the clicks and hand-draw the repairs - >> (extremely tedious and very time consuming - but effective). >> >> I did try Audacity's Click Removal and never got any satisfactory results >> (probably empirically explained by Vaughan's recent delve into the code). >> Thankfully Koz gave a steer to Brian Davies' excellent ClickRepair - which, >> for me, remains the benchmark - Bill favours this app too I believe, but >> IIRC >> Gale prefers Goldwave. >> >> >> Gale wrote in reply to Steve: >>> So there is no way we can remove Click Removal until we have >>> something better that works on the entire audio or significant >>> lengths of it. >> >> +1 to that - and +1 to a tool that works on the *entire* audio, >> not just "significant lengths of it". >> >> I do seem to remember various folk trying to work up improvements to Click >> Removal a while back - did those attempts just drift off into the long >> grass? > > Paul L on the forum has been doing some interesting and quite > promising things with click detection and removal (using Nyquist). As > far as I'm aware that project is ongoing. Great. If it's doing anything at all in real world examples, it's probably better than Click Removal, and we can consider using it as a replacement. - V > > Steve > > >> >> >> Peter. >> >> Peter Sampson >> Tel: +44 (0)1625 524 780 >> Mob: +44 (0)7732 278 299 >> >> From: Gale Andrews <ga...@au...> >> To: audacity-quality <aud...@li...> >> Sent: Friday, December 13, 2013 3:27 PM >> Subject: Re: [Audacity-quality] bugs in 'Click Removal' >> >> >> | From Steve the Fiddle <ste...@gm...> >> | Fri, 13 Dec 2013 03:02:49 +0000 >> | Subject: [Audacity-quality] bugs in 'Click Removal' >>> On 13 December 2013 01:33, Vaughan Johnson <va...@au...> >>> wrote: >>>> Okay, thanks. Not a very compelling use case, I think. In some dramatic >>>> cases, it works. Isn't Repair always better, such that we can just >>>> remove Click Removal? >>> >>> Repair works very well, but imagine that you have 500 LPs to transfer >>> to CD and you want to reduce the vinyl crackle. There is no way that >>> you are going to go through selecting 128 samples at a time. >> >> +1. So there is no way we can remove Click Removal until we have >> something better that works on the entire audio or significant >> lengths of it. >> >> As far as I know, no one ever tried this patch to make Repair >> work automatically to fix "clipping": >> http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html. >> >> The patch is stale now, but despite my reservations in the topic >> I assume it could be a useful approach for clicks and clipping that >> were only "here and there" in the audio. >> >> See below. >> >>>>> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> >>>>> wrote: >>>>>> I was trying to do some click removal. I usually use Repair, but I >>>>>> tried >>>>>> Click Removal, and no matter what parameters I gave it, it seemed to >>>>>> do >>>>>> nothing, so I debugged it, and indeed it does nothing. >>>>>> >>>>>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the >>>>>> loop >>>>>> conditional is: >>>>>> >>>>>> while((s < len)&&((len-s)>(windowSize/2))) { >>>>>> >>>>>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That >>>>>> makes the first clause is true, but windowSize is hard-coded to 8192, >>>>>> so >>>>>> the second clause fails. >>>>>> >>>>>> >>>>>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks >>>>>> says it may not work well with clicks 10ms or longer, but it >>>>>> apparently >>>>>> does nothing if len is shorter than 4097 samples, and doesn't tell the >>>>>> user it did nothing. >>>>>> >>>>>> So then I tried a selection that's 8332 samples, stepped through >>>>>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it >>>>>> never >>>>>> executes line 268 that modifies the 'buffer' var), despite a prominent >>>>>> spike, no matter where I set the parameters. >> >> If I generate white noise of 0.01 amplitude and raise a sample to 0.5 >> with Draw Tool, Click Removal at default settings removes the spike if >> I have a selection of about 6000 samples, and I can remove the spike >> with a selection of about 5000 samples if I reduce "Threshold" or make >> sure the click is more or less in the centre of the selection. >> >> If the left edge of the selection is only a few hundred samples to left >> of the click, the click is not removed whatever the selection length. >> Repair can remove the click if the left selection edge is only a few >> samples to left of the click. >> >> Still, most users will probably select "all" or centre the selection >> over the click. >> >> Vaughan wrote: >>>> If not, it definitely needs more code to alert the user in cases where >>>> it does nothing. >> >> Is it easy to detect that the effect did nothing? >> >> Or could we workaround it by warning if the selection is < 4097 samples >> and suggesting to "Drag a larger selection centered over the click(s)"? >> >> Would the effect still work if (windowSize/2) was relaxed to e.g. >> (windowSize/4)? >> >> >> >> Gale >> >> >> >>>> And btw, there's a general principle that commands should be verbs, so >>>> e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find >>>> Silences' (or even 'Label Silences' or 'Mark Silences'). >>>> >>>> - V >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Gale A. <ga...@au...> - 2013-12-13 17:01:38
|
| From Peter Sampson <pet...@ya...> | Fri, 13 Dec 2013 08:23:09 -0800 (PST) | Subject: [Audacity-quality] bugs in 'Click Removal' > Steve wrote: > > Repair works very well, but imagine that you have 500 LPs to transfer > > to CD and you want to reduce the vinyl crackle. There is no way tha > > you are going to go through selecting 128 samples at a time. > > +1 > > When I started out with Audacity for my LP transcriptions we didn't even > have Repair - I used to find the clicks and hand-draw the repairs - > (extremely tedious and very time consuming - but effective). > > I did try Audacity's Click Removal and never got any satisfactory results > (probably empirically explained by Vaughan's recent delve into the code). > Thankfully Koz gave a steer to Brian Davies' excellent ClickRepair - which, > for me, remains the benchmark - Bill favours this app too I believe, but IIRC > Gale prefers Goldwave. Click Repair has a substantial learning curve and requires Java. Goldwave has a very effective Click/Pop filter and Noise Removal tool. It also has a "Smother" for crackle that works well for that vinyl "static" that was mentioned and for other vinyl pressing defects (at the cost that it dulls the audio considerably unless applied very lightly). So for vinyl noise that Audacity can't remove (quickly, or without a lot of artifacts) Goldwave is an excellent single program that does the job with very few artifacts. Gale |
From: Peter S. <pet...@ya...> - 2013-12-13 17:43:36
|
Gale wrote: >Click Repair has a substantial learning curve ... C'mon, it's not that hard to use it. It works pretty well straight OOTB, but personally after a little experimenting I decided to soften Brian's default settings. ---------------------------------------------------------------------------------------- Gale Wrote: >Goldwave ... It also has a "Smother" for crackle that works well for that vinyl "static" that was mentioned and for other vinyl pressing defects . ClickRepair also has a de-crackle option. Personally I never used it as I always took cold-pressings and bad-pressings back to the shop for a replacement (my dealer was very glad when I switched to CDs). ----------------------------------------------------------------------------------------- One of the cute tricks that CR offers is the ability to process the audio in "reverse" to avoid false positives occasioned by sharp percussives. It's also clever in that it reverses the audio in buffered small chunks to work on it so the user can still listen to the repairs (or the clicks that are being removed) apparently forward as usual. -------------------------------------------------------------------------------------- But the upshot is that we should really be doing our best to make Audacity equal "best in class" in this respect whichever other apps or combinations of apps you measure it against. And clearly we are not at that stage right now. Peter. Peter Sampson Tel: +44 (0)1625 524 780 Mob: +44 (0)7732 278 299 From: Gale Andrews <ga...@au...> To: audacity-quality <aud...@li...> Sent: Friday, December 13, 2013 5:01 PM Subject: Re: [Audacity-quality] bugs in 'Click Removal' | From Peter Sampson <pet...@ya...> | Fri, 13 Dec 2013 08:23:09 -0800 (PST) | Subject: [Audacity-quality] bugs in 'Click Removal' > Steve wrote: > > Repair works very well, but imagine that you have 500 LPs to transfer > > to CD and you want to reduce the vinyl crackle. There is no way tha > > you are going to go through selecting 128 samples at a time. > > +1 > > When I started out with Audacity for my LP transcriptions we didn't even > have Repair - I used to find the clicks and hand-draw the repairs - > (extremely tedious and very time consuming - but effective). > > I did try Audacity's Click Removal and never got any satisfactory results > (probably empirically explained by Vaughan's recent delve into the code). > Thankfully Koz gave a steer to Brian Davies' excellent ClickRepair - which, > for me, remains the benchmark - Bill favours this app too I believe, but IIRC > Gale prefers Goldwave. Click Repair has a substantial learning curve and requires Java. Goldwave has a very effective Click/Pop filter and Noise Removal tool. It also has a "Smother" for crackle that works well for that vinyl "static" that was mentioned and for other vinyl pressing defects (at the cost that it dulls the audio considerably unless applied very lightly). So for vinyl noise that Audacity can't remove (quickly, or without a lot of artifacts) Goldwave is an excellent single program that does the job with very few artifacts. Gale ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Audacity-quality mailing list Aud...@li... https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-12-14 01:17:09
|
On 12/13/2013 9:43 AM, Peter Sampson wrote: > [...] > -------------------------------------------------------------------------------------- > But the upshot is that we should really be doing our best to make Audacity > equal "best in class" in this respect whichever other apps or combinations > of apps you measure it against. And clearly we are not at that stage > right > now. !Exactamente! ;-) - V |
From: Vaughan J. <va...@au...> - 2013-12-14 01:14:06
|
On 12/13/2013 8:23 AM, Peter Sampson wrote: > Steve wrote: >> Repair works very well, but imagine that you have 500 LPs to transfer >> to CD and you want to reduce the vinyl crackle. There is no way tha >> you are going to go through selecting 128 samples at a time. > +1 > When I started out with Audacity for my LP transcriptions we didn't even > have Repair - I used to find the clicks and hand-draw the repairs - > (extremely tedious and very time consuming - but effective). > I did try Audacity's Click Removal and never got any satisfactory results > (probably empirically explained by Vaughan's recent delve into the code). > Thankfully Koz gave a steer to Brian Davies' excellent ClickRepair - which, > for me, remains the benchmark - Bill favours this app too I believe, but > IIRC > Gale prefers Goldwave. Too bad neither is open source. > Gale wrote in reply to Steve: >>So there is no way we can remove Click Removal until we have >>something better that works on the entire audio or significant >>lengths of it. > +1 to that - and +1 to a tool that works on the *entire* audio, > not just "significant lengths of it". > I do seem to remember various folk trying to work up improvements to Click > Removal a while back - did those attempts just drift off into the long > grass? Dunno. Don't recall that discussion. But the current implementation is so ineffective we should remove it. I'm *not* saying we should never again have a click remover effect, just that this one is bad for our reputation. - V > Peter. > Peter Sampson > Tel: +44 (0)1625 524 780 > Mob: +44 (0)7732 278 299 > > *From:* Gale Andrews <ga...@au...> > *To:* audacity-quality <aud...@li...> > *Sent:* Friday, December 13, 2013 3:27 PM > *Subject:* Re: [Audacity-quality] bugs in 'Click Removal' > > > | From Steve the Fiddle <ste...@gm... > <mailto:ste...@gm...>> > | Fri, 13 Dec 2013 03:02:49 +0000 > | Subject: [Audacity-quality] bugs in 'Click Removal' > > On 13 December 2013 01:33, Vaughan Johnson <va...@au... > <mailto:va...@au...>> wrote: > > > Okay, thanks. Not a very compelling use case, I think. In some dramatic > > > cases, it works. Isn't Repair always better, such that we can just > > > remove Click Removal? > > > > Repair works very well, but imagine that you have 500 LPs to transfer > > to CD and you want to reduce the vinyl crackle. There is no way that > > you are going to go through selecting 128 samples at a time. > > +1. So there is no way we can remove Click Removal until we have > something better that works on the entire audio or significant > lengths of it. > > As far as I know, no one ever tried this patch to make Repair > work automatically to fix "clipping": > http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html. > > The patch is stale now, but despite my reservations in the topic > I assume it could be a useful approach for clicks and clipping that > were only "here and there" in the audio. > > See below. > > > >> On 12 December 2013 01:17, Vaughan Johnson > <va...@au... <mailto:va...@au...>> wrote: > > >>> I was trying to do some click removal. I usually use Repair, but > I tried > > >>> Click Removal, and no matter what parameters I gave it, it seemed > to do > > >>> nothing, so I debugged it, and indeed it does nothing. > > >>> > > >>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, > the loop > > >>> conditional is: > > >>> > > >>> while((s < len)&&((len-s)>(windowSize/2))) { > > >>> > > >>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That > > >>> makes the first clause is true, but windowSize is hard-coded to > 8192, so > > >>> the second clause fails. > > >>> > > >>> > http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks > > >>> says it may not work well with clicks 10ms or longer, but it > apparently > > >>> does nothing if len is shorter than 4097 samples, and doesn't > tell the > > >>> user it did nothing. > > >>> > > >>> So then I tried a selection that's 8332 samples, stepped through > > >>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it > never > > >>> executes line 268 that modifies the 'buffer' var), despite a > prominent > > >>> spike, no matter where I set the parameters. > > If I generate white noise of 0.01 amplitude and raise a sample to 0.5 > with Draw Tool, Click Removal at default settings removes the spike if > I have a selection of about 6000 samples, and I can remove the spike > with a selection of about 5000 samples if I reduce "Threshold" or make > sure the click is more or less in the centre of the selection. > > If the left edge of the selection is only a few hundred samples to left > of the click, the click is not removed whatever the selection length. > Repair can remove the click if the left selection edge is only a few > samples to left of the click. > > Still, most users will probably select "all" or centre the selection > over the click. > > Vaughan wrote: > > > If not, it definitely needs more code to alert the user in cases where > > > it does nothing. > > Is it easy to detect that the effect did nothing? > > Or could we workaround it by warning if the selection is < 4097 samples > and suggesting to "Drag a larger selection centered over the click(s)"? > > Would the effect still work if (windowSize/2) was relaxed to e.g. > (windowSize/4)? > > > > Gale > > > > > > And btw, there's a general principle that commands should be verbs, so > > > e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find > > > Silences' (or even 'Label Silences' or 'Mark Silences'). > > > > > > - V > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > <mailto:Aud...@li...> > https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Vaughan J. <va...@au...> - 2013-12-14 01:02:01
|
On 12/13/2013 7:27 AM, Gale Andrews wrote: > > | From Steve the Fiddle <ste...@gm...> > | Fri, 13 Dec 2013 03:02:49 +0000 > | Subject: [Audacity-quality] bugs in 'Click Removal' >> On 13 December 2013 01:33, Vaughan Johnson <va...@au...> wrote: >>> Okay, thanks. Not a very compelling use case, I think. In some dramatic >>> cases, it works. Isn't Repair always better, such that we can just >>> remove Click Removal? >> >> Repair works very well, but imagine that you have 500 LPs to transfer >> to CD and you want to reduce the vinyl crackle. There is no way that >> you are going to go through selecting 128 samples at a time. > > +1. So there is no way we can remove Click Removal until we have > something better that works on the entire audio or significant > lengths of it. Yes, there's a way we can remove an embarrassing, ineffective effect. > > As far as I know, no one ever tried this patch to make Repair > work automatically to fix "clipping": > http://audacity.238276.n2.nabble.com/Patch-Repair-Clipping-Plugin-td2623796.html . > > The patch is stale now, but despite my reservations in the topic > I assume it could be a useful approach for clicks and clipping that > were only "here and there" in the audio. Is that relevant to Click Removal, i.e., as to whether we keep that useless mess of an effect? ;-) > > See below. > >>>> On 12 December 2013 01:17, Vaughan Johnson <va...@au...> wrote: >>>>> I was trying to do some click removal. I usually use Repair, but I tried >>>>> Click Removal, and no matter what parameters I gave it, it seemed to do >>>>> nothing, so I debugged it, and indeed it does nothing. >>>>> >>>>> Specifically, in EffectClickRemoval::ProcessOne(), at line 174, the loop >>>>> conditional is: >>>>> >>>>> while((s < len)&&((len-s)>(windowSize/2))) { >>>>> >>>>> Var s is 0. I am using a ~9ms selection, so len is 386 samples. That >>>>> makes the first clause is true, but windowSize is hard-coded to 8192, so >>>>> the second clause fails. >>>>> >>>>> http://wiki.audacityteam.org/wiki/Click_Removal#Repair_of_broader_clicks >>>>> says it may not work well with clicks 10ms or longer, but it apparently >>>>> does nothing if len is shorter than 4097 samples, and doesn't tell the >>>>> user it did nothing. >>>>> >>>>> So then I tried a selection that's 8332 samples, stepped through >>>>> EffectClickRemoval::RemoveClicks(), and again it does nothing (it never >>>>> executes line 268 that modifies the 'buffer' var), despite a prominent >>>>> spike, no matter where I set the parameters. > > If I generate white noise of 0.01 amplitude and raise a sample to 0.5 > with Draw Tool, Click Removal at default settings removes the spike if > I have a selection of about 6000 samples, and I can remove the spike > with a selection of about 5000 samples if I reduce "Threshold" or make > sure the click is more or less in the centre of the selection. No way the user would figure that out given there's no indication that selection size matters. > > If the left edge of the selection is only a few hundred samples to left > of the click, the click is not removed whatever the selection length. > Repair can remove the click if the left selection edge is only a few > samples to left of the click. So sometimes it works on a very artificial test case of a spike of *one* sample (nothing like a real world example), and sometimes fails. I've never gotten it to do anything in a real world example, an actual pop from an LP. It's an embarrassment. > > Still, most users will probably select "all" or centre the selection > over the click. > > Vaughan wrote: >>> If not, it definitely needs more code to alert the user in cases where >>> it does nothing. > > Is it easy to detect that the effect did nothing? I would not have suggested it if I didn't know how to do it. But I think it's such a lousy implementation, we should just drop it. > > Or could we workaround it by warning if the selection is < 4097 samples > and suggesting to "Drag a larger selection centered over the click(s)"? Effectively the same thing. > > Would the effect still work if (windowSize/2) was relaxed to e.g. > (windowSize/4)? On what basis? It would 'work' in more cases, i.e., pass the conditional, but I don't know the algorithm, so just arbitrarily changing a value -- sorry, I don't understand why you suggest that. Generally, calculations with windows move them incrementally and overlapping, so definitely the code would need to change substantially. - V > > > > Gale > > >>> And btw, there's a general principle that commands should be verbs, so >>> e.g., that one and Silence Finder, should be 'Remove Clicks' and 'Find >>> Silences' (or even 'Label Silences' or 'Mark Silences'). >>> >>> - V > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Vaughan J. <va...@au...> - 2013-12-16 06:03:26
|
Hi. I'm eliding the context on this long discussion and answering only what I think is still open. A one-sample spike is not a realistic use case, but 1/3 fix of real-world problems is useful, somewhat. Thanks for updating manual/wiki, Gale. I've increased the responsiveness to the other cases where it does nothing, but still need to add an error alert. I'm very much in favor of "reduction" wording instead of "removal", as 1/3 effectiveness is definitely not removal. Thanks, Steve! 'Reduce Clicks', per my invocation that menu commands should be verbs... Okay? I agree with Peter this is P2 -- as I think the current effect is totally useless to most users, and not good for our rep. - V |
From: Steve t. F. <ste...@gm...> - 2013-12-16 10:43:37
|
On 16 December 2013 06:03, Vaughan Johnson <va...@au...> wrote: > Hi. I'm eliding the context on this long discussion and answering only > what I think is still open. > > A one-sample spike is not a realistic use case, but 1/3 fix of > real-world problems is useful, somewhat. > > Thanks for updating manual/wiki, Gale. I've increased the responsiveness > to the other cases where it does nothing, but still need to add an error > alert. > > I'm very much in favor of "reduction" wording instead of "removal", as > 1/3 effectiveness is definitely not removal. Thanks, Steve! > > 'Reduce Clicks', per my invocation that menu commands should be verbs... > Okay? > > I agree with Peter this is P2 -- as I think the current effect is > totally useless to most users, and not good for our rep. > > - V On the positive side, audiophiles tend to have a strong preference for restoration tools to not damage the audio. Click / noise reduction tools can often "overly correct" the audio and remove audio information that should not be removed. Most audiophiles would much rather put up with a bit of crackle than to lose clarity and definition of transients due to aggressive click removal. This is a bonus for Audacity's effect in that (from my tests) it always does zero damage to the music. Steve |
From: Gale A. <ga...@au...> - 2013-12-16 15:46:50
|
| From Steve the Fiddle <ste...@gm...> | Mon, 16 Dec 2013 10:43:31 +0000 | Subject: [Audacity-quality] bugs in 'Click Removal' > On 16 December 2013 06:03, Vaughan Johnson <va...@au...> wrote: > > Hi. I'm eliding the context on this long discussion and answering only > > what I think is still open. > > > > A one-sample spike is not a realistic use case, but 1/3 fix of > > real-world problems is useful, somewhat. > > > > Thanks for updating manual/wiki, Gale. I've increased the responsiveness > > to the other cases where it does nothing, but still need to add an error > > alert. Thanks for your further work, Vaughan. That sounds useful when we have the alert, but AFAICT Click Removal isn't working at all in HEAD on Windows, even on artificial one sample spikes. Were you expecting that? Try for example this real world LP recording: http://gaclrecords.org.uk/bugs/click_removal/mozart_clicky_lp.zip . In 2.0.5 release at default settings of Threshold=200, Max Spike Width=20, removal is quite effective, IMO. Now try it in HEAD. No click removal at all, it seems. > On the positive side, audiophiles tend to have a strong preference for > restoration tools to not damage the audio. > Click / noise reduction tools can often "overly correct" the audio and > remove audio information that should not be removed. Most audiophiles > would much rather put up with a bit of crackle than to lose clarity > and definition of transients due to aggressive click removal. This is > a bonus for Audacity's effect in that (from my tests) it always does > zero damage to the music. Very low Threshold values do damage the music, as the Manual points out. Try my example in 2.0.5 at Threshold=12. Gale |
From: Steve t. F. <ste...@gm...> - 2013-12-16 15:56:16
|
On 16 December 2013 15:46, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Mon, 16 Dec 2013 10:43:31 +0000 > | Subject: [Audacity-quality] bugs in 'Click Removal' >> On 16 December 2013 06:03, Vaughan Johnson <va...@au...> wrote: >> > Hi. I'm eliding the context on this long discussion and answering only >> > what I think is still open. >> > >> > A one-sample spike is not a realistic use case, but 1/3 fix of >> > real-world problems is useful, somewhat. >> > >> > Thanks for updating manual/wiki, Gale. I've increased the responsiveness >> > to the other cases where it does nothing, but still need to add an error >> > alert. > > Thanks for your further work, Vaughan. That sounds useful when we > have the alert, but AFAICT Click Removal isn't working at all in HEAD > on Windows, even on artificial one sample spikes. Were you expecting > that? > > Try for example this real world LP recording: > http://gaclrecords.org.uk/bugs/click_removal/mozart_clicky_lp.zip . > > In 2.0.5 release at default settings of Threshold=200, Max Spike > Width=20, removal is quite effective, IMO. > > Now try it in HEAD. No click removal at all, it seems. > > >> On the positive side, audiophiles tend to have a strong preference for >> restoration tools to not damage the audio. >> Click / noise reduction tools can often "overly correct" the audio and >> remove audio information that should not be removed. Most audiophiles >> would much rather put up with a bit of crackle than to lose clarity >> and definition of transients due to aggressive click removal. This is >> a bonus for Audacity's effect in that (from my tests) it always does >> zero damage to the music. > > Very low Threshold values do damage the music, as the Manual > points out. Try my example in 2.0.5 at Threshold=12. Agreed, you can do damage if you try hard enough :-) Steve > > > > Gale |
From: Vaughan J. <va...@au...> - 2013-12-17 04:11:35
|
On 12/16/2013 7:56 AM, Steve the Fiddle wrote: > On 16 December 2013 15:46, Gale Andrews <ga...@au...> wrote: >>[...] >>> On the positive side, audiophiles tend to have a strong preference for >>> restoration tools to not damage the audio. >>> Click / noise reduction tools can often "overly correct" the audio and >>> remove audio information that should not be removed. Most audiophiles >>> would much rather put up with a bit of crackle than to lose clarity >>> and definition of transients due to aggressive click removal. This is >>> a bonus for Audacity's effect in that (from my tests) it always does >>> zero damage to the music. >> >> Very low Threshold values do damage the music, as the Manual >> points out. Try my example in 2.0.5 at Threshold=12. > > Agreed, you can do damage if you try hard enough :-) > > Steve ;-) But should we change the allowed ranges? - V |
From: Gale A. <ga...@au...> - 2013-12-17 20:41:46
|
| From Vaughan Johnson <va...@au...> | Mon, 16 Dec 2013 20:11:28 -0800 | Subject: [Audacity-quality] bugs in 'Click Removal' > On 12/16/2013 7:56 AM, Steve the Fiddle wrote: > > On 16 December 2013 15:46, Gale Andrews <ga...@au...> wrote: > >>[...] > >>> On the positive side, audiophiles tend to have a strong preference for > >>> restoration tools to not damage the audio. > >>> Click / noise reduction tools can often "overly correct" the audio and > >>> remove audio information that should not be removed. Most audiophiles > >>> would much rather put up with a bit of crackle than to lose clarity > >>> and definition of transients due to aggressive click removal. This is > >>> a bonus for Audacity's effect in that (from my tests) it always does > >>> zero damage to the music. > >> > >> Very low Threshold values do damage the music, as the Manual > >> points out. Try my example in 2.0.5 at Threshold=12. > > > > Agreed, you can do damage if you try hard enough :-) > > > > Steve > > ;-) > > But should we change the allowed ranges? My experience is that down to Threshold=30 is as low as you can go without serious damage, but do we know enough about how the usable range differs with different material to make a decision? Another point that I've seen complained about is that it isn't clear from the interface what units the Threshold and Max Spike Width values relate to, which doesn't help users make any kind of informed decision on settings. Gale |
From: Vaughan J. <va...@au...> - 2013-12-17 04:10:25
|
On 12/16/2013 7:46 AM, Gale Andrews wrote: > > | From Steve the Fiddle <ste...@gm...> > | Mon, 16 Dec 2013 10:43:31 +0000 > | Subject: [Audacity-quality] bugs in 'Click Removal' >> On 16 December 2013 06:03, Vaughan Johnson <va...@au...> wrote: >>> Hi. I'm eliding the context on this long discussion and answering only >>> what I think is still open. >>> >>> A one-sample spike is not a realistic use case, but 1/3 fix of >>> real-world problems is useful, somewhat. >>> >>> Thanks for updating manual/wiki, Gale. I've increased the responsiveness >>> to the other cases where it does nothing, but still need to add an error >>> alert. > > Thanks for your further work, Vaughan. That sounds useful when we > have the alert, but AFAICT Click Removal isn't working at all in HEAD > on Windows, even on artificial one sample spikes. Were you expecting > that? Ahem, just a one-character bug that I've just now fixed. Woke up this morning realizing I should have used "|=" instead of "&=". Amazing how much code review I do in my sleep! Plus, I agglomerated the test for whether it did anything, to a higher level, so now it's not per track, it's for the entire selection. Please test again. Thanks. - V |
From: Gale A. <ga...@au...> - 2013-12-16 16:39:56
|
> On 16 December 2013 06:03, Vaughan Johnson <va...@au...> wrote: > Hi. I'm eliding the context on this long discussion and answering only > what I think is still open. [...] > I'm very much in favor of "reduction" wording instead of "removal", as > 1/3 effectiveness is definitely not removal. Thanks, Steve! > > 'Reduce Clicks', per my invocation that menu commands should be verbs... > Okay? Personally I wouldn't change it to "Reduce Clicks" or "Remove Clicks" unless we are going to make every effect command a verb. If we did, what would we call "Bass and Treble" or "Sliding Time Scale/Pitch Shift"? Wouldn't "Compress" look a bit odd in the Effect Menu? Aren't people looking for the "thing" to apply the verb to? The rename to "Reduce" would push it far down the menu. FWIW the Forum helpers discussed renaming "Noise Removal" to "Noise Reduction" a while ago. I suggested if we did that we would want to rename "Click Removal" to Click Reduction" too. On balance I'm (a weak) -1 on renaming both to "Reduction". "Noise Removal" should have been called "Noise Reduction" in the first place, but it's embarrassing to change it now. Shouldn't we avoid renaming effects (once released) unless functionality changes demand it? I don't think the current names are demonstrably wrong. * The slider in "Noise Removal" already says "Noise reduction" so it's clear that it's removal of the reduced noise. * I've never seen "Click Removal" reduce a spike - have others seen that? It seems to remove spikes or not, as I would expect from what it does. I'm +1 on improving both effects so they are more worthy of the "Remove" moniker. > > I agree with Peter this is P2 -- as I think the current effect is > > totally useless to most users, and not good for our rep. I think Click Removal is P2/P3 borderline and Noise Removal is P3/P4, but Click Removal performance has been mentioned on lists several times without a lot of response before now. If there is some motivation to work on them in future then I'm fine with bugzilla entries. Gale |
From: Vaughan J. <va...@au...> - 2013-12-17 04:30:59
|
On 12/16/2013 8:39 AM, Gale Andrews wrote: > >> On 16 December 2013 06:03, Vaughan Johnson <va...@au...> wrote: >> Hi. I'm eliding the context on this long discussion and answering only >> what I think is still open. > [...] >> I'm very much in favor of "reduction" wording instead of "removal", as >> 1/3 effectiveness is definitely not removal. Thanks, Steve! >> >> 'Reduce Clicks', per my invocation that menu commands should be verbs... >> Okay? > > Personally I wouldn't change it to "Reduce Clicks" or "Remove Clicks" > unless we are going to make every effect command a verb. It's a worthwhile goal, imo. It's certainly easy and clear in this one. And obviously "Removal" is a falsehood in ~2/3 of cases. >If we did, > what would we call "Bass and Treble" or "Sliding Time Scale/Pitch Shift"? Brevity sometimes trumps verb-ness. (And I'm not so sure about 'sliding', vs, for example, 'elastic' -- neither is common terminology, I think.) And btw, how about "Bass/Treble" instead of "Bass and Treble" so it's briefer, and those two are consistent? > Wouldn't "Compress" look a bit odd in the Effect Menu? Probably, as 'compressor' is a common term. We don't have to be doctrinaire, but 'Reduce Clicks' is much better, to me, than 'Click Reduction'. > > Aren't people looking for the "thing" to apply the verb to? The rename > to "Reduce" would push it far down the menu. I said this is a principle -- that means it's long been shown to be more effective in GUI testing for many years, that people are more often looking for an action than the object of the action. But there are exceptions to every principle, right? > > FWIW the Forum helpers discussed renaming "Noise Removal" to > "Noise Reduction" a while ago. I suggested if we did that we would > want to rename "Click Removal" to Click Reduction" too. > > On balance I'm (a weak) -1 on renaming both to "Reduction". "Noise > Removal" should have been called "Noise Reduction" in the first place, > but it's embarrassing to change it now. Totally disagree. It's a fix to something that, as you say, has been wrong from the beginning. If we agree something has been wrong from the outset, we should not continue to support it! Works against our rep. Or remove "Noise Removal" altogether, but that's on the other subthread now. ;-) >Shouldn't we avoid renaming > effects (once released) unless functionality changes demand it? Not always. The wording is wrong. Generally, as you know, I'm against changing GUI elements without changing function, but I think this is a very good case for doing so, and we should do it in a sweeping manor, i.e., verb-ize, and honest-ize (e.g. 'reduce' vs 'remove') as many as possible before 2.0.6 release. > I don't think the current names are demonstrably wrong. "Click Removal" is certainly wrong in 2/3 cases. > > * The slider in "Noise Removal" already says "Noise reduction" so > it's clear that it's removal of the reduced noise. That's also wrong. They should agree. We shouldn't throw multiple terms for the same thing at the user, it's just confusing. They choose a 'Removal' command, but then see they can only reduce? Irritating. > > * I've never seen "Click Removal" reduce a spike - have others seen > that? It seems to remove spikes or not, as I would expect from > what it does. Right, it's a very flawed effect. That's why I started this. > > I'm +1 on improving both effects so they are more worthy of the > "Remove" moniker. No matter how much they can be improved, they'll never be perfect, so "Reduce" is much more honest. > > >>> I agree with Peter this is P2 -- as I think the current effect is >>> totally useless to most users, and not good for our rep. > > I think Click Removal is P2/P3 borderline and Noise Removal is > P3/P4, but Click Removal performance has been mentioned on > lists several times without a lot of response before now. But there's no entry for either, right? > > If there is some motivation to work on them in future then I'm > fine with bugzilla entries. I thought the criterion was that they're known, not that there's motivation to fix them. These are clearly more important, and motivating, than most P5's. - V |
From: Vaughan J. <va...@au...> - 2013-12-17 05:41:11
|
On 12/16/2013 8:30 PM, Vaughan Johnson wrote: > On 12/16/2013 8:39 AM, Gale Andrews wrote: >>[...] > >> >> * I've never seen "Click Removal" reduce a spike - have others seen >> that? It seems to remove spikes or not, as I would expect from >> what it does. > > Right, it's a very flawed effect. That's why I started this. Re-reading your comment, I see you're posing that "reduce" could be interpreted as about spike level, rather than number of clicks it handles. As I understood it, this follow-on has been about percentage of obvious (i.e., very audible) clicks/pops removed. As I understand the testing, that's about 1/3 of them on average, so not "removal". - V |
From: Steve t. F. <ste...@gm...> - 2013-12-17 13:13:25
|
On 17 December 2013 05:41, Vaughan Johnson <va...@au...> wrote: > On 12/16/2013 8:30 PM, Vaughan Johnson wrote: >> On 12/16/2013 8:39 AM, Gale Andrews wrote: >>>[...] >> >>> >>> * I've never seen "Click Removal" reduce a spike - have others seen >>> that? It seems to remove spikes or not, as I would expect from >>> what it does. >> >> Right, it's a very flawed effect. That's why I started this. > > Re-reading your comment, I see you're posing that "reduce" could be > interpreted as about spike level, rather than number of clicks it handles. > > As I understood it, this follow-on has been about percentage of obvious > (i.e., very audible) clicks/pops removed. As I understand the testing, > that's about 1/3 of them on average, so not "removal". > > - V It's a bit like a "Stain Remover". It is "really good" any time that it works. There are lots of kinds of "click" and probably not one algorithm that will work on all. For "vinyl clicks" I'm sure that we can do a lot better than the current Click Remover. Is that the type of click that we want to remove? Steve |