Détecter les événements audio avec Amazon Rekognition

Lorsque la plupart des gens pensent à utiliser l'apprentissage automatique (ML) avec des données audio, le cas d'utilisation qui vient généralement à l'esprit est transcription, également connu sous le nom de synthèse vocale. Cependant, il existe d'autres applications utiles, notamment l'utilisation de ML pour détecter les sons.

L'utilisation d'un logiciel pour détecter un son s'appelle détection d'événement audio, et il a un certain nombre d'applications. Par exemple, supposons que vous souhaitiez surveiller les sons provenant d'un atelier bruyant, en écoutant une sonnerie d'alarme indiquant un problème avec une machine. Dans un environnement de soins de santé, vous pouvez utiliser la détection d'événements audio pour écouter passivement les sons d'un patient qui indiquent un problème de santé aigu. Les charges de travail des médias conviennent parfaitement à cette technique, par exemple pour détecter le coup de sifflet d'un arbitre dans une vidéo de sport. Et bien sûr, vous pouvez utiliser cette technique dans une variété de charges de travail de surveillance, comme écouter un coup de feu ou le bruit d'un accident de voiture à partir d'un microphone monté au-dessus d'une rue de la ville.

Cet article décrit comment détecter les sons dans un fichier audio même s'il y a des sons de fond importants qui se produisent en même temps. De plus, peut-être étonnamment, nous utilisons des techniques basées sur la vision par ordinateur pour effectuer la détection, en utilisant Amazon Reconnaissance.

Utiliser des données audio avec l'apprentissage automatique

La première étape de la détection d'événements audio consiste à comprendre comment les données audio sont représentées. Aux fins de cet article, nous ne traitons que de l'audio enregistré, bien que ces techniques fonctionnent avec le streaming audio.

L'audio enregistré est généralement stocké sous la forme d'une séquence d'échantillons sonores, qui mesurent l'intensité des ondes sonores qui ont frappé le microphone pendant l'enregistrement, au fil du temps. Il existe une grande variété de formats pour stocker ces échantillons, mais une approche courante consiste à stocker 10,000 20,000, 40,000 0 ou même 65535 XNUMX échantillons par seconde, chaque échantillon étant un nombre entier compris entre XNUMX et XNUMX XNUMX (deux octets). Étant donné que chaque échantillon ne mesure que l'intensité des ondes sonores à un moment donné, les données sonores ne sont généralement pas utiles pour les processus ML car elles ne présentent aucune fonctionnalité utile à l'état brut.

Pour rendre ces données utiles, l'échantillon sonore est converti en une image appelée spectrogramme, qui est une représentation des données audio qui montre l'intensité de différentes bandes de fréquences au fil du temps. L'image suivante montre un exemple.

L'axe X de cette image représente le temps, ce qui signifie que le bord gauche de l'image est le tout début du son et le bord droit de l'image est la fin. Chaque colonne de données dans l'image représente différentes bandes de fréquences (indiquées par l'échelle sur le côté gauche de l'image), et la couleur à chaque point représente l'intensité de cette fréquence à ce moment précis.

L'échelle verticale des spectrogrammes peut être changée en d'autres représentations. Par exemple, la mise à l'échelle linéaire signifie que l'axe Y est réparti uniformément sur les fréquences, la mise à l'échelle logarithmique utilise une échelle logarithmique, etc. Le problème avec l'utilisation de ces représentations est que les fréquences dans un fichier son ne sont généralement pas réparties uniformément, de sorte que la plupart des informations qui pourraient nous intéresser finissent par être regroupées près du bas de l'image (les fréquences les plus basses).

Pour résoudre ce problème, notre exemple d'image est un exemple de Spectrogramme Mel, qui est mis à l'échelle pour se rapprocher de la façon dont les êtres humains perçoivent le son. Remarquez les indicateurs de fréquence le long du côté gauche de l'image - ils donnent une idée de la façon dont ils sont distribués verticalement, et il est clair qu'il s'agit d'une échelle non linéaire.

