[SoX-devel] [ sox-Bugs-3602130 ] SoX on Windows "Broken pipe" on specific byte values

[SourceForge.net <no...@so...>]

Bugs item #3602130, was opened at 2013-01-25 08:59
Message generated for change (Comment added) made by uklauer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3602130&group_id=10706

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bgr (bgrz)
Assigned to: Nobody/Anonymous (nobody)
Summary: SoX on Windows "Broken pipe" on specific byte values

Initial Comment:
When using sox with |sox pipe subcommands on Windows (tested on Windows 7 64-bit and Windows XP 32-bit - fails in cmd.exe, works in Cygwin), writing to the pipe will terminate prematurely depending on the value of the byte(s) currently written. Might be the case of pipes not treated as binary but changelogs mention that that's already fixed.
Among affected versions are 14.4.0 and 14.4.1rc2.

After a lot of experimenting I've distilled the following commands that will best showcase the problem:

sox -n -b 16 full.wav synth 3 sine 0.5 dcshift 1
sox -t wav -b 16 "|sox full.wav -t wav -b 16 -" wrong.wav

Explanation:
The first command will create the "control" wav file. The second will load it and try to dump it through pipe, but it'll fail at some point. Now the interesting thing:
The point of failure can be changed by tweaking the frequency of the sine in the first command (change 0.5 to something else). The reason I put "dcshift 1" and chose that small frequency is to postpone the failure, it has nothing to do with the cause of the problem itself. It took me a while to discover it, since sines with high frequency fail immediately. If you change 0.5 to 1, the resulting wrong wav's size will be the half of the one with freq 0.5, since the point of failure happens 2x sooner. If you change 0.5 to 0, the point of failure won't appear and the second command won't fail.

Note that this is by no means an edge case, what I actually want to do is something as simple as: 
sox "|sox -n -p synth 3 sine 300" out.wav
but that doesn't even output a file, at all (gives "can't open input pipe - premature EOF" + "error writing output file: Broken pipe"), only after half a day of messing with it I've managed to pinpoint this case that actually outputs files, so hopefully it'll help you fix the problem.

----------------------------------------------------------------------

>Comment By: Ulrich Klauer (uklauer)
Date: 2013-01-25 10:48

Message:
It looks very much like a binary mode vs. text mode problem indeed. Could
you try these three commands and report which one fails (or which ones
fail)?

sox "|sox -n -p trim 0 1 dcshift 47e-10" newline.wav
sox "|sox -n -p trim 0 1 dcshift 121e-10" ctrl-z.wav
sox "|sox -n -p trim 0 1 dcshift 452e-10" letter-a.wav

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3602130&group_id=10706