[VB] ou [C] conversion wav et sauvegarde data dans un .TXT en binaire

[genocyber]

Bonjour

Je débute en VB et j'aimerai convertir des fichiers wav 8bits en wav 4 bits pcm et je dois pour mon projet (µc qui pilote un vieu chipsound ) avoir les données binaire de ce sample wav 4 bits dans un fichier .txt pour pouvoir utiliser cette suite de valeurs de 4 bits dans un autre IDE "Mplab" .

J'apprend a programmer sur µc en language d 'assemblage , j'aimerai ne pas avoir a étudier le VB pendant des mois pour pouvoir continuer mon projet µc , je sais qu'on a rien sans boulot , si je ne peux m'y soustraire j'y passerai le temps , mais si vous avez une idée pour cibler mon apprentissage du VB en vue d'allez plus vite dans mon projet vous me tireriez une épine du pied

J'ai des notions en C , si vous pensez que j'aurai plus simple et que ça serai plus rapide en C en mode console , hésitez pas a me dire que je fais fausse route .

J'ai essayer d' écrire un pseudo code histoire de commencer quelque part .

'mon pseudo code

pointer au début du sample
passer 43 octets ( headers )

while pas le dernier octet du sample 
lire octet suivant sauver dans une variable
convertir variable en 4 bit
envoyer la valeur en binaire dans fichier .TXT ( dans un tableau l un a la suite de l autre )
endwhile

merci d'avance
-----

[Bluedeep]

Bonjour

Je débute en VB

En VB ? Vous êtes sur ? ou est-ce plutôt en VB.NET ou en VBA ?

Car je serais très surpris que vous débutiez avec un langage abandonné de facto depuis 11 ans.

Par ailleurs, mais là j'avoue que je n'y connais rien ou presque, ça me surprend que vous puissiez utiliser VB pour piloter un microcontroleur.

[lou_ibmix_xi]

e débute en VB et j'aimerai convertir des fichiers wav 8bits en wav 4 bits pcm et je dois pour mon projet (µc qui pilote un vieu chipsound ) avoir les données binaire de ce sample wav 4 bits dans un fichier .txt pour pouvoir utiliser cette suite de valeurs de 4 bits dans un autre IDE "Mplab" .

Il y a quelque chose que je ne trouve pas super clair, tu as un fichier d'entrée en WAV 8bits mais que dois tu en faire, un WAV 4 bits _ET_ un fichier texte contenant des valeurs comprises entre -8 et +7, simplement le fichier texte?

Toujours est-il que c'est très simple à faire avec MATLAB/OCTAVE (le dernier étant le clône gratuit du 1er), c'est même aussi simple que ça:

s = wavread('fichier.wav');
csvwrite ('fichier.csv',  round (8*s));

Tu as d'autres solutions:
- utiliser un ou plusieurs petit utilitaire en ligne de commande (sox, les utilitaires livrés avec libsndfile...) pour le faire
- faire un programme en C qui utilise libsndfile ou une autre bibliothèque

[genocyber]

Effectivement je débute en Vb.NET .
Au sujet du µc , celui ci pilote un chipsound et ce chipsound peu jouer des samples avec un mode proche d une sortie pwm (non linéaire ) avec 4 bits non-signé qui sont le volume en Db .

merci pour ces réponses , je vais tester et voir ce qui me convient le mieu

[A voir en vidéo sur Futura]

[genocyber]

Il y a quelque chose que je ne trouve pas super clair, tu as un fichier d'entrée en WAV 8bits mais que dois tu en faire, un WAV 4 bits _ET_ un fichier texte contenant des valeurs comprises entre -8 et +7, simplement le fichier texte?

Voici une précision issue d'une réponse a un email que j'ai envoyé

Pour sortir des samples PCM l'astuce consiste à mettre tout les fréquences à 0x0000 pour que le chipset passe dans un mode proche d'une sortie PWM (non linéaire) et d'utiliser les 4 bits de volume comme dac.

