[Announce] node-red-contrib-sox-utils : first beta (testers wanted)

[dceejay]

Yes - I would only search bytes 0 - 4 (or however long the magic number is) - if it's doesn't work with mp3 then tough... set msg.format correctly (you are only trying to be helpful, but without compromising performance for everyone)

[JGKK]

@dceejay

Yes - I would only search bytes 0 - 4

I check the first 8 bytes as this the longest one i found (ogg).
It should work with most mp3s. Definitely all recent ones.

[JGKK]

Now in the repo. Both the convert and play node now try to guess the format of a buffer input making the msg.format unnecessary thanks to the input of @dceejay . They can auto detect wav, flac, ogg and mp3 right now.
edit:
Also fixed an issue that arose when a lot of buffers where queued for playback that could lead to the tmp files being overwritten.

[JGKK]

Version 0.2.1

• the record node now has a button to start/stop recording in addition to accepting messages:
  
• both the record and convert node now have the option to write the output directly to a file (which is recommended for very long record durations or very large files):
  
  
• both the record and play node now try to guess the file format of input buffers. You can add as many files / buffers of different types to the play queue as you like now:
  
  
• all three nodes can be directly connected to each other and they dont have to be in the same mode to work. So you record to a file. The record node will emit the file path when finished, convert it to mp3 with the convert node in buffer mode which when finished which will then be played by the play node. You can also do something like recording to mp3. by setting the record node to send a single wav buffer when finished and the convert node to write a mp3 file.
  
  
• a lot of small fixes have happened again too but their should be no breaking changes.

Johannes

[dceejay]

Oh no - please no...

If you want to do that then add an option inside the config to allow either / or, but not both and then show the appropriate connection or button.

[JGKK]

will do also i dont know how to hide the button with an option. How would i do that?

[dceejay]

See debug node for example of turning on off button visibility - https://github.com/node-red/node-red/blob/master/packages/node_modules/%40node-red/nodes/core/common/21-debug.html#L72
and see email in node for example of adding an input.

[JGKK]

As requested now in the repo its either or button/msg

[JGKK]

Version 0.2.2

• the nodes are now to complying with the expected behavior introduced in nod-red 1.0 to call done() if available to tell the runtime when there done processing an input:

• the record node will call done() at different times depending on the mode:

  • If set to only stop recording on a stop message it will call done() on the start message as soon as the record process was spawned and will call done() again on the stop message when recording
  • If set to stop on silence or only record for a certain time the node wont call done() on the start input when the recording finished
  • If started and/or stopped in button mode done() will not be called

• the convert node will call done() when conversion is done.

• the play node will call done() as soon as playback was successfully started or the input was added to the queue

[janvda]

Hi @JGKK,

I am currently using these excellent nodes.

I would like to stream the recorded audio directly to the play node.
This is currently not possible. The sox-play node is reporting following error in that case.

1. In order to fix this it should be somehow possible to specify the sample rate for the sox-play node

extract from sox options:

2. Also the options -b, -e and -c are needed for playing raw audio format.
   see https://unix.stackexchange.com/questions/274166/sox-in-between-two-pipes

[JGKK]

If you actually wanted to stream that wouldnt work with any format right now as the play node only accept single buffers/files no matter which format and not a stream of buffers.
I had originally implemented playback of an input stream but it was very brittle as what the nodes do intenally is not actually the same as using straight pipes on the commandline to get the audio to sox.
So right now the only way to play audio from the record node is to record first in the wav buffer output or wav file mode and than pass that to the play node once recording finished.
If i revisit the playback of a stream in the future it will be in form of an additional mode added to the current choice of keep, replace and queue as a stream is not compatible with any of the current playback models.

Raw PCM audio support in general is on my backlog for both the convert and play node but im not quite sure yet on how i will require the additional input parameters like rate and so on. I still have to give this quite some thought as I will also have to check the input parameters object when the format is raw and for the play node i would probably than have to add wav headers to input raw audio files/buffers before playback so that the above mentioned queue logic wouldnt have to be completely rewritten.

[janvda]

@JGKK, thanks for your clarifying response.
According to me, this node is ready for publishing. well done !