Re: normalizing clipping 32bit wav files?

Just curious, which specification are you referring to, that disallows
values outside the +1/-1 range?

While audio outside that range is clearly not reproducible, it's not
meaningless or useless or not even necessarily "broken."  In practice, most
audio software can input and output such files, and they can be useful as
part of a processing chain.  Not useful "on purpose," but rather, not
"invalid" simply because some stage didn't bother to normallize.

That's beside the point that SoX can't handle it, which is unfortunate but
understandable.

BTW, it's trivial to write a program that does nothing but normalize, that
could be used in a process chain that involves SoX, and that would be a lot
easier to do than to rework SoX to use floating point internally.

I use SoX regularly as part of my process when creating sampled
instruments, and it's incredibly handy to have a tool that's robust and
works using CLI, for batch processing of large numbers of sample files.  In
my case, I want to see if any stage produces (or would produce) clipping,
so how SoX works today is just fine for me.

Regards
Jeff


On Wed, 24 May 2023 at 22:20, John Dyson via Sox-users <
[email protected]> wrote:

>
> A lot of trouble dealing with FP files that have values bigger than +-1.0
> could be helped by hijacking the '-v' switch on input, and do the scaling
> before conversion from FP to integer.  This would allow working with FP
> files with the greater than +-1.0 values without going elsewhere to do the
> scaling.
>
> It might seem like a 'hack', but would also make it easier to deal with
> the FP files that exist in the real world.
>
> As it is now, I have to either fiddle around with a GUI program, or run my
> whole, slow decoder with all of it's complex threading to simply do the
> scaling from old DolbyA master tape images.  If SoX could support a simple
> scaling functionality ON INPUT before conversion from FP, a practical
> solution results.  (One can create local versions of the 'sndfile'
> utilities also, but using SoX is the easiest for the SoX user.)
>
> John
>
>
>
> On Wednesday, May 24, 2023, 03:30:19 PM EDT, Måns Rullgård <[email protected]>
> wrote:
>
>
> "Dr. Thomas Tensi" <[email protected]> writes:
>
> > So one has to change the internal and overall sample type
> > sox_sample_t from int32 to float or double and then
> > recompile _the whole system_ and see what happens.  I
> > haven't tried it yet, but my gut feeling is that there are a
> > lot of type incompatibilities due to the initial design
> > decision that samples are integers.
>
> That's exactly it.  Simply changing sox_sample_t from int to float would
> for sure break a lot of things.
>
> --
> Måns Rullgård
>
>
>
> _______________________________________________
> Sox-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sox-users
> _______________________________________________
> Sox-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

_______________________________________________
Sox-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sox-users