E-Stim Analyzer 0.0.2 Release

[astonia]

With all the various E-Stim files around it can be difficult to determine how they will feel before you try them. I've been wanting a way to analyze them to let you see what they contain. Now, I'm not a signal processing expert, but I was able to put together something that at least gives a general idea of what an e-stim file will feel like.

What it will do is take an input audio file, and then generate a video of what the signal is doing. Basically it's the intensity of each channel and difference in phase and intensity between channels. It works best when the input is sine waves and the channels are the same frequency.

Here's a single frame from an output video


The size of the circle under each channel represent the intensity of the signal for that frame and the horizontal line with circle represents the phase shift and intensity difference between the channels, which roughly corresponds to where you feel the sensation between the connections. Directly between the channels being the ground connection and directly under each channel being the positive connection for that channel. It's easier to see an example that will make it clearer.

Here's a few seconds of an analyzed video
Analysis Excerpt

You can check out the project on github, and there's a release with a Windows executable if you don't want to build it yourself.
Github Project

[markus]

Hi there!

Wish you good luck with this project, just don't get too disappointed if there won't be much or none feedback at all, ... that's the curse nowadays with such niche projects, they don't get the attention they should get anymore.

Personally I am not into EStim, so I cannot give any feedback, just a hint of what came to my attention:

Here's a few seconds of an analyzed video
Analysis Excerpt

I've downloaded that video and my (outdated) version of the VLC media player doesn't play it, gives me an error, so maybe you reencode this with a more common codec.
It plays fine after I have reencoded it on my own, but maybe it's better to present something which doesn't have such a problem.
(I don't get tired to recommend the 'Free Video Editor' to convert videos since it has really good default settings so you don't have to take care about that, and it's quite fast as well)
https://www.chip.de/downloads/Free-Vide ... 14359.html

Best greetings,
Markus

[edger477]

Thank you for sharing this!

I am working on a impulse box, and I planned to look at FFT to see if I will be able to play audio signal to it. This analyzer of yours is great starting point to review the code as to produce impulses I need to know frequency and phase shift so it will be of great help!

[astonia]

Here's a few seconds of an analyzed video
Analysis Excerpt

I've downloaded that video and my (outdated) version of the VLC media player doesn't play it, gives me an error, so maybe you reencode this with a more common codec.
It plays fine after I have reencoded it on my own, but maybe it's better to present something which doesn't have such a problem.
(I don't get tired to recommend the 'Free Video Editor' to convert videos since it has really good default settings so you don't have to take care about that, and it's quite fast as well)

It's encoded to VP9 with ffmpeg, and recent versions of VLC can play it. I was trying to get the github page to embed the video, but it just wouldn't work with webm or mp4. I think I'll just use h264 for now.

[darthjj]

Would you mind doing an ELI5 version of the algorithm you're using?

I did some experiments with similar stuff a few years ago, and while it seems like I have lost the actual code, the home-brew algorithm I came up with was more or less:

1. Add current sample value to current "bucket"
2. If the sign of the sample value changes, start a new bucket
3. For each vertical slice of the generated image (i.e. a time duration) plot the average of all buckets for that time

Then I had to tweak it a little, like adding a threshold for sample values, but over all I found it better at calculating perceived stim intensity than looking at the amplitude of the waveform.

[astonia]

Would you mind doing an ELI5 version of the algorithm you're using?

It's nothing special. The code is in the github and it's very simple. The audio is broken into windows that correspond to the time each frame of video is displayed (25ms at the default 40fps). Then the absolute value of each sample for each channel is summed together and then the average value taken to get the channel intensity for that frame. The intensity of the interchannel display is just the averages of the sum of the absolute values values of the difference in each sample of the second channel and first channel. The position between the channels is based on the phase from the most prominent frequency from a FFT for the samples in that window for each channel. It's just a simple subtraction to find the phase difference between the two channels, and the result is mapped to a position between the channels with -180 and 180 degrees directly under the first and second channels respectively, and 0 being directly between them (i.e. no phase difference).

[senorgif2]

Pretty interesting stuff, most of the time i can just look at the file in Audacity and get an idea of the file. Usually volume level will indicate the level of intensity, and I've done enough stimming to have some idea of what freqs will feel like. I do like the indication of which channel will be more intense, it gives you an idea of where the "stroke" is on the triphase files.

[darthjj]

It's nothing special. The code is in the github and it's very simple. The audio is broken into windows that correspond to the time each frame of video is displayed (25ms at the default 40fps). Then the absolute value of each sample for each channel is summed together and then the average value taken to get the channel intensity for that frame. The intensity of the interchannel display is just the averages of the sum of the absolute values values of the difference in each sample of the second channel and first channel. The position between the channels is based on the phase from the most prominent frequency from a FFT for the samples in that window for each channel. It's just a simple subtraction to find the phase difference between the two channels, and the result is mapped to a position between the channels with -180 and 180 degrees directly under the first and second channels respectively, and 0 being directly between them (i.e. no phase difference).

Ah, I was looking at the FFT part of the code, and mistook that for your main analysis code.

If you're looking at absolute values for the main channels, without any involvement of frequency analysis, wouldn't it be more consistent to do so for the common trode as well? I believe the formulas for tri-phase are:

trode A = 2*L - R
trode B = 2*R - L
trode common = L + R