[SDMOTO] fusion SDBOOT + demonstration SD

[__sam__]

Oh il y a inversion des échantillons! Sur un bloc de N échantillons, le numéro 0 se retrouve en position N-1, et lycée de Versailles.

Allez mon pari: N=512, la longueur d'un bloc sur carte SD et c'est provoqué par la lecture du buffer interbloc. Peut-être que L'octet 1 du CRC récupère un échantillon de fin de bloc, et l'octet 2 de CRC récupère un échantillon de fin de bloc précédent. Si c'est ca c'est peut-être provoqué par la logique (complique) du déplacement du pointeur X lors de la lecture (le leax 2,x que je n'ai pas encore cherché à comprendre).

Un truc m'étonne: le player joue approx à 5khz, les sinusoïdes sont approx à 0.4khz, on a donc 50/4 = 11 échantillons par périodes. Or sur les captures la sinusoïde a l'air bien lisse avec bien plus de 11 échantillons/période. La freq de la sinusoïde ne serait-elle pas plutôt de 44hz au lieu de 440hz ?

A 44hz, on joue autour de 110 échantillons par periodes ce qui n'est pas assez pour remplir un bloc de 512 octets. Il n'y aurait donc pas correlation entre la frequence des "glitchs" et la frequence de changement de bloc. Mon hypothèse s'effondre. Dommage elle me paraissait séduisante.

Reste alors un truc: le générateur de fichier binaire est il ok ? je ne vois rien qui cloche.

[__sam__]

non c'est pas une inversion des échantillons. J'ai repris l'image que tu as posté daniel, et j'ai relié les le bas d'un pic avec le sommet du pric précédent. Ca correspond très bien. Trop bien pour être du hasard.

Untitled.png (29.45 Kio) Consulté 3071 fois

Il y a clairement corrélation entre les pics consécutifs. On pourrait croire que le dernier échantillon d'un pic, se retrouve être le premier du suivant.

Ca pourrait être une sinusoïde supplémentaire de plus basse fréquence d'échantillonnage qui s'échange par moment avec la belle sinusoïde échantillonnée à plus haute fréquence. Les deux sinusoïdes semble être de fréquence propre similaires. Comment est le fichier RAW d'origine ? Il contient déjà peut-être ce glitch.

[EDIT] La belle sinusoïde est vraiment étrange. A 440Hz on devrait avoir 4486/440=12.69 échantillons sur une période. On en a manifestement bien plus.

[EDIT2] En zoomant je n'ai plus tellement l'impression que les pics soient consécutifs. Il semble y avoir aussi quelques légers accrocs dans la courbe bien lisse. En comptant les pics et les légers accrocs.. je dirais qu'il y en a une douzaine par période de sinusoïde. Hasard? (j'y crois peu).

sdplay_sine.png (7.35 Kio) Consulté 3069 fois

Je me pencherais vraiment sur la façon dont est généré le fichier RAW initial.

[Daniel]

C'était tout bête, comme la plupart des erreurs en informatique. SDPLAY est juste, le générateur de fichier binaire est juste, mais je suis très mauvais :

Le fichier de données pour SDPLAY contient une image sur $2000 octets, suivi du fichier binaire contenant les échantillons (avec des bits supplémentaires pour générer les autres échantillons à jouer entre deux blocs). J'ai tout bêtement mis une image de $1F40, en oubliant de la compléter à $2000. Tous les secteurs de 512 octets savamment préparés se trouvent décalés, les frontières de secteurs ne sont plus au bon endroit, et l'algorithme de génération des octets supplémentaires fait n'importe quoi. En fait il calcule bien les bons octets mais ne les joue pas tous au bon moment, pour certains il y a un buffer de décalage.

C'est réparé, l'incident est clos, j'écoute les Quatre Saisons en boucle depuis une heure, c'est ma punition pour cette bêtise.

Tous les fichiers de mon post précédent sont bons, vous pouvez maintenant générer vos propres fichiers de musique pour SDPLAY. Pour vous aider il y a ci-dessous un fichier .sd tout prêt contenant SDPLAY.BIN et SDPLAY.BAS. Il suffit d'ajouter derrière les données de la démo.

sdplay.zip

(13.51 Kio) Téléchargé 104 fois

Dans les jours qui viennent je vais refaire toutes les anciennes démonstrations de musique et mettre à jour le site dcmoto pour remplacer les anciennes.

[Daniel]

La belle sinusoïde est vraiment étrange. A 440Hz on devrait avoir 4486/440=12.69 échantillons sur une période. On en a manifestement bien plus.

La courbe est obtenue en sortie de dcmoto, qui génère des échantillons à 22050 Hz. C'est indépendant de la fréquence du fichier de musique, qui est de 5586 Hz. La dernière sinusoïde dont j'ai donné l'image est à 2 Hz. J'en avait fait une précédemment à 440 Hz, mais elle ne permettait pas de bien voir le défaut.

[__sam__]

pour certains il y a un buffer de décalage.

Arf oui ca explique mon hypothèse initiale de l'échantillon de fin de buffer qui se trouve au début. Ce que je ne comprends pas cependant est qu'un buffer dure environ 0.1sec, soit 44 périodes de sinusoïdes. On ne devrait donc avoir recour au buffer que très rarement du point de vu de la sinusoide. Or sur la capture les pics sont bien plus nombreux que ca. D'où viennent tous ces pics superbement corrélés à la sinusoïde principale? J'ai du mal à imager que le décalage de 192 octets, soit 34ms c'est à dire 15.12 périodes fasse apparaitre des pics. C'est juste un décalage.
[EDIT après avoir lu le msg sur la sinusoïde à 2hz] Tout s'explique avec une sinusoïde à 2hz. A cette vitesse, c'est environ 10 à 11 changements de buffer par période, ce qui correspond aux 10-11 accrocs de mon dessin plus haut (cf la source et la destination des flèches jaunes).

