You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have a waveform that is close to peak 0+-dB then there's a decent chance that, after running it through 432Hz Batch Converter, the resulting output will actually be clipped (especially if resampling to substantially higher sample rates).
I have a particular waveform that I had to de-amplify to have a peak of around 1.2dB before running it through 432Hz Batch Converter in order for the result to not be clipped, especially compared to a copy of the same waveform that was normalized.
Here's the normalized sample of it (encoded as 32bit WavPack):
I was able to use the Replay Gain scanner in foobar2000 in order to measure the average loudness whereby I could put hard numbers to seeing that there was about a full 1dB difference of perceived volume between the two waveforms even though, if I normalized both of the resulting waveforms, there'd only be like 0.1dB or 0.2dB of a difference in peak, implying that the originally-normalized version has about 1dB of its waveform peaks clipped.
Alternatively, if I output the normalized waveform to M4A/AAC in 432Hz Batch Converter and then do an "amplify" process in Audacity, then I can see that there's a bit under 1dB of the waveform that's being clipped but is still preserved via the format's floating-point nature.
(normally when outputting to 32bit WAV you should be able to similarly de-amplify the resulting waveform and recover the clipped data, but with that format the clipped data is missing which is why I previously created issue #17)
Ideally it'd probably be best to have an on/off toggle setting labeled something like prevent clipping which simply reduces the gain of any waveform that would ordinarily clip until it no longer clips.
EDIT: Even though github is dumb and doesn't let you attach audio files, it seems to only look at the file extension. This means that you can actually "cheat" and just manually rename the file extension to something used for video files or the like (e.g. mp4 or webm). Therefore, with this "cheat", I've attached a copy of the above wavpack file albeit with an mp4 file extension (media players picky about extensions matching their actual format, e.g. foobar2000 or Audacious, will require you to first manually rename the .mp4 extension to .wv; video players don't seem to care as much however, e.g. VLC and mpv):
If you have a waveform that is close to peak 0+-dB then there's a decent chance that, after running it through 432Hz Batch Converter, the resulting output will actually be clipped (especially if resampling to substantially higher sample rates).
I have a particular waveform that I had to de-amplify to have a peak of around 1.2dB before running it through 432Hz Batch Converter in order for the result to not be clipped, especially compared to a copy of the same waveform that was normalized.
Here's the normalized sample of it (encoded as 32bit WavPack):
I was able to use the Replay Gain scanner in foobar2000 in order to measure the average loudness whereby I could put hard numbers to seeing that there was about a full 1dB difference of perceived volume between the two waveforms even though, if I normalized both of the resulting waveforms, there'd only be like 0.1dB or 0.2dB of a difference in peak, implying that the originally-normalized version has about 1dB of its waveform peaks clipped.
Alternatively, if I output the normalized waveform to M4A/AAC in 432Hz Batch Converter and then do an "amplify" process in Audacity, then I can see that there's a bit under 1dB of the waveform that's being clipped but is still preserved via the format's floating-point nature.
(normally when outputting to 32bit WAV you should be able to similarly de-amplify the resulting waveform and recover the clipped data, but with that format the clipped data is missing which is why I previously created issue #17)
Ideally it'd probably be best to have an on/off toggle setting labeled something like
prevent clipping
which simply reduces the gain of any waveform that would ordinarily clip until it no longer clips.EDIT: Even though github is dumb and doesn't let you attach audio files, it seems to only look at the file extension. This means that you can actually "cheat" and just manually rename the file extension to something used for video files or the like (e.g. mp4 or webm). Therefore, with this "cheat", I've attached a copy of the above wavpack file albeit with an mp4 file extension (media players picky about extensions matching their actual format, e.g. foobar2000 or Audacious, will require you to first manually rename the
.mp4
extension to.wv
; video players don't seem to care as much however, e.g. VLC and mpv):The text was updated successfully, but these errors were encountered: