Audio recording #594
Audio recording #594
Conversation
|
Hello @cjcliffe! First, I wish you a happy new Year ! I tried the I have a couple of UI suggestions:
|
src/demod/DemodulatorInstance.cpp
Outdated
| std::wstring userLabel = getDemodulatorUserLabel(); | ||
|
|
||
| // TODO: Can we support wstring filenames for user labels? | ||
| std::string userLabelStr(userLabel.begin(), userLabel.end()); |
There was a problem hiding this comment.
- A better and still quick way to convert a
std::wstringto astd::stringin a consistent way is to usewxStringservices:
wxString userLabelForFileName(userLabel);
std::string userLabelStr = userLabelForFileName.ToStdString();It works well to create "best-effort" file names from std::wstring while the previous solution may create invalid ones.
|
Some thoughts about my previous suggestions: If you agree with this I can contribute the 1. 3. 4. modifications if you don't have time to do it yourself. |
|
@vsonnier Happy New Year! -- all good suggestions thanks; I'll tinker with the placement / recording indication ideas when I'm back later this evening. At some point I'd like to use some symbols/graphics to indicate things and will likely add a simple 'sprite sheet' type rendering which would be basically the same as the text renderer without the string building logic and font loader. |
|
Last changes Look Cool To Me. |
|
@cjcliffe I think I've found a bug : nothing is registered in the Wav file if the demod level is below the squelch. If you test by changing the squelch during the recording, and back again, you can hear that no "silence" is registered between the 2 sequences. Given the existing implementation, I think we need to fill the gaps between squelch breaks by dumping Zero-level audio into the WAV file so that the WAV timecode is consistent with what a user would hear in realtime. If a demod never break the squelch during a recording, the file is even never created at all. |
|
@vsonnier is recording hours of silence the intended result of these patches or are you still working towards something? |
|
Recording "silence" as you say is perfectly intended. If you don't record the below-squelch level as "silence", the time in the record will be all fucked up and you won't be able to know when some particular event occurred. I checked that a 48KHz - Stereo - S16 bit WAV file (recording FMS) is 0.28MB/ s which leads to about 1GB per hour. |
|
@starvald To answer your question, I don't think there is more we can do here with a WAV file format so I'm not planing any further improvement on this. |
|
Something I have been exploring lately is the notion of embedding tomecodes
into the recorded stream for forensic integrity. I was looking at the FLAC
seektable and application metadata frames for this, specifically to record
RF streams and trim out the "silence". Keep in mind, as a user, that any
recording method that excludes "silence" means squelch adjustment or you
will inadvertently cut off audio you intend to keep or include audio you
intended to discard. It is better from an acquisition standpoint to record
an uninterrupted stream and then let the user trim out undesired data from
a copy of the file, and I believe that's the best option for CubicSDR as
well, though an option that only records when squelch is broken and writes
a new file to disk when squelched for more than, say 5 seconds, could be
useful for some applications.
One other caveat with .wav is that it is 32-bit constrained and files
cannot exceed 4GB, roughly 6 hours of 44khz stereo audio.
…On Sat, Jan 6, 2018 at 11:00 AM, Vincent Sonnier ***@***.***> wrote:
Well, recording silence as you say is perfectly intended indeed.
Imagine you start a recording, take note of the time Start_time, then
stops 10 hours later (we now have terabyte HDs do we ?)
Later on Iif you have something interesting at some date D in the
recording, you will be able to know when it actually happened, i.e at Start_time
+ D.
If you don't record "the silence", the the time will be all fucked up.
I checked that a 48KHz - Stereo (for FM) WAV file is roughly 0.2MB / s
which leads to 720MB per hour.
All the other modulations (NFM, AM and so on) are twice smaller because
they are inherently Mono.
I think that manageable.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#594 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALN_d_asVWiX4nueMAnpToPSDXN-_9Itks5tH6bDgaJpZM4RP7Il>
.
|
|
couldn't you make that a toggle to record silence or not? |
|
Thanks @mmgarland3 for the suggestions ! I merely fixed a inconsistency to be able to track the time correctly. On the other hand, a muted demod is recorded anyway with the actual code, which make sense: It is up to @cjcliffe now to decide of further improvements among all those suggestions. |
|
@starvald The WAV is a simple "stream" format with the samples stored in a single array without other additional information. As a consequence, we are forced to store "zero samples" to mark the correct elapsing of time. |
- Limit WAV size to 2GB for maximum compatibility, - Continue recording on another file when size gets too big (XXX_001.wav, then XXX_002.wav and so on) - The sequence assure up to 2000GB worth of recording which should be enough - Changed file pattern to international Year.Month.Day so its recognizable whether you are English of French or whatever :)
|
In the last commit, I've removed the recording duration limitation by generating multiple files automatically:
That won't make WAV files any smaller, though :) |
|
@vsonnier thanks for the patches; I hadn't tested large files before and forgot about the size limit; and after some consideration I also agree that the squelch shouldn't affect recording times by default.. Though since @starvald 's use case matches my own initial thinking when deciding to discard the squelch gaps I think I'll go ahead and move the Recording path option into a "Recording" sub-menu and add a simple "Squelch" -> "Record Silence / Skip Silence / Record Always" option toggle there as well. We do need to consider sometime adding a real "preferences" dialog to contain optional settings to soften some of the hard-coded details in general (and before we fill up the menu bar). |
|
@cjcliffe My thoughts exactly, about a recording dialog, and about confuguring squelch as well so tthat it is ok for all tastes. |
- Added a Recording menu, git commit -m Added
|
@starvald Hello ! I introduced the following changes in the last commit:
The commit message wrongly references #583, but I really meant #587. |
|
Sounds great, thanks @vsonnier :)
|
|
LOL my Java habit strikes again ! here is the fix. |
|
@mmgarland3:
Now that the record file time limit is configurable, we have this kind of feature. So if you configure your File Time Limit to 10 s with the Skip Silence option on, for instance, and start a recording for the night. The next day, you will only get files whose names denote the actual date (in their timestamp) at which something break the squelch, with a margin of error of 10 s. From within a unique 10 s file, you won't know the exact time a given event occurred because of the reasons given above but on the bright side you won't record hours of silence either. ((c)@starvald). |
|
As you see I didn't use a dialog for Recording configuration because I think it is enough to have a separate menu considering we have very few options. Maybe in the future a Dialog may be needed if tons of other options are added. And the real reason: I don't know how to use wxFormsBuilder so I did what I can do best :) |
|
@vsonnier thanks for the patches; taking a look now and will see about getting a build ready |
|
@vsonnier seems to have introduced a crash on exit in OSX after any recording operations, attempting to track it down now: |
|
@vsonnier looks like there's some sort of recursive mutex issue with pushing the same object to the sink thread unless it's at the end of the demod thread function -- if it's pushed before the viz section uses it then it crashes with that error on application exit. |
|
Just wanted to say, thanks a ton for the recording! Never realized how useful it would be and I love the implementation. |
Audio Recording features