ronibandini/reggaetonBeGone: the configured target address is five colons, the model was trained on six songs, and the repository says so

The configured target address is five colons

The whole configuration block is ten settings, and one of them decides whether the project does anything at all:

myPath = "/home/pi/reggaeton/"

selectedDeviceId = 1

method = 1

targetAddr = ":::::"

packagesSize = 800
threadsCount = 1000

threshold = 0.95
myDelay = 0.1

forceFire = 0

model = "reggaetonbgone-linux-armv7-v4.eim"

The target address, the field the settings table describes as the test speaker address, is committed as a run of five colons. That is not a Bluetooth address in any form; it is a placeholder that has never been filled in. So the repository as published contains a classifier that works and a Bluetooth stage that has no target, which means the more alarming half of the project cannot run without someone editing the source and supplying an address of their own. That fact does more for a reader's safety than any disclaimer does, and it is worth reading as the single most important line in the document. The rest of the block is hardware-plausible and committed without ceremony: a package size of 800, a repetition count of 1000, a delay of 0.1 between actions, an audio input index of 1, and a runtime directory hard-coded to a path under the default Raspberry Pi user account.

The model was trained on six songs and the card says so

The model card is the most honest document in the repository, and it is hosted separately from the code. It specifies the input format as 16 kHz mono WAV, and it names two labels, reggaeton and otros, so the classifier is binary and the negative class is everything that is not the target genre. Then it states that the published reference model was trained with only six songs, and it recommends training a larger dataset for improved generalisation. It follows that with the list of conditions where the published model should not be trusted: rooms with speech, with television, with other music genres, with different speakers, with background noise, and with varying microphone distance. Six songs means the decision boundary between one genre and everything else is being drawn from a handful of minutes of audio, and the card is explicit that this is not enough. The training pipeline in the document is consistent with the card: mono 16 kHz input, four-second windows, mel frequency energy features, classification as the learning block, and a Linux ARM deployment as the output. The window length deserves a note. Four seconds is a long window for a genre decision, long enough that a track change inside it produces a label for the average of two songs, and it sets how long the device must hear something before it can answer anything about it.

The manual override skips the threshold but not the label

The feature list advertises a manual test mode for the Bluetooth path, and the code does something slightly different. There are two branches and they are properly complementary, with one using a less-than-or-equal comparison on the score and the other a greater-than comparison, so there is no gap and no overlap between them. The first branch runs when the label is the target genre and the score is at or below the threshold, and it updates the display with the confidence to two decimal places. The second branch runs when the label is the target genre and either the score exceeds the threshold or the manual override flag equals one. The label test sits outside the disjunction in both. So the override relaxes the confidence requirement and does not relax the classification requirement, which means a manual test still waits for the six-song model to say reggaeton. Whether that is deliberate or accidental is not stated, but it is the kind of detail worth reading in the source rather than in the feature list, and it is a one-line change in either direction. The display branch renders the score by rounding the product to two decimal places and appending a percent sign, and the example output shows 87.42 percent, which is consistent with a threshold of 0.95. So the number a reader sees on the OLED is a two-decimal rendering of a model score that the model card says came from six songs.

One Python file, five assets, and no dependency manifest

The complete top-level listing is a licence, a readme, the single Python file the configuration section points at, a log file, two images, and a font. There is no requirements file, no packaging file, no container recipe and no installation section. So the imports at the top of that one file, which include the Edge Impulse Linux runner and the Raspberry Pi GPIO library, are undeclared, and the two components the document relies on most, the inference runtime and the GPIO pin, are the two a new user is least likely to have. The font and the images are not incidental: a custom font, a logo, a sticker and a 3D-printed front panel are all listed as features, so this repository carries its physical design assets next to its code, which is what an art project that also has to run on hardware looks like. The runtime directory is also hard-coded, so even after installing the dependencies the asset path has to exist at exactly that location under the default user account or the model file will not be found.

The runtime log is committed to the repository

