forum.system-cfg.com

Sur mon émulateur, le son est joué à 176 400 hz. Cela ne change rien à l'exécution de l'émulation, c'est DirectX qui joue le sample.
Ceci est aussi bien valable en C qu'en VB et même sous Linux avec SDL !

La durée est dû la la longueur de bitume encodé (16 metres à 60km/h font 1sec),
La note est dû à l'intervalle entre 2 crêtes du rainurage (pour un LA il faut 440 rainures pour 1 sec donc 1 rainure tous les 16m/440 soit 37.8 cm)

oui, et le pas étant très grand (aller de -127 à 128 par pas n de 32, ou 64 - ce qui ne donne que 8 valeurs pour n=32) cela ne fait pas du dent de scie mais plutôt du carré (bon, marche d'escalier); c'est pour ça que ta valeur de 32 m'étonnait au départ... Il faut peut être un échantillonnage beauco...

oups c'etait pas le bon...
sinon voila ce que cela donne avec l'encodage Sigma Delta : Et revoici avec l'encodage scie : (pour info la tonalité est juste : Stairway to heaven est repris par Jadyn Rylee...)

Ce que j'entend par là c'est que le signal en dent de scie est à 8khz. il s'additionne au signal à numériser. et c'est bien ce que j'ai : j'ai bien le son à 8KHz ET le signal à numériser qui sont joué en même temps (le 8KHz étant bien restitué par mon systeme qui fonctionne à 66KHz. [edit] Le son ob...

excellent l'explication des tailles des entailles pour expliquer l'erreur (donc erreur constante, quelque soit la note -> désaccordé de note en note)
comme quoi un bon plan vaut mieux qu'une explication foireuse ! surtout la seconde fois ! ils sont très fort ces américains

OK pour cet algo, sam. Par contre étant en fréquence 66 666Hz (sur vbhector) et 59150 Hz sur Hector reel, il faut que je monte la fréquence en dent de scie : là avec 32 j'ai fscie = 66 666 * 32/256 soit 8,3Khz soit une fréquence audible. il faut monter le coef à 128 pour obtenir quelque chose d'inau...

Depuis le début de mes essais de son sur Hector, je suis un peu déçu du rendu du son. Je suis également assez surpris de la qualité du son dans les 2 essais de ce fil : https://forum.system-cfg.com/viewtopic.php?f=25&t=7847&start=117 cela fait quelque temps que je travaille sur l'amélioratio...

Hélas si !
La résolution maxi en BR et de 112*77 mais en HR que de 230*221 (de tête). pour ne pas avoir de distorsion je suis en 204 * 153 (ok, je pourrais monter à 230 mais sur certaines vidéo j'ai plus assez de débit pour être correct).

ok, mais effectivement la méthode du pipe me semble très largement plus classe !
(maintenant que je comprends ! )

oui, c'est ce que j'avais effectivement fait (sans toutefois utiliser system, et donc ffmpeg fonctionnait en // sur un autre thread), et à la fin ça fonctionnait avec pour le test de fin avec un : my $read = read($name,$buf,256); $ok = 0 unless $read; # était: last unless $read; Sans utilisation du ...

Salut, Effectivement cette façon de voir le pipe, il faut encore que je relise correctement ça, je commence à le comprendre : on nourri ffmpeg par le flux qui "passe travers" ffmpeg pour qu'il fasse son job (des images à générer) et lorsqu'il y a terminé le read donnera forcément 0. Néanmo...

Bien joué !
Je n'ai pas pensé lancer ffmpeg pour voir si le pb venait de là, d'autant plus qu toutes les images étaient présente !
Merci et ouf !

EDIT : J'ai parlé trop vite : chez moi ça marche pas ...

pour éviter tous soucis (de ce genre), je travaille avec 2 mp4 :
* Un petit film fait au portable de 6 secondes (c'est pas trop long !)
* un mp4 de Kylie Minogue (can't get out of my head) transférer depuis youtube avec un convertisseur on line.

Salut, J'ai modifié le script avec la variable pour le while, ainsi que le buffer à 256. Pareil. J'ai un doute sur le syswrite. J'ai fait un : syswrite OUT, $buf, $read if ($ok==1); (c'est cocasse cette écriture!) Mais c'est pareil : pas de suite si la sortie se réalise suite à la fin du traitement ...