Watermarking .wav from stdin can cause SIGPIPE

[swesterfeld]

When watermarking a .wav file from stdin, audiowmark stops reading data after all samples have been read. However, there are valid .wav files that contain data after the actual samples. Here is one example:

$ wget https://github.com/sfzinstruments/karoryfer.weresax/blob/master/Samples/alto/a2_p_rr2_cnd.wav?raw=true -q -O test.wav
$ rifftree -s test.wav
RIFF(WAVE)-> (796900 Bytes)
            fmt ; (16 Bytes)
            data; (793728 Bytes)
            cue ; (28 Bytes)
            LIST(adtl)-> (74 Bytes)
                        ltxt; (20 Bytes)
                        labl; (11 Bytes)
                        note; (17 Bytes)
            _PMX; (2738 Bytes)
            DISP; (4 Bytes)
            SyLp; (184 Bytes)
            smpl; (60 Bytes)
$ strace -o trace dd if=test.wav bs=16 | audiowmark add - - f0 > /dev/null
Input:        -
Output:       -
Message:      f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0
Strength:     10

Time:         0:05
Sample Rate:  44100
Channels:     1
Data Blocks:  0
$ tail trace
read(0, "                ", 16)         = 16
write(1, "                ", 16)        = 16
read(0, "                ", 16)         = 16
write(1, "                ", 16)        = 16
read(0, " \n              ", 16)        = 16
write(1, " \n              ", 16)       = 16
read(0, "                ", 16)         = 16
write(1, "                ", 16)        = -1 EPIPE (Datenübergabe unterbrochen (broken pipe))
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=3253354, si_uid=1000} ---
+++ killed by SIGPIPE +++

We can see that test.wav in this example has a RIFF data chunk (which contains the actual samples) but after it there are a few other RIFF chunks. Reading these is not necessary for watermarking the audio, so currently we don't. Actually this behaviour is not explicitly implemented in audiowmark but is caused by how libsndfile implements reading from the pipe (it simply stops reading somewhat after the data chunk).

There are two possible ways to deal with this:

1. keep it as is, and force the process that provides the data to handle this problem
2. drain the pipe when watermarking "-" when closing the input file

I slighly prefer (2) because it makes things robust without forcing the user to deal with a few corner cases that occur very infrequently.