If I want to maximize WAVs, resample, and change the bit rate, what would be the order of the plug-in chain in WaveLab’s batch processing?
resample - from/to what sample rate?
change the bit rate - presumably you mean truncating to 16-bit from a higher bit depth?
Is this batch processing a final processing stage for the files?
In my opinion, a guideline order for these processes might be resampling, maximising, truncation.
If by resampling and changing bit rate you mean to increase both, i would do that before Maximizing.
Remember NOT to apply Dither if you’re increasing Bit Rate.
If you mean reducing both i would Maximize first, then resample and reduce bit rate in the end (with or without Dither, that’s up to you).
Whatever the option, all processing, such as Maximizing, should be done with the maximum quality in the file (highest bit rate, highest sample rate).
But resampling can change the level, right? meaning that however you set the maximizer could be undone by the downsampling. So resampling should ideally happen before maximizing.
It would also depend upon the context of the processing - if this is part of an interim process or a final mastering chain.
No, resampling shouldn’t change the level.
That happening, there’s an error somewhere.
Applying any effect (reverb, maximizer, compressor, modulation, delay… any effect) to a lower sample rate file results in a process happening with lower definition.
Do all the audio manipulation and editing at higher sample rates and then, downsample.
That’s how it should be done.
EDIT: in fact, when Mastering i often upsample files, do the mastering process and then downsample to the rquired delivery Sample Rate.
Sample-rate conversion preserves overall gain very closely, but it can change certain peak levels, especially true peak. I’m not talking about WaveLab resampling. I’m talking about any resampling algorithm.
This is often misunderstood.
Resampling with any resampling algorithm can and does change the peak level and probably more often than you would think. The consequences may not matter for non level-critical applications and may or may not be applicable to your ‘upsampling for editing and processing’ case. However, where absolute accuracy is required, such as with files maximized to 0dBFS and then resampled, this can easily result in some of the processed files showing peak overs. The results vary according to the characteristics of the material being processed. If these were files being supplied to a client who was expecting pristine non-clipping audio then this result would of course be less than satisfactory. And such results would be less than satisfactory when using the batch processor for this kind of processing (the OP’s case). Some of the resulting files may have no digital overs whereas others will suffer the digital overs. In other words the results would be inconsistent.
Peak overshoots due to resampling are actually fairly easy to prove as follows:
- Take any short duration audio file with a sample rate of 48kHz which contains significant transient peaks (such as speech or drums) and instantiate Steinberg’s Maximizer plug-in in the effects rack of the Master section. Use the ‘Light Dance Master’ preset. Render in place. Audition the file and carefully observe the peak values in Wavelab’s Master section meter. You should see no clipping on the meters.
- Undo the processing of step 1 above. Instantiate Steinberg’s Maximizer plug-in in the effects rack of the Master section. Use the ‘Light Dance Master’ preset, as in step 1. Activate the Master section Resampling module set to 44.1KHz. Render in place. Audition the file again. Nine times out of ten you will now see digital peak clipping. And the overshoot will be worse for true peaks.
A) The signal level of the 48kHz file after applying the Maximizer plug-in processing only (render in place). NO CLIPPING
B) The signal level of the file after applying the Maximizer plug-in processing and downsampling to 44.1kHz (render in place). CLIPPING ON THE LEFT CHANNEL
P.S.
FYI RX mention SRC changing peak levels, at the foot of the following page under the title ‘WHEN TO USE THE POST LIMITER’: Resample - RX 9 Help
Yes, many work like this.
Whatever happens after modifying sample rate is the operator/engineer’s responsibility.
If peaks have changed, control them.
Apply a Limiter or whatever.
I stick with: apply all processing before reducing Sample Rate.
I think the OP was asking about Batch Processing - Normalizing and Resample at the Same time.
Having the Resampler plugin in Batch makes this a single task than to Resample changing output format and then Normalizing.
Therefore, the OP can use the below plugin chain as Stingray and PG advised in earlier posts.
In the Output File Format, change only the bit depth
And that might sometimes be bad practice, as a general rule for mastering. Any such guideline would also have to take into consideration the context of the processing and whether you are working to a spec with a strict maximum peak for the material, such as -1dBTP for example, bearing in mind that many clients would insist upon this.
Yeah sure, but this goes against your own advice since you are suggesting using a Limiter after resampling, not before. In the light of this, do you now at least accept that resampling can and does cause changes in the peak level?
Precisely!
Do the processing to the file.
Resample/Redither.
Resampling changed peaks? Tame them with a limiter or a Clipper, whatever suits your preferences better.
Apply Dither if you like.
That’s it. Basic M.O. for file processing.
Whenever the operator/engineer has access to two different Sample Rates of the same file, apply all processing to the highest sample rate one.
Absurd!
It’s the only correct practice.
You have two versions of the same file, one 44.1KHz and one 48KHz and have to adjust their level: do it on the 48KHz file and then downsample.
After downsampling peaks appear above the maximum allowed level?
Two options:
- undo and repeat the process one more time in the original file with a more conservative level.
- apply a limiter to tame those peaks.
It is so incredibly simple and basic that i can’t even figure out where the idea of processing a downsampled file came from.
It’s absurd, ridiculous, preposterous.
So many ways to do it without overloading peaks.
[facepalm]
@PauloMiranda you seem to be adept at changing goalposts and you seem to not wish to answer the basic premise or consider the importance of context. Maybe I should have wrote ‘that might not be good practice for all mastering workflows…’ but my comment was made in the context of applying resampling after maximization. Remember the OP was making a request with regard to the Batch processor. Presumably this was for processing multiple files, perhaps to a set standard with a fixed max peak.
Firstly, you said :
No, resampling shouldn’t change the level.
That happening, there’s an error somewhere.
I tried to be generous before but since you wish to be blunt I will do similar. That statement was just plain wrong and has no basis in truth. After I read that I simply laid out the facts as to how that statement is not true and provided a practical proof / example with regard to the subject.
And now you are saying:
After downsampling peaks appear above the maximum allowed level…
Repeatedly contradicting yourself would be my definition of ‘absurd’.
So which is it? Yes, downsampling can cause changes in the peak level? or No, downsampling does not or shouldn’t change the level (your words)? Yes or no?
So, you prefer to insist on picking on something that i said to save yourself from the fact that you know nothing about of what you’re talking about.
I am your buoy, right? Cool.
Yes, if peaks appear after downsampling it is operator error because it can be avoided. Simply adjust levels carefully before downsampling.
So, again, you sunk.
But whatever. Do it as you wish and see fit.
I’d rather keep on doing it well.
I’ll take that as a ‘yes’.
To put it in simple terms: Yes, downsampling will with very high probability increase the overall volume. This can become critical when the incoming file is already at 0db. The outgoing file will have clipping, if not in 32bit float.
Question: Can this occur also when upsampling?
I believe, but have no proof, that upsampling with an integer multiple will be fine.
So, from 44.1 kHz to 88.2 kHz or 176.4 kHz will be fine, as 48 → 96 → 192 kHz.
But 44.1 → 48 kHz ? I am not sure.
Down from 96 → 48 might be fine, but 96 → 88.1 kHz probably not, also 48 → 44.1 kHz.
So, yes this is indeed a very interesting topic, imho.
So, how to solve this to be sure?
Maybe work with -1db or even better -2 db during the full mastering stage, than resample and then apply normalization to 0db? This way, one may loose 1 or 2 db of dynamics, but does this really matter? Sure, there might be cases, when full dynamics is needed, but they might seem academic… and then 32 bit float or at least 24 bit int should be used, not 16 bit.
Of course, this is terrible, when this will be known, when it is too late already… there is always something to be learned. That’S what life is all about, imho. Learn, make mistakes, reflect on them, learn,…make mistakes… again and again…
Sisyphos knows more
For the mathematically inclined:
Check the theorem of Faber for approximations