Feature Request: Better Timestamped Noncontinuous Audio File Outputs

[Staja]

I think when continuous and append is false, the recording behaviour should be to record to the same timestamped audio file until squelch is closed, a new file will be opened (with the appropriate timestamp) only when squelch is opened again. Such an implementation gives us the benefit of recording only useful audio and no silence (like append) but without losing important timestamp information (useful for airband applications when the time of transmission is important).

Some ideas on how to achieve this:

1. Should use gettimeofday() because it also has tv_usec (microseconds), although, a number of other functions could also be used.
2. Filename suffix should be changed to _%Y%m%d%H%M%S with an additional appending of microseconds %06ld and the relevant extension of course (.mp3 or .cs16)
3. Audio data should be recorded to the same file up until squelch is closed, handle should be closed, ready to be opened next time squelch is open, allowing for a new file (with appropriate timestamped filename) to be created
4. In environments where squelch flaps a lot, behaviour could be further improved by recording continuously to the open file for a further N seconds after squelch is closed, the timer resetting if squelch is opened back up during this period.

I think such an implementation would achieve the best of both worlds of the current continuous and append recording modes.

[charlie-foxtrot]

Similar request / discussion at the bottom of #59

[Staja]

I decided to code up the feature myself, I have a test build I'm running at the moment that does 1 through 3 (not 4). That said, what's discussed in #59 looks like a much fuller and nicer implementation then what I've done.

[charlie-foxtrot]

@Staja see #163

Differences from your request:

• Output filename doesn't include microseconds, instead MIN_TRANSMISSION_TIME_SEC = 1.0 ensures there are no more than one file open per second.
• For "flappy squelch" MAX_TRANSMISSION_IDLE_SEC = 0.5 will wait half a second incase the squelch is re-opened before closing off the file. This could be made a config parameter if needed.

[Staja]

@charlie-foxtrot If squelch closes within the MAX_TRANSMISSION_IDLE_SEC window, does #163 just append to previous data or does it create silence for the missing period then append? It seems to be the former if I'm looking at this right?

[charlie-foxtrot]

@Staja squelch "open" means audio, squelch "closed" means no audio. I think what you meant to ask is if squelch opens again within MAX_TRANSMISSION_IDLE_SEC. If that happens the recording continues without inserting silence (the silence is "lost")

[Staja]

@charlie-foxtrot Yes, sorry, I meant if squelch was reopened after it closed within said window. I think I might stick with what I've done for my specific use-case as rebuilding the exact timeline as accurate as possible is a higher priority for my particular use-case (even at the expense of spamming files) but I'll rebase my changes on this new commit and, if what I've done seems to be useful beyond my own scenario, I'll revisit and see if it's useful to anyone else.

[charlie-foxtrot]

👍

dropping MIN_TRANSMISSION_TIME_SEC and MAX_TRANSMISSION_IDLE_SEC to 0.0 and changing the filename format on open_file_check() may be all you need to do

[Staja]

Do you think it's worth me spinning them into config instead of constants?

[charlie-foxtrot]

Maybe?

I didn't because I wasn't including ms in the filename and I didn't want to figure out filename conflicts. With that said, the existing fdata_open() handles appending, so it may just work auto-magically 🤷‍♂️

If you do, storing at the root of the config (next to localtime) rather than per-output may be good.

[ThellraAK]

Do you think it's worth me spinning them into config instead of constants?

Please do, being able to configure this will make it so I can grab an entire event/conversation into one recording.

[devnulling]

I decided to code up the feature myself, I have a test build I'm running at the moment that does 1 through 3 (not 4). That said, what's discussed in #59 looks like a much fuller and nicer implementation then what I've done.

@Staja have you posted your fork anywhere?

[Staja]

@devnulling No I haven't, we're currently using @charlie-foxtrot 's great work from https://github.com/szpajder/RTLSDR-Airband/pull/163 and the unstable branch code for https://github.com/szpajder/RTLSDR-Airband/issues/198

The only change we're really planning to do is adding microseconds to the filename format but, unfortunately, I've been retasked to another project so I haven't done much more work on our rtl_airband deployment project.

[LoganSound]

140 and #111 discuss this "squelch delay" feature "4...recording continuously to the open file for a further N seconds after squelch is closed." And I would vote for including this in the config as it may be tweaked a lot, and different values for different frequencies in scan mode.

[szpajder]

charlie's work on this topic has been released in version 4.0.0. @Staja if this satisfies your needs, then please close the issue.