Thread: [Audacity-devel] Noise coring filter
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Jérôme M. B. <jeb...@fr...> - 2012-05-17 08:23:07
Attachments:
signature.asc
|
Hi, Now that version 2 is out and feature freeze is over, may I resubmit my noise coring filter: https://bitbucket.org/jmb/audacity-patches/src/tip/noise-coring.patch Here are some examples of the results here ("Bruts" are the originals, "Filtre" are filtered): http://jeberger.free.fr/public/110911-BenedictionOrgue-mp3/ Jerome -- mailto:jeb...@fr... http://jeberger.free.fr Jabber: jeb...@ja... |
From: Jérôme M. B. <jeb...@fr...> - 2012-08-10 21:55:24
Attachments:
signature.asc
|
Hi, Following the latest exchange of mails, I've added the ability to autodetect the noise shape and threshold. This is a lot more complicated than I originally assumed (especially since applause should *not* be filtered even though it looks like extra loud noise...) and is currently rather slow. Moreover, it tends to underestimate the shape (pink noise is seen at 9.5dB/decade, but brown noise is seen at 17dB/decade) and the threshold (so you need to set a higher reduction to compensate). For the time being, this is available as a checkbox in the options dialog. There are too many options there for it to be included as is, but I'd like more people to test it before I start removing options (or hiding them behind an "advanced" button or tab). Note that if your recorder has a lo-cut "noise reduction" filter, this should be disabled or the missing low frequencies will probably cause the detection code to fail. Finally, I've also fixed a bug that could cause glitches for certain combinations of filter length and window size (including length 2000 and window size 8192). Jerome https://bitbucket.org/jmb/audacity-patches/src/tip/noise-coring.patch -- mailto:jeb...@fr... http://jeberger.free.fr Jabber: jeb...@ja... |
From: Jérôme M. B. <jeb...@fr...> - 2012-08-11 11:11:18
Attachments:
signature.asc
|
Jérôme M. Berger wrote: > Hi, > > Following the latest exchange of mails, I've added the ability to > autodetect the noise shape and threshold. This is [...] currently rather slow. > You can disregard the remark about it being slow. I have just optimized it so that the detection pass went from taking 98% of the time to just under 9%, which makes it perfectly acceptable. Jerome -- mailto:jeb...@fr... http://jeberger.free.fr Jabber: jeb...@ja... |
From: Steve t. F. <ste...@gm...> - 2012-08-20 08:11:41
Attachments:
noise-coring-Aug-20.patch
|
Attached is a patch file in the usual format. Patch works correctly against SVN head using: patch -p 0 < noise-coring-Aug-20.patch No problems building it. I think this definitely shows some promise with the potential for an almost 'automatic' method for hiss reduction. The two controls that have the most significant effect on the quality (by a long way) are the "Threshold" and "Noise Shape" settings. I seem to be getting best results with the Noise Reduction amount some way below the default level, at around (-) 10 dB. The defaults for Filter Length, Window Size and Reactivity seem to work well and changing these values generally has little effect, so could these perhaps be pre-set to optimised values so as to simplify the user interface? The automatic settings seem to be a bit hit-or-miss at the moment, and better results are achieved with some manual adjustment. @ Jérôme, I don't know exactly what this is doing internally, but is it 'necessary' that the noise profile is defined as a linear slope (dB per decade), or could the process work with a non-linear noise profile? Noise coring definitely seems to work best with "hiss" type noise, (one of the most common noise problems). Steve On 11 August 2012 12:11, "Jérôme M. Berger" <jeb...@fr...> wrote: > Jérôme M. Berger wrote: >> Hi, >> >> Following the latest exchange of mails, I've added the ability to >> autodetect the noise shape and threshold. This is [...] currently rather slow. >> > You can disregard the remark about it being slow. I have just > optimized it so that the detection pass went from taking 98% of the > time to just under 9%, which makes it perfectly acceptable. > > Jerome > -- > mailto:jeb...@fr... > http://jeberger.free.fr > Jabber: jeb...@ja... > > |
From: Vaughan J. <va...@au...> - 2012-08-20 21:25:31
|
Should this go into 2.0.2rc4? - V On 8/20/2012 1:11 AM, Steve the Fiddle wrote: > Attached is a patch file in the usual format. > > Patch works correctly against SVN head using: > patch -p 0 < noise-coring-Aug-20.patch > > No problems building it. > > I think this definitely shows some promise with the potential for an > almost 'automatic' method for hiss reduction. > The two controls that have the most significant effect on the quality > (by a long way) are the "Threshold" and "Noise Shape" settings. > > I seem to be getting best results with the Noise Reduction amount some > way below the default level, at around (-) 10 dB. > The defaults for Filter Length, Window Size and Reactivity seem to > work well and changing these values generally has little effect, so > could these perhaps be pre-set to optimised values so as to simplify > the user interface? > > The automatic settings seem to be a bit hit-or-miss at the moment, and > better results are achieved with some manual adjustment. > > @ Jérôme, I don't know exactly what this is doing internally, but is > it 'necessary' that the noise profile is defined as a linear slope (dB > per decade), or could the process work with a non-linear noise > profile? > > Noise coring definitely seems to work best with "hiss" type noise, > (one of the most common noise problems). > > Steve > > > > On 11 August 2012 12:11, "Jérôme M. Berger" <jeb...@fr...> wrote: >> Jérôme M. Berger wrote: >>> Hi, >>> >>> Following the latest exchange of mails, I've added the ability to >>> autodetect the noise shape and threshold. This is [...] currently rather slow. >>> >> You can disregard the remark about it being slow. I have just >> optimized it so that the detection pass went from taking 98% of the >> time to just under 9%, which makes it perfectly acceptable. >> >> Jerome >> -- >> mailto:jeb...@fr... >> http://jeberger.free.fr >> Jabber: jeb...@ja... >> >> >> |
From: Steve t. F. <ste...@gm...> - 2012-08-20 22:13:03
|
I'm quite excited about the possibilities of Jérôme's Noise Coring effect, but personally I don't think that it's ready yet for prime time. I'm not sure how experimental features are handled within Audacity or what policies there are regarding experimental features, but I'd see Noise Coring as experimental. In the future this could be a very useful addition to Audacity's restoration / repair tools, either incorporated as an option within the Noise Removal effect, or a very simple to use separate de-hiss tool. Personally I think I'd prefer the latter as there are a lot of users that want a simple method to reduce hiss from recordings without the complexity of the Noise Removal effect. I'd be interested to hear Jérôme's thoughts about how he would like to develop the effect. Steve On 20 August 2012 22:25, Vaughan Johnson <va...@au...> wrote: > Should this go into 2.0.2rc4? > > - V > > On 8/20/2012 1:11 AM, Steve the Fiddle wrote: >> Attached is a patch file in the usual format. >> >> Patch works correctly against SVN head using: >> patch -p 0 < noise-coring-Aug-20.patch >> >> No problems building it. >> >> I think this definitely shows some promise with the potential for an >> almost 'automatic' method for hiss reduction. >> The two controls that have the most significant effect on the quality >> (by a long way) are the "Threshold" and "Noise Shape" settings. >> >> I seem to be getting best results with the Noise Reduction amount some >> way below the default level, at around (-) 10 dB. >> The defaults for Filter Length, Window Size and Reactivity seem to >> work well and changing these values generally has little effect, so >> could these perhaps be pre-set to optimised values so as to simplify >> the user interface? >> >> The automatic settings seem to be a bit hit-or-miss at the moment, and >> better results are achieved with some manual adjustment. >> >> @ Jérôme, I don't know exactly what this is doing internally, but is >> it 'necessary' that the noise profile is defined as a linear slope (dB >> per decade), or could the process work with a non-linear noise >> profile? >> >> Noise coring definitely seems to work best with "hiss" type noise, >> (one of the most common noise problems). >> >> Steve >> >> >> >> On 11 August 2012 12:11, "Jérôme M. Berger" <jeb...@fr...> wrote: >>> Jérôme M. Berger wrote: >>>> Hi, >>>> >>>> Following the latest exchange of mails, I've added the ability to >>>> autodetect the noise shape and threshold. This is [...] currently rather slow. >>>> >>> You can disregard the remark about it being slow. I have just >>> optimized it so that the detection pass went from taking 98% of the >>> time to just under 9%, which makes it perfectly acceptable. >>> >>> Jerome >>> -- >>> mailto:jeb...@fr... >>> http://jeberger.free.fr >>> Jabber: jeb...@ja... >>> >>> >>> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Vaughan J. <va...@au...> - 2012-08-20 22:35:40
|
Okay, thanks. Might as well commit it right away for 2.0.4-alpha, once 2.0.3 is out. - V On 8/20/2012 3:12 PM, Steve the Fiddle wrote: > I'm quite excited about the possibilities of Jérôme's Noise Coring > effect, but personally I don't think that it's ready yet for prime > time. > I'm not sure how experimental features are handled within Audacity or > what policies there are regarding experimental features, but I'd see > Noise Coring as experimental. > > In the future this could be a very useful addition to Audacity's > restoration / repair tools, either incorporated as an option within > the Noise Removal effect, or a very simple to use separate de-hiss > tool. Personally I think I'd prefer the latter as there are a lot of > users that want a simple method to reduce hiss from recordings without > the complexity of the Noise Removal effect. I'd be interested to hear > Jérôme's thoughts about how he would like to develop the effect. > > > Steve > > On 20 August 2012 22:25, Vaughan Johnson <va...@au...> wrote: >> Should this go into 2.0.2rc4? >> >> - V >> >> On 8/20/2012 1:11 AM, Steve the Fiddle wrote: >>> Attached is a patch file in the usual format. >>> >>> Patch works correctly against SVN head using: >>> patch -p 0 < noise-coring-Aug-20.patch >>> >>> No problems building it. >>> >>> I think this definitely shows some promise with the potential for an >>> almost 'automatic' method for hiss reduction. >>> The two controls that have the most significant effect on the quality >>> (by a long way) are the "Threshold" and "Noise Shape" settings. >>> >>> I seem to be getting best results with the Noise Reduction amount some >>> way below the default level, at around (-) 10 dB. >>> The defaults for Filter Length, Window Size and Reactivity seem to >>> work well and changing these values generally has little effect, so >>> could these perhaps be pre-set to optimised values so as to simplify >>> the user interface? >>> >>> The automatic settings seem to be a bit hit-or-miss at the moment, and >>> better results are achieved with some manual adjustment. >>> >>> @ Jérôme, I don't know exactly what this is doing internally, but is >>> it 'necessary' that the noise profile is defined as a linear slope (dB >>> per decade), or could the process work with a non-linear noise >>> profile? >>> >>> Noise coring definitely seems to work best with "hiss" type noise, >>> (one of the most common noise problems). >>> >>> Steve >>> >>> >>> >>> On 11 August 2012 12:11, "Jérôme M. Berger" <jeb...@fr...> wrote: >>>> Jérôme M. Berger wrote: >>>>> Hi, >>>>> >>>>> Following the latest exchange of mails, I've added the ability to >>>>> autodetect the noise shape and threshold. This is [...] currently rather slow. >>>>> >>>> You can disregard the remark about it being slow. I have just >>>> optimized it so that the detection pass went from taking 98% of the >>>> time to just under 9%, which makes it perfectly acceptable. >>>> >>>> Jerome >>>> -- >>>> mailto:jeb...@fr... >>>> http://jeberger.free.fr >>>> Jabber: jeb...@ja... >>>> >>>> |
From: Vaughan J. <va...@au...> - 2012-08-20 23:20:44
|
Oops, auto-increment was on in my brain. I meant for 2.0.3-alpha, once 2.0.2 is out. Must seem to me like this is taking a long time. :-) - V On 8/20/2012 3:35 PM, Vaughan Johnson wrote: > Okay, thanks. Might as well commit it right away for 2.0.4-alpha, once > 2.0.3 is out. > > - V > > > > On 8/20/2012 3:12 PM, Steve the Fiddle wrote: >> I'm quite excited about the possibilities of Jérôme's Noise Coring >> effect, but personally I don't think that it's ready yet for prime >> time. >> I'm not sure how experimental features are handled within Audacity or >> what policies there are regarding experimental features, but I'd see >> Noise Coring as experimental. >> >> In the future this could be a very useful addition to Audacity's >> restoration / repair tools, either incorporated as an option within >> the Noise Removal effect, or a very simple to use separate de-hiss >> tool. Personally I think I'd prefer the latter as there are a lot of >> users that want a simple method to reduce hiss from recordings without >> the complexity of the Noise Removal effect. I'd be interested to hear >> Jérôme's thoughts about how he would like to develop the effect. >> >> >> Steve >> >> On 20 August 2012 22:25, Vaughan Johnson <va...@au...> wrote: >>> Should this go into 2.0.2rc4? >>> >>> - V >>> >>> On 8/20/2012 1:11 AM, Steve the Fiddle wrote: >>>> Attached is a patch file in the usual format. >>>> >>>> Patch works correctly against SVN head using: >>>> patch -p 0 < noise-coring-Aug-20.patch >>>> >>>> No problems building it. >>>> >>>> I think this definitely shows some promise with the potential for an >>>> almost 'automatic' method for hiss reduction. >>>> The two controls that have the most significant effect on the quality >>>> (by a long way) are the "Threshold" and "Noise Shape" settings. >>>> >>>> I seem to be getting best results with the Noise Reduction amount some >>>> way below the default level, at around (-) 10 dB. >>>> The defaults for Filter Length, Window Size and Reactivity seem to >>>> work well and changing these values generally has little effect, so >>>> could these perhaps be pre-set to optimised values so as to simplify >>>> the user interface? >>>> >>>> The automatic settings seem to be a bit hit-or-miss at the moment, and >>>> better results are achieved with some manual adjustment. >>>> >>>> @ Jérôme, I don't know exactly what this is doing internally, but is >>>> it 'necessary' that the noise profile is defined as a linear slope (dB >>>> per decade), or could the process work with a non-linear noise >>>> profile? >>>> >>>> Noise coring definitely seems to work best with "hiss" type noise, >>>> (one of the most common noise problems). >>>> >>>> Steve >>>> >>>> >>>> >>>> On 11 August 2012 12:11, "Jérôme M. Berger" <jeb...@fr...> wrote: >>>>> Jérôme M. Berger wrote: >>>>>> Hi, >>>>>> >>>>>> Following the latest exchange of mails, I've added the ability to >>>>>> autodetect the noise shape and threshold. This is [...] currently rather slow. >>>>>> >>>>> You can disregard the remark about it being slow. I have just >>>>> optimized it so that the detection pass went from taking 98% of the >>>>> time to just under 9%, which makes it perfectly acceptable. >>>>> >>>>> Jerome >>>>> -- >>>>> mailto:jeb...@fr... >>>>> http://jeberger.free.fr >>>>> Jabber: jeb...@ja... >>>>> >>>>> > |
From: Gale (A. Team) <ga...@au...> - 2012-08-21 06:50:49
|
I tried it and found it much preferable to Noise Removal for mild hiss (much less destruction of the signal). It seems very aggressive with the signal and the noise in heavy white noise, even with shape of zero dB - such that I think Noise Removal is currently better in extreme white noise cases. I generally agree that Threshold and Shape have the most effect and that the automatic settings are often not optimal - if the "automatic" box is checked, should not the sliders underneath the box grey out? I got repeatable crashes with high window sizes such as 4064 and 4095: effects/NoiseCoring.cpp:226: virtual bool EffectNoiseCoring::Process(): Assertion `newWindowSize <= 16384' failed. I agree it should perhaps be experimental unless we can investigate some simplifications in time for its release. I would be interested too in knowing if coring could be a control in Noise Removal with the existing controls or similar (or indeed if not capturing a profile could be extended to other types of noise, so potentially applicable to Noise Removal). Gale On 11 August 2012 12:11, "Jérôme M. Berger" <jeberger@> wrote: > Jérôme M. Berger wrote: >> Hi, >> >> Following the latest exchange of mails, I've added the ability to >> autodetect the noise shape and threshold. This is [...] currently rather >> slow. >> > You can disregard the remark about it being slow. I have just > optimized it so that the detection pass went from taking 98% of the > time to just under 9%, which makes it perfectly acceptable. > > Jerome -- View this message in context: http://audacity.238276.n2.nabble.com/Noise-coring-filter-tp7555895p7556065.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Jérôme M. B. <jeb...@fr...> - 2012-08-21 22:12:03
Attachments:
signature.asc
|
Gale (Audacity Team) wrote: > I tried it and found it much preferable to Noise Removal for mild hiss (much > less destruction of the signal). > > It seems very aggressive with the signal and the noise in heavy white noise, > even with shape of zero dB - such that I think Noise Removal is currently > better in extreme white noise cases. > I'm not sure what you mean by that. Do you have a sample that exhibits the problem so that I can see if I can improve the results? > I generally agree that Threshold and Shape have the most effect and that > the automatic settings are often not optimal - if the "automatic" box is > checked, should not the sliders underneath the box grey out? > Yes, if we keep all the options then the automatic checkbox should enable/disable the sliders underneath. However, I believe that the dialog should be simplified before being released to everyone. The main reason I kept all the controls for the time being is so that other developers and/or early adopters could play with the settings so that we can find the best default values for those we eventually remove. > I got repeatable crashes with high window sizes such as 4064 and 4095: > > effects/NoiseCoring.cpp:226: virtual bool EffectNoiseCoring::Process(): > Assertion `newWindowSize <= 16384' failed. > Yes, I fixed a bug in the previous version of the patch, but that reduces slightly the maximum allowed filter length and I forgot to update the limit. The filter length should be smaller than 4032, higher values will trigger the assertion. This is now fixed in the latest version. > I agree it should perhaps be experimental unless we can investigate some > simplifications in time for its release. > > I would be interested too in knowing if coring could be a control in Noise > Removal with the existing controls or similar (or indeed if not capturing a profile > could be extended to other types of noise, so potentially applicable to Noise > Removal). > The noise coring filter could use a captured profile. However, I'm not sure how the other parameters would translate between the two filters... Steve the Fiddle wrote: > @ Jérôme, I don't know exactly what this is doing internally, but is > it 'necessary' that the noise profile is defined as a linear slope (dB > per decade), or could the process work with a non-linear noise > profile? The process could work with any noise profile, including a profile captured by a process similar to what is done in Noise Removal. There were mainly two reasons for using a linear slope profile: - It was simpler to implement at the beginning while I was not sure whether the filter would be good enough to justify the extra effort of using a captured profile; - Capturing a good noise profile requires a long enough interval with only noise, and the same noise as what will be found in the background of the signal. This is not always easy to find. Now that I've tested it with the linear profile, I'm not sure how much improvement a "precise" profile would bring. Although this is something I intend to try eventually. Jerome -- mailto:jeb...@fr... http://jeberger.free.fr Jabber: jeb...@ja... |
From: Gale A. <ga...@au...> - 2012-08-24 07:00:13
|
| From "Jérôme M. Berger" <jeb...@fr...> | Wed, 22 Aug 2012 00:11:50 +0200 | Subject: [Audacity-devel] Noise coring filter > Gale (Audacity Team) wrote: > > I tried it and found it much preferable to Noise Removal for mild hiss (much > > less destruction of the signal). > > > > It seems very aggressive with the signal and the noise in heavy white noise, > > even with shape of zero dB - such that I think Noise Removal is currently > > better in extreme white noise cases. > > > I'm not sure what you mean by that. Do you have a sample that > exhibits the problem so that I can see if I can improve the results? You could try: http://gaclrecords.org.uk/noise_samples_public/jazz_noise.wav It's only Audacity white noise at 0.1 amplitude mixed into some quiet jazz music (just enough noise at the start to take a noise profile for standard Noise Removal). What I meant was that with Noise Coring, the noise seemed to be disfigured as much as the jazz, such that the standard Noise Removal sounded more natural. Maybe you can find settings that disprove that, I don't know. By the way I have a large collection of noise samples that Dominic gave me a while ago (not just hiss but all types of noise) from the time when he was working on the Noise Removal effect. I can't link to these publicly as Dominic said not to, but if anyone working on click or other noise removal wants the samples for private research, he is fine with that. If so, please let me know off list. Gale |
From: Steve t. F. <ste...@gm...> - 2012-08-24 07:33:43
|
On 24 August 2012 07:59, Gale Andrews <ga...@au...> wrote: > > | From "Jérôme M. Berger" <jeb...@fr...> > | Wed, 22 Aug 2012 00:11:50 +0200 > | Subject: [Audacity-devel] Noise coring filter >> Gale (Audacity Team) wrote: >> > I tried it and found it much preferable to Noise Removal for mild hiss (much >> > less destruction of the signal). >> > >> > It seems very aggressive with the signal and the noise in heavy white noise, >> > even with shape of zero dB - such that I think Noise Removal is currently >> > better in extreme white noise cases. >> > >> I'm not sure what you mean by that. Do you have a sample that >> exhibits the problem so that I can see if I can improve the results? > > You could try: > http://gaclrecords.org.uk/noise_samples_public/jazz_noise.wav > > It's only Audacity white noise at 0.1 amplitude mixed into some > quiet jazz music (just enough noise at the start to take a noise > profile for standard Noise Removal). > > What I meant was that with Noise Coring, the noise seemed to > be disfigured as much as the jazz, such that the standard Noise > Removal sounded more natural. Maybe you can find settings that > disprove that, I don't know. There's a different kind of "damage" depending on which effect is used which makes it difficult to draw a direct comparison, but I'm getting (subjectively) slightly better results with Noise Coring than with standard Noise Removal with jazz_noise.wav. Steve > > By the way I have a large collection of noise samples that Dominic > gave me a while ago (not just hiss but all types of noise) from the > time when he was working on the Noise Removal effect. I can't > link to these publicly as Dominic said not to, but if anyone working > on click or other noise removal wants the samples for private > research, he is fine with that. If so, please let me know off list. > > > > Gale > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Steve t. F. <ste...@gm...> - 2012-05-17 13:01:27
|
To Jerome, I'm not a developer, but I'm pleased to see work on this feature continuing, it was showing a lot of promise when I tested the previous patch. To the developers, could this feature be accommodated as an experimental feature (assuming that the current patch works, which I've not tested yet)? Noise coring is already included in the wiki proposal for improving Noise Removal and I think that including it in the svn code would help to move this feature along. From testing the old patch, with certain (common) types of noise/audio it can produce significantly better noise removal than the current effect. Steve On 17 May 2012 09:04, "Jérôme M. Berger" <jeb...@fr...> wrote: > > Hi, > > Now that version 2 is out and feature freeze is over, may I > resubmit my noise coring filter: > https://bitbucket.org/jmb/audacity-patches/src/tip/noise-coring.patch > > Here are some examples of the results here ("Bruts" are the > originals, "Filtre" are filtered): > http://jeberger.free.fr/public/110911-BenedictionOrgue-mp3/ > > Jerome > -- > mailto:jeb...@fr... > http://jeberger.free.fr > Jabber: jeb...@ja... > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Marco D. A. M. <mar...@gm...> - 2012-05-17 14:29:43
|
Isn't it possible to turn Noise Coring into an option of the current noise removal effect? Like a checkbox that can be marked/unmarked? |
From: Steve t. F. <ste...@gm...> - 2012-06-01 18:44:04
|
Experimenting with Noise Coring, it seems to give pretty reasonable results with Noise Reduction set to 5 dB and the noise threshold set to about 15 dB below the peak noise level (other settings at default). I've tested this on quite a wide range of sound/noise samples and it's pretty consistent. This could give a quick and easy (rough and ready) noise removal tool that is a lot more simple to use than the Audacity "Noise Removal" tool. What I was thinking is that a first pass could find the level of say the lowest 1% of the selection and set the noise floor 15 dB below that, then use fixed settings of 5dB reduction, 10dB/octave, Filter length 2000, Min window size 8192 To make analysing the noise floor faster it would probably be adequate to miss out 99 of every 100 samples (effectively analysing a low sample rate copy). Alternatively it could use a "Noise Profile" (like Noise Removal) to calculate the threshold and noise shape. Either way it can probably give reasonable results while being a lot easier for users. Steve On 17 May 2012 15:29, Marco Diego Aurélio Mesquita <mar...@gm...> wrote: > Isn't it possible to turn Noise Coring into an option of the current > noise removal effect? Like a checkbox that can be marked/unmarked? > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Paul L <chr...@ya...> - 2014-08-04 21:24:58
|
Jerome, if you are still reading... I am reading your code and trying to understand all of your math. In a few places there is an unexplained "magic number" of 163.0. It is used in calculating how noise threshold varies with frequency, according to the noise shape (or "color.") My guess about the origin of this number is that you took (440 Hz * 16384 samples per window) / 44100 samples per second and rounded to the nearest integer. If I am correct, then the use of this number encodes an assumption about sample rate that needs to be generalized to work correctly in all Audacity projects. There are other calculations that do not assume the same FFT window size of 16384 samples per second, but I believe they are not there to correct this number for varying window size. So this constant may need to be replaced by an expression taking both project rate and window size into account. Am I mistaken? -- View this message in context: http://audacity.238276.n2.nabble.com/Noise-coring-filter-tp7555200p7562571.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Jérôme M. B. <jeb...@fr...> - 2014-08-12 06:40:12
|
Paul L wrote: > Jerome, if you are still reading... I am reading your code and trying to > understand all of your math. > > In a few places there is an unexplained "magic number" of 163.0. It is used > in calculating how noise threshold varies with frequency, according to the > noise shape (or "color.") > > My guess about the origin of this number is that you took > > (440 Hz * 16384 samples per window) / 44100 samples per second > > and rounded to the nearest integer. > > If I am correct, then the use of this number encodes an assumption about > sample rate that needs to be generalized to work correctly in all Audacity > projects. > > There are other calculations that do not assume the same FFT window size of > 16384 samples per second, but I believe they are not there to correct this > number for varying window size. So this constant may need to be replaced by > an expression taking both project rate and window size into account. > > Am I mistaken? > Hi, It's been a while since I last looked at the code, so I can't comment on this specific "magic number" without taking the time to dig back in. However, I remember that there is at least one magic number that assumes a frequency of 440Hz and a sampling of 44kHz (I don't remember either way for the window size) and that affects the interpretation of the "Threshold" parameter: the threshold can be seen as the amount of noise at 440Hz when the sound is sampled at 44kHz, using another sampling rate implies adjusting the threshold, which wasn't too much of an issue for testing. I don't remember for sure, but it is possible that this line makes the necessary adjustments (at least for window size): https://bitbucket.org/jmb/audacity-patches/src/tip/noise-coring.patch#cl-284 Jerome |