Urban Acoustic Sensing with IoT-AED: A Dataset Analysis for Public Spaces

Why analyse this dataset for public spaces?

A public courtyard beside a municipal building can contain several overlapping sound sources: vehicles on a nearby street, people passing through the entrance, children playing, dogs and occasional sirens. An acoustic monitoring system might help researchers study which kinds of sounds occur there and how classification behaves under changing conditions.

IoT-AED offers a starting point for investigating parts of this problem. Its seven labels include several categories relevant to an urban outdoor setting. However, a collection of labelled clips does not establish how frequently those events occur at a particular site, how reliably they can be detected in continuous audio, or whether a model will run efficiently on a specific device.

This analysis addresses three questions:

• What does the distributed dataset actually contain?
• Which aspects of its structure affect preparation and evaluation?
• How could it support a defensible public-space research experiment?

Dataset, provenance and analytical method

This article concerns IoT-AED, version 1, published by Daniel Quirumbay Yagual and Luis Benalcazar through Mendeley Data on 5 May 2026. The publisher describes a collection that combines material derived from UrbanSound8K with additional field recordings obtained using ESP32-C6 sensing nodes, together with class restructuring, balancing and augmentation. The accompanying methods paper by the same authors reports the detection approach developed around this material [4].

The analysis inspected the archive inventory, the distributed manifest, supporting documentation and the headers of all 6,400 WAV files. Counts describe the released files without filtering, resampling or removing clips. Audio format and duration were obtained from WAV headers. Semantic label accuracy was not assessed by listening to every recording, and no classification model or hardware benchmark was run.

Scope of the application example. The municipal-building courtyard discussed here is an illustrative research setting. The analysis does not establish that IoT-AED was recorded at such a site or that a system trained on it has been validated there.

What the 6,400 clips contain

The manifest uses Spanish class names. The English descriptions below are reading aids; the original labels should remain available in analysis code and exported results.

The collection is moderately unequal in clip counts. Each largest class contains about 1.67 times as many clips as the smallest. An always-one-class predictor choosing any 1,000-clip class would achieve 15.625% accuracy on the complete collection. This is a count-derived reference value, not a trained-model result, and it applies to the released distribution; a balanced or otherwise resampled evaluation set carries a different reference value, which should be stated alongside reported results.

These proportions describe a curated dataset. They should not be interpreted as the distribution of sounds in a city, the fraction of time that people occupy a courtyard, or the probability that a siren will occur near a building.

Consistent audio format, variable duration

A shared sample rate and channel count simplify input preparation. Duration remains a separate modelling choice. A pipeline that assumes every file contains exactly four seconds will need an explicit policy for shorter and slightly longer clips. The observed maximum is consistent with the four-second ceiling documented for UrbanSound8K excerpts [1], which is compatible with the described derivation, though it does not by itself identify which files originate there.

For a proposed baseline, researchers could select a fixed input window and document padding, cropping and any minimum-duration criterion. Very short clips deserve inspection before exclusion; short duration alone does not establish that a file is invalid. Any filtering changes should be reported by class so that the resulting training set can be distinguished from the original release.

The manifest needs an explicit path-mapping step

The distributed file is named data/manifests/maniest_full.csv, including that spelling. It contains three columns: filepath, classID and className.

Its paths use backslashes and class-directory names that differ from the directories under data/audio/. Replacing path separators alone therefore does not resolve the directory mismatch. The observed naming correspondence is:

A preparation script should preserve the original manifest and write a separate resolved-path field. It should then check that every resolved path exists and that no file is unintentionally assigned more than once. These are preparation requirements; this article does not claim that the complete path-resolution procedure has been executed.

Why the available metadata does not establish independent splits

The release description discusses partitioning by groups, but the distributed three-column manifest does not expose explicit source-recording, device or session identifiers. It therefore does not provide enough information by itself to verify separation along those dimensions.

This matters because the publisher describes augmentation and adaptation of existing recordings. Related clips or transformed versions of the same recording could cross a randomly generated split. Exact duplicate detection can identify one type of overlap, but it cannot establish independence between acoustically similar or augmented recordings. This is the grouped form of the leakage problem described in the general data-mining literature, where an apparently random split leaks target-related information that would not be available at prediction time [5].