les octets a envoyer au chipsound ont cette structure :
LccMdddd => L = latch
cc = channel
M = mode tone ou volume ( volume dans mon cas )
dddd = les 4 bits du samples .

l'utilité du fichier TXT serai de pouvoir simplement copier coller le résultat de la conversion en 4 bits non-signé dans mon IDE en language d 'assemblage je pourrai alors faire une macro qui utilise cette suite de valeurs et l'envoyer au 3 channel avec le bon latch et le bon mode

[Bluedeep]

Je ne comprends pas ce mail : le PCM ne comporte pas d'information de fréquence (il faut être d'accord sur la fréquence d'échantillonage utilisé) et comporte juste des infos de hauteur de signal quantifié sur n bits, échantillonés à une fréquence donnée.

[lou_ibmix_xi]

les octets a envoyer au chipsound ont cette structure :
LccMdddd => L = latch
cc = channel
M = mode tone ou volume ( volume dans mon cas )
dddd = les 4 bits du samples .

l'utilité du fichier TXT serai de pouvoir simplement copier coller le résultat de la conversion en 4 bits non-signé dans mon IDE en language d 'assemblage je pourrai alors faire une macro qui utilise cette suite de valeurs et l'envoyer au 3 channel avec le bon latch et le bon mode

Ce genre de chose devrait être faite de manière automatique, et c'est à mon avis très facile avec un petit script shell qui prend en entrée le fichier wav, en extrait les données sous forme textuelle, redirigé vers une combinaison de sed et/ou awk pour insérer les infos et les enregistrer dans un fichier ".h" ou autre à inclure dans ton projet.

Remarques:
- c'est le genre de chose que je fais très souvent pour mon boulot (transformer un fichier wav en tableau directement exploitable dans mon programme), mais je programme C (je ne connais pas les possibilité d'inclusion en assembleur), et sous environnement linux (ou le shell possède les "pipe" et les redirections)
- pourquoi travailler en assembleur, de nos jours les compilateurs C sont bien plus performant pour l'optimisation du code (au pire avec l'aide de mots clefs comme "const" ou "restrict"), et l'assembleur n'est réservé qu'à des endroit où on ne peut pas faire autrement, typiquement dans les premiers instants du démarrage (installation du vecteur d'interruption, de la "c-runtime" ...)

[genocyber]

Exactement , c'est le chipsound qui est mis a la fréquence 0x0000 pour passer en mode pseudo pwm .
Les informations sont bien des hauteurs de signal en db et pas des fréquences .
Donc je dois avec mon µc lire nbits avec une interruption sur le timer qui sera la mème que la fréquence d'échantillonage du sample max 8khz .

la doc du chipsound si tu souhaite des précisions plus clair que mon vocabulaire de noob

http://www.smspower.org/Development/...amplesOnThePSG

[Bluedeep]

- pourquoi travailler en assembleur, de nos jours les compilateurs C sont bien plus performant pour l'optimisation du code (au pire avec l'aide de mots clefs comme "const" ou "restrict"), et l'assembleur n'est réservé qu'à des endroit où on ne peut pas faire autrement, typiquement dans les premiers instants du démarrage (installation du vecteur d'interruption, de la "c-runtime" ...)

+1
On ne voit pas l'interêt ici : n'importe quel langage capable de manipuler au niveau du bit convient.

[genocyber]

- c'est le genre de chose que je fais très souvent pour mon boulot (transformer un fichier wav en tableau directement exploitable dans mon programme), mais je programme C (je ne connais pas les possibilité d'inclusion en assembleur), et sous environnement linux (ou le shell possède les "pipe" et les redirections)

J'ai des petites notions de C ( apparemment pas assez ) et je suis sous windows .
Les librairies que je trouve ne descendent pas en dessous de 8bits pcm non-signé .

Pour lire octet par octet mon wav en C le mieu est-il d'utilisé fgets ( que je ne métrise pas ) ?

pourquoi travailler en assembleur

