* Måns Rullgård <mans@xxxxxxxxx> [2023-05-22 21:32]: > "Peter P." <peterparker@xxxxxxxxxxxx> 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 _______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
