Reggaeton Be Gone: an Edge Impulse classifier wired to a Bluetooth test routine
Detects reggaeton genre with Machine Learning and sends packets to disable BT speakers (hopefully)
At a glance
- What is it?
- Reggaeton Be Gone is a Raspberry Pi 3 project that classifies ambient audio with an Edge Impulse model and, past a confidence threshold, fires a Bluetooth routine at a configured speaker. The classifier is the credible part; the Bluetooth side is described in the README itself as an experiment.
- Who is it for?
- Adopt it if you want a worked example of Edge Impulse audio inference on a Pi with an OLED readout, and you are prepared to train your own model rather than use the six-song reference one. Do not adopt it if your actual goal is stopping a neighbour's speaker; the README presents the packet routine as a Bluetooth test and points to Pocket Gone as the later, ML-free project.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 24 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is a neighbour's speaker, and the project answers it in two halves
Roni Bandini wrote the first version in Buenos Aires in February 2024, and the README states the motivation plainly: a neighbouring Bluetooth speaker playing loud reggaeton every morning. The device is described as inspired by TV-B-Gone, the gadget that switches off televisions in public places. That framing matters, because it tells you what kind of project this is. It is a single-purpose build aimed at one room and one annoyance, not a general audio-monitoring platform.
The people who will get something out of the repository are narrower than the topic list suggests. If you want to see an Edge Impulse audio model deployed on a Raspberry Pi 3 with a 128x32 SSD1306 OLED for feedback and a timestamped log file, the code is a compact example of exactly that. If you want a tool that reliably silences a specific speaker, the README does not promise it. The Bluetooth section is labelled a test routine, the topic list includes ddos, and the parenthetical in the description says hopefully. Read those signals together and the intent is clear.
The two halves are also separable. The classification loop runs entirely on the Pi. The Bluetooth action is a separate branch that only executes once the score crosses a threshold. You can study or reuse the first half without touching the second.
Audio in, MFE features, classification, and one branch on the score
The data flow in the README diagram is short. Ambient music reaches a USB microphone, the microphone feeds the Raspberry Pi 3, and the Pi hands audio to an Edge Impulse AudioImpulseRunner. The classifier returns a label and a score. Both go to the OLED; both go to log.txt. Only when the score exceeds the threshold does the Bluetooth routine run against the configured speaker.
On the training side, the README explains why a custom model exists at all: common music-genre datasets such as GTZAN have no dedicated reggaeton class. The documented workflow takes music samples, converts them to mono WAV at 16 kHz, splits them into 4 second windows, runs MFE (Mel-frequency energy) processing, feeds a classification learning block, and exports a Linux ARM .eim deployment for the Pi.
The inference side uses the Edge Impulse Linux runner. The code imports AudioImpulseRunner from edge_impulse_linux.audio, opens the model file, calls runner.init(), and reads the label list out of model_info['model_parameters']['labels']. Classification then runs in a continuous loop over runner.classifier(device_id=selectedDeviceId). That is the whole mechanism: a blocking classifier loop, a label comparison, and a screen update. There is no queueing layer, no buffering of detections, no smoothing across windows. A single 4 second window that scores above the threshold is enough to fire.
The configuration block is the whole control surface
Everything tunable sits in a group of variables near the top of reggaetonBeGone.py. myPath points at the runtime asset directory and defaults to /home/pi/reggaeton/. selectedDeviceId is set to 1 and selects the audio input; the README says to change it to match your microphone or USB audio interface. model names the .eim file, and the current source expects reggaetonbgone-linux-armv7-v4.eim, so the filename in myPath has to match.
threshold is 0.95, meaning 95 percent confidence, and the program watches only the reggaeton label. Below the threshold the OLED shows a line like Is reggaeton? followed by the score as a percentage, rounded to two decimals. forceFire set to 1 bypasses the model entirely and triggers the Bluetooth action for testing. myDelay is 0.1 and spaces out actions.
The Bluetooth parameters are method, targetAddr, packagesSize and threadsCount. targetAddr ships as a placeholder string of colons, so nothing fires at a real device until you fill it in. packagesSize is 800 and threadsCount is 1000, described only as method-specific and as a number of repetitions. The README does not document what each method value does, which is the thinnest part of the repository. If you plan to touch the Bluetooth path, expect to read the source rather than the documentation.
Getting it onto a Pi: what the README actually specifies
The repository does not include an install script or a requirements file in the material provided, so there is no documented single command that sets the whole thing up. What you can reconstruct from the README is the sequence of things that must be true before the script runs.
You need a Raspberry Pi 3 with a USB microphone or USB audio interface attached, and a 128x32 SSD1306 OLED wired up. You need the Edge Impulse Linux Python runner installed, because the code imports from edge_impulse_linux.audio. You need the .eim file present in myPath, and the value of model has to match its filename. You need to edit selectedDeviceId until the runner is reading the input you intended, and set targetAddr to your test speaker's address. Then run the Python file, and if you want to exercise the Bluetooth branch without waiting for music, set forceFire = 1.
There is also a physical start button listed among the features, but the README excerpt does not show the GPIO pin or the code that reads it. Treat that as undocumented in the supplied material. The same goes for the OLED wiring and the 3D-printed front panel: both are mentioned, neither is specified here.
The reference model was trained on six songs
A public reference model is published on Hugging Face under ronibandini/reggaetonbegone. The model card states the input format as 16 kHz WAV mono and the labels as reggaeton and otros. It also states that the published model was trained with only six songs, and recommends training a larger dataset for better generalization.
That single sentence is the most important limitation in the whole project. A two-class classifier trained on six songs is a demonstration, not a detector. The README itself lists the conditions where this matters: rooms with speech, television, other music genres, different speakers, background noise, and varying microphone distance. Every one of those is a normal living room. A score above 0.95 from a model this small is a statement about the model's confidence, not about the world.
The threshold compounds it. At 0.95 the device will stay quiet through a lot of genuine reggaeton, because a small model rarely reaches that confidence on audio that differs from its six training songs. Lower the threshold and you trade missed detections for false positives on speech or other genres. There is no smoothing across windows, so a single spurious high score is enough to trigger. If you want this to work in a real room, budget for collecting and labelling your own audio and retraining, and treat the published .eim as a placeholder that proves the pipeline runs.
The Bluetooth half is an experiment, and the README says so
The repository topics include ddos, and the configuration exposes packagesSize and threadsCount, which is the shape of a packet-flooding routine rather than a pairing or control command. The README calls it a Bluetooth test routine against a configured speaker and never claims it works. The parenthetical in the project description ends with hopefully.
That is a fair description of where the code stands, and it is also the reason to be careful. Sending floods of packets at a device you do not own sits differently from switching off a television with an infrared blaster, and the legality depends on where you are and what you target. The MIT licence covers the source code; it does not cover what you do with the radio. The project also aims at one configured address, so it is not a general-purpose tool even if the routine works.
The author's own answer to this is Pocket Gone, a later project the README presents as the simpler alternative: smaller, cheaper and portable, with no machine learning and no Raspberry Pi. The evolution from one to the other was presented at Nerdearla 2025. That is a useful signal. If your interest is the Bluetooth side, the author has already indicated which project to look at. If your interest is the classification side, Reggaeton Be Gone is the one with the model.
What a Pi plus Edge Impulse costs you over time
The hardware is a Raspberry Pi 3, a USB microphone, an OLED and a printed panel. The software is MIT licensed, so you can copy, modify and redistribute the code, including commercially, provided the copyright notice and permission notice travel with it. That is the extent of what the licence text in the repository tells you, and it says nothing about the model weights, the Edge Impulse tooling, or the audio you train on. Those are separate questions with separate terms, and the README does not address them.
The ongoing cost is the model. A classifier trained on six songs will not hold up, so the realistic maintenance path is collecting audio in your own room, labelling it, retraining in Edge Impulse, exporting a new Linux ARM .eim, and updating the model variable to the new filename. Every retrain is a new file and a one-line edit, which is cheap. The collection and labelling are not. There are no releases in the material provided, so there is no versioned upgrade path to follow; you track main and read the diff.
The other cost is drift in the environment. Move the microphone, move the speaker, or change the room and the scores change. Nothing in the code adapts to that automatically.
Where it fits, and where it does not
As a reference implementation, the project is clear about its own shape. The Edge Impulse pipeline is documented end to end, from mono 16 kHz WAV through 4 second windows and MFE to a Linux ARM .eim, and the Python side is short enough to read in one sitting. The OLED readout showing the live percentage is a genuinely useful debugging aid when you are tuning a threshold, and forceFire lets you exercise the downstream branch without waiting for the right song to come on the radio.
As a product, it does not fit. The model is a six-song demonstration, the Bluetooth routine is described as a test, and the configuration is a block of module-level variables rather than a config file. There is no packaging, no install script in the supplied material, and no release history. Anyone expecting to clone, run and walk away will be disappointed at the point where selectedDeviceId does not match their hardware or the .eim filename does not match the model variable.
The honest summary is that this is one person's answer to a specific annoyance, published with enough detail to reproduce the interesting part. The interesting part is the classifier on the Pi. The rest is a sketch.
Editorial conclusion
Adopt it if you want a worked example of Edge Impulse audio inference on a Pi with an OLED readout, and you are prepared to train your own model rather than use the six-song reference one. Do not adopt it if your actual goal is stopping a neighbour's speaker; the README presents the packet routine as a Bluetooth test and points to Pocket Gone as the later, ML-free project. Before anything else, check selectedDeviceId against your own capture device, confirm the .eim filename matches the file in myPath, and treat threshold = 0.95 as a starting number to retune against your room.
Community notes