Hello,
I just finished the first usable beta version of my very first node.
The node is a wrapper around the record functionality of the sox commandline tool on linux and you can find it here:
I’m happy for any testers who could give it a spin and tell me about any errors they find or usage feedback.
This node will record audio from the specified audio source on the machine node-red runs on.
It has several features which distinguish it from the microphone/record nodes already present.
It has options for record duration and a fine tune able silence detection which can be both used together or separate. It can be configured to either return a stream of raw audio buffers or a single buffer when recording is done. It separates the audio data and info/debug to two different outputs and the debug amount can be specified.
You can easily combine it with nodes like https://github.com/bartbutenaers/node-red-contrib-wav or use it in speech projects involving watson, voice2json or similar to record voice commands.
There is some detailed usage instructions in the readme which you can find in the repository.
Here are some pictures:
Hey Jonathan,
Unfortunately I cannot test this node, since I don't have a microphone for my raspberry ...
But is there any reason why you have added all this functionality into a single node? Because I can image it would be nice to have a separate highpass-node and a lowpass-node (in a separate repository). Then it would be possible to reuse that functionality e.g. when I want to process audio arriving from my node-red-contrib-ui-microphone node.
Or is this perhaps functionality that is completely stuffed into the sox library?
Its all typically things you do within a single sox command. As sox can do amazing things the commands tend to get quite long which is why i made this node in the first place. It just offers that little bit more in tunability compared to any of the other microphone nodes. As this is something you do to a live audio stream it also makes sense to have as much as possible in one workstep as by splitting it into several nodes you would introduce extra latency in each step which is not what you want especially if you use it for something like speech commands.
I tried to get around some of the menu bulkiness by hidding some of the more detailed options till you actually use them but i agree it is quite a long menu. Hopefully its structure is logical enough that it still is usable.
where some of the more advanced settings that are optional are hidden by default and make the config more manageable but you can expand it all the way up to a monster like this if you want to have full control:
Thank you for your great work!
I ve no microphone connected to my raspi. I guess its not possible to use the mircophone from the laptop/mobile phone I use to view the dashboard with?
A play node has been added that can play audio from a file path send to it for now. Buffer support will be added soon. The new play node also includes a dropdown that shows all available playback devices. I will add this feature to the record node too to make input selection easier.
can convert from all available sox formats to wav, flac, mp3 and ogg (i will add more target formats in the future, if you have a request for one tell me )
it accepts both buffers and file paths
fixed a whole lot in the play node when it comes to playing buffer input
breaking change: If you want to play a buffer you now have to attach a msg.format to the msg.object that contains the buffer that contains the file extension of the buffer (eg. wav, mp3, flac, ogg...)
the record and convert node now automatically include this msg.format property in their output so that the nodes can still be connected straight to each other.
Just tested this and it looks like i should be able to simply use buffer.includes(Buffer.from(formatAsHex)) and just keep an array of the formats hex identifiers to compare against.
Thanks for this great input @dceejay
Don’t think that would work as the file signatures are not always in the same place. For example for mp3s without an id3 Tag i have to look for frame headers to identify it.
I think big audio files will probably be passed in as urls or file paths and i don’t need to do the searching and guessing for them. You wouldn’t want to pass around a buffer of 3 hours of flac audio in memory anyway. I might integrate it as a checkbox with a disclaimer of possible performance problems. So check this box if you want the node to guess the input format. I might add a note that this option should only be used with smaller files.
I would not have the option (one more thing to confuse users) - just search the first few bytes - if successful then hooray - good win - if not then error/warn that msg.format was not supplied.
To catch the ones that are not at the start i would have to search at least the first 20000 buffer elements. Does that count as a few I will only check the first few and if you pass in mp3s that don’t include modern tags its your own fault and you have to supply a msg.format
)
I will only check the first few and if you pass in mp3s that don’t include modern tags its your own fault and you have to supply a msg.format