Bienvenue aux AYTers! (Fra)
Cela faisait un moment que je n’avais par écrit sur ce blog.
La publication récente de nos travaux et du format musical AYT est donc une excellente occasion de m’y remettre.
Click here for english version 🇬🇧 https://blog.logonsystem.eu/welcome-to-ayters-eng/
2025-10-29 08:51:39
Qu’est ce que le format AYT ?
AYT (AY Turbo) est un format de fichier musical qui a été conçu pour les puces sonores AY-3-8910/2 de Général Instrument et Yamaha YM2149. Il est généré à partir du format YM, créé originellement par Léonard à partir de données à l'origine sur ATARI ST. Le format YM représente le contenu brut de toutes les valeurs envoyées au circuit.
Le format AYT propose une nouvelle approche de « compression » dans l’objectif d’obtenir une restitution très rapide et en temps constant du code qui joue une musique pour des plateformes antérieures à l’ATARI ST, et disposant de moins de ressources CPU et de mémoire.
D’autres formats musicaux existent déjà!
Alors qu’est ce qui distingue ce nouveau format des autres déjà disponibles ?
Je vais essayer de répondre à cette question dans ce billet.
Et pour ça, il faut aborder avant....
La compression de données
La compression de données est née du besoin de réduire la quantité d’informations stockées ou transmises, dans un contexte où les ressources étaient limitées : mémoire coûteuse, bandes passantes réduites, supports lents. Les premiers travaux théoriques — Shannon, Huffman, Lempel et Ziv — ont jeté les fondations permettant de transformer de longues séquences redondantes en représentations plus compactes.
Au fil des décennies, les méthodes se sont diversifiées : compression statistique, dictionnaires adaptatifs, transformées, entropie, delta-encoding, run-length, etc. Chaque approche répond à un compromis différent entre efficacité, rapidité, universalité et coût de mise en œuvre.
Cependant, la compression introduit une opposition fondamentale :
Pour les systèmes modernes, ce compromis est aujourd’hui souvent masqué par l’augmentation constante de la puissance matérielle. Quelques millisecondes de décompression sont presque indétectables pour un ordinateur contemporain.
Pourtant, ce dilemme demeure très concret pour la communauté travaillant avec des ordinateurs rétro, particulièrement ceux dont la mémoire et le processeur sont extrêmement limités, comme l’Amstrad CPC. Sur ces machines, décompresser un format complexe peut avoir un coût prohibitif : cycles CPU perdus, difficultés à tenir un timing fixe, tenter de partager la CPU entre l’envoi au circuit sonore et la décompression...
La corrélation entre taux de compression élevé et vitesse de traitement lente reste donc un enjeu majeur dans ce domaine.
Réduire la taille d'un fichier YM
Le YM est simple mais volumineux car il stocke les registres du circuit à chaque frame. Une grande majorité des approches précédentes consistait à utiliser la très bonne capacité de ce fichier à être compressé par des algorithmes récents, optimisés et très performants.
Malgré ces performances, la décompression a un coût CPU. Sur Amstrad CPC ou ZX Spectum, cette ressource CPU est devenue précieuse car les programmes sont de plus en plus optimisés et profitent de chaque cycle libre. Sans modifier totalement l’identité d’une machine, vouloir accélérer un ancien processeur relève davantage de l’expérimentation personnelle en électronique et présente souvent peu d’intérêt pour une majorité de personnes au sein de ces communautés.
En revanche, la mémoire, qui pouvait déjà à l’époque être étendue avec des extensions hors de prix, peuvent aujourd’hui bénéficier de nombreux projets qui ont permis d’étendre les limites de la ram et de rom disponibles de base sur les machines, ou même encore les espaces disques disponibles (adoption par exemple de formats de disquettes double piste, double tête).
Si je vous parle de CPU et de mémoire, c’est que contrairement aux approches visant une compression maximale du format YM (le format brut non compressé des registres de la puce), AYT a choisi un chemin différent, en misant sur la simplicité et la structure originelle des données musicales.
Le format AYT n’essaie pas d’atteindre un ratio de compression extrême et tente de « retrouver » l’organisation interne des données telles qu’elles sont produites par les outils de compositions (trackers, séquenceurs YM). Cela permet de garder une logique de vectorisation de « motifs » (appelés « Pattern » dans le jargon musical) accessibles et directement exploitables.
Le format AYT prend donc le contrepied des logiques précédentes :
il propose une compression légère, mais se base directement sur la structure d’origine des données telles qu’elles sont organisées dans les outils de création musicale.
L’objectif n'est pas de compresser au maximum, mais de représenter efficacement et proprement l’intention musicale, tout en garantissant des performances déterministes.
Bien sûr, c’est une idée qui a traversé la tête de très nombreuses personnes, mais encore fallait il avoir la motivation et le temps de travailler sur ce sujet et de l’avancer à ce stade...
La génèse du projet AYT
Si Candy avait travaillé sur ce sujet, comme moi-même bien des années auparavant, c’est la collusion des élucubrations de ce dernier, croisée avec la motivation altruiste de Tronic, qui a conduit ce dernier à construire les premières versions d’un format exploitable.
Tronic s’est « amusé » à prendre des séries de sorties du Loto pour voir combien de fois elles apparaissaient dans l’historique complet des tirages. Une fois devenu immensément riche, tel Emmett Brown découvrant le convecteur temporel, l’idée lui est venue de pousser cette idée et de l'appliquer à quelque chose de réellement utile cette fois ci: calculer combien de patterns uniques de taille T on pouvait dégager d’un registre AY.
Je ne dirai rien sur la gueule des premiers formats qu'il m'a montré, mais l’affaire était lancée, et nous avons tous apporté des idées pour faire avancer positivement les choses. Siko rejoignant alors Tronic dans une course folle à la vectorisation des patterns, à base de terminologies barbares (principe du recuit, algorithmes génétiques, le petit glouton...). Il vous en dira certainement bien plus que moi avec ses propres mots prochainement.
Une particularité intéressante de ce projet, c’est qu’il est possible de gagner en compression sans avoir à retoucher au Player, ce qui nous a permis d'avancer bien plus vite. C’est d'ailleurs encore ce que continue à faire Siko et à l’heure ou j’écris ce billet. Ses derniers résultats sont d'ailleurs étonnants au niveau de la taille gagnée. Le moins qu’on puisse dire donc, c’est qu’ils ont tous les deux avancé tous azimuts, chacun dans un style propre.
Tronic en mode fusée intersidérale et Siko en mode ultra-pondéré.
De mon côté, j’ai ajouté quelques spécifications au format, pour définir le contenu du header ou les séquences additionnelles ou d’initialisation, organisées pour que leur traitement soit le plus simple et efficace possible.
Je souhaitais que la facilité d’utilisation soit un des points forts de ce format, et nous avons oeuvré pour que cela le soit, et que l'information soit la mieux partagée possible. Nos travaux sont ainsi disponible en libre service ici:
Pour l’anecdote, en 2021, j’ai eu besoin d’un player temps fixe, et n'en trouvant pas, je n’ai pas eu d’autre choix à l’époque que d’adapter en temps fixe le player AYC très performant écrit par Madram et Shap [Si le sujet du temps fixe vous intéresse, j’ai écrit quelques chapitres sur le sujet, que vous pouvez lire au chapitre 24 du Compendium 1.8].
J’avais largement commenté ce source du player pour en faciliter l’utilisation et je l’avais distribué au sein de la "communauté Cpc". Malheureusement, malgré cette initiative de partage, son usage a trouvé peu d’écho auprès des personnes qui ont eu besoin de player après. Peut-être à cause de la complexité de génération de fichiers AYC ou de l’utilisation même du player, ou encore une mauvaise distribution. Il est resté jusqu'en juin 2025 le player temps fixe public le plus rapide sur CPC, mais je n’étais pas allé le clamer sur le portail Pouet.
Il me semblait nécessaire que le format AYT dispose d’une meilleure visibilité auprès de la communauté, et surtout qu’il soit bien plus simple à utiliser que le player AYC "temps fixe" délaissé ou les autres formats.
Cette simplicité passait naturellement par un changement conceptuel de gestion du player. Au lieu de fournir une « routine » classique transformée de manière alambiquée par un code d'initialisation, la nouvelle idée consiste à fournir un code capable de générer lui-même l'intégralité du code du player, tel que le ferait un compilateur. J’ai appelé ce code un « builder » (constructeur) et il a grandement simplifié le processus d’utilisation sur la plateforme.
En partant de ce principe, et pour les personnes qui travaillent en cross dev, il est d'ailleurs possible d’imaginer que le « builder » soit adapté en C sur la plateforme de développement pour fournir le code, voir directement le source du player intégrable dans une chaine de compilation.
Mes deux compères m’ont suivi sur cette voie de leur côté en créant des outils de plus en plus puissants et faciles à utiliser. Cela s’est traduit concrètement par des outils directement disponibles sur le web et simplifiant grandement des sujets tels que les conversions, l'écoute, le séquencage, ou même les conversions de fréquences puisqu'il est nécessaire d’adapter les données en fonction de la vitesse ou le circuit est cadencé sur la plateforme cible et en fonction de celle qu’il avait sur la plateforme d’origine.
La taille d'un fichier AYT
Si la taille d’un fichier AYT n’est pas son meilleur atout par rapport à un format ultra compressé, il faut aussi retenir que la taille du fichier est très dépendante de l’origine des données de base, afin d'éviter toute généralisation abusive.
Un fichier issu de certains trackers pourra donc donner de très mauvais résultats, et l’inverse avec des fichiers provenant d’autres outils, ou sur des musiques courtes. Il existe par exemple énormément de musiques réalisées sur d’autres plateformes que le CPC.
Sur ZX Spectrum, qui dispose de la plus vaste collection de musique AY existante, 83% des musiques AYT converties à partir du format PT3 existantes ont une taille inférieure à 17k. Plus de 100 000 musiques en AYT ont actuellement été transformées à partir de très nombreux formats et chipsets sonores, ce qui a permit de consituer une base statistique intéressante.
Enfin, il ne faut pas perdre de vue si on évoque la taille des données, qu'il faut y intégrer la taille du code nécessaire à jouer la musique. Le player AYT n'a pas besoin de buffers de décompression alignés en mémoire, ne nécessite pas la présence d'un code d'initialisation pour pouvoir reboucler sans problème et occupe lui même bien moins de place que les autres players.
Mais évoquer la seule taille des données du fichier AYT sans évoquer ses nombreux autres atouts ne serait pas très juste....
Quand choisir AYT plutôt qu’un format plus compressé ?
De nombreux critères peuvent justifier le choix d’un format moins compressé, mais plus performant comme AYT.
Certains critères sont même impossibles à obtenir actuellement avec des formats fortement compressés :
✔ Taille du fichier compacté hors exécution
Une fois compacté par un packer externe, un fichier AYT est souvent plus petit que d'autre formats déjà compressés. En effet, les algorithmes de compression de ces autres formats ne sont pas les plus performants car ils sont contraints de permettre une décompression rapide et à la volée. Aussi la recompression d'un fichier déjà compressé de cette manière est peu rentable et efficace.
Cela permet au format AYT d'occuper moins de place sur disque et en mémoire avant son exécution, et particulièrement quand le code du décompresseur est plus gros que l’économie réalisée au runtime. On pourrait citer de nombreux exemples, mais pour le programmeur d'une démo limitée à un fichier de 4 kilo-octets, le format AYT est sans doute le meilleur choix.
✔ Player en temps fixe
Les players AYT garantissent une exécution en temps strictement constant, indispensable pour certains usages comme les démos. C'est une notion très appréciables, notamment dans le demomaking qui exige des timings extrêmement précis. De plus, la constance de la CPU reste vraie pour chaque frame, et notamment lors du bouclage ou la fin du morceau lorsque le player passe en "mute". Sur CPC, l'initialisation qui a lieu durant le premier frame est également réalisée en respectant le temps du player.
✔ CPU du player
La CPU du player est le temps que ce dernier prend pour jouer la musique. Sur CPC on l'exprime en général en NOPs (ou µsecondes) et sur d'autres plateformes, elle est exprimée en TS (Timing State ou Cycle d'horloge du processeur). Elle dépend de la plateforme utilisée car l'accès au circuit sonore peut être plus long sur certaines plateformes.
Sur CPC, le player AYT « standard » est actuellement le player AY le plus rapide existant, et le player « + » (optimisé CPC+) est deux fois plus rapide que le player CPC.
✔ CPU d’initialisation
Il s'agit du temps utilisé par le player pour initialiser les registres qu'il n'utilisera pas. C'est une opération nécessaire pour garantir toute fausse note liée à un registre non initialisé. Elle est très faible pour AYT et on peut noter que sur CPC, l’initialisation est intégrée au player de manière transparente, sans qu'il soit nécessaire d'appeler une routine dédiée comme sur tous les autres players.
✔ Gestion du rebouclage
Le format AYT permet de reboucler n’importe où dans le morceau, et toujours en temps fixe. Les formats compressés ne peuvent en général reboucler qu’au début ce qui peut être bloquant ou complexe à contourner.
✔ Mute de fin propre
Le format et le player AYT assurent un mute déterministe à la fin du nombre de lectures prévu. En effet, certains fichiers au format YM original sont souvent mal terminés ou pollués par des séquences redondantes et inutiles, ce qui peut produire des fins et rebouclages irréguliers.
✔ Absence d’altération des données
La création du format AYT ne modifie pas les données musicales, contrairement à certains players ou convertisseurs qui peuvent induire des approximations ou contentions.
✔ Taille maximale et limites d’adressage
Le format et le player AYT n'impose pas de contraintes fortes ; la structuration interne permet de gérer de gros fichiers. Ce n'est pas le cas de tous les formats hautement compressés et il est nécessaire de s'en assurer.
✔ Impact de l'adresse Player/Musique
Le format est stable et n’est pas dépendant de l’adresse mémoire, contrairement à certains players sensibles aux alignements de pages, notamment lorsque des buffers de décompression sont impliqués.
✔ Accès à la durée CPU via le builder
Le builder sur CPC renvoie la durée CPU consommée par le player. Cela peut avoir un intérêt indéniable pour un code qui est entièrement (ou partiellement) écrit en temps fixe.
✔ Player multiplateforme
Le format est pensé pour être portable, même si le CPC constitue sa cible principale. Il faut noter qu'au sein même des machines CPC Amstrad, la plupart des player prévus sur CPC fonctionneront aussi sur CPC+, sans toutefois bénéficier de ses atouts particulier. Il existe néanmoins une version de player AYT spécifiquement prévue pour CPC+ pour obtenir un player plus compact et bien plus rapide.
✔ Fonctionnement en ROM
Une version ROM du player sur CPC est disponible afin de pouvoir être intégrée efficacement dans toute production qui impliquerait ce support.
✔ Critères pratiques
La facilité d’utilisation d’un compacteur, la disponibilité d’outils web, les convertisseurs multiplateformes, ainsi que la simplicité d’intégration du player sont également des critères majeurs.
L’écosystème AYT a été pensé pour être simple à utiliser, ce qui n'est pas toujours le cas des formats compressés nécessitant des décodeurs complexes.
D'autres critères sont à l'étude, comme par exemple la possibilité de réutiliser le code d'un player pour différents morceaux, ce qui peut s'avérer déterminant dans un jeu qui a besoin de gérer plusieurs musiques et des bruitages.
Il reste également énormément de sujets à creuser dans le domaine des formats musicaux et des players car c'est un immense terrain d'expérimentation. Certains points durant ce projet ont éveillé notre curiosité et quelques idées se révèlent très prometteuses. Mais c'est une autre histoire que je vous conterai plus tard...😄.
En attendant, j'arrête ici ce long billet et j'en profite pour saluer tous les AYTers qui nous ont accompagné et encouragé de près ou de loin durant ce travail passionnant. Un grand merci à Ced, Made et Med, qui ont contribué par leur immense talent à donner un peu de visibilité à ce beau projet.
Et pardon à tous ceux qui ont du se taper "Le petit pont de bois" que nous avions égaré sur un disque de compositions 😜
Longshot / Logon System