C'est réparé, l'incident est clos, j'écoute les Quatre Saisons en boucle depuis une heure, c'est ma punition pour cette bêtise.

Il y a pire

Dans les jours qui viennent je vais refaire toutes les anciennes démonstrations de musique et mettre à jour le site dcmoto pour remplacer les anciennes.

Oui maintenant la technologie devient mure.

[__sam__]

Pour info, j'ai trouvé une version de CoolEdit2000 ici: http://www.oldapps.com/CoolEdit.php?old ... 1?download, mais c'est une version d'eval (30jours). Je ne sais pas s'il est en abandonware et complètement débridé quelque part.

[Daniel]

J'ai voulu l'acheter, mais il n'est plus en vente. Syntrillium n'existe plus. Adobe Audition ne me plaît pas. Les logiciels open source ne valent pas CoolEdit2000, au moins pour mon usage. Il ne reste plus que les moyens illégaux ici.

Sur internet on trouve CoolEdit2000 v1.0 et v1.1. J'ai utilisé les deux, il n'y a pas de différences dans les fonctions les plus courantes.

[Daniel]

Mise en ligne de la nouvelle version de sdmoto-annees80 : http://dcmoto.free.fr/programmes/sdmoto ... index.html

La carte SD, grâce à sa grande capacité et à sa rapidité d'accès, apporte des possibilités nouvelles et très spectaculaires aux ordinateurs Thomson. Années 80 en est un bon exemple. Il faut lancer cette démonstration sur un MO ou un TO réel pour apprécier l'exploit technique à sa juste valeur. Nécessite un contrôleur CS91-280 associé à une interface SDMOTO. La section Bricolage du site dcmoto fournit toutes les explications. Le fichier doc ci-dessous contient tous les programmes pour créer vos propres démonstrations. Les sources sont fournies. Le fichier mp3 donne un aperçu des dix premières minutes de la démonstration. Elle dure en réalité 75 minutes.
Le regroupement d'une image de disquette et d'un fichier de données dans le même fichier .sd est une idée originale de Samuel Devulder. Il a programmé le calcul de l'adresse physique des données et participé à la mise au point et au test du nouveau programme SDPLAY.

Les 10 premières minutes de la démo de 75 minutes sont ici en mp3 --> :
Je demande un peu d'indulgence aux mélomanes : replacez cette musique dans le contexte, elle sort d'un MO5, pas d'une chaîne HiFi. Evidemment, c'est très mauvais, mais personne d'autre n'avait réussi l'exploit technique avant l'invention de sdmoto.

Le développement n'est pas terminé : il faudrait ajouter une barre de défilement, un bouton pause, des boutons d'avance rapide et de retour au début, etc... Mais je suis passé à autre chose, alors j'ai préféré mettre toutes les sources en ligne pour les candidats à l'amélioration du programme

[irios]

C'est excellent les gars !! Beau boulot. Bravo !!!!

[Fabf]

Désolé j'ai pas tout bien compris
Est ce que le fichier audio est lu en streaming depuis la SD ou chargé dans la RAM ?

[__sam__]

C'est lu en streaming depuis la carte SD. (la ram ne suffirait pas pour 75min de zik en continu)

Je teste en ce moment même.. ca passe impec' pour l'instant.
Ce soir chez boris^wsam c'est soirée disco!

RdV dans 75mins...

{EDIT] ca y est... j'ai loupé le rebouclage (pas de bol ca faisait moins que 75mins).. C'est reparti pour un tour.. RdV dans 70mins si j'ai le courage..

[Daniel]

En pinaillant un peu, on peut dire que la RAM est aussi utilisée : pendant la lecture de 512 échantillons en streaming, 32 échantillons sont stockés en RAM vidéo pour être joués pendant le gap entre deux blocs.

Dans les 32Ko de RAM utilisateur du MO5, on peut stocker un peu plus de 5 secondes de musique à cette fréquence d'échantillonnage. Sur la carte SD on peut mettre 32Go, soit un million de fois plus (1388 heures).

[Fabf]

Merci pour les précisions
Je posais juste la question parce que j'ai fais un COVOX sur MSX et les seuls programmes dispos charge le fichier entier en RAM.
Il faut donc un memory mapper de 4MO

[__sam__]

Si je lis bien http://en.wikipedia.org/wiki/Covox_Speech_Thing, le covox est un circuit CNA simple type R/2R qui se branche sur le port parallèle. Sur thomson on a pas besoin de cela car l'extension "manette" contient déjà un CNA sur 6 bits de type R/2R. C'est ce qui est utilisé dans le cas présent.

Il existe aussi un buzzer 1 bit qu'on peut utiliser en PWM avec un bon timing des instructions 6809 (rechercher le message relatant l'expérience de Daniel sur le sujet).

[Daniel]

A noter que le CNA des Thomson utilise aussi un diviseur à résistances, exactement comme le Covox des MSX. Mais il n'a que 6 bits.
Pour la démo annees80, il faudra 25 Mo de RAM sur le MSX. Je ne sais pas si c'est possible ?