I need to increase the volume in Batch Processing except if it would cause clipping. How may I do this?
I see no Change Voume ( ) Reduce average level to avoid clipping or ( )
Abort processing if clipping is required.
Thanks.
Change volume without clipping
-
DewDude420
- Posts: 1171
- Joined: Fri Mar 11, 2005 11:15 pm
- Location: Washington DC Metro Area
- Contact:
I'm not sure if I understood you correctly, but the Maximize does allow you to specific an amount for the new volume change. When you click Maximize, there is an option called New Maximum where you can set your values (eg. 1, 1.5, 2.0). A 1.0 is essential no change.Sorry to be unclear - I need an increase of a specified amount a la Change Voume, and Maximise does not support that.
Here's a little trick...
Run Maximize. It will report the current maximum. Make a note of that, and click Cancel.
Now, you know how much "headroom" you have. For example, if the current peak is -1.5dB, you can increase the level by 1.5dB (or less) without clipping.
Of course, if it reports 0dB you cannot increase the gain without clipping.
Note that GoldWave can temporarily store values above 0dB. But if you save the file (as a regular WAV file), it will get clipped.
Since this involves human interaction, I'm not sure if you will be able to use any batch processing. But, since it appears that you may need to make different level adjustments to each file, you may not be able to automate this anyway.
Run Maximize. It will report the current maximum. Make a note of that, and click Cancel.
Now, you know how much "headroom" you have. For example, if the current peak is -1.5dB, you can increase the level by 1.5dB (or less) without clipping.
Of course, if it reports 0dB you cannot increase the gain without clipping.
Note that GoldWave can temporarily store values above 0dB. But if you save the file (as a regular WAV file), it will get clipped.
Since this involves human interaction, I'm not sure if you will be able to use any batch processing. But, since it appears that you may need to make different level adjustments to each file, you may not be able to automate this anyway.
I don't actually think it's possible to do what you want short of writing a custom plug-in; it's a fairly specialized requirement so I would doubt if any software would support it.
The best I can offer is a non-batch method, but it will get the result quicker and easier than doing each file individually.
1. Merge the files.
2. Open the merged file.
3. Increase by the specified amount - don't worry if it causes clipping for now.
4. Run maximize, note the position where it exceeds 1, and cancel.
5. Select the cues before and the position as start and end, then maximize to 1.
6. Repeat 4 and 5 until there are no more such points.
7. Split the file.
The best I can offer is a non-batch method, but it will get the result quicker and easier than doing each file individually.
1. Merge the files.
2. Open the merged file.
3. Increase by the specified amount - don't worry if it causes clipping for now.
4. Run maximize, note the position where it exceeds 1, and cancel.
5. Select the cues before and the position as start and end, then maximize to 1.
6. Repeat 4 and 5 until there are no more such points.
7. Split the file.
And it would be fairly trivial to add, but how many people actually need or want to do it this way? It seems as though your requirement to have change volume with clipping protection through batch processing is something that has only ever come up once - this time.chrisjj wrote:> it's a fairly specialized requirement
I cannot see how. Clipping protection was added to Match volume - it just hasn't yet been added to Change Volume.
To be honest I can't see how it would be useful, you'll achieve nothing that isn't already do-able using the method I gave above.
> It seems as though your requirement to have change volume with
> clipping protection through batch processing is something that has only
> ever come up once - this time.
You're wrong.
> To be honest I can't see how it would be useful, you'll achieve nothing
> that isn't already do-able using the method I gave above.
It would achieve the ability to meet the requirement using batch processing.
> clipping protection through batch processing is something that has only
> ever come up once - this time.
You're wrong.
> To be honest I can't see how it would be useful, you'll achieve nothing
> that isn't already do-able using the method I gave above.
It would achieve the ability to meet the requirement using batch processing.
chrisjj,
You might try the Hydrogenaudio Froum. A lot of people participate in that forum, and they are using lots of different audio software for lots of different purposes. Somebody there might have a solution for you.
Chris (GoldWave's developer) is generally open to suggestions. He monitors the forums and sometimes responds. If he thinks it's a good idea, he will add it to a future version. You can also contact Chris directly via the Support Web Form. I tend to agree that this is an unusual requirement. So, it might be useful to "sell the idea" by explaining (to Chris) exactly what you are doing, why maximize doesn't work for this application, why all of the files need exactly the same adjustment yet some files clip with this "standardized" adjustment, etc.
If you can't find any software to do this, and if you're not in a hurry, you might try the Audacity Forum. Audacity is open source, so any programmer can create a new version with new features. You just need to convince one programmer that it's a useful feature. (I don't know if Audacity currently supports batch processing).
A programmer could also create a plug-in for GoldWave, but I suspect there are far more programmers "playing around" with Audacity, so your odds are better.
Personally, I've never used batch processing. Although there are things that I do fairly routinely, I've just never had a situation where several files needed the exact same editing/processing/filtering... Most audio editing/processing requires human-monitoring and human-judgment.
You might try the Hydrogenaudio Froum. A lot of people participate in that forum, and they are using lots of different audio software for lots of different purposes. Somebody there might have a solution for you.
Chris (GoldWave's developer) is generally open to suggestions. He monitors the forums and sometimes responds. If he thinks it's a good idea, he will add it to a future version. You can also contact Chris directly via the Support Web Form. I tend to agree that this is an unusual requirement. So, it might be useful to "sell the idea" by explaining (to Chris) exactly what you are doing, why maximize doesn't work for this application, why all of the files need exactly the same adjustment yet some files clip with this "standardized" adjustment, etc.
If you can't find any software to do this, and if you're not in a hurry, you might try the Audacity Forum. Audacity is open source, so any programmer can create a new version with new features. You just need to convince one programmer that it's a useful feature. (I don't know if Audacity currently supports batch processing).
A programmer could also create a plug-in for GoldWave, but I suspect there are far more programmers "playing around" with Audacity, so your odds are better.
Personally, I've never used batch processing. Although there are things that I do fairly routinely, I've just never had a situation where several files needed the exact same editing/processing/filtering... Most audio editing/processing requires human-monitoring and human-judgment.
I'm a programmer myself, and I've experimented with GW's plug-in architecture in the past, so I can tell you that this would be utterly trivial to implement.
I can also tell you that the reason why it's available for "match" is that "match" pre-scans the entire wave before letting you select settings, so it is able to predict in advance if it will clip. "Change" doesn't pre-scan, so it can't predict in advance - implementing it in the current "change" effect would require somewhat more work than implementing it as a plug-in. There would be 3 main ways to do this:
1) Add a pre-scan to "change" - a lot of people would be seriously unhappy about this. Significantly more, I expect, than would be happy about the addition of the option. (This, incidentally, would be easiest way, and probably the way to go with a plug-in implementation).
2) Detect if the operation is selected when you click on "OK", then run a pre-scan before applying the change. Might work well, and if I was doing it in the built-in operation, that's the way I'd do it.
3) Change the volume without a pre-scan, testing each changed sample for a clip, and aborting and undoing changes so far if it gets one. Could be rather messy, and it would at the very least require one conditional (is the option selected?) to be added to each volume change operation, which would slow down regular changes owing to the conditional testing and branching required.
I can also tell you that the reason why it's available for "match" is that "match" pre-scans the entire wave before letting you select settings, so it is able to predict in advance if it will clip. "Change" doesn't pre-scan, so it can't predict in advance - implementing it in the current "change" effect would require somewhat more work than implementing it as a plug-in. There would be 3 main ways to do this:
1) Add a pre-scan to "change" - a lot of people would be seriously unhappy about this. Significantly more, I expect, than would be happy about the addition of the option. (This, incidentally, would be easiest way, and probably the way to go with a plug-in implementation).
2) Detect if the operation is selected when you click on "OK", then run a pre-scan before applying the change. Might work well, and if I was doing it in the built-in operation, that's the way I'd do it.
3) Change the volume without a pre-scan, testing each changed sample for a clip, and aborting and undoing changes so far if it gets one. Could be rather messy, and it would at the very least require one conditional (is the option selected?) to be added to each volume change operation, which would slow down regular changes owing to the conditional testing and branching required.
> 1) Add a pre-scan to "change"
I agree unconditionally prescanning would be poor.
> 3) Change the volume without a pre-scan, testing each changed sample
> for a clip, and aborting and undoing changes so far if it gets one. Could
> be rather messy, and it would at the very least require one conditional
> (is the option selected?) to be added to each volume change operation
I think not, since that conditional could be outside the loop. Though the 'did it clip?' conditionals would not, I think the overhead they incurred would be tiny.
I agree unconditionally prescanning would be poor.
> 3) Change the volume without a pre-scan, testing each changed sample
> for a clip, and aborting and undoing changes so far if it gets one. Could
> be rather messy, and it would at the very least require one conditional
> (is the option selected?) to be added to each volume change operation
I think not, since that conditional could be outside the loop. Though the 'did it clip?' conditionals would not, I think the overhead they incurred would be tiny.