Je ne connais pas les spécificités du système de Google, mais deux technologies sont pertinentes pour résoudre ce problème, et il se peut qu'il utilise les deux ensemble (selon les circonstances). Dans tous les cas, la première chose qu'il fait est de transformée de Fourier de courts échantillons de ce qu'il entend. Il obtient ainsi le spectre du son, ce qui lui indique la proportion de chaque fréquence présente et (parce qu'il dispose d'une séquence d'échantillons) l'évolution dans le temps. Une fois qu'il dispose de ces informations, il peut filtrer certaines bandes très aiguës et très graves qui ne l'aident pas à identifier le son.
Le résultat est une collection de "godets", où chaque godet représente une bande de fréquence pour une fraction de seconde particulière, et la valeur vous indique la quantité de son dans ce godet. C'est là qu'il y a deux possibilités.
Classificateur bayésien
La solution la plus simple consiste à confier ces catégories à une sorte de classificateur bayésien pré-entraîné. Il s'agit d'une classe d'algorithmes d'IA qui peuvent prendre une collection de caractéristiques (les intervalles de fréquence et de temps) et classer la situation dans l'un des groupes que vous avez définis : dans ce cas, "parole", "musique" ou "autre chose". Bien que cela demande beaucoup de données de formation pour apprendre à l'algorithme comment effectuer cette classification, les paramètres qui en résultent (l'algorithme pré-entraîné) sont très compacts, il est donc pratique d'inclure ces données dans l'application, permettant une classification hors ligne. Je m'attends à ce qu'il utilise ce type d'algorithme tout seul si vous utilisez la fonction de reconnaissance vocale hors ligne de Google.
N'oubliez pas que cette fonction pourrait être utilisée pour reconnaître une requête "OK Google" dans un pub avec de la musique en arrière-plan. La classification n'est donc pas aussi simple que "parole" ou "musique" : il faut décider ce qui est le plus fort ou au premier plan.
Reconnaissance de la musique
L'autre possibilité est d'essayer de trouver immédiatement un morceau de musique correspondant. La reconnaissance musicale implique une grande base de données de tous les morceaux de musique que vous souhaitez reconnaître. Chaque morceau de musique a déjà été soumis à l'analyse fréquentielle et est donc indexé selon les mêmes plages de fréquence et de temps que l'application a enregistrées. L'application n'a plus qu'à se rendre dans le nuage pour demander à la base de données : "Avez-vous de la musique qui possède ces catégories ?".
La partie temporelle des compartiments n'est calculée que par rapport aux compartiments voisins, ce qui permet de trouver le morceau de musique quelle que soit la partie que vous écoutez. En outre, les informations contenues dans les compartiments sont réduites à l'aide d'une fonction de hachage (une fonction qui transforme certains nombres en un nombre plus petit), ce qui permet de résister à la perte de certaines fréquences (à cause d'un mauvais système de sonorisation ou d'autres bruits de fond).
Il s'agit d'une opération très longue pour distinguer la parole de la musique, et il faut interroger les serveurs de Google pour le faire, ce qui n'est normalement pas une bonne option. Ce n'est une bonne option que parce que, s'il s'agit de musique, l'application devra de toute façon le faire pour la reconnaître.
Résumé
Compte tenu des avantages et des inconvénients des deux algorithmes, je m'attendrais à ce que l'application intègre les deux. Pour une utilisation hors ligne, elle n'utiliserait que le classificateur simple. Pour une utilisation en ligne, elle pourrait bien utiliser les deux en parallèle : utiliser le classificateur pour donner un résultat rapide si l'entrée est très probablement de la parole, pendant qu'elle attend que la base de données musicale dans le nuage essaie de reconnaître le morceau de musique particulier (ou dit non).