De plus, nous pouvons modifier la mesure de l'intensité par fréquence par temps pour améliorer diverses caractéristiques de l'audio mesuré. Comme avec la mise à l'échelle de l'axe Y qui est mise en œuvre par un spectrogramme Mel, d'autres mettent l'accent sur des caractéristiques telles que l'intensité des 12 classes de hauteur distinctes qui sont utilisées pour étudier la musique (chroma). Une autre classe met l'accent sur les caractéristiques horizontales (harmoniques) ou verticales (percutantes). Le type de son détecté doit déterminer le type de spectrogramme utilisé pour le système de détection.

L'exemple précédent de spectrogramme représente un clip musical d'un peu plus de 2 minutes. Un zoom avant révèle plus de détails, comme le montre l'image suivante.

Les nombres en haut de l'image indiquent le nombre de secondes depuis le début du fichier audio. Vous pouvez clairement voir une séquence de sons qui semble se répéter plus de quatre fois par seconde, indiquée par les couleurs vives près du bas de l'image.

Comme vous pouvez le constater, il s'agit de l'un des avantages de la conversion de l'audio en spectrogramme : les sons distincts sont souvent facilement visibles à l'œil nu, et même s'ils ne le sont pas, ils peuvent souvent être détectés à l'aide d'algorithmes de détection d'objets de vision par ordinateur. En fait, c'est exactement le processus que nous suivons pour détecter les sons.

Recherche de sons discrets dans un spectrogramme

Selon la longueur du fichier audio que nous recherchons, trouver un son discret qui ne dure qu'une seconde ou deux est un défi. Reportez-vous au premier spectrogramme que nous avons partagé, car nous visualisons 3 minutes 30 entières de données, les détails qui ne durent qu'une seconde environ ne sont pas visibles. Nous avons beaucoup zoomé pour voir le rythme qui apparaît sur la deuxième image. Clairement, avec des fichiers sons plus volumineux (et donc des spectrogrammes beaucoup plus volumineux), on se heurte rapidement à des problèmes à moins d'utiliser une approche différente. Cette approche s'appelle fenêtrage.

Le fenêtrage fait référence à l'utilisation d'une fenêtre coulissante qui se déplace sur l'ensemble du spectrogramme, en isolant quelques secondes (ou moins) à la fois. En isolant à plusieurs reprises des parties de l'image globale, nous obtenons des images plus petites qui peuvent être recherchées pour la présence du son à détecter. Étant donné que chaque fenêtre ne peut aboutir qu'à une partie de l'image que nous recherchons (comme dans le cas de la recherche d'un son qui ne commence pas exactement au début d'une fenêtre), le fenêtrage est souvent effectué avec des fenêtres successives se chevauchant. Par exemple, la première fenêtre commence à 0:00 et s'étend sur 2 secondes, puis la deuxième fenêtre commence à 0:01 et s'étend sur 2 secondes, et la troisième fenêtre commence à 0:02 et s'étend sur 2 secondes, et ainsi de suite.

Le fenêtrage divise une image de spectrogramme horizontalement. Nous pouvons améliorer l'efficacité du processus de détection en isolant certaines bandes de fréquences en recadrant ou en recherchant uniquement certaines parties verticales de l'image. Par exemple, si vous savez que la sonnerie d'alarme que vous souhaitez détecter crée des sons allant d'une fréquence spécifique à une autre, vous pouvez modifier la fenêtre actuelle pour ne prendre en compte que ces plages de fréquences. Cela réduit considérablement la quantité de données à manipuler et se traduit par une recherche beaucoup plus rapide. Il améliore également la précision, car il élimine les éventuelles correspondances de faux positifs se produisant dans des bandes de fréquences en dehors de la plage souhaitée. Les images suivantes comparent un axe Y complet (à gauche) avec un axe Y limité (à droite).

Axe Y complet

Axe Y limité