Car a la base je fais de l'élèctronique , que je voulais être au plus près du µc au besoin , quand le language d 'assemblage de microchip sera bien assimilé je peux intégrer des bouts de code en C dans mon code ASM et vis versa .

Aussi j'ai simplement envie d'apprendre sans souci d'utilité ou d'interêt , Just for Fun

[Bluedeep]

J'ai des petites notions de C ( apparemment pas assez ) et je suis sous windows .
Les librairies que je trouve ne descendent pas en dessous de 8bits pcm non-signé .

Pour lire octet par octet mon wav en C le mieu est-il d'utilisé fgets ( que je ne métrise pas ) ?

Je ne comprends pas : je croyais que ton programme C tournait sur ton micro-controleur ?

Si c'est pour lire les fichiers octet par octet sous Windows, le framework .NET a tout ce qu'il faut : tu instancie un FileStream et un BinaryReader à partir du FileStream et roulez jeunesse( et tu peux le faire en VB.Net même si pour la manipulation au niveau du bit C# est beaucoup mieux outillé, ça peut se faire quand même).

Tu peux même le faire en PowerShell directement.

[genocyber]

J'ai du mal m'exprimer .
Mon code est en language d assemblage coté µc .

Je vais fouiller du coter du framework.net je sent que je vais manger du tuto pendant un bout de temps

mon µc devra contenir la suite de valeurs de 4 bits

[lou_ibmix_xi]

J'ai des petites notions de C ( apparemment pas assez ) et je suis sous windows .
Les librairies que je trouve ne descendent pas en dessous de 8bits pcm non-signé .

Je ne vois pas de problème, si c'est de la lecture d'un fichier WAV je veux bien le croire mais ton fichier d'entrée est bien en plus de 8bits par échantillons, et en sortie tu veux un fichier qui ne tombe pas dans un standard donc tu fais ce que tu veux.

Pour lire octet par octet mon wav en C le mieu est-il d'utilisé fgets ( que je ne métrise pas ) ?

Non le mieux est d'utilisé dans ton programme une bibliothèque qui lit le WAV directement (par exemple libsndfile), ou mieux un ou plusieurs outils combinés et ne pas faire de programme. C'est une des bases du développement logiciel: ne pas réinventer la roue et utiliser les bibliothèques / outils existants. En tout cas surtout pas "fgets" qui est orientée lecture de fichier texte, si vraiment tu veux te le palucher à la main c'est plutôt "fread".

J'ai du mal m'exprimer .
Mon code est en language d assemblage coté µc .

Je vais fouiller du coter du framework.net je sent que je vais manger du tuto pendant un bout de temps

mon µc devra contenir la suite de valeurs de 4 bits

Bon si j'ai bien compris:
Tu programmes un PIC en assembleur, et tu programmes en VB.NET côté PC pour tes outillages, communications... Tout celà dans un but éducatif / ludique ? J'ai bon ?

Du coup, je reviens à la charge pour critiquer les outils que tu utilises:
- l'assembleur: tu vas passer beaucoup de temps à apprendre une syntaxe compliquée, utilisable uniquement sur ton PIC, qui va te faire te focaliser sur des détails en te faisant COMPLETEMENT passer à côté des aspects "développement logiciel"
- le PIC, sans critiquer le composeant en lui-même, le compilateur MPLAB me sort par les yeux! Je ne sais pas si la situation a évolué depuis, mais il y a quelques années il était perturbant, et d'autant plus qu'il laissait passé des monstruosités (j'ai vu de l'unsigned float compilé!), ce qui est loin d'être l'idéal pour apprendre le C
- Windows, non non ce n'est pas encore une énième guerre de c'est mieux ci ou ça, c'est un constat, pour mon boulot je suis très souvent dans ce genre de problématiques: faire des outillages côtés PC pour discuter / configurer / traire les données depuis mon programme embarqué sur un petit UC, l'avantage de LINUX (et peut-être de MAC) est que tu peux en faire énormément SANS ECRIRE UNE LIGNE DE C! Voui tout est fichier sous UNIX, la liaison série également, et les "pipes" et redirections font le reste: un exemple concret, nous avons réalisé un système de positionnement qui diffusait par radio la position de différents mobiles, j'ai pu réaliser la visualisation des différents mobiles sur "google map" uniquement en SHELL (et un peu d'OCTAVE pour la vonversion XY <-> coordonnées GPS)

