WAV file saving from piped audio

[fred-freeman]

I seem to be only able to generate .wav output files from recorded .wav input files. If I instead attempt to first pipe the audio through a media player like suggested here https://github.com/lwvmobile/dsd-fme/issues/162#issuecomment-1694725646 the output just fails.

Successfully saves decoded audio but has a lot of garble and white noise. dsd-fme -fi -R 1 -4 -i test.wav -s 96000 -P

Successfully plays audio through speakers and greatly improves the quality. aplay -r 48000 -f S16_LE -t raw -c 1 test.wav | padsp -- dsd-fme -fi -R 1 -4 -i - -o /dev/dsp

Continues to play the audio through my speakers and generates 2 .wav files in ./WAV/ both of size 44bytes (probably just header I would guess). aplay -r 48000 -f S16_LE -t raw -c 1 test.wav | dsd-fme -fi -R 1 -4 -i - -P

I would like the improved audio quality gained by first feeding the data through aplay (or similar) but I absolutely need the output to be saved to a file. I've tried simply redirecting -o to a file or using -w but both of these options fail to generate anything as well.

[lwvmobile]

The -P option only works in conjunction with the ncurses terminal, since the ncurses terminal code handles the call history and also, by exntension, the per call wav file saving. So, which ever method above works best for you, I'd tack on a -N 2> /dev/null or -N 2> log.ans to get that functionality to work properly.

On a side note, if you are using the -s 96000 option, I am assuming this must be a DSDPlus recorded wav file (or maybe GQRX). If so, I should tell you now, that using nxdn raw signal wav file recordings from DSDPlus isn't the greatest in terms of decoding. DSDPlus doesn't squelch its raw signal wav files, and the noise can trigger tons of false positives, and also, since its recorded at 96000 and not 48000, in order to make it work at all in DSD-FME, I can't properly apply any filtering to it, so while it can decode it, its not an optimal result, especially for data portions like the VCALL which is needed to seperate out per call wav files.

My suggestion, if you must absolutely only run prerecorded wav files, is to use SDR++, and use its squelch feature, and in its recording module, have your radio module set to NFM, 7000 BW, no audio filtering, and enable an appropriate squelch level to gate out the noise floor from the actual signal. Have your audio sink set to 48000 (no stereo), and then with your recording module, have it record int16 (SB16_LE) and tell it to ignore silence.

Here, I am using the command: dsd-fme -fi -i tcp -P -N 2> log.ans

[lwvmobile]

If you make wav files the method listed above, you can then in turn play them back via dsd-fme -fi -i wav_name.wav -N -P 2> log.ans

Also worth mentioning, you can also make your own raw signal wav files from DSD-FME using the -6 raw_signal.wav option, or better yet, you can create much smaller symbol capture bins by using -c capture.bin that can both in turn be played back with the -i capture.bin or -i raw_signal.wav file.

[lwvmobile]

Does that adequately answer your question? If so, I'll go ahead and close this issue down, but the entire call history/per call/alias things will undergo a comprehensive overhaul at some point in the future, just not entirely sure when.

[fred-freeman]

@lwvmobile Thanks for the extensive answer. I was away from my desk with family over so I have not had a chance to test anything yet but I will ASAP. To real quick note some of your observations, my recordings are coming from Gqrx that is correct. I've been having some trouble with SDR+ libraries so I am hoping to stick with dsd-fme and Gqrx but if needed I will fight that install.

EDIT: I just tried the recommended commands and get the same behavior as before. aplay -r 48000 -f S16_LE -t raw -c 1 test.wav | padsp -- dsd-fme -fi -R 1 -4 -i - 48000 -P -N 2>log.ans alternatively I also tried -6 and -c with similar header only files being created. As noted earlier the motivation here is the aplay portion of the command to help with the white noise which might be the squelching you mentioned above. I think you are saying SDR+ would not need that, if so please let me know. Also if that's the case do you know if SDR+ can be remotely controlled that was a big win for GQRX?

[lwvmobile]

Okay, so I did a little testing of my own with NXDN and GQRX, and what I found is that is first and foremost, enable the squelch so that random white noise doesn't pass through, but signal will. Here is a screenshot of my settings. You'll want to adjust squelch until you see no activity down below in the Audio window unless signal is present, and also keep in mind the filter width and mode settings for max dev and Tau, I've found in the past, the wrong settings on those will lead to poor decodes.

I then hit the Rec button and let it record for a while until a call came in, at which time it decoded the call just fine. I then stopped the recording, and dumped the wav file into DSD-FME to decode again and got a pretty immaculate decoding out of it, no data decoding issues or garble, so having that squelch on will mute all noise in the wav file as well, there doesn't appear to be anything that triggers false positives when the squelch is enabled, even in the wav file.

I played back the attached file with the following command.

dsd-fme -fi -i gqrx_20231127_174234_154987500.wav -s 96000

I then attempted to use the aplay method, but didn't have much luck doing so, I tried different variations on the sample rate and so on, but couldn't get the settings right for decoding. Another thing that I did do that worked, which is kind of one of those things I don't usually recommend doing, but since we know this wav file is 2 channel at 96000, using this command and playing it through the input pipe.

cat '/SSD_STORAGE/Radio/Audio Samples/_RAW/gqrx_20231127_174234_154987500.wav' | dsd-fme -fi -i - -s 96000

All this being said, I think if you use squelch, you can just open the file directly with the -i file.wav option, and to be honest, if you use input pipe, or the internal wav file, they both use the exact same handling with libsndfile anyways, in the code, there is literally zero difference as to how wav files, stdin, and the tcp audio connection works when it reads samples.

Also, just of note, if you are using the padsp command (pulse audio dsp emulation), the default mode of dsd-fme is to play through the pulse audio server, so its kind of like an extra step to accomplishing the same goal. Used to have to use padsp to get the szechys branch to work on Linux, but I implemented the pulse audio support directly into dsd-fme so that would work without obtuse piping commands and wrappers.

If you do try to run this file, just keep in mind that its over 7 minutes long and then the call occurs, so if you use aplay and can get it to work, you are stuck waiting in real time for that 7 minutes to end. If you use the -i gqrx.wav -s 96000 command, it'll just blow through all the dead air in a fraction of the time.

gqrx_20231127_174234_154987500.zip

Also if that's the case do you know if SDR+ can be remotely controlled that was a big win for GQRX?

Yes, SDR++ has a RIGCTL module, its the same protocol as GQRX (both are rigctl) as far as tuning and all, although it does lack a few extra commands that GQRX has coded in for misc purposes, but other than that, the remote control feature of GQRX is compatible with SDR++ RIGCTL server module, which both can be and have been tested to work with DSD-FME trunking and scanning functions.

[fred-freeman]

Hmmm I double checked my configs and here is what I found.

My squelch is way above the noise floor. However, I also noticed that when audio comes through there is some noise at very close frequencies above my squelch level. I tried upping the squelch even more but still have white noise when playing back the recording.

It is interesting that you couldn't get aplay to work at all when it is the only method that produces crisp audio for me. I took a look at the ncurses code for creating the files from -P and saw how there was no difference hence my confusion but none the less no files. I think I'll just work around the issue for now. Thank you.

[fred-freeman]

Update: Just for anyone who runs into this in the future.

It turns out my original recording was already decrypted/undigitized. I thought it still was hence my confusion.