Maintenant que nous savons comment itérer sur un spectrogramme avec une approche de fenêtrage et filtrer certaines bandes de fréquences, l'étape suivante consiste à effectuer la recherche réelle du son. Pour cela, nous utilisons Étiquettes personnalisées Amazon Rekognition. La fonctionnalité Rekognition Custom Labels s'appuie sur les capacités existantes d'Amazon Rekognition, qui est déjà formé sur des dizaines de millions d'images dans de nombreuses catégories. Au lieu de milliers d'images, il vous suffit de télécharger un petit ensemble d'images d'entraînement (généralement quelques centaines d'images, mais la taille optimale de l'ensemble de données d'entraînement doit être déterminée expérimentalement en fonction du cas d'utilisation spécifique pour éviter de sous- ou sur-entraîner le modèle ) spécifiques à votre cas d'utilisation via la console Rekognition Custom Labels.

Si vos images sont déjà étiquetées, la formation Amazon Rekognition est accessible en quelques clics. Vous pouvez également étiqueter les images directement dans l'interface d'étiquetage d'Amazon Rekognition ou utiliser Vérité au sol Amazon SageMaker pour vous les étiqueter. Lorsqu'Amazon Rekognition commence l'entraînement à partir de votre ensemble d'images, il produit pour vous un modèle d'analyse d'image personnalisé en quelques heures seulement. Dans les coulisses, Rekognition Custom Labels charge et inspecte automatiquement les données de formation, sélectionne les bons algorithmes ML, forme un modèle et fournit des mesures de performance du modèle. Vous pouvez ensuite utiliser votre modèle personnalisé via le API d'étiquettes personnalisées Rekognition et intégrez-le dans vos applications.

Assemblage des données de formation et formation d'un modèle d'étiquettes personnalisées Rekognition

Dans le Dépôt GitHub associé à ce message, vous trouverez un code qui montre comment écouter le son d'un avertisseur de fumée qui se déclenche, quel que soit le bruit de fond. Dans ce cas, notre modèle d'étiquettes personnalisées Rekognition est un modèle de classification binaire, ce qui signifie que les résultats sont soit "le son de l'avertisseur de fumée a été détecté" soit "le son de l'avertisseur de fumée n'a pas été détecté".

Pour créer un modèle personnalisé, nous avons besoin de données d'entraînement. Ces données d'entraînement sont composées de deux types principaux : les sons environnementaux et les sons que vous souhaitez détecter (comme un avertisseur de fumée qui se déclenche).

Les données environnementales doivent représenter une grande variété de paysages sonores typiques de l'environnement dans lequel vous souhaitez détecter le son. Par exemple, si vous souhaitez détecter un son d'alarme de fumée dans un environnement d'usine, commencez par les sons enregistrés dans cet environnement d'usine sous une variété de situations (sans que le détecteur de fumée ne sonne, bien sûr).

Les sons que vous souhaitez détecter doivent être isolés si possible, ce qui signifie que les enregistrements ne doivent être que le son lui-même sans aucun bruit de fond environnemental. Pour notre exemple, il s'agit du son d'un avertisseur de fumée qui se déclenche.

Une fois que vous avez collecté ces sons, le code du dépôt GitHub montre comment combiner les sons environnementaux avec les sons du détecteur de fumée de différentes manières (puis les convertir en spectrogrammes) afin de créer un certain nombre d'images qui représentent les sons environnementaux. avec et sans les sons du détecteur de fumée superposés. L'image suivante est un exemple de certains sons environnementaux avec un son d'alarme de fumée (les barres horizontales lumineuses) superposé.

Les données d'entraînement et de test sont stockées dans un Service de stockage simple Amazon (Amazon S3). La structure de répertoires suivante est un bon point de départ pour organiser les données dans le compartiment.

L'exemple de code du référentiel GitHub vous permet de choisir le nombre d'images d'entraînement à créer. Rekognition Custom Labels ne nécessite pas un grand nombre d'images de formation. Un ensemble de formation de 200 à 500 images devrait suffire.

La création d'un projet d'étiquettes personnalisées Rekognition nécessite que vous spécifiiez les URI du dossier S3 qui contient les données d'apprentissage et (éventuellement) les données de test. Lors de la spécification des sources de données pour la tâche d'entraînement, l'une des options est Étiquetage automatique, comme illustré dans la capture d'écran suivante.

L'utilisation de cette option signifie qu'Amazon Rekognition utilise les noms des dossiers comme noms d'étiquettes. Pour notre cas d'utilisation de détection d'alarme de fumée, la structure des dossiers à l'intérieur des dossiers d'apprentissage et de test ressemble à la capture d'écran suivante.

