On Wed, Jan 18, 2023 at 04:51:28PM +0100, Brian Durant wrote: > Record audio from USB sound card: > $ aucat -o /home/user/Music/set/1 - ?.wav > > Playback audio file: > $ aucat -i /home/user/Music/set/1 - ?.wav
You might want to specify the encoding and other parameters rather than rely on the defaults, which might change. Last year I had to fix a problem for a company who were recording VoIP calls on an OpenBSD system with a simple shell script that invoked aucat twice to record the local and remote audio via separate sndio subdevices. (So the resulting file was stereo, with the local audio on the left channel and the remote party on the right channel.) When the VoIP program ended, the audio was trimmed of digital silence, and then compressed with FLAC, (the choice of which was quite lucky, as you will shortly see). The problem is that they were writing to raw, headerless files rather than wav or au, which I understand was done to make it easier to write the digital silence trimming program. At some point last year, in revision 1.178 of aucat.c, the default file encoding was changed from 16-bit to 24-bit. After upgrading to OpenBSD 7.1, their call recording script continued processing the data as 16-bit, but nobody checked that the call recordings were actually audible. As you can imagine, since the incoming data was actually 24-bit, and yet the two streams were being interleaved as if they were two 16-bit channels, the end result was, if I remember rightly, very bad distortion in the left channel, and pure noise in the right channel. They only noticed the problem after about three weeks because the FLAC processes were taking up a lot more CPU than before, (because they were effectively trying to compress noise). I had to study the exact transformations that their home-grown scripts and programs had performed *, write code to reverse that, decompress all of the FLAC files, (preserving the call metadata that was also stored in them), fix the audio, then re-compress them all with FLAC again. All because: 1. The defaults changed. 2. Their scripts assumed that the defaults would not change. * It was more complicated than it sounds, because the trimming of the digital silence had on some occasions caused further mangling of the data, since it was cutting at the wrong point, and not even at sample boundaries. If the audio data has been compressed with a lossy algorithm, it would have been impossible to recover it. Luckily that was not the case.
