Enhancement: Removing swoosh noises

[Steve Crook]

I've got a number of LPs where one channel has repeating swoosh noises, each swoosh lasting no more than one second. When I look at the waveform in the cleanup view at 2-5000% I can see tiny spikes in the basic waveform, at lower zoom levels the wave just looks fatter than you'd expect.

They're impossible to remove by using normal click removal, but can be cleaned by doing manual repairs. At the default repair width a single manual repair follows the basic waveform really well and eliminates these tiny spikes quite effectively.

But even to remove a relatively short stretch needs a lot of manual repairs.

Would it be possible to select a region in the waveform and then have VS automatically apply a series of manual repairs to fill the selected region?

In the attached screenshot the waveform is 5000% and the highlighted repair is ~170 samples at 192kHz. I hope this explains what I'm trying to achieve...

[Paul Sanders (AlpineSoft)]

I'm not sure I understand this.  Do you mean that you want a single repair covering the entire region, or something else?  I don't understand what 'a series of repairs' might look like.

[Steve Crook]

> Do you mean that you want a single repair covering the entire region, or something else?

1. I select a region in the recording, say 1sec.
2. I ask VS to make a series of contiguous small repairs to that region

My experiments show that a series of relatively small repair regions fit the overall shape of the waveform really well, don't significantly clip peaks, or otherwise mess with the recording. But they do remove those very small peaks that make up this sort of noise. The wider the repair the poorer the fit to the waveform hence wanting a series of contiguous small repairs.

But, obviously, even for a single second, this could be a lot of repairs. At 10 samples per repair @ 192kHz it's ~18k repairs and I can see this would be disruptive for the VS UI as it stands and would pretty much destroy the corrections list. I guess it means inventing a completely new class of repair...

I think what I'm asking for is the equivalent of very fine sandpaper. The sort we use to smooth a rough surface but without changing its shape in any way. I'm sure there are curve fitting algorithms that do this to remove sample noise, but it's not my field.

If I've still not explained myself properly, I apologise. I could provide an album where I've made a short section of these repairs by hand...

[Paul Sanders (AlpineSoft)]

OK, I think I understand now.  Do the repairs really need to be that narrow?  We have optimised VinylStudio to handle a large number of click repairs and something like 100k repairs total (probably more) works fine, but I can see that you might greatly exceed this with this approach if you want such tiny repairs.

[Steve Crook]

Smaller repairs give a better curve fit though the 10 sample width was an extreme I'm regretting suggesting. I'm not saying this is how it should be done, but the only way I could manage it with VS as it is at present.

The original screen print showed a repair of 170 samples but a repair of this width doesn't always leave the overall waveform intact on peakier sections. Perhaps up to 100 samples? If you're interested I can experiment with a few recordings and see what gets the job done with the least damage.

Everything that needs to be removed is generally very low level. Sometimes barely more than small bumps. See the attached image. This is at 5000% and significantly horizontally zoomed. You can see the unevenness in the waveform. It's audible as background noise, largely invisible on speakers unless the music level is low, but inescapable on headphones.

The higher level noise is still way below anything click repair would pick up.

[Paul Sanders (AlpineSoft)]

Hi Steve,

Yes, I'm interested, provided that I can implement it as a series of regular click repairs.  We could call it 'smooth waveform' or something.

100 samples is certainly more reasonable than 10, but it's still uncomfortably small.  So yes, do please experiment and make me an offer.  Also, how long are these swooshy bits (in terms of time) and how many are there please, on a representative recording?

[Steve Crook]

This is a section of a track with this sort of noise. Overall it lasted around 8 seconds, basically on one channel. The image is at 5000% vertically zoomed. It's probably at the worst case end of things mostly the sections of noise are shorter than this, though I've got a few LPs with lower level noise that extends across a whole side.

[Paul Sanders (AlpineSoft)]

OK, thanks.  How many repairs did you need put in and what repair width did you go for in the end?  Also, how long did it take you!

I'm in the throes of cleaning up some old and hairy code at the moment, but once that's done I'd appreciate a copy of that recording (and perhaps one or two other similar ones).  I do like the idea of adding this feature, if its feasible to do so without major surgery.

[Steve Crook]

