Martin Guy <martinw...@gmail.com> wrote:
> Hi all
>
> I'm looking at launching external programs to decode a million other
> formats automatically and have run into a mystery I cannot fathom.
>
>
> sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f ircam -" 'Candy
> Toy.wav'
>
> works but
>
> sox "|ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" 'Candy
> Toy.wav'
>
> fails saying
>
> sox FAIL formats: can't open input `-': can't find sox file format
> identifier
>
> as do
>
> -f wav sox FAIL formats: can't open input `-': WAVE: RIFF header not
> found
> -f aiff sox FAIL formats: can't open input `-': AIFF header does not
> begin with magic word `FORM'
>
> though
>
> ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox -" > 'Candy Toy.sox'
>
> sox 'Candy Toy.sox' 'Candy Toy.wav'
>
> works.
>
>
> Is it because ffmpeg is seeking back in the file and rewriting the header
> once it's decoded? Nope:
>
> ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | cat > 'Candy
> Toy.sox'
>
> cat 'Candy Toy.sox' | sox - 'Candy Toy.wav'
>
> works too.
>
>
> What's the difference for sox between that last command pair that works and
>
> ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | sox - 'Candy
> Toy.wav'
>
> or
>
> ffmpeg -loglevel quiet -i 'Candy Toy.wma' -f sox - | cat | sox - 'Candy
> Toy.wav'
>
> that don't?
>
>
> And how come -f ircam works in the simple pipeline invocations but -t
> {wav,aiff,sox} don't?
Looks like if you specify input format via `sox -t sox', it
consistently works, but inconsistently w/o -t on the input.
I don't have a wma, but with flac this fails after a while:
n=0
while sox '|ffmpeg -loglevel quiet -i in.flac -f sox -' out.wav
do
n=$((n + 1))
done
echo $n # I got to 14
However, with `-t sox' it hasn't failed after a few minutes:
n=0
while sox -t sox '|ffmpeg -loglevel quiet -i in.flac -f sox -' out.wav
do
n=$((n + 1))
done
echo $n
I suspect scheduling + stdio/pipe buffering unpredictability
causes format detection to fail without `-t sox' if a read is
too small. Most likely sox needs to repeat fread(3) during the
detection phase to ensure the buffer is actually full enough.
With cat(1) in the middle, the input sox sees probably becomes
more predictable if cat buffers output into larger chunks before
sox sees it. ffmpeg probably makes small write(2) calls which
sox can't handle since I've never had a problem with sox writing
to sox via "|sox ..." inputs (which I use nearly every day in
scripts).
(not really feeling like reading code atm to confirm).
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
