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 <sox-users@xxxxxxxxxxxxxxxxxxxxx> 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.)JohnOn Wednesday, May 24, 2023, 03:30:19 PM EDT, Måns Rullgård <mans@xxxxxxxxx> wrote:"Dr. Thomas Tensi" <t.tensi@xxxxxx> 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
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
_______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
