Quand Elliot et moi enregistrons l’audio brut pour le podcast hebdomadaire, il n’est pas inhabituel pour nous de passer la majeure partie de deux heures à errer d’un sujet à l’autre. Au cours d’une de ces sessions de bavardage prolongées, nous nous sommes demandé s’il serait possible d’intégrer un signal numérique dans le podcast de manière à ce qu’il puisse être décodé par l’auditeur. Bien sûr, stocker et transmettre des données via le son n’a rien de nouveau, mais le format podcast lui-même a introduit un certain niveau d’incertitude.
Le son encodé survivrait-il à la compression en MP3 ? Est-ce que le service de syndication qui distribue le fichier, ou les différents clients que les auditeurs utiliseront pour le lire, brouilleraient encore plus les cartes ? Était-il possible que tout l’épisode soit signalé quelque part comme malveillant? Après un peu de spéculation sauvage, la conversation est passée à un autre sujet, et l’idée a été laissée à mijoter sur l’un de nos nombre infini de brûleurs arrière.
C’est-à-dire jusqu’à ce qu’Elliot parte en vacances il y a quelques semaines. Au lieu d’un épisode régulier, nous avons convenu que j’essaierais de créer une édition spéciale composée de segments préenregistrés de plusieurs contributeurs de Hackaday. Nous avons pensé que cette approche simplifiée me permettrait d’éditer plus facilement, ou de le regarder d’une autre manière, plus difficile pour moi de bousiller. Pour la première fois, cela m’a donné la chance de superviser personnellement l’enregistrement, la production et la distribution d’un épisode. Cela, et le fait que mon patron était hors de la ville, en ont fait l’occasion idéale d’essayer de créer un message caché à découvrir pour la communauté Hackaday.
Je suis maintenant heureux d’annoncer que, onze jours après la EMF Camp Édition Spéciale épisode est sorti, passeur est devenu le premier à comprendre toutes les étapes et à arriver au message final. Pendant que vous lisez ceci, un t-shirt très convoité Hackaday Podcast est déjà envoyé à leur emplacement.
Comme il n’y a plus de compétition pour voir qui arrivera en premier, j’ai pensé que ce serait le bon moment pour revenir sur la façon dont le message a été préparé et documenter quelques observations intéressantes que j’ai faites pendant l’expérience.
Suivez la route des briques jaunes
Maintenant, comme déjà mentionné, le codage de données numériques en son audible n’est en aucun cas une nouvelle technique. Il fut même un temps où des cassettes audio standard étaient utilisées pour distribuer des logiciels commerciaux. Alors plutôt que de réinventer la roue et de trouver une nouvelle façon de convertir la première partie du message en audio, j’ai opté pour un vrai classique : le standard de Kansas City (KCS).
Le produit d’une conférence animée par Octet magazine en 1975, KCS était destiné à être une norme universelle pour le stockage de données numériques sur des cassettes audio. Initialement conçu pour fournir des vitesses allant jusqu’à 300 bits par seconde, des variantes ultérieures ont réussi à obtenir des débits de données légèrement améliorés au détriment de l’interopérabilité.
En fin de compte, KCS n’a pas été un grand succès, car les entreprises individuelles semblaient déterminées à trouver leur propre façon exclusive de faire la même chose (cela vous semble familier ?), Mais cela a posé des bases importantes et plusieurs encodeurs/décodeurs les forfaits sont encore disponibles aujourd’hui.
Le message initial de 20 caractères a été encodé dans un fichier WAV à l’aide de py-kcs par David Beazley. En tant que vérification ponctuelle, j’ai également exécuté le même message via une implémentation Perl de KCS écrite par Martin Ward. Étant plus qu’un peu inquiet que peu d’auditeurs soient familiers avec un format audio vieux de près de 50 ans conçu pour les cassettes, j’ai ajouté un petit indice à la dernière minute sous la forme du célèbre « Toto, j’ai un sentiment » de Dorthy nous ne sommes plus au Kansas », ligne de Le magicien d’Oz. Enfin, parce que les messages secrets doivent toujours être joués à l’envers, j’ai inversé le tout et l’ai cloué directement à la fin de l’épisode édité avant qu’il ne passe par le script de mastering final d’Elliot.
Notez la nature numérique très claire des données KCS par rapport à la forme d’onde de la parole de Dorthy. J’étais sûr que quiconque ouvrirait cela dans un éditeur audio reconnaîtrait immédiatement qu’il y avait plus que du bruit ici. Mais à quoi cela ressemblerait-il après le script Podcast Perfection ™ Bash soigneusement conçu par Elliot?
Eh bien, c’est différent. La conversion en stéréo ne devrait pas être un problème, mais il est clair que le script est passé et a été nettoyé pendant l’encodage MP3. La voix de Dorthy est maintenant beaucoup plus importante, ce qui, si vous y réfléchissez, est logique étant donné que le fichier vient d’être exécuté via un script conçu pour améliorer le son des podcasts. Mais les données ne sont plus une série d’ondes carrées parfaites, car elles produisent un fondu étrange au début. Plus important encore, nous pouvons maintenant voir clairement ce qui semble être les données codées au milieu du signal.
[Elliot: Compressor/limiter with a slow attack keeps our ever-changing volumes relatively constant for earbuds. And that digital audio section was waaay too loud originally. If it had started out at the average loudness, it wouldn’t have been ducked at all.]
Malgré mes inquiétudes initiales, la version MP3 du son est toujours décodée correctement par les outils mentionnés précédemment, tant qu’elle a d’abord été convertie dans le fichier WAV qu’ils attendaient. Confiant que le message était intact, l’épisode a été envoyé au service de syndication pour qu’il soit diffusé le lendemain matin.
Peux tu m’entendre maintenant?
Une fois le podcast sorti vendredi matin, le vrai plaisir a commencé. Est-ce que Spotify ou Google Podcasts le relanceraient ? Est-ce qu’un réglage automatique de leur côté couperait le signal parce qu’il y avait trop d’air mort devant lui ? La réponse courte semble être… personne ne s’en soucie. Je pense que c’est un peu comme l’érotisme des dinosaures sur le Kindle Store ; une fois que vous vous êtes pleinement engagé à laisser les gens télécharger ce qu’ils veulent, vous devez accepter qu’il y aura des bizarreries occasionnelles.
Autant que je sache, l’épisode a joué comme prévu sur tous les différents services. Quelques personnes nous ont envoyé un e-mail pour nous demander si nous étions au courant du « bruit étrange » à la fin de l’épisode, et quelqu’un du Hackaday Discord a sagement conseillé aux porteurs d’écouteurs d’éviter ces dernières secondes, mais c’était tout.
Mais le message a-t-il survécu et comment les utilisateurs pourraient-ils l’extraire ? Pour les besoins de la discussion, oublions que nous proposons un téléchargement direct du MP3 pour chaque podcast, car ce serait évidemment la voie la plus directe. Je voulais voir s’il était possible d’extraire le message des différents services de podcast. J’ai donc configuré Audacity pour enregistrer à partir d’un moniteur de l’audio du système, ouvert le podcast dans les lecteurs Web pour Spotify, Google et TuneIn, et sauté directement à la fin de la piste.
Effectivement, l’audio capturé directement à partir du Web a été correctement décodé à l’aide des outils KCS. Ensuite, je me suis demandé si je pouvais brancher différents gadgets de lecture de podcasts, tels que mon Pixel 4 ou Echo Show sur l’ordinateur, et enregistrer directement l’audio à partir d’eux.
Chose intéressante, cela a en fait causé quelques problèmes. Alors que la forme d’onde était la même dans Audacity, py-kcs ajouterait systématiquement des caractères inutiles au début de la chaîne prévue. L’outil Perl de Martin Ward a fait un peu mieux, mais rencontrait également des erreurs occasionnelles. Les résultats étaient les mêmes lors de l’enregistrement à partir de mon Thinkpad T400 et de mon Chromebook Lenovo. Je ne sais pas pourquoi c’est, et je serais intéressé d’entendre quelqu’un qui pourrait avoir une théorie.
Cela dit, si vous avez ignoré les données corrompues, le message approprié est toujours passé. J’appelle donc celui-ci une victoire partielle, car si vous louchez juste sur les résultats, vous pouvez toujours passer à l’étape suivante.
La vérité est là-bas
Alors maintenant, nous avons notre réponse. Non seulement il est tout à fait possible d’utiliser un schéma d’encodage comme la norme de Kansas City pour mettre des données numériques dans un épisode de podcast, mais il est facilement possible de récupérer les données à l’extrémité réceptrice même si l’auditeur n’a pas accès au MP3 d’origine. dossier.
Mais quel est le contenu du signal décodé, et qu’en faites-vous une fois que vous l’avez ? Eh bien, je n’ai jamais promis de tout vous dire. Ne vous inquiétez pas cependant, ce message devrait vous amener à mi-chemin. Après tout, l’intention n’a jamais été de faire cela aussi difficile, ce n’était qu’une expérience.
Bien sûr, maintenant que nous savons que le concept est solide, la prochaine fois que nous cacherons un message dans un épisode du podcast… attendez-vous à avoir du pain sur la planche.