Event logging is one of the listed features and the log file is described as a timestamped activity log, so the device records what it decides over time. The output file is a top-level entry in the repository. That means the log this device produces is a tracked file, which has two consequences. The first is reputational and mundane: every run is a permanent, diffable record in a public history, so a misfiring classifier is documented in full detail, including the times and the confidence scores, and cannot be quietly revised. The log format is not specified beyond being timestamped, so the repository does not say what else a line contains: whether a trigger is recorded separately from a classification, whether the address is written down, whether the room is identified. That matters, because the privacy question here is not the classification, which is a genre guess, but the record of it. The second consequence is the one that matters for scope. The device is classifying audio it picks up in a room, on a continuous basis, and writing the result to a file that ends up in version control. What that file contains is therefore whatever happened to be audible, expressed as a genre label and a number, and the repository gives no guidance on retention. The project's own framing is that the classification is a two-way choice between one genre and everything else, so most of that log is noise by its own definition, stored forever.

The description says one thing and the readme says another

The repository description is one sentence and the readme is a different sentence. The description says the device sends packets to disable Bluetooth speakers, with a parenthetical hopefully. The readme calls the same action a Bluetooth test routine, calls the mode setting a Bluetooth experiment mode, and lists several experimental Bluetooth methods as a feature. So the same behaviour is described as disabling a device in one place, a test in another, and an experiment in a third, and the words get weaker as the document gets longer. The readme does add a line that matters: the source is intended for controlled experimentation with hardware you own. That is the correct scope statement and it sits at the end of the configuration section, after the settings rather than before them. It is also the only place in the repository that addresses ownership at all. Nothing in the code or the configuration checks whether the configured speaker belongs to the person running the device, and there is no allow list, no dry-run mode and no abort switch that stops a run once it has started.

The published model only runs on one generation of one board

The model file the source expects is named with a Linux ARM v7 marker, which is 32-bit ARM, and that is the architecture of the Raspberry Pi 3 the project is built around. So the published artefact loads on a 32-bit board of that generation and on nothing newer that a vendor has moved to 64-bit, and on no x86 machine at all. Anyone arriving with a current single-board computer, which is the default purchase now, has a model file that will not load and a readme that does not mention the constraint outside the file name. The board badge in the header is a specific model too, not a family, so the hardware assumption is explicit even where the software one is implicit. The public model on the model hub is the alternative route in, and its card is the same one that recommends a larger dataset, so the documentation quality is consistent between the two. The gap is between the documentation and the deployment: a reader is told to retrain, and not told that retraining is only worthwhile if the target board can run the result.

Once the button is pressed the microphone runs continuously

The physical start button is the only gate in the design, and it is a good one to have. The program configures the GPIO library for the Broadcom pin numbering scheme, sets pin 26 as an input with a pull-up, and waits at a prompt for that pin to be pulled low. Nothing is classified before that. After the press the display changes to a listening message and the loop described in the code begins: audio is classified continuously through a generator call on the runner, and each result goes to the display, the log, and the trigger test. There is no duty cycle, no push-to-talk, no time limit and no second press to stop it. So the switch is a one-way arming, and a device that has been switched on classifies everything it can hear in that room indefinitely, on a four-second analysis window with a delay of a tenth of a second between actions, and records each verdict. The write-up does not discuss power, so whether the microphone is sampling while the display is idle is left to the hardware. The button itself is an input rather than a latching switch: it shorts pin 26 to ground, which is the right way to arm something and the wrong way to stop it.

Editorial conclusion

The genuinely valuable part of this repository is the model card and the threshold write-up, not the hardware action, and it is worth saying that first: an author who publishes a six-song classifier and a list of the six conditions under which it will fail has done something most projects in this space do not do. Four things to check before you build it. The configured target address is an empty placeholder, so the published code cannot reach any device, and the document says the source is for hardware you own, while its stated motivation involves a neighbour's speaker; those two things sit together and you should resolve the second before you resolve the first. The trigger is audio, not an address, so the device acquires its target from the room rather than from an operator, and the same run that identifies reggaeton is a run that decides a speaker is now the target. There is a manual override, and it is worth reading the code for that rather than the feature list, because it does not do what the label suggests. And the model binary is built for one 32-bit ARM board generation, with no dependency manifest, no releases and a committed log file. As a documented edge inference write-up and as a hardware art piece it holds up. As something to point at a device that is not yours, nothing here authorises it and the document says as much.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. ronibandini/reggaetonBeGone on GitHub