On 03/11/24 07:52, Martin Guy wrote:
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
In case you tried this, found it worked and assumed that I'm mad...
Today, instead, all the failing cases worked fine and *I* thought I was
mad. The only difference today was that I had a background process
running 100% on one of the two CPUs. Stopped that, it failed again every
time. With the background process running again it failed about once in
seven runs, so is timing-dependent.
It turns out to be because ffmpeg writes a few bytes of WAV header to
the pipe, sox reads them, ffmpeg writes again, sox reads again, and when
the file autodetection code tries to rewind the pipe back to 0, stdio no
longer has the initial data in its buffer.
It's resolved by dumping the pipe rewinding hacks completely and
inplementing an in-house pipe rewinder that, when doing auto-detection
from a pipe (the only use case of pipe rewinding), it remembers the
first block of data and returns it again later before switching to
regular stdio reading for the rest of the data.
I'm happy this bit me and seems resolved now because the plethora of
different pipe rewinding hacks for different libc versions was getting
silly and has caused no end of grief to maintainers of unusual distros.
Implemented as https://codeberg.org/sox_ng/sox_ng/commit/69751b3
M
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