Je te conseillerais donc de te mettre au C, apprendre les rudiments de la syntaxe (en oubliant le PIC dans un 1er temps): tu iras plus vite à l'essentiel (faire un programme sympa) tout en restant proche de la réalité industrielle d'aujourd'hui (en embarqué, nous faisons du C à 90% voir plus), et tout en apprenant un langage que tu pourras utilisé de partout.

Pour le matos, je critique plus MPLAB que le PIC en lui-même, et à l'époque il n'y avait pas vraiment d'alternative crédible et peu chère. J'aime bien le MSP430, MSP430x (version 20bits) de chez texas instrument, il est comparable en terme de puissance / complexité, mspgcc (le compilateur gratuit open-source) marche très bien, et on trouve des cartes et sondes JTAG pour pas cher (chez OLIMEX par exemple, et chez TI j'avais acheté une "carte de dev" en montre pour une 40aine d'euro sonde jtag comprise!)

Pour ta plateforme de dev, je ne sais pas si une machine virtuelle peut faire l'affaire, je n'ai jamais vraiment joué avec ce genre de truc sous windows donc je ne sais pas si l'accès aux périphériques est suffisament fonctionnel pour en tirer un quelconque avantage, mais de nos jour installer un (X)UBUNTU en double boot est à la porté de n'importe quel électronicien ! Iil y a certe un apprentissage mais le gain de temps dérrière est énorme.

[Bluedeep]

Du coup, je reviens à la charge pour critiquer les outils que tu utilises:
- l'assembleur: tu vas passer beaucoup de temps à apprendre une syntaxe compliquée, utilisable uniquement sur ton PIC, qui va te faire te focaliser sur des détails en te faisant COMPLETEMENT passer à côté des aspects "développement logiciel"

+1
Entiérement d'accord avec toi là dessus.

- Windows, non non ce n'est pas encore une énième guerre de c'est mieux ci ou ça, c'est un constat, pour mon boulot je suis très souvent dans ce genre de problématiques: faire des outillages côtés PC pour discuter / configurer / traire les données depuis mon programme embarqué sur un petit UC, l'avantage de LINUX (et peut-être de MAC) est que tu peux en faire énormément SANS ECRIRE UNE LIGNE DE C!

Une fois de plus, ta méconnaissance de Windows te fait attribuer à Linux un avantage totalement inexistant. (mais est-ce de la méconnaissance ou du parti pris ?).

Les scripts PowerShell permettent d'instancier n'importe quel objet du framework .NET préinstallé sans écrire une ligne de code que ce soit en C ou autre chose.

[bisou10]

MPLAB n'existe plus. C'est maintenant MPLABX qui est trés bon (c'est un netbeans relooké), et la chaine de compilation C fournie (XC8 pour les 8 bits) contient une librairie logicielle tout à fait convenable (qu nécessite bien sûr la lecture de la doc, mais qui contient tous les define nécessaire pour l'accès direct aux fonctions/ports et bien plus).

Honnetement, je me sens aussi bien sur PIC que sur DSP TI (qui lui, utilise CCS: un eclipse relooké). Les outils sont excellents et la communauté existe dans les 2 cas. La réputation low cost de Microchip commence à s'atténuer, leurs efforts sont payants.

[bisou10]

Les scripts PowerShell permettent d'instancier n'importe quel objet du framework .NET préinstallé sans écrire une ligne de code que ce soit en C ou autre chose.

En powershell, quand même, ce qui n'est pas à proprement parler une syntaxe C like neutre. Perso, comme elle me rebute un peu, je préfère directement coder ça en C#, ce que je conseille (ou tout autre RAD existant).
Ceci étant, je conseillerais quand même, quel de soit l'OS, de partir sur un RAD, je ne compte plus les 'petits' outils de test sur lesquels on a ajouté une IHM et étendu le fonctionnement. Lancer Visual Studio est imho une bonne chose.

