Subject:Auto Trim/Crop bug in 9.0c

Posted by: Avene

Date:8/21/2007 1:06:50 AM

I was just about to batch process 6700 drum samples when I came accross this problem.. Lucky!

Auto Trim/Crop trims the end of the sample to whatever the attack threshold is set at, not to the release threshold as it should.

I've not used Auto Trim/Crop for a while, so I'm not sure if this occurred in previous versions also. Any idea how soon this can be fixed or if there's an older build it still works in that I can use? I'd like to get these samples trimmed asap.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: Avene

Date:8/21/2007 4:40:42 PM

EDIT:

I tried it in Soundforge 7 and it doesn't work there either! So the the problem or bug must date back a few years at least. How could this have been missed?

But thankfully, it DOES work in Batch Converter 5b using the old Sonic Foundry version of Trim/Crop. So I'll be using that.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: ForumAdmin

Date:8/22/2007 6:58:31 AM

Actually, I think it goes back to Forge 6. That's truly weak. Guess it's not a very popular process, eh?

I've found and fixed the issue, so it will appear in future updates and versions.

If you need another solution, the effect itself is pretty trivial, so it could be reproduced (correctly) with a custom script without too much effort. Let me know if this would be helpful.

J.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: Avene

Date:8/22/2007 6:25:36 PM

Great, thanks for fixing that. There's one other part of it you might want to fix that also drives me crazy. In the current 9.0c version of auto trim crop, it trims the start point at the threshold, but doesn't move that start point to the zero crossing. If a fade in is then applied afterwards, the start point will still end up off axis. I'm guessing it may work the same for the end point too. Anyway, this worked fine in Soundforge/Batch Converter 5 that I've been using for the current batch of samples.

I'm surprised it hasn't been picked up before. Such a brilliant tool. Although I was still using Batch Convertor 5 up until upgrading to Soundforge 9, and don't think I'd used it on it's own in SF7.

How I use it is like this - I get a lot of free samples of the net, magazine cds etc. They're usually always badly edited with gaps at the start and end. So that's where auto trim crop and Batch Converter come in handy. For drum samples I like a nice sharp attack. After a bit of experimenting I've come up with some nice settings. Firstly I run them through the DC offset remove, normalise, and then auto trim crop with no fade in and the attack threshold at -12db (sounds drastic I know!), the release at a -46db threshold and a 50ms fade out. Now because the -12db threshold can result in a bit of a click, I then use a fade in. Now a minimum 1ms fade in would be way too long, so I use eelliott's Batch Converter With Selection Option script, set the start selection time to 0.00014ms (roughly 6 samples) and use the graphic fade in with the '-3 dB exponential fade in' preset which smooths out the attack. Then in case those first 6 samples I'm fading in contain the peak and the fade in reduces that, I then use a normalise again following this and then another 10ms fade out at the end which doesn't do any harm.

For the current batch of samples it became a bit time consuming. Firstly I thought I could do it all using the Batch Converter With Selection Option script. Then found the release threshold problem. So I went to use Batch Converter 5 for the DC offset remove, normalise and auto trim, but then found that the DC offset remove wasn't working in Batch Converter 5! Some of the samples had serious DC offsets. So it was back to SF9 for the DC offset removal and normalise, then to BC5 again for the trim crop, and finally back to SF9 for the graphic fade ins. To make things worse, some of the samples had problems and kept freezing the Batch Converter with Selection script. With the offending samples deleted, the job's now done!

Thanks for the offer of a custom script, but could that be used with the Batch converter with Selection Option script? I should really spend a bit more time learning a bit a about the scripting.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: mpd

Date:8/23/2007 7:08:09 AM

Actually, I use auto trim / crop to set precise handles on every single audio file I produce. Looking over my presets, though, I always use the same threshold for attack and release.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: ForumAdmin

Date:8/23/2007 1:52:08 PM

If you want to ensure that the edges of the auto-trim/crop result are zero, you should use the fade options inside that tool. Just a few milliseconds will be sufficient in most cases. For higher thresholds, you may want to use something bigger, but it's largely material dependent.

Just setting the first/last sample isn't going to have much of an effect. I'd have to look at the old version you are using, but I will venture that it is doing a small fade without telling you about it.

J.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: Avene

Date:8/23/2007 9:51:55 PM

Alright, here's the difference. Firstly a screen grab from the sample processed using Auto Trim / Crop in Batch Converter 5. (I hope these images work). It appears to add an extra sample at the start so it begins on the zero crossing. This is how I like it!

http://www.avene.org/images/BatchConverter5.png

Now here's how it works in Sound forge 9 using the same sample.

http://www.avene.org/images/SoundForge9.png

A 1ms fade in or more using Auto Trim Crop would be too long. That would equal about 45 samples. I'm using a graphic fade in length later on of roughly 6 samples using the script I mentioned to keep the sharp transient attack, but the graphic fade doesn't always fade up from zero if it's been trimmed off axis.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: ForumAdmin

Date:8/24/2007 2:24:43 PM

It turns out that the BC5 version enforces at minimum 1 sample fade, which isn't really a fade at all and amounts to sticking a zero on each end of the trim.

While this might work for your specific task, it is just moving the same initial discontinuity over one sample (and cooking it into the file). Can't say I'm too keen on restoring that behavior. In fact, I'd call it a bug.

It would be more appropriate to increase the resolution of the fade controls inside the effect and let the user specify fade lengths down to the sample level. The other curves we offer for edge fades might be a nice option, as well. I'll make a note of that.

Question: Why doesn't your post-trim graphic fade curve just start at zero (-Inf. dB)?

J.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: Avene

Date:8/25/2007 7:01:46 AM

If that's more like a bug, not a problem then.

Actually, yes, a user curve like you mentioned will do the trick. I didn't think of that. Normally I'd just use either the -3db or -6db exponential curves and neither of those go to zero at a 6 sample length, although the -6 does get close. The -20db curve does though, so I've created an S shaped curve somewhere in between those two, and it appears to work fine. Thanks for mentioning it. That along with the release threshold fix should keep me from having to go back to BC5 :)

One other unrelated thing I should mention. I once used the SF9 batch converter to process 200 or so samples through the free Nebula CM VST plugin from Computer Music magazine, and it crashed the batch converter a number of times. Not a serious problem as I could just continue processing the remaining samples each time it happened. No idea what caused it, but I guess could possibly be the plugin itself. The Nebula plugin works in a similar way to Focusrite's Liquid Mix, emulating the sound of classic preamps, compressors etc.

Subject:RE: Auto Trim/Crop bug in 9.0c

Reply by: Avene

Date:11/25/2007 5:34:46 AM

Just thought I'd check in here as it's been a few months now.

Is the 9.0d update due anytime soon with this fix?

Cheers,
Glenn