The original UrbanSound8K documentation explains why its predefined folds should be preserved: reshuffling can place related excerpts in both training and test sets [2]. IoT-AED has different classes and transformed material, so those original folds cannot simply be assumed to remain recoverable from its current manifest.

The class vocabularies also only partly overlap, which bounds how much of the collection could in principle inherit that fold structure. UrbanSound8K defines ten classes: air conditioner, car horn, children playing, dog bark, drilling, engine idling, gun shot, jackhammer, siren and street music [1]. Four IoT-AED labels have a direct counterpart there: claxon, niños, perro and sirena. The remaining three, balon, personas and ambiente, do not. Any attempt to recover upstream grouping information would therefore apply, at most, to part of the release, and the rest would still require provenance supplied by the publisher.

The accompanying methods paper describes the collection procedure in more detail than the distributed archive documents [4]. Readers seeking the grouping information absent from the manifest should consult it directly, since this analysis is limited to what the release itself exposes.

A stronger experiment would obtain a traceable mapping to original recordings and collection sessions, group related material before splitting, and apply new augmentation only within the training partition. If that mapping remains unavailable, results should be described as performance under a stated provisional split, with source independence unresolved.

An urban example: a courtyard beside a municipal building

Consider a research prototype intended to describe acoustic activity around a public entrance and an adjacent courtyard. IoT-AED could support an initial experiment involving horn, siren, dog, ball, children, people and ambient labels.

The first research question would be whether a classifier can distinguish these labels in held-out clips. A second, separate question would concern how the system behaves on continuous recordings from the intended site, where events can overlap and unfamiliar sounds can appear.

The labels also constrain interpretation. A personas prediction is not a people count. A sirena prediction does not establish that an emergency is occurring. An ambiente label does not guarantee that all previously unseen sounds are represented.

Similarly, the supplied PCM format does not by itself provide the acoustic calibration needed to interpret waveform amplitude as an environmental sound-pressure level. Event classification and calibrated noise measurement should be treated as separate research tasks.

Recommended research protocol

1. Preserve and document the release

Record the dataset DOI and version. Retain the original archive, manifest and documentation. Generate checksums for the analysed artifacts and save the path-mapping and preprocessing rules with the experiment. A locally generated checksum identifies an artifact; it should not be called publisher-verified unless an authoritative comparison value is available.

2. Define the prediction task before training

Begin with a clearly specified clip-classification task. Document whether the target is one label per clip, how variable durations are handled and which classes are included. Continuous event detection requires additional decisions about windows, overlapping events and the timing of predictions.

3. Separate data preparation from evaluation

Resolve grouping and split membership before fitting preprocessing steps that learn from the data. Keep model selection and threshold tuning within the training and validation material. Report uncertainty about original-recording overlap whenever the available provenance cannot resolve it.

4. Report class-level performance

A proposed evaluation should include macro-F1, per-class precision and recall, and a confusion matrix, alongside overall accuracy. These measures make performance on the smaller people class visible. Results should also identify the split, sample counts and preprocessing configuration used.

5. Evaluate the intended site separately

For the courtyard example, hold out recordings from separate sessions and, where possible, another location. Assess unfamiliar background sounds, overlapping sources and changing microphone conditions. Report false alarms per hour and event-level detection behaviour when the system is evaluated as a continuous monitor.

6. Measure edge performance directly

The use of ESP32-C6 nodes during data collection does not establish that a particular trained model will fit or meet timing requirements on that platform. Measure the complete proposed inference pipeline, including feature extraction, model execution and buffering. Report the actual hardware and software configuration with latency, memory and energy measurements.

7. Resolve the licence position before reuse

Establish which reuse terms apply to the specific files an experiment depends on, and record that determination with the experiment. The licence section below sets out why the declared terms do not settle this question on their own.

Reproducibility findings and remaining limitations

The archive supports useful checks of file inventory, class counts, audio headers and documentation. It also contains gaps that affect stronger claims about reproducing published experiments.