[Bluedeep]

En powershell, quand même, ce qui n'est pas à proprement parler une syntaxe C like neutre.

Euh .... oui .... mais ca ne limite pas son usage pour autant.

Perso, comme elle me rebute un peu, je préfère directement coder ça en C#, ce que je conseille (ou tout autre RAD existant).

L'avantage c'est que PWRS permet de livrer des scripts complexes à la production qui peut les modifier (par exemple dans le cadre d'installation d'appli MOSS où tu es amené à faire des scripts pouvant être vraiment "touchy") ce qui ne serait pas le cas avec C#

[genocyber]

Salut

J 'aime quand mes posts deviennent aussi intéressant


Oui pour pic en assembleur et le coté ludique , éducatif , j'ai choisi ce premier µc pour commencer l 'assembleur car les cours de Mr Bigonoff sont vraiment très claire , donc il rend déja "je trouve" la tache plus facile quand au coté un peu austère de mplab .
Mais honnètement j'aime bien ce language d'assemblage , peu être aussi parceque je n'utilise que celui la .
J'avais un peu coder sur arduino mais je suis pas fan , j'ai l'impression de pas allez au fond des choses , mon but surtout c'est la compréhension des µc et leur structures donc arduino j'ai laisser tombé mais ,mas je pense qu'il faut pas s'arreter a un seul language faut savoir jongler avec tous ce qui passe .
Donc je compte bientot m'attaquer a atmega et puis a d'autre avec chaque fois un projet a réaliser avec cahier des charges comme je fais pour le moment avec un pic16f et je compte vraiment pas m'arreter la , j'ai pas encore fouiller la théorie et pratique niveau DSP mais ça commence a me chatouiller et ce n'est qu'un exemple .

Pour le C j'ai des notions jusqu'au pointeur . C'est plus au niveau algoritme que je dois travailler , enfin je crois , je connais quelques outils basique du C mais je dois apprendre a les utiliser combiner et poursuivre mon apprentissage.

Je pense t'ecouter et revenir vers le C un moment le temps de créé des automatisme de programmation .

En ce qui concerne mon projet j'ai plus ou moins fait comme tu disais .
J'ai converti le sample avec sox , j ai ouvert le sample converti dans hexedit , j'ai passer 44octets et j'ai copier colller le resultat .
C'est pas idéale mais ça marche .

J'ai un windows et un linux qui traine , j'aime beaucoup kali linux pour le moment .
Mais j'en suis encore qua l'ecriture de simple script j'ai pas encore assez fouiller le sujet , mais je pense plutot que de me mettre a fond dans VB ou autre plutot choisir du multiplateforme , j 'avoue que j'ai pas encore bien réfléchis au meilleur choix , mais j'aimerai que le codage hors interface graphique soi du C .

[lou_ibmix_xi]

Une fois de plus, ta méconnaissance de Windows te fait attribuer à Linux un avantage totalement inexistant. (mais est-ce de la méconnaissance ou du parti pris ?).

Les scripts PowerShell permettent d'instancier n'importe quel objet du framework .NET préinstallé sans écrire une ligne de code que ce soit en C ou autre chose.

Tachons d'éteindre la polémique... C'est donc peut-être du parti pris basé sur de la méconnaissance. Je ne connais plus windows, je n'y touche plus depuis un bon bout de temps, et à cette époque "powershell" n'existait pas! Donc il y a enfin sur une plateforme microsoft un SHELL suffisant pour pouvoir y implémenter des fonctionnalités un peux sérieuses. Néanmoins, j'ai quelques remarques:

