Re: normalizing clipping 32bit wav files?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





> For the issue I have brought up I would it be sufficient to only
> have the software part that reads in the file to not clip the values and
> apply the "gain" and/or "normalize" effects before converting to 32-bin
> integers for all the other effects. Not super elegant, but possibly
> more easier than changing all effects?

One reason why some might sometimes use the FP data type is to avoid clipping when using certain kinds of effects, thereby avoiding redos.   Also, it allows direct representation of levels when coming off of a master tape, thereby always avoiding scaling.   It is important to precisely track levels on and off of master material for subsequent processing to maintain coherence.

I have a few digital images of analog master tapes, at least some are in FP format.   With FP, there is no need to worry about +3dB or even +9 dB peaks when doing certain processing that is level sensitive (e.g. NR.)  Whether or not a standard requires that the FP represent values outside of +-1, it IS used, and  it does happen.

SoX is definitely very wonderfully useful, so far for me, missing only the FP input scaling without clipping and a complete handling for 1st order EQ.   SoX has fewer low level technical flaws than my own software, by far.

*  Except for maintaining perfect master tape level matches, the missing FP input scaling does have some workarounds, but require conscious decision making as opposed to it 'just working'.

John

On Wednesday, May 24, 2023, 02:37:58 AM EDT, Peter P. <peterparker@xxxxxxxxxxxx> wrote:


Hi Thomas, Måns, list,

* Dr. Thomas Tensi <t.tensi@xxxxxx> [2023-05-23 17:10]:
[...]
> I understand that this does not directly help Peter with his
> problem.  But it means that at least for the effects
> allpass, band, bandpass, bandreject, bass, biquad, compand,
> equalizer, gain, highpass, lowpass, mcompand, overdrive,
> phaser, reverb, treble and tremolo there is a reference
> floating point implementation available as open-source.
Thank you Thomas, this is amazing work!

> And this implementation reproduces the command-line SoX
> "bit-exactly" (with a residual noise of -150dBFS, as shown
> in the documentation and the test cases), so you can be sure
> that command-line processing and floating point VST
> processing produce almost (!) the same audio.
>
> So if somebody volunteered, a step towards a floating-point
> SoX implementation would be not too complicated...
For the issue I have brought up I would it be sufficient to only
have the software part that reads in the file to not clip the values and
apply the "gain" and/or "normalize" effects before converting to 32-bin
integers for all the other effects. Not super elegant, but possibly
more easier than changing all effects?



_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users

[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux