Re: normalizing clipping 32bit wav files?

"Peter P." <[email protected]> Tue, 23 May 2023 12:38:30 +0200
Newsgroups gmane.comp.audio.sox
Message-ID <[email protected]>
* Måns Rullgård <[email protected]> [2023-05-22 21:32]:
> "Peter P." <[email protected]> writes:
> 
> > Hi list,
> >
> > I have a 32bit wav file in 0x3 => WAVE_FORMAT_IEEE_FLOAT with samples
> > outside of -1 and 1 which will be clipped at playback. 
> >
> > Using 
> >  sox in.wav out.wav norm -1 
> > will clip these files as well instead of leaving the original waveform
> > intact. Audacity is able to do this.
> >
> > Is this intentional, if not is this known, should I be filing a bug
> > report?
> 
> Such files are not valid according the specification, so it's not a bug.
> If something is producing files with values outside of ±1, it is broken
> and should be fixed.
> 
> That said, I'm not in principle opposed to adding a command line option
> to scale the input by some specified factor.  However, due to the way
> the code is structured, doing so is not a trivial matter.  Bear in mind
> that SoX is old, from a time when floating-point was often slow, if were
> lucky enough to have it at all.
If I understand it correctly, SoX is using (at least) 32bit floating
point numbers internally, no? I think we do not need a command line
option to scale the input by a certain factor, we have the "norm" and
"gain" effects to do that. Do you know where the clipping of values
outside of -1 and 1 happens for 32bit input files? Does it happen when
SoX reads the file, or when it applies an effect, or when it writes a
file?

Thanks again,
Peter