@scorpdt: actually, you're report isn't quite correct
Audio encoding does in fact work. But using your source, BeSweet doesn't act like it normally does. Besweet writes progress reports to the commandline.
Normally such output looks like this:
[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...
[00:00:00:032] | Maximum Gain Found : 128.7dB
[00:00:00:064] | Maximum Gain Found : 122.1dB
....
transcoding ...
[00:00:00:640] transcoding ...
[00:00:00:672] transcoding
In order to compute the percentage, I use the last "Gain found" line as the audio length, then compare the value in a transcoding line with that value. Now here's a snippet of how audio encoding looks using your source file:
[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...
[00:00:00:072] | Maximum Gain Found : 0.0dB
[00:00:00:072] |
[00:00:00:040] Asserting negative delay..
[00:00:00:064] transcoding ...
[00:00:00:088] transcoding ...
As you can see, there is no gain finding for reasons beyond me. I tried without the delay but that seems to have no influence. I've also used the exact same settings for both files. And since we don't have an audio format mismatch (encoding a 2.0 source to 5.1 will give weird timestamps).. it's BeSweet's doing. I basically have to capitulate here.. only DSPGuru can tell why BeSweet reacts like that. But, in order to still allow you to encode, I have added a sanity check to my percentage finding algorithm.. if it gets a value that is too large (like in your case), I'll simply set it back to the maximum allowed value.. 100%. It'll look like it is done right away, but I'm afraid there's really not much more I can do.