1.5.4 BUG: Bad ffmpeg command for custom audio sample rate setting

[Jeff Roberson]

My machine: WinXP-Pro-32bit running WinFF version 1.5.4

I discovered this BUG today when trying to convert a bunch of 44.1 kHz stereo MP3 files to 32kHz mono WAV files.

First I selected the following preset: Audio->Wav for CD

Then I manually set the sample rate to 32000 (and Audio channels to 1) in the Audio Options tab.

Clicking convert results in a mono WAV file but with no change of sample rate frequency.

I looked at the ffmpeg command line and could see the problem right away:

ffmpeg.exe -y -i filename.mp3 -vn -r:a 32000 -ac 1 filename.wav
The change sample rate option is erroneously being set to: "-r:a 32000
" when it should be: "-ar 32000".

I managed to work around this bug by creating a new preset with the correctly encoded ffmpeg.exe command line option.

p.s. Today is my first day playing with WinFF (with its ffmpeg engine) - pretty cool app!

[BiggMatt]

It can vary. Different ffmpegs prefer different thing and then we change and they change back

--
You received this message because you are subscribed to the Google Groups "WinFF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to winff+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Roberson]

Yes, but WinFF should work correctly with the version of ffmpeg bundled with the WinFF download. It does not.

[Paul Gevers]

On 27-12-14 19:35, Jeff Roberson wrote:
> Yes, but WinFF should work correctly with the version of ffmpeg bundled
> with the WinFF download. It does not.

I agree, but Winff is also bundled elsewhere with other ffmpeg's (or
even libav's version). I also wouldn't have expected that ffmpeg would
go back to the old style. Maybe we can come up with some detection
algorithm, although those things tend to be a pain to keep supporting,
especially once they are not needed anymore, but nobody notices that.

In Debian I created an auto tester to at least test the presets shipped
with Winff against the current libav (for results see [1]). Maybe we
should have something similar for the Windows release, as it would have
detected the problem.

Paul

[1] http://ci.debian.net/packages/w/winff/unstable/amd64/