ffmprovisr
ffmprovisr copied to clipboard
amiaopensource
new recipe: change audio sample rate
Hey, this is more of a note to self - I think that this would be useful to document.
I'd just use -ar to do it, but perhaps there are better ways, @privatezero @jamessam? I guess sox might do it too, but an ffmpeg method of doing it would be ideal I guess.
For audio manipulations like time-stretching and pitch-shifting we compile FFmpeg --with-rubberband.
@kieranjol, are you thinking more a recipe for creating a down sampled mezzanine? (Like going from 96 kHz/24 bit -> 48 kHz/16 bit) Or manipulations like @retokromer was talking about?
Aye, I was thinking of going from 96/24 to 48/16, I think I had some weird case where I needed to do that. It's so long ago that I forgot the specific use case!
Also from 96/24 (preservation) to 48/24 (mezzanine) is used in the archive world. A note at the other case would be sufficient.
Therefore I suggested, if we agree on including also more complex audio filtering, to consider rubberband as well.
@kieranjol maybe you were going to 44.1/16 to make files that were red book spec? Perhaps that would be a good recipe to create? Typically I have been using -ar when I have needed to, but I know FFmpeg supports another way - would have to test it out to see if there is an audible difference!
Also, would need to note dithering in that recipe, which as an aside reminds me that I have been testing a bit with triangular dither as opposed to the square dither currently in ffmprovisr - might be worth looking into!
Also, would need to note dithering in that recipe, which as an aside reminds me that I have been testing a bit with triangular dither as opposed to the square dither currently in ffmprovisr - might be worth looking into!
+1
Not entirely scientific, but I ran a little test using one of the test files here using different methods to go from 96 kHz to 44.1 kHz in FFmpeg, and then visualized the spectrum to see if I could notice any artifacts. It looks to me like both setting -ar and out_sample_rate are using the default FFmpeg resampler, so no difference there. libsox does seem to avoid that blip (of aliasing?) at the end, but my days of hearing above 18 kHz are behind me, so no idea if there is an audible difference.
out_sample_rate 44100
-ar 44100
-af aresample=resampler=soxr -ar 44100
Woah cool!I won't pretend to fully understand those graphs , but I have a rough idea of what you're saying. Thanks Andrew!
On 15 Nov 2017 23:45, "Andrew Weaver" [email protected] wrote:
Not entirely scientific, but I ran a little test using one of the test files here http://src.infinitewave.ca/ using different methods to go from 96 kHz to 44.1 kHz in FFmpeg, and then visualized the spectrum to see if I could notice any artifacts. It looks to me like both setting -ar and out_sample_rate are using the default FFmpeg resampler, so no difference there. libsox does seem to avoid that blip (of aliasing?) at the end, but my days of hearing above 18 kHz are behind me, so no idea if there is an audible difference.
out_sample_rate 44100 [image: resample] https://user-images.githubusercontent.com/12941699/32865616-b74f89e4-ca18-11e7-8f7a-83503d670f09.png
-ar 44100 [image: ar] https://user-images.githubusercontent.com/12941699/32865627-bdfc6b2c-ca18-11e7-99f5-d7b67b0a5be9.png
-af aresample=resampler=soxr -ar 44100 [image: soxr] https://user-images.githubusercontent.com/12941699/32865634-c23a1374-ca18-11e7-957d-02834943594b.png
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amiaopensource/ffmprovisr/issues/238#issuecomment-344767304, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEyvqMWLYGe63-C-upA2v6dfh-LWf8Vks5s23ezgaJpZM4PwURk .