• The supplied manifest has fewer fields than the reproducibility checklist describes, including the absence of explicit grouping identifiers.
• Its filename and directory references differ from some examples in the supporting documentation.
• Some helper scripts and split files referenced by the checklist are not present in the inspected archive.
• A placeholder Zenodo identifier appears in the checklist; it is not a verified DOI and is not used as a source here.
• The absence of source-recording identifiers also prevents per-file determination of which upstream licence terms apply.
• Header inspection does not establish semantic label accuracy, recording independence or the representativeness of the clips.
• No model performance, exact-duplicate analysis, device benchmark or real-world deployment result is reported by this article.

These findings do not make the collection unusable. They define which steps a researcher must resolve or explicitly qualify before presenting results as independently reproducible or transferable to a new site.

Conclusion

IoT-AED provides a concrete starting point for urban acoustic research: 6,400 clips, seven categories and a consistent audio format. Its labels can motivate a public-space experiment, including a courtyard beside a municipal building, while its variable clip durations and uneven class counts inform preparation and evaluation choices.

The principal methodological issue is provenance at the recording and session level. Without that information, a convenient random split should not be treated as evidence of generalisation to new acoustic environments. The same gap leaves the applicable reuse terms unresolved at the level of individual files. The most useful next step is a documented preparation pipeline followed by independently collected evaluation data from the intended setting.

Data access, licence and citation

The dataset is indexed in the IoTDataset catalog and distributed through the Mendeley Data version 1 record .

Licence: two separate questions

The Mendeley record declares CC BY 4.0, while the distributed dataset_description.txt states “Academic research use.” That internal inconsistency should be clarified with the publisher.

A second question is independent of it and potentially more consequential. The publisher describes material derived from UrbanSound8K. UrbanSound8K is offered free of charge for non-commercial use only, under the Creative Commons Attribution-NonCommercial licence, version 3.0. Its audio originates from Freesound, and the release includes a FREESOUNDCREDITS.txt attribution list for the source recordings [2].

A CC BY 4.0 declaration carries no non-commercial restriction. To the extent that any distributed clip derives from UrbanSound8K material, the declared licence and the upstream terms do not align, and the upstream attribution obligation would still apply to the derived clip. This analysis does not determine which specific files are affected, because the distributed manifest exposes no source-recording identifiers. That is the same provenance gap discussed above, reappearing as a licensing question.

Users should therefore treat the declared licence as unresolved for any commercial or redistribution purpose until the publisher documents the per-clip provenance and the terms that apply to each component.

Dataset citation

Quirumbay Yagual, D., & Benalcazar, L. (2026). IoT-AED (Version 1) [Data set]. Mendeley Data. https://doi.org/10.17632/dg5k9pwv4d.1

Method and background references

1. Salamon, J., Jacoby, C., & Bello, J. P. (2014). A dataset and taxonomy for urban sound research. Proceedings of the 22nd ACM International Conference on Multimedia, 1041 to 1044. https://doi.org/10.1145/2647868.2655045
2. Salamon, J., Jacoby, C., & Bello, J. P. Urban Sound Datasets: UrbanSound8K documentation, evaluation guidance and licence terms. Music and Audio Research Laboratory, New York University. Retrieved 14 September 2026, from https://urbansounddataset.weebly.com/urbansound8k.html
3. IoT-AED version 1 supplementary files: dataset_description.txt, REPRODUCIBILITY_CHECKLIST.md and data/manifests/maniest_full.csv. Retrieved 14 September 2026, available within the cited dataset release .
4. Quirumbay-Yagual, D., Benalcazar-Yagual, L., & Sánchez-Aquino, J. (2026). Deep learning-based acoustic event detection in IoT edge devices. In Computational Science and Its Applications: ICCSA 2026 Workshops. Springer. https://doi.org/10.1007/978-3-032-30524-4_12
5. Kaufman, S., Rosset, S., Perlich, C., & Stitelman, O. (2012). Leakage in data mining: Formulation, detection, and avoidance. ACM Transactions on Knowledge Discovery from Data, 6(4), Article 15. https://doi.org/10.1145/2382577.2382579