Thread: Re: [Audacity-quality] [Audacity-devel] Noise generators
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2013-01-24 01:28:38
|
Cc'd to -quality There's a bug in the Brown Noise generator. A click is produced at intervals of 262,144 samples. This is fixed in my current code, but I still don't know what low frequency response is preferred. The attached images are: new-hp-brown-noise.png: This gives a reasonably straight 6 dB/octave response down to 20 Hz and is rolled off with a 15 Hz second order high-pass filter. new-brown-noise.png: The same as above without the low frequency roll-off. audacity-brown-noise.png: The current Audacity implementation. For comparison purposes, each track has been normalized to roughly the same loudness and all show about -54 dB at 1 kHz. The two new versions sound virtually identical. The unfiltered version looks best, but it tends to be rather quiet as the subsonic frequencies prevent the level being raised without clipping. The filtered version can be made about 4.5 dB "louder" than the unfiltered version before clipping. The Audacity version is the loudest, but clearly lacks low bass. I think that both new versions are "better" (more "Brownian") than the current Audacity version. The question is, do we provide sub-sonic brown noise and leave it to the user to filter out if they don't want it, or are the noise generators intended to be "audio band" (20Hz - 20kHz) generators? An audio sample is available here: http://easyspacepro.com/audacity/examples/brown-noise-x3.flac It has three short samples: 1) Unfiltered new version. 2) Filtered new version 3) Current Audacity version. These samples were taken from the same tracks as the images. I also agree with Martyn that it would be more accurate to rename "Brown" as "Brownian". Steve On 23 January 2013 12:37, Rob Sykes <aq...@ya...> wrote: > ----- Original Message ----- > >> From: Steve the Fiddle <ste...@gm...> >> To: Audacity-Devel list <aud...@li...> >> Cc: >> Sent: Wednesday, 23 January 2013, 4:17 >> Subject: Re: [Audacity-devel] Noise generators >> >> Attached is a patch based on Paul Kellet's "instrumentation grade" >> algorithm. > > That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. > > Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. > > Cheers, > Rob > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2013-01-24 12:35:05
|
| From Steve the Fiddle <ste...@gm...> | Thu, 24 Jan 2013 01:28:27 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > Cc'd to -quality > > There's a bug in the Brown Noise generator. A click is produced at > intervals of 262,144 samples. This is fixed in my current code, but I > still don't know what low frequency response is preferred. > > The attached images are: > > new-hp-brown-noise.png: This gives a reasonably straight 6 dB/octave > response down to 20 Hz and is rolled off with a 15 Hz second order > high-pass filter. > > new-brown-noise.png: The same as above without the low frequency roll-off. > > audacity-brown-noise.png: The current Audacity implementation. > > For comparison purposes, each track has been normalized to roughly the > same loudness and all show about -54 dB at 1 kHz. > The two new versions sound virtually identical. > The unfiltered version looks best, but it tends to be rather quiet as > the subsonic frequencies prevent the level being raised without > clipping. > The filtered version can be made about 4.5 dB "louder" than the > unfiltered version before clipping. > The Audacity version is the loudest, but clearly lacks low bass. > > I think that both new versions are "better" (more "Brownian") than the > current Audacity version. The question is, do we provide sub-sonic > brown noise and leave it to the user to filter out if they don't want > it, or are the noise generators intended to be "audio band" (20Hz - > 20kHz) generators? > > An audio sample is available here: > http://easyspacepro.com/audacity/examples/brown-noise-x3.flac > It has three short samples: > 1) Unfiltered new version. > 2) Filtered new version > 3) Current Audacity version. > These samples were taken from the same tracks as the images. Thanks, Steve. I agree that the spectra of 1) and 2) look more "correct" than 3). Listening with speakers or headphones I hear a pronounced "beating" every 500 ms or so in 2) which is not very "relaxing" (which I thought was one "purpose" of generating this softer more muffled type of noise). So I much prefer 1) I think users who generate noise should get what they asked for without filtering. I would not as a naive user expect filtering to be done. > I also agree with Martyn that it would be more accurate to rename > "Brown" as "Brownian". +1. Gale > > Steve > > On 23 January 2013 12:37, Rob Sykes <aq...@ya...> wrote: > > ----- Original Message ----- > > > >> From: Steve the Fiddle <ste...@gm...> > >> To: Audacity-Devel list <aud...@li...> > >> Cc: > >> Sent: Wednesday, 23 January 2013, 4:17 > >> Subject: Re: [Audacity-devel] Noise generators > >> > >> Attached is a patch based on Paul Kellet's "instrumentation grade" > >> algorithm. > > > > That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. > > > > Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. |
From: Steve t. F. <ste...@gm...> - 2013-01-24 17:17:46
|
On 24 January 2013 12:33, Gale Andrews <ga...@au...> wrote: [snip] > > Thanks, Steve. > > I agree that the spectra of 1) and 2) look more "correct" than 3). > > Listening with speakers or headphones I hear a pronounced > "beating" every 500 ms or so in 2) which is not very "relaxing" > (which I thought was one "purpose" of generating this softer > more muffled type of noise). So I much prefer 1) I don't notice a "beating" myself, though it could just be on that one audio clip. If you are looping the sample you are likely to notice "patterns" that are really just random variations (clustering) that would not be present on a longer sample. I could post a longer sample, but see below... > > I think users who generate noise should get what they asked > for without filtering. I would not as a naive user expect filtering > to be done. I'm inclined to go with unfiltered, but my reservation is that the perceived volume will be rather low - also there may be a possibility of damage to speakers if a user plays unfiltered brown noise too loud. Perhaps the manual could give a warning about this if we agree to use unfiltered brown noise? If there are no contrary votes I'll go with unfiltered brown noise. > > >> I also agree with Martyn that it would be more accurate to rename >> "Brown" as "Brownian". > > +1. OK, "Brownian" it is. Steve |
From: Gale A. <ga...@au...> - 2013-01-24 19:05:53
|
| From Steve the Fiddle <ste...@gm...> | Thu, 24 Jan 2013 17:17:35 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > On 24 January 2013 12:33, Gale Andrews <ga...@au...> wrote: > [snip] > > > > > Thanks, Steve. > > > > I agree that the spectra of 1) and 2) look more "correct" than 3). > > > > Listening with speakers or headphones I hear a pronounced > > "beating" every 500 ms or so in 2) which is not very "relaxing" > > (which I thought was one "purpose" of generating this softer > > more muffled type of noise). So I much prefer 1) > > I don't notice a "beating" myself, though it could just be on that one > audio clip. If you are looping the sample you are likely to notice > "patterns" that are really just random variations (clustering) that > would not be present on a longer sample. I could post a longer sample, > but see below... No, I'm not looping. > > I think users who generate noise should get what they asked > > for without filtering. I would not as a naive user expect filtering > > to be done. > > I'm inclined to go with unfiltered, but my reservation is that the > perceived volume will be rather low - also there may be a possibility > of damage to speakers if a user plays unfiltered brown noise too loud. > Perhaps the manual could give a warning about this if we agree to use > unfiltered brown noise? Does the existing brown noise carry a risk of subsonic damage? Gale > > If there are no contrary votes I'll go with unfiltered brown noise. > > > > > > >> I also agree with Martyn that it would be more accurate to rename > >> "Brown" as "Brownian". > > > > +1. > > OK, "Brownian" it is. > > Steve |
From: Steve t. F. <ste...@gm...> - 2013-01-24 19:18:47
|
>> > I think users who generate noise should get what they asked >> > for without filtering. I would not as a naive user expect filtering >> > to be done. >> >> I'm inclined to go with unfiltered, but my reservation is that the >> perceived volume will be rather low - also there may be a possibility >> of damage to speakers if a user plays unfiltered brown noise too loud. >> Perhaps the manual could give a warning about this if we agree to use >> unfiltered brown noise? > > Does the existing brown noise carry a risk of subsonic damage? > Possibly, but less so than the new version because proportionally the existing version has a lot less bass and sub-bass, so it sounds a lot louder for the same peak amplitude. I guess that if their speakers start rattling then they should get the hint that they're driving then too hard. Steve > > Gale > >> >> If there are no contrary votes I'll go with unfiltered brown noise. >> >> > >> > >> >> I also agree with Martyn that it would be more accurate to rename >> >> "Brown" as "Brownian". >> > >> > +1. >> >> OK, "Brownian" it is. >> >> Steve > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Steve t. F. <ste...@gm...> - 2013-01-26 20:58:36
Attachments:
noise-gen.patch
|
Patch to upgrade pink noise and brown (Brownian) noise. The pink noise uses Paul Kellet's high quality pink noise filter. "Brown" noise has been renamed "Brownian" and uses "leaky integration". Peaks are constrained to within 0dB (a little trick that I picked up from the SoX code) so the Brownian noise is now a bit louder than it would otherwise be, without any clipping. The glitch that was occurring each 2^18 samples in both pink and brown noise has been fixed. Steve |
From: Martyn S. <mar...@gm...> - 2013-01-28 00:39:38
|
Hi Steve I've had a look over your patch and done a few tests of my own. The patch is basically good, but is it needed / wanted? The pink noise differences do extend the bandwidth of 'pink' down an octave or two, but does anyone really care about that or want it? Or would it harm them? I think that was part of your original question. Putting the roll-off an octave or two below my hearing seems a bit mad to me. On the Brown/Brownian noise, I don't like the clipping test and would rather have a lower overall level. And again I see no real reason to extend the LF cutoff much below 20Hz. We could change that in the original code by setting fc at a different value, I think. The fixes for the limitations at 2^18 samples are good, from what I can see. Would you like to make a patch just for that, so I can commit it? For the 'brown' (brownian) noise, the original code had b1=exp(-2*M_PI*fc/fs); a0=1.0f-b1; and we can see how the 'magic numbers' were generated. http://www.idsc.ethz.ch/Courses/signals_and_systems/lectureNotes10.pdf is an example. I am inclined to move that fc to 20Hz, and readjust the normalisation factor, but I haven't tried that. Perhaps a solution to this would be to have an extra option on the noise generator dialog to set the LF roll-off of these generators to some frequency. That way users could get what they want. This would be a 'rather advanced' option however. Are there any user request for this? TTFN Martyn PS Steve sent the following useful Nyquist code to run at the "Nyquist Prompt" effect ;; print the % of clipped samples (mono tracks only) (setq clipped (do ((count 0) (val (snd-fetch s)(snd-fetch s))) ((not val) count) (if (> (abs val) 1)(setq count (1+ count))))) (print (* 100 (/ clipped len))) On 26/01/2013 20:58, Steve the Fiddle wrote: > Patch to upgrade pink noise and brown (Brownian) noise. > > The pink noise uses Paul Kellet's high quality pink noise filter. > > "Brown" noise has been renamed "Brownian" and uses "leaky > integration". Peaks are constrained to within 0dB (a little trick that > I picked up from the SoX code) so the Brownian noise is now a bit > louder than it would otherwise be, without any clipping. > > The glitch that was occurring each 2^18 samples in both pink and brown > noise has been fixed. > > Steve > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > > > > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale A. <ga...@au...> - 2013-01-28 11:47:32
|
Steve wrote: > The current Audacity "Brown" noise is definitely too light on the bass > when listening on good speakers, so I think that this improvement is > definitely justified. Some user feedback I can point to is that pink and brown are too "similar". The Manual says that brown "has the most muffled, low pitched sound of the three types". I don't sense the muffled or "low pitched" very much compared to pink in the currently released noise. Steve's previous brown noise samples were an improvement IMO, but I have not tried his latest patch. Someone said "brown should be sensed as loud (bassy) enough but still relaxing - it's the best noise for brainwave entrainment (or should be). Think a loud waterfall." Martyn wrote: > Perhaps a solution to this would be to have an extra option on the noise > generator dialog to set the LF roll-off of these generators to some > frequency. That way users could get what they want. This would be a > 'rather advanced' option however. Are there any user request for this? Not seen any, though they may be implied by the comments about pink and brown being too similar. Other comments I've seen: * Add Blue or Violet noise (4 votes) * Make the peaks of brown and white what the user asked for. 0.5 amplitude means that Amplify gives you + 6 dB and certainly the noise peaks should not get louder the longer the noise (3 votes) Gale |
From: Steve t. F. <ste...@gm...> - 2013-01-28 18:49:07
|
On 28 January 2013 11:46, Gale Andrews <ga...@au...> wrote: > > Steve wrote: >> The current Audacity "Brown" noise is definitely too light on the bass >> when listening on good speakers, so I think that this improvement is >> definitely justified. > > Some user feedback I can point to is that pink and brown are too > "similar". The Manual says that brown "has the most muffled, low > pitched sound of the three types". I don't sense the muffled or > "low pitched" very much compared to pink in the currently released > noise. Steve's previous brown noise samples were an improvement > IMO, but I have not tried his latest patch. The current Brown noise and Pink noise in Audacity are a lot more similar than they should be. Below 100 Hz the Brown noise should have a lot more bass than the Pink noise, but it doesn't because the bass shelves off below 100 Hz in Brown noise, whereas it continues to rise in Pink noise. The Pink noise actually has greater amplitude at 20 Hz than Brown noise, which is the wrong way round. Brown noise in the latest patch should sound virtually identical to the previous patch, though a little louder at the same peak dB level. > > Someone said "brown should be sensed as loud (bassy) enough > but still relaxing - it's the best noise for brainwave entrainment > (or should be). Think a loud waterfall." > > > Martyn wrote: >> Perhaps a solution to this would be to have an extra option on the noise >> generator dialog to set the LF roll-off of these generators to some >> frequency. That way users could get what they want. This would be a >> 'rather advanced' option however. Are there any user request for this? > > Not seen any, though they may be implied by the comments > about pink and brown being too similar. > > Other comments I've seen: > > * Add Blue or Violet noise (4 votes) That could certainly be done if there is a demand. Is there an actual definition of "Violet noise"? Violet noise could potentially carry a health warning for tweeters. > > * Make the peaks of brown and white what the user asked > for. 0.5 amplitude means that Amplify gives you + 6 dB > and certainly the noise peaks should not get louder the > longer the noise (3 votes) The new Brownian noise largely solves this. Except for very short selections you get what you asked for. I don't know of a good way to achieve the same predictability for Pink noise, but the latest patch is consistently pretty close. The original noise generator code for 30 seconds or more at 44100 Hz sample rate gives: Pink noise: about 0.06% clipped samples Brown noise: about 0.1% clipped samples The new code gives: Pink noise: less than 0.001% clipped samples Brownian noise: no clipping. For short tracks it is not possible to predict the peak level without normalizing - this is just the nature of random noise. Until there are a few cycles of the lowest frequency component there is no way to predict the peak level. With the current patch, Pink noise can be expected to be within 1 dB of the target level for durations greater than 100000 samples (about 5 seconds at 44.1 kHz). Brown noise can be expected to be the exact specified amplitude for durations greater than 2 seconds. Steve > > > > Gale > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2013-01-29 11:56:27
|
| From Steve the Fiddle <ste...@gm...> | Mon, 28 Jan 2013 18:48:55 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > On 28 January 2013 11:46, Gale Andrews <ga...@au...> wrote: [...] > > > > Steve wrote: > >> The current Audacity "Brown" noise is definitely too light on the bass > >> when listening on good speakers, so I think that this improvement is > >> definitely justified. > > > > Some user feedback I can point to is that pink and brown are too > > "similar". The Manual says that brown "has the most muffled, low > > pitched sound of the three types". I don't sense the muffled or > > "low pitched" very much compared to pink in the currently released > > noise. Steve's previous brown noise samples were an improvement > > IMO, but I have not tried his latest patch. > > The current Brown noise and Pink noise in Audacity are a lot more > similar than they should be. Below 100 Hz the Brown noise should have > a lot more bass than the Pink noise, but it doesn't because the bass > shelves off below 100 Hz in Brown noise, whereas it continues to rise > in Pink noise. The Pink noise actually has greater amplitude at 20 Hz > than Brown noise, which is the wrong way round. +1 to address this. > > Other comments I've seen: > > > > * Add Blue or Violet noise (4 votes) > > That could certainly be done if there is a demand. The expressed demand I've seen is "4 votes" :=) but that doesn't mean it should not be considered. > Is there an actual definition of "Violet noise"? Wikipedia http://en.wikipedia.org/wiki/Colors_of_noise#Blue_noise thinks the distinction is that blue has a 3 dB per octave increase with increasing frequency, and violet a 6 dB increase. > Violet noise could potentially carry a health warning for tweeters. > > > > * Make the peaks of brown and white what the user asked > > for. 0.5 amplitude means that Amplify gives you + 6 dB > > and certainly the noise peaks should not get louder the > > longer the noise (3 votes) Sorry for duplicating the original user typo there - as you realised the comments are about amplitude of brown and pink noise. > The new Brownian noise largely solves this. Except for very short > selections you get what you asked for. > I don't know of a good way to achieve the same predictability for Pink > noise, but the latest patch is consistently pretty close. > > The original noise generator code for 30 seconds or more at 44100 Hz > sample rate gives: > Pink noise: about 0.06% clipped samples > Brown noise: about 0.1% clipped samples > > The new code gives: > Pink noise: less than 0.001% clipped samples > Brownian noise: no clipping. > > For short tracks it is not possible to predict the peak level without > normalizing - this is just the nature of random noise. Until there are > a few cycles of the lowest frequency component there is no way to > predict the peak level. > > With the current patch, Pink noise can be expected to be within 1 dB > of the target level for durations greater than 100000 samples (about 5 > seconds at 44.1 kHz). Brown noise can be expected to be the exact > specified amplitude for durations greater than 2 seconds. Thanks for the explanation. I added to the Manual "By their nature, pink and brown noise may have a few peaks slightly above the requested amplitude" and an ednote about your proposed patch. Gale |
From: Richard A. <ri...@au...> - 2013-01-28 21:00:37
|
On Mon, 28 Jan 2013 00:39:30 +0000 Martyn Shaw <mar...@gm...> wrote: > I've had a look over your patch and done a few tests of my own. > The patch is basically good, but is it needed / wanted? > > The pink noise differences do extend the bandwidth of 'pink' down an > octave or two, but does anyone really care about that or want it? When I get my SPL meter (1/3 octave bands) working I am likely to want accurate (so rather better than -3dB) pink noise down to 40Hz as a test source, so I can be sure that the roll-off I see is due to the equipment, not the noise source. I'd certainly be worried if getting that with Audacity was a major problem - narrow band noise can always be created with a filter on the result. Richard |
From: Steve t. F. <ste...@gm...> - 2013-01-28 02:21:57
|
Thanks for reviewing the patch Martyn, On 28 January 2013 00:39, Martyn Shaw <mar...@gm...> wrote: > Hi Steve > > I've had a look over your patch and done a few tests of my own. The patch > is basically good, but is it needed / wanted? I'd say yes, which is why I wrote it :=) I know that I previously raised a question about possible speaker damage if the low frequency range was extended too far, but that was considering an extreme case of Brownian noise with a low apparent "loudness" but high amplitude sub-sonic frequencies (or even DC). With this patch I don't believe there is a problem because the "constrained" brown noise has a reasonable loudness and the sub-sonic content is not extreme. > > The pink noise differences do extend the bandwidth of 'pink' down an octave > or two, but does anyone really care about that or want it? Or would it harm > them? I think that was part of your original question. Putting the > roll-off an octave or two below my hearing seems a bit mad to me. The bandwidth of the pink noise is not really much different from now, but the roll-off is a little more precise. This is probably the least "necessary" change, but there is a measurable improvement in quality with a negligible impact on speed, so why not? > > On the Brown/Brownian noise, I don't like the clipping test and would rather > have a lower overall level. I was unsure at first about the clipping test, but after a lot of thought I decided to go with it. There is the theoretical / philosophical argument that perhaps we shouldn't mess with the randomness, but I don't think that this criticism is justified. When considering Brownian motion of water molecules, it does not suddenly cease to be "Brownian" just because the water is in a container, and yet the walls of the container impose a limit on the motion of the particles in similar fashion to the clipping test. Essentially, sample values "bounce off" the 0 dB limit rather than being clipped. We have no qualms about constraining the absolute values of white noise. All we are actually doing is biasing the random increment for a tiny percentage of sample values so that the waveform is kept within reasonable bounds. Without such a test there is a small but finite chance that the waveform could drift off into space. so we have put a lid on it to prevent such "evaporation". The patched version is a lot less constrained than Brownian noise from SoX, but even with the very modest amount used in this patch the overall "loudness" can be increased by more than 4 dB. I think that the benefit of not clipping heavily outweighs arguments against, as any clipping will create much more "damage" than constraining the absolute sample values for a few peaks. > And again I see no real reason to extend the LF > cutoff much below 20Hz. I agree, which is why the 6 dB/octave slope is "only" extended to 20 Hz. > We could change that in the original code by > setting fc at a different value, I think. I did try that, but to achieve a similar degree of linearity down to 20 Hz, the amount of sub-sonic frequencies was about 3 dB greater than the current patch. > > The fixes for the limitations at 2^18 samples are good, from what I can see. > Would you like to make a patch just for that, so I can commit it? > > For the 'brown' (brownian) noise, the original code had > b1=exp(-2*M_PI*fc/fs); > a0=1.0f-b1; > and we can see how the 'magic numbers' were generated. > http://www.idsc.ethz.ch/Courses/signals_and_systems/lectureNotes10.pdf > is an example. I am inclined to move that fc to 20Hz, and readjust the > normalisation factor, but I haven't tried that. I did try that, and also a more complex low pass filter, but neither worked as well as the leaky integrator method. One problem with filtering white noise is that the amplitude is highly dependent on the sample rate. For a track sample rate of 192 kHz the peak amplitude of Brown noise is about 3dB too low, whereas at for a sample rate of 8000 Hz the peak level is about 10 dB too high. The only adverse effect that sample rate has on the patched version is that at high sample rates the bandwidth does not extend as low as at 44.1 kHz, but even at 192 kHz sample rate it is no worse than the current version. Even this limitation has a benefit, in that if a user requires low frequency Brownian noise, they can produce it by generating with a low sample rate. The current Audacity "Brown" noise is definitely too light on the bass when listening on good speakers, so I think that this improvement is definitely justified. Now that the potential risk of excessive sub-sonic frequencies has been alleviated I'm very much inclined to go with the previously stated opinion of giving the user what it says on the tin. Steve > > Perhaps a solution to this would be to have an extra option on the noise > generator dialog to set the LF roll-off of these generators to some > frequency. That way users could get what they want. This would be a > 'rather advanced' option however. Are there any user request for this? > > TTFN > Martyn > > PS Steve sent the following useful Nyquist code to run at the "Nyquist > Prompt" effect > > ;; print the % of clipped samples (mono tracks only) > (setq clipped > (do ((count 0) > (val (snd-fetch s)(snd-fetch s))) > ((not val) count) > (if (> (abs val) 1)(setq count (1+ count))))) > (print (* 100 (/ clipped len))) > > > On 26/01/2013 20:58, Steve the Fiddle wrote: >> >> Patch to upgrade pink noise and brown (Brownian) noise. >> >> The pink noise uses Paul Kellet's high quality pink noise filter. >> >> "Brown" noise has been renamed "Brownian" and uses "leaky >> integration". Peaks are constrained to within 0dB (a little trick that >> I picked up from the SoX code) so the Brownian noise is now a bit >> louder than it would otherwise be, without any clipping. >> >> The glitch that was occurring each 2^18 samples in both pink and brown >> noise has been fixed. >> >> Steve >> >> >> >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> >> >> >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > |
From: Martyn S. <mar...@gm...> - 2013-01-31 01:23:39
|
On 28/01/2013 02:21, Steve the Fiddle wrote: > Thanks for reviewing the patch Martyn, > > On 28 January 2013 00:39, Martyn Shaw <mar...@gm...> wrote: >> Hi Steve >> >> I've had a look over your patch and done a few tests of my own. The patch >> is basically good, but is it needed / wanted? > > I'd say yes, which is why I wrote it :=) Fair enough :) > I know that I previously raised a question about possible speaker > damage if the low frequency range was extended too far, but that was > considering an extreme case of Brownian noise with a low apparent > "loudness" but high amplitude sub-sonic frequencies (or even DC). With > this patch I don't believe there is a problem because the > "constrained" brown noise has a reasonable loudness and the sub-sonic > content is not extreme. > >> >> The pink noise differences do extend the bandwidth of 'pink' down an octave >> or two, but does anyone really care about that or want it? Or would it harm >> them? I think that was part of your original question. Putting the >> roll-off an octave or two below my hearing seems a bit mad to me. > > The bandwidth of the pink noise is not really much different from now, > but the roll-off is a little more precise. This is probably the least > "necessary" change, but there is a measurable improvement in quality > with a negligible impact on speed, so why not? OK, I can go with that. >> >> On the Brown/Brownian noise, I don't like the clipping test and would rather >> have a lower overall level. > > I was unsure at first about the clipping test, but after a lot of > thought I decided to go with it. > > There is the theoretical / philosophical argument that perhaps we > shouldn't mess with the randomness, but I don't think that this > criticism is justified. When considering Brownian motion of water > molecules, it does not suddenly cease to be "Brownian" just because > the water is in a container, and yet the walls of the container impose > a limit on the motion of the particles in similar fashion to the > clipping test. Essentially, sample values "bounce off" the 0 dB limit > rather than being clipped. Hmm. OK. But why have the container so small? We can be closer to 'ideal' (no container) if we make the container bigger (== the signal smaller). It's always going to be a compromise. I'd rather have a smaller percentage of samples hitting the limit (and I have been testing with 10 million samples) > We have no qualms about constraining the absolute values of white > noise. (This is a misconception about 'white' noise. White noise has no correlation from sample to sample but has no restriction on the pdf. I used to use AWGN (additive white Gaussian noise) in a project I worked on, since it was the most appropriate; independent noise samples but with a Gaussian (Normal) distribution. It's still 'white'.) All we are actually doing is biasing the random increment for a > tiny percentage of sample values so that the waveform is kept within > reasonable bounds. We are arguing about the definition of 'tiny' here, I think. Your implementation does 'look' clipped to me (and Gale). Without such a test there is a small but finite > chance that the waveform could drift off into space. Indeed. so we have put a > lid on it to prevent such "evaporation". Indeed, and the method seems reasonable, in the sense that it is easy and I can't think of anything better at the moment. > > The patched version is a lot less constrained than Brownian noise from > SoX, I have not looked at that. but even with the very modest amount used in this patch the > overall "loudness" can be increased by more than 4 dB. I think that > the benefit of not clipping heavily outweighs arguments against, as > any clipping will create much more "damage" than constraining the > absolute sample values for a few peaks. That seems reasonable. But again it's just a matter of at what level we do something. >> And again I see no real reason to extend the LF >> cutoff much below 20Hz. > > I agree, which is why the 6 dB/octave slope is "only" extended to 20 Hz. > >> We could change that in the original code by >> setting fc at a different value, I think. > > I did try that, but to achieve a similar degree of linearity down to > 20 Hz, the amount of sub-sonic frequencies was about 3 dB greater than > the current patch. OK, thanks. You have spent much more time on this than me, and I trust your observations. >> >> The fixes for the limitations at 2^18 samples are good, from what I can see. >> Would you like to make a patch just for that, so I can commit it? Oh, go on! Just for a start! >> For the 'brown' (brownian) noise, the original code had >> b1=exp(-2*M_PI*fc/fs); >> a0=1.0f-b1; >> and we can see how the 'magic numbers' were generated. >> http://www.idsc.ethz.ch/Courses/signals_and_systems/lectureNotes10.pdf >> is an example. I am inclined to move that fc to 20Hz, and readjust the >> normalisation factor, but I haven't tried that. > > I did try that, and also a more complex low pass filter, but neither > worked as well as the leaky integrator method. One problem with > filtering white noise is that the amplitude is highly dependent on the > sample rate. For a track sample rate of 192 kHz the peak amplitude of > Brown noise is about 3dB too low, whereas at for a sample rate of 8000 > Hz the peak level is about 10 dB too high. OK, but where do you get the 'magic numbers' (0.997f and 0.05) from? If they are in some way derived from / related to the sample rate then we should include that in the code so that it works at all sample rates. If they are experimental and derived at 44100 could we scale them by fs/44100? > The only adverse effect that sample rate has on the patched version is > that at high sample rates the bandwidth does not extend as low as at > 44.1 kHz, but even at 192 kHz sample rate it is no worse than the > current version. Even this limitation has a benefit, in that if a user > requires low frequency Brownian noise, they can produce it by > generating with a low sample rate. > > The current Audacity "Brown" noise is definitely too light on the bass > when listening on good speakers, so I think that this improvement is > definitely justified. Now that the potential risk of excessive > sub-sonic frequencies has been alleviated I'm very much inclined to go > with the previously stated opinion of giving the user what it says on > the tin. I am 'for' changes along these lines. It is a minority sport and possibly won't get revisited in a while so just looking to get it the best we can at the moment. Thanks for all your input here Steve. Martyn > Steve > >> >> Perhaps a solution to this would be to have an extra option on the noise >> generator dialog to set the LF roll-off of these generators to some >> frequency. That way users could get what they want. This would be a >> 'rather advanced' option however. Are there any user request for this? >> >> TTFN >> Martyn >> >> PS Steve sent the following useful Nyquist code to run at the "Nyquist >> Prompt" effect >> >> ;; print the % of clipped samples (mono tracks only) >> (setq clipped >> (do ((count 0) >> (val (snd-fetch s)(snd-fetch s))) >> ((not val) count) >> (if (> (abs val) 1)(setq count (1+ count))))) >> (print (* 100 (/ clipped len))) >> >> >> On 26/01/2013 20:58, Steve the Fiddle wrote: >>> >>> Patch to upgrade pink noise and brown (Brownian) noise. >>> >>> The pink noise uses Paul Kellet's high quality pink noise filter. >>> >>> "Brown" noise has been renamed "Brownian" and uses "leaky >>> integration". Peaks are constrained to within 0dB (a little trick that >>> I picked up from the SoX code) so the Brownian noise is now a bit >>> louder than it would otherwise be, without any clipping. >>> >>> The glitch that was occurring each 2^18 samples in both pink and brown >>> noise has been fixed. >>> >>> Steve >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> >>> >>> >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Steve t. F. <ste...@gm...> - 2013-02-05 04:26:11
Attachments:
noise-gen-03.patch
|
This patch is against svn r12211 and supersedes the previous patches. The Pink noise generator is the same as previous patches, based on Paul Kellet "instrumentation grade" algorithm. (which I hope will be nice for Richard Ash when he gets his SPL meter working :=) The improvements in this version are to the Brownian noise. The waveform is less "constrained" than the previous version, so it doesn't "look clipped" even with 10 million samples duration, but durations as short as 1 second should still be very close (and not more than) the user selected peak level. The parameters for Brownian noise now take into account the sample rate to provide 6dB/octave from (close to) 20 Hz to (close to) the Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). The "ToDo" is also fixed by this patch, as is the 2^18 sample glitch bug. Steve |
From: Gale A. <ga...@au...> - 2013-02-05 15:06:49
|
Hi Steve, It doesn't compile for me in Windows 7 Unicode Release >Noise.cpp 26>..\..\..\src\effects\Noise.cpp(133) : error C3861: 'fmin': identifier not found 26>..\..\..\src\effects\Noise.cpp(134) : error C3861: 'fmax': identifier not found Gale | From Steve the Fiddle <ste...@gm...> | Tue, 5 Feb 2013 04:26:04 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > This patch is against svn r12211 and supersedes the previous patches. > > The Pink noise generator is the same as previous patches, based on > Paul Kellet "instrumentation grade" algorithm. (which I hope will be > nice for Richard Ash when he gets his SPL meter working :=) > > The improvements in this version are to the Brownian noise. The > waveform is less "constrained" than the previous version, so it > doesn't "look clipped" even with 10 million samples duration, but > durations as short as 1 second should still be very close (and not > more than) the user selected peak level. > > The parameters for Brownian noise now take into account the sample > rate to provide 6dB/octave from (close to) 20 Hz to (close to) the > Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). > > The "ToDo" is also fixed by this patch, as is the 2^18 sample glitch bug. > > Steve |
From: Steve t. F. <ste...@gm...> - 2013-02-05 15:59:31
Attachments:
noise-gen-04b.patch
|
Thanks Gale, I think Windows needs #include <math.h> New patch attached. Steve On 5 February 2013 15:05, Gale Andrews <ga...@au...> wrote: > > Hi Steve, > > It doesn't compile for me in Windows 7 Unicode Release > >>Noise.cpp > 26>..\..\..\src\effects\Noise.cpp(133) : error C3861: 'fmin': identifier not found > 26>..\..\..\src\effects\Noise.cpp(134) : error C3861: 'fmax': identifier not found > > > > Gale > > > | From Steve the Fiddle <ste...@gm...> > | Tue, 5 Feb 2013 04:26:04 +0000 > | Subject: [Audacity-quality] [Audacity-devel] Noise generators >> This patch is against svn r12211 and supersedes the previous patches. >> >> The Pink noise generator is the same as previous patches, based on >> Paul Kellet "instrumentation grade" algorithm. (which I hope will be >> nice for Richard Ash when he gets his SPL meter working :=) >> >> The improvements in this version are to the Brownian noise. The >> waveform is less "constrained" than the previous version, so it >> doesn't "look clipped" even with 10 million samples duration, but >> durations as short as 1 second should still be very close (and not >> more than) the user selected peak level. >> >> The parameters for Brownian noise now take into account the sample >> rate to provide 6dB/octave from (close to) 20 Hz to (close to) the >> Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). >> >> The "ToDo" is also fixed by this patch, as is the 2^18 sample glitch bug. >> >> Steve > > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2013-02-05 17:07:06
|
| From Steve the Fiddle <ste...@gm...> | Tue, 5 Feb 2013 15:59:24 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > I think Windows needs #include <math.h> > New patch attached. I restored Noise.cpp and Noise.h from HEAD, then patched and rebuilt into an empty build folder, but still get the same error. Gale > On 5 February 2013 15:05, Gale Andrews <ga...@au...> wrote: > > > > Hi Steve, > > > > It doesn't compile for me in Windows 7 Unicode Release > > > >>Noise.cpp > > 26>..\..\..\src\effects\Noise.cpp(133) : error C3861: 'fmin': identifier not found > > 26>..\..\..\src\effects\Noise.cpp(134) : error C3861: 'fmax': identifier not found > > > > > > > > Gale > > > > > > | From Steve the Fiddle <ste...@gm...> > > | Tue, 5 Feb 2013 04:26:04 +0000 > > | Subject: [Audacity-quality] [Audacity-devel] Noise generators > >> This patch is against svn r12211 and supersedes the previous patches. > >> > >> The Pink noise generator is the same as previous patches, based on > >> Paul Kellet "instrumentation grade" algorithm. (which I hope will be > >> nice for Richard Ash when he gets his SPL meter working :=) > >> > >> The improvements in this version are to the Brownian noise. The > >> waveform is less "constrained" than the previous version, so it > >> doesn't "look clipped" even with 10 million samples duration, but > >> durations as short as 1 second should still be very close (and not > >> more than) the user selected peak level. > >> > >> The parameters for Brownian noise now take into account the sample > >> rate to provide 6dB/octave from (close to) 20 Hz to (close to) the > >> Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). > >> > >> The "ToDo" is also fixed by this patch, as is the 2^18 sample glitch bug. > >> > >> Steve |
From: Steve t. F. <ste...@gm...> - 2013-02-05 19:10:01
Attachments:
noise-gen-06.patch
|
On 5 February 2013 17:05, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Tue, 5 Feb 2013 15:59:24 +0000 > | Subject: [Audacity-quality] [Audacity-devel] Noise generators >> I think Windows needs #include <math.h> >> New patch attached. > > I restored Noise.cpp and Noise.h from HEAD, then patched > and rebuilt into an empty build folder, but still get the same > error. I think I've found the answer. >From a Google search: "fmax was introduced in the C99 Standard. VC++ does not implement all the provisions of that Standard, including fmax." Sorry about that, please try this version (attached). Steve > > > > Gale > >> On 5 February 2013 15:05, Gale Andrews <ga...@au...> wrote: >> > >> > Hi Steve, >> > >> > It doesn't compile for me in Windows 7 Unicode Release >> > >> >>Noise.cpp >> > 26>..\..\..\src\effects\Noise.cpp(133) : error C3861: 'fmin': identifier not found >> > 26>..\..\..\src\effects\Noise.cpp(134) : error C3861: 'fmax': identifier not found >> > >> > >> > >> > Gale >> > >> > >> > | From Steve the Fiddle <ste...@gm...> >> > | Tue, 5 Feb 2013 04:26:04 +0000 >> > | Subject: [Audacity-quality] [Audacity-devel] Noise generators >> >> This patch is against svn r12211 and supersedes the previous patches. >> >> >> >> The Pink noise generator is the same as previous patches, based on >> >> Paul Kellet "instrumentation grade" algorithm. (which I hope will be >> >> nice for Richard Ash when he gets his SPL meter working :=) >> >> >> >> The improvements in this version are to the Brownian noise. The >> >> waveform is less "constrained" than the previous version, so it >> >> doesn't "look clipped" even with 10 million samples duration, but >> >> durations as short as 1 second should still be very close (and not >> >> more than) the user selected peak level. >> >> >> >> The parameters for Brownian noise now take into account the sample >> >> rate to provide 6dB/octave from (close to) 20 Hz to (close to) the >> >> Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). >> >> >> >> The "ToDo" is also fixed by this patch, as is the 2^18 sample glitch bug. >> >> >> >> Steve > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2013-02-05 21:15:26
|
| From Steve the Fiddle <ste...@gm...> | Tue, 5 Feb 2013 19:09:54 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > On 5 February 2013 17:05, Gale Andrews <ga...@au...> wrote: > > > > | From Steve the Fiddle <ste...@gm...> > > | Tue, 5 Feb 2013 15:59:24 +0000 > > | Subject: [Audacity-quality] [Audacity-devel] Noise generators > >> I think Windows needs #include <math.h> > >> New patch attached. > > > > I restored Noise.cpp and Noise.h from HEAD, then patched > > and rebuilt into an empty build folder, but still get the same > > error. > > I think I've found the answer. > From a Google search: > "fmax was introduced in the C99 Standard. VC++ does not implement all > the provisions of that Standard, including fmax." > > Sorry about that, please try this version (attached). > > Steve That patch compiles fine in Windows Unicode Release, thanks! See below. > >> On 5 February 2013 15:05, Gale Andrews <ga...@au...> wrote: > >> > > >> > Hi Steve, > >> > > >> > It doesn't compile for me in Windows 7 Unicode Release > >> > > >> >>Noise.cpp > >> > 26>..\..\..\src\effects\Noise.cpp(133) : error C3861: 'fmin': identifier not found > >> > 26>..\..\..\src\effects\Noise.cpp(134) : error C3861: 'fmax': identifier not found > >> > > >> > > >> > > >> > Gale > >> > > >> > > >> > | From Steve the Fiddle <ste...@gm...> > >> > | Tue, 5 Feb 2013 04:26:04 +0000 > >> > | Subject: [Audacity-quality] [Audacity-devel] Noise generators > >> >> This patch is against svn r12211 and supersedes the previous patches. > >> >> > >> >> The Pink noise generator is the same as previous patches, based on > >> >> Paul Kellet "instrumentation grade" algorithm. (which I hope will be > >> >> nice for Richard Ash when he gets his SPL meter working :=) > >> >> > >> >> The improvements in this version are to the Brownian noise. The > >> >> waveform is less "constrained" than the previous version, so it > >> >> doesn't "look clipped" even with 10 million samples duration, but > >> >> durations as short as 1 second should still be very close (and not > >> >> more than) the user selected peak level. Six minutes of brownian noise at 0.5 amplitude no longer looks very "flat topped" and the peak is -6 dB as expected. I got six individual clipped samples with six minutes of brownian at amplitude 1, which is less clipping than with the other noise types. Two seconds of brownian at 0.5 always seems to have a peak of - 6 dB. One second of brownian at 0.5 usually seems to have a peak of - 6 dB but the peak was -6.8 dB on the first try out of six. > >> >> The parameters for Brownian noise now take into account the sample > >> >> rate to provide 6dB/octave from (close to) 20 Hz to (close to) the > >> >> Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). I'm looking in Plot Spectrum at size 256, log, Hanning window and in that view the curve seems to be steeper for lower frequencies (for pink as well as brown). For example at: 352800 Hz amplitude 0.5, stereo track, 2 minutes 1 second duration I see 2000 Hz is -24 dB and 4000 Hz is -36 dB, so twice the expected drop in level (unless I'm misunderstanding). At 44100 Hz (otherwise as above), 200 Hz is at -14 dB and 400 Hz at -24 dB. You can begin to see the steeper slope at lower frequencies even at default size 512/log. Although HEAD isn't correct either at low sizes/log, I don't see the steepening of the slope there, so it's closer to -6 dB per octave at lower frequencies. What is the "optimal" view to judge this in Plot Spectrum? Gale > >> >> The "ToDo" is also fixed by this patch, as is the 2^18 sample glitch bug. |
From: Steve t. F. <ste...@gm...> - 2013-02-05 23:42:48
|
[snip] >> >> Nyquist frequency for all Audacity project rates (8000 to 384000 Hz). > > I'm looking in Plot Spectrum at size 256, log, Hanning window > and in that view the curve seems to be steeper for lower > frequencies (for pink as well as brown). For example at: > > 352800 Hz > amplitude 0.5, > stereo track, > 2 minutes 1 second duration > > I see 2000 Hz is -24 dB and 4000 Hz is -36 dB, so twice the > expected drop in level (unless I'm misunderstanding). > > At 44100 Hz (otherwise as above), 200 Hz is at -14 dB and > 400 Hz at -24 dB. > > You can begin to see the steeper slope at lower frequencies > even at default size 512/log. > > Although HEAD isn't correct either at low sizes/log, I don't > see the steepening of the slope there, so it's closer to -6 dB > per octave at lower frequencies. > > What is the "optimal" view to judge this in Plot Spectrum? > Set the "Size" as large as possible (16384). With a small "Size" setting there aren't enough "frequency buckets" for low frequencies and it makes the slope look much steeper than it really is. At the default size of 512 there is only one "frequency bucket" below 1000 Hz (689 Hz and the next is at 1378 Hz) so that one bucket catches everything below 1 kHz. At the largest size you'll see a reasonably accurate plot down to about 30 Hz or so and you should see that for Brownian noise at all sample rates, the slope starts to roll off at around 40 Hz so that it's just a couple of dB down from the theoretical level at 20 Hz. Although the Pink noise is optimised for 44100 Hz sample rate, that too looks good at other sample rates and I think it would be more effort than it's worth to try to optimise it further. Steve > > > Gale |
From: Rob S. <aq...@ya...> - 2013-01-24 08:18:34
|
----- Original Message ----- > From: Steve the Fiddle <ste...@gm...> > I think that both new versions are "better" (more > "Brownian") than the > current Audacity version. No doubt about it. > The question is, do we provide sub-sonic > brown noise and leave it to the user to filter out if they don't want > it, or are the noise generators intended to be "audio band" (20Hz - > 20kHz) generators? I really can't decide. It should come down to use-cases, if there are some where one is clearly better. If not, try to follow a standard (e.g. what do other DAWs/tools do?). Cheers, Rob |