- Un système UNIX est "texte-centrique": les interfaces avec le système sont textuelles (/etc, /proc et /sys), les outils fournis (le shell, mais également le triplet gagnant grep/sed/awk) sont fait pour travailler sur du texte... Ca tombe bien le terminal est forcément une interface textuelle et tout cela est cohérent. A l'inverse, les OS de MICROSOFT sont centrés "composants binaires": base de registre, communications entre processus... etc ce sont des objets binaires. Je ne dis pas qu'une philosophie est mieux que l'autre dans l'absolue. En revanche, dans ce cas de figure, la philosophie textuelle me semble plus adapté car tu communiquera avec le système embarqué de manière textuelle (ou même si c'est du binaire, ce ne sera certainement pas des composant OLE), donc tu seras dans une philosophie "homogène". Si PowerShell est aussi "efficace" dans le traitement de flux textuel, ce n'est pas un vrai argument...

- Cette philosophie UNIX (flux textuel + shell puissant + quelques outils simples) a plus de 30 ans, et elle est là pour durer... Elle a évolué mais c'est un outils pérenne. PowerShell est un shell construit sur .NET, ce dernier n'a qu'une 10aine d'années. Le jour où MICROSOFT change .NET pour autre chose, tu devras changer d'outils. Or pour être efficace, il faut connaître son outils, et plus il est compliqué plus l'apprentissage est long. Un shell est un outils compliqué, si tu dois en changer lorsque tu commences à peine à être efficace avec ce n'est pas génial. Je ne connais pas la roadmap de MICROSOFT sur la durée de vie de .NET, mais il y a des précédents (MFC), c'est donc un risque à prendre en compte...

- Choisir le shell à la UNIX plutôt que PowerShell, c'est apprendre un outils que je pourrais utiliser sur Linux, MacOS et Windows (grâce à cygwin), sans citer les outsiders xBSD, QNX... PowerShell, c'est MICROSOFT seulement. Pour que choisisse d'apprendre PowerShell, il faudrait donc que ce dernier possède la "killer feature" (pour le type d'application dont pn parle dans ce fil) qui compense son déficit de portabilité (ie le surcoût d'apprendre un nouvel outils, qui se paye en temps et en qualité de code). Interfacer le shell avec l'infrastructure .NET et certainement un super atout dont on se contrefiche pour le développement embarqué...

- L'embarqué est de plus en plus basé sur linux... Et même si d'un coup les parts de marchés s'inversaient en faveur de WindowsRT, lorsqu'on est "hobbyiste" ce n'est pas le genre de chose que l'on peut s'offrir... Donc lorsque Genocyber voudra "monter en puissance" et faire du bricolage sur une Raspberry Pi, alors il faudra qu'il fasse du shell Linux.

MPLAB n'existe plus. C'est maintenant MPLABX qui est trés bon (c'est un netbeans relooké), et la chaine de compilation C fournie (XC8 pour les 8 bits) contient une librairie logicielle tout à fait convenable (qu nécessite bien sûr la lecture de la doc, mais qui contient tous les define nécessaire pour l'accès direct aux fonctions/ports et bien plus).

Je ne critiquais pas l'IDE, mais bien le compilateur... Les deux seuls souvenirs que j'en ai sont:
- il laissait passer un "unsigned float" à la compilation !
- un retour de fonction directement en argument d'appel d'une autre fonction

int foo(void); int bar(int x); bar(foo());

pétait de manière "aléatoire", plus aucuns problèmes si on passe par une variable intermédiaire!
Et des merdouilles de ce genre j'en ai eu des tonnes...
Je proposais le MSP430(x) en remplacement car la gamme a environ la même couverture que celle du PIC, et mspgcc (gcc + patch) marche très bien tout en restant bon marché (gratos), je n'ai jamais utilisé CCS.

J'avais un peu coder sur arduino mais je suis pas fan , j'ai l'impression de pas allez au fond des choses , mon but surtout c'est la compréhension des µc et leur structures donc arduino j'ai laisser tombé mais ,mas je pense qu'il faut pas s'arreter a un seul language faut savoir jongler avec tous ce qui passe .

C'est un très bon "jouet" éducatif qui permet de faire de très belle chose mais effectivement il faut passer à "autre chose". Si je ne dis pas de bêtise, l'arduino est basé sur de l'AVR, et c'est du matériel ouvert, rien ne devrait t'empêcher de l'utiliser "comme les grands".

j'ai pas encore fouiller la théorie et pratique niveau DSP mais ça commence a me chatouiller et ce n'est qu'un exemple.

Attention, les solutions matérielles et logicielles abordables sont nettement plus rare. De plus qu'est ce qui t'intéresse d'apprendre sur un DSP? Les math du traitement du signal (alors l'aspect matériel de présente aucun intérêt) ? Les spécificités des architectures DSP, elles sont de plus en plus flou, et quasiment transparente puisque c'est le compilateur qui fait le boulot (au risque de me répéter, on ne fait plus d'assembleur de nos jours). Avoir un outils de plus à ton arc pour "casser du nombre", alors je te conseillerai plutôt FPGA + FHDL qui est pour le coup un monde complètement différent (mais je ne sais pas s'il y a des solutions accessibles pour le hobbyiste), avec lequel tu pourras faire du "number crunching" et tout un tas d'autres choses. C'est à mon avis le complémentaire idéal.

Pour le C j'ai des notions jusqu'au pointeur . C'est plus au niveau algoritme que je dois travailler , enfin je crois , je connais quelques outils basique du C mais je dois apprendre a les utiliser combiner et poursuivre mon apprentissage.

Le noeud du problème est là: la programmation c'est avant tout de l'algorithmique et un ensemble de méthodes de réalisations, la syntaxe n'est (rapidement) plus un problème... Or l'assembleur n'est pas, à mon avis, le bon outils pour parfaire cet apprentissage car la syntaxe est trop "bas-niveau", ce qui rend plus difficile la traduction algorithme -> programme. Il n'est pas assez "structuré" pour te simplifier la vie à découper ton problème en sous-problèmes... Ajoute à tout ça que ce n'a apporte quasiment plus aucun intérêt en terme de performance, et que la nécessité de travailler en assembleur est réduite à quelques cas très particuliers.

Je pense t'ecouter et revenir vers le C un moment le temps de créé des automatisme de programmation .

C'est en faisant du C que tu maximises tes chances de créé de bon automatisme de programmation, en persistant en apprenant avec l'assembleur je pense que tu vas te créer de mauvais automtismes, qui serront d'autant plus difficile à corriger une fois qu'ils seront en place.

En ce qui concerne mon projet j'ai plus ou moins fait comme tu disais .
J'ai converti le sample avec sox , j ai ouvert le sample converti dans hexedit , j'ai passer 44octets et j'ai copier colller le resultat .
C'est pas idéale mais ça marche .

Un début d'automatisation (avec un shell type BASH):

sox foo.wav -t dat - | awk '{print $2 }' | sed 's/$/*8/' | bc | awk -F'.' '{print $1}'

transforme le fichier WAV "foo.wav" (quelque soit sont format) en une suite de valeurs comprise entre -8 et +7 (donc encodable sur 4bits), pour sauvegarder le résultat dans "foo.txt":

sox foo.wav -t dat - | awk '{print $2 }' | sed 's/$/*8/' | bc | awk -F'.' '{print $1}' > foo.txt

ajouter les "fioritures" autours pour transformer ton fichier texte en un tableau contenu dans une entête est extrèment simple, et automatisable...

J'ai un windows et un linux qui traine , j'aime beaucoup kali linux pour le moment .

Si tu débutes sur Linux, je te conseillerai de rester chez les "ténors": (X)UBUNTU, FEDORA, DEBIAN... Surtout "kali linux" à l'air très orienté "pénétration de systèmes d'information"... Je ne suis pas sûr que tu trouves ton bonheur dans les dépôts... Sous UBUNTU, FEDORA et autres DEBIAN, les outils de développement pour AVR et autres MSP430 sont dans les dépots, ce qui simplifie la vie, sans lister les autres avantages de rester sur une distribution "grand public", d'autant plus prépondérant lorsqu'on débute sous Linux...

[genocyber]

Un début d'automatisation (avec un shell type BASH):
Code:

sox foo.wav -t dat - | awk '{print $2 }' | sed 's/$/*8/' | bc | awk -F'.' '{print $1}'

transforme le fichier WAV "foo.wav" (quelque soit sont format) en une suite de valeurs comprise entre -8 et +7 (donc encodable sur 4bits), pour sauvegarder le résultat dans "foo.txt":
Code:

sox foo.wav -t dat - | awk '{print $2 }' | sed 's/$/*8/' | bc | awk -F'.' '{print $1}' > foo.txt

ajouter les "fioritures" autours pour transformer ton fichier texte en un tableau contenu dans une entête est extrèment simple, et automatisable...

Génial c'exactement ce qu'il me fallais mes sur 4 bits non signé , par contre pour transformer mon fichier en tableau avec " DA (valeur)\n" je pédale je galère avec la syntaxe sox et je comprend rien au pipe .
ça serai abuser de te demander de completer ton automation pour quel convertisse en 4bit non signé et que ça rajoute "DA " a chaque octet et que ça passe a ligne ?
Un peu honte de demander qu'on me mache le travail merci d'avance et encore merci pour toutes ces infos

[genocyber]

Faudrai ptet après que je fasse une ligne de code qui permette de glisser une liste de samples et qu'il fasse le boulot tous seul , style un .bat y'avais un bat exemple dans le dossier windows de sox mais j 'y comprend rien faudrais ptet ue j 'édite ce fichier , quand j aurai compris comment ça marche
le .bat

rem Example of how to do batch processing with SoX on MS-Windows.
rem
rem Place this file in the same folder as sox.exe (& rename it as appropriate).
rem You can then drag and drop a selection of files onto the batch file (or
rem onto a `short-cut' to it).
rem
rem In this example, the converted files end up in a folder called `converted',
rem but this, of course, can be changed, as can the parameters to the sox
rem command.

cd %~dp0
mkdir converted
FOR %%A IN (%*) DO sox %%A "converted/%%~nxA" rate -v 44100
pause

je suppose que les lignes qui importe sont celles ci

cd %~dp0
mkdir converted
FOR %%A IN (%*) DO sox %%A "converted/%%~nxA" rate -v 44100

si quelqu'un peut m'expliquer comment éditer correctement ce .bat avec le code d automatisation vers un txt avec avant chaque octet "DA " puis a la ligne

Merci d'avance a tous

[lou_ibmix_xi]

Génial c'exactement ce qu'il me fallais mes sur 4 bits non signé , par contre pour transformer mon fichier en tableau avec " DA (valeur)\n" je pédale je galère avec la syntaxe sox et je comprend rien au pipe .

pour sox, "man sox" t'expliquera tout mieux que moi... le "-" est un fichier un peu spécial: la "sortie standard", les caractères sur l'écran noir du terminal... Le flux de données textuelles dont je parlais dans mon précédent poste.
Le pipe "|", comme son nom l'indique est un tuyau, et les commandes grep/sed/awk sont des "filtres" que tu branches avec les tuyaux. Tu as ton générateur sox, et si tu veux enregistrer le résultat tu redirige vers un fichier avec ">"

ça serai abuser de te demander de completer ton automation pour quel convertisse en 4bit non signé et que ça rajoute "DA " a chaque octet et que ça passe a ligne ?
Un peu honte de demander qu'on me mache le travail merci d'avance et encore merci pour toutes ces infos

Il suffit de rajouter "DA" en début de chaque ligne ?
Pour ça il faut rajouter un filtre "sed" à la fin (sur le résultat de la tuyauterie précédente).

sox foo.wav -t dat - | awk '{print $2 }' | sed 's/$/*8/' | bc | awk -F'.' '{print $1}' | sed 's/^/DA/'

[genocyber]

Oui avant chaque octet il faudrai qu'il y ai " DA " puis un passage a la ligne

merci beaucoup , pour tous ces conseils !