I've come back to reheat this idea after a long break away because of domestic issues. I have a recording that illustrates what I'm trying to achieve. If you're still interested I'll zip it up and upload it (where?). This is a recording made at 24/192. Click repair was level 2, max protection.

On side 1 there's a pair of markers roughly 0.3 secs apart relatively close to the start of the first track. Zoom in to 5000% and expand and you'll see there are loads of short duration spikes off the main waveform. They don't make a loud noise, but there's a steady background splick, low level swoosh and all sort of other grumble. Many are <30 samples in length, a few are wider, probably up to 50 samples.

My approach has been to work along the waveform pressing 'R'. I've found these repairs are often too wide (212 samples) and in places make larger changes than I'd like. But, if I drop the repair width to <=50 samples I can remove the anomaly and the overall waveform keeps it's shape.

So if I do a load of these back to back I can perform a non destructive clean on a section of the waveform, but it's time consuming to do even a 1sec. But overall the result is less background noise and most of the irritating splicks disappear. Or at least I think that's the case.

So idea is that this would be a new form of repair mostly for use on lead in and lead out. Select a section of the track, choose the width of individual repairs, and one channel or both, and then press the button. A series of consecutive repairs would be done along the selection. It would show up in the repair list as a single repair.

[Paul Sanders (AlpineSoft)]

Hi Steve,

OK, why don't you send me the file.  I will then take a look and report back.  If you contact me direct I can send you a Dropbox link:

https://www.alpinesoft.co.uk/contact_us.aspx

I will also need your .mcf file, since that contains the location of those markers.

[Paul Sanders (AlpineSoft)]

Hello again Steve,

I've now looked at the files you sent me (for which much thanks) and what I can see that what you have (very patiently!) done is to insert 150 or so more-or-less adjacent 1ms-wide manual repairs spanning a 0.3 second interval.  The results do sound better to me than the results of automatic scanning, although not massively so.

It seems to me that 1ms repairs are fine for this - I don't see any need to make them any narrower - and if they were automatic repairs (instead of manual ones) then they don't really need to be made into one big one as it's possible to hide them in the list if one wishes to.  Put it this way, it's easier for us not to add a new repair type if we don't have to, although I will look into that.

So my proposal is to add a feature to construct a contiguous sequence of 1ms-wide repairs covering any predefined range (i.e. the selection) automatically.  If that can easily be made one big repair then we will do it, otherwise it will be a sequence of small ones.  How does that sound?  I'll see when we can schedule it for implementation, I do like the idea.

[Steve Crook]

Many thanks.

1ms sounds reasonable, though the width is partly from the default size of a repair when you press 'R' and my unwillingness to spend extra time tweaking the repair width I do occasionally trim the width to better fit the 'terrain' to which it's being applied.

I do have concerns about the number of repairs this is going to generate and how easy it'll be to manage them if it isn't a new repair type. For instance to be able to undo or just delete them or just resulting in a very large repairs panel. However, I think that's only something that can be worked through by trying something and seeing how it goes.

I'd be pleased to take an early alpha/beta to help out with testing/evaluation if you're agreeable.

[Paul Sanders (AlpineSoft)]

Yes, we're certainly agreeable (it would be a Beta).  It just depends on when we can take a look at it.

I'd hope that managing a batch of such repairs would not be something you'd often want to do - you'd just apply them, take a listen, and then move on.  We'll make sure that Undo undoes the entire batch and maybe we could put a couple of (different coloured?) markers in to delimit each batch.

But yes, I can see you might end up with a lot of repairs (but then scanning can do that anyway).  Once this procedure is automated, do you have any idea how many sections you might want to apply it to (and how long those sections would be)?  Seems to me it's only really worth doing for quiet passages so maybe it's not that bad.

[Steve Crook]

Yes, I'd rarely use it anywhere other than those tracks with extended fade in/out where the background noise becomes very apparent. I used to use the track fade in/out markers but found I didn't like the fade.

At the moment I de-click (level 2+max protection) and de-noise the track before placing the track markers and listening to fades and doing manual repairs. It's worked really well for me, I rarely have to do a more aggressive de-click pass.

But there are always cases like those in the sample I sent you. Probably in areas no more than 1s and often less, of repetitive noise

The aim isn't perfection just something where the noise is sufficiently background when listening on headphones.

[Paul Sanders (AlpineSoft)]

Thanks, that's helpful.  I'll look into this when I can.