Les images de données de formation vont dans ces dossiers, avec des spectrogrammes contenant le son du détecteur de fumée dans le dossier d'alarme, et des spectrogrammes qui ne contiennent pas le son du détecteur de fumée dans le dossier no_alarm dossier. Amazon Rekognition utilise ces noms comme noms de classe de sortie pour le modèle d'étiquettes personnalisées.

La formation d'un modèle d'étiquette personnalisé prend généralement 30 à 90 minutes. À la fin de cette formation, vous devez démarrer le modèle formé afin qu'il soit prêt à être utilisé.

Architecture de bout en bout pour la détection sonore

Après avoir créé notre modèle, l'étape suivante consiste à configurer un pipeline d'inférence, afin que nous puissions utiliser le modèle pour détecter si un son d'alarme de fumée est présent dans un fichier audio. Pour ce faire, le son d'entrée doit être transformé en spectrogramme, puis fenêtré et filtré par fréquence, comme cela a été fait pour le processus de formation. Chaque fenêtre du spectrogramme est attribuée au modèle, qui renvoie une classification qui indique si l'avertisseur de fumée a retenti ou non.

Le diagramme suivant montre un exemple d'architecture qui implémente ce pipeline d'inférence.

Cette architecture attend qu'un fichier audio soit placé dans un compartiment S3, ce qui provoque alors un AWS Lambda fonction à invoquer. Lambda est un service de calcul sans serveur et piloté par les événements qui vous permet d'exécuter du code pour pratiquement n'importe quel type d'application ou de service backend sans provisionner ni gérer de serveurs. Vous pouvez déclencher une fonction Lambda à partir de plus de 200 services AWS et applications logicielles en tant que service (SaaS) et ne payer que ce que vous utilisez.

La fonction Lambda reçoit le nom du bucket et le nom de la clé (ou nom de fichier) du fichier audio. Le fichier est téléchargé depuis Amazon S3 vers la mémoire de la fonction, qui le convertit ensuite en un spectrogramme et effectue un fenêtrage et un filtrage de fréquence. Chaque partie fenêtrée du spectrogramme est ensuite envoyée à Amazon Rekognition, qui utilise le modèle Amazon Custom Labels préalablement formé pour détecter le son. Si ce son est trouvé, la fonction Lambda signale qu'en utilisant un Service de notification simple d'Amazon (Amazon SNS). Amazon SNS propose une approche pub/sub où les notifications peuvent être envoyées à Service Amazon Simple Queue (Amazon SQS), fonctions Lambda, points de terminaison HTTPS, adresses e-mail, push mobile, etc.

Conclusion

Vous pouvez utiliser l'apprentissage automatique avec des données audio pour déterminer quand certains sons se produisent, même lorsque d'autres sons se produisent en même temps. Pour ce faire, il faut convertir le son en une image de spectrogramme, puis se concentrer sur différentes parties de ce spectrogramme en fenêtrant et en filtrant par bande de fréquence. Rekognition Custom Labels facilite la formation d'un modèle personnalisé pour la détection sonore.

Vous pouvez utiliser le GitHub repo contenant le code d'exemple pour ce post comme point de départ pour vos propres expériences. Pour plus d'informations sur la détection d'événements audio, reportez-vous à Détection d'événements sonores : un didacticiel.

---

À propos des auteurs

Greg Sommerville est architecte principal de prototypage au sein de l'équipe AWS Prototyping and Cloud Engineering, où il aide les clients AWS à mettre en œuvre des solutions innovantes aux problèmes complexes liés à l'apprentissage automatique, à l'IoT et aux technologies sans serveur. Il vit à Ann Arbor, dans le Michigan, et aime pratiquer le yoga, s'occuper de ses chiens et jouer au poker.

Jeff Harmann est architecte principal de prototypage au sein de l'équipe AWS Prototyping and Cloud Engineering, où il aide les clients AWS à mettre en œuvre des solutions innovantes à des problèmes complexes. Il vit à Unionville, Connecticut et aime le travail du bois, la forge et Minecraft.