[qyot27]

At least the way I'd understand it, AVStoDVD *should* be passing the script to the particular programs (where applicable), therefore whatever the program does to access AviSynth would matter more than whether AVStoDVD itself might use the VfW interface to talk to scripts. For FFmpeg this would mean accessing the library directly and - if using -acodec copy - getting out exactly whatever the audio format output from the script is.

ffmpeg -i input.avs -acodec copy output.wav

If the script outputs 16-bit integer, output.wav will be pcm_s16le. If it output 24-bit integer, it'll be pcm_s24le. If it output float, it'll be pcm_f32le. It's just copying the PCM samples output from AviSynth directly to the output file.

Originally Posted by manolito

I am not talking about WAV EXTENSIBLE or WAV 64 since these formats are not supported by SoX and Aften.

FFmpeg writes WAVE_FORMAT_EXTENSIBLE headers for 24-bit and Float output, but not for 16-bit.

For Aften, you can work around this using qaac as a passthrough:

ffmpeg -i test.avs -acodec copy -f wav - | qaac --silent -D - -o - | aften - output.ac3

(forcing -f wav is necessary so aften doesn't puke)

SoX and Aften do support WAVE_FORMAT_EXTENSIBLE, but not when piped by FFmpeg (this is discussed in this thread - the short version: some programs don't like the way FFmpeg writes the WAVE headers when piping). A standalone file with an extensible header does work, although I was testing with 30-second samples.

An alternative is to force FFmpeg to use a different format to pipe to SoX. WavPack works (and from how the docs read, the native libavcodec wavpack encoder only does lossless):

ffmpeg -i test.avs -acodec wavpack -f wv - | sox -t wv - output.wav

Although as sneaker_ger pointed out, avs2pipemod seems to handle this correctly without resorting to qaac passthrough tricks or using alternative pipe formats.