Re: normalizing clipping 32bit wav files?

"Peter P." <[email protected]> writes:

> * 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?

SoX uses 32-bit integers internally, although some effects use
floating-point in their calculations.

> 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?

In this case, the clipping happens when the samples are read from the
file and converted to 32-bit integers.

Changing any of this would be a lot of work only for the sake of
"supporting" a certain type of invalid file.  What is the origin of
your bad files?  Can't you fix the problem there?

-- 
Måns Rullgård