Shrinking (with another program) a file in use might not be a good idea.
It can make bus errors. Songs tries to handle them, but the
code is not very tested, it may fail, and Songs may behave very
weirdly. So simply avoid modifying your audio files while using
Songs.

The recorder is not accurate in full duplex mode.
The recorded and played sound may not be synchronized.
I don't know if there is a good and generic way to
ensure a not too bad synchronization using simple
audio cards like the sb16 (which uses 2 dma buffers,
which might be started at different times, and even
if not, how can I know that the nth byte I sent to the
card is played at the same time than the mth byte
I read?).
Maybe the best we can do is this:
1 - open the audio device in full-duplex, but don't start
    play/record yet
2 - feed the output buffers
3 - start the play/record (so that we have play and record
    almost synchronized)
4 - record what you want
5 - close the audio card.
With such a way of doing things, I think we get a not too
bad synchronization. Unfortunately, the OSS stuff does not
seem to provide the 1/2/3 stuff. When your open syscall
returns, the card has started to play, so when I send an
audio buffer, I won't be sure when it starts, so the recorded
data may be completely de-synchronized. So, well...

strtol is used in such a way that "12 " is not a valid
number, because there are trailing spaces. Is it a bug ?
If a file is edited by hand, one could introduce white
space, which will hardly be detected...
