J'ai salement codé un sorte de k7towav pour le TO7 (c'est plus un moche
bricolage amateur en python bien crado suivi d'un script bash qu'un
véritable programme) mais n'ayant pas le TO7 sous la main je peux pas
le tester pour le moment.
Toutefois, à l'oreille, on retrouve bien les mélodies d'antan ;-)
Cependant, n'ayant pas vraiment les compétences pour valider mes "choix
techniques" (on fait avec ce qu'on a !), j'ai quelques questions à vous
soumettre :
Samuel Devulder a expliqué qu' il faillait "5 périodes à 4.5khz pour
un bit à 0 et 7 périodes à 6.3khz pour un bit à 1".
Je n'ai pas de compétences particulière en electronique mais j'ai pu
trouver sur le net que T=1/f.
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms
quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
N'ayant pas non plus les compétences mathématiques pour coder un
générateur de fréquences, après moultes recherches j'ai fini par
trouver siggen (http://www.comp.leeds.ac.uk/jj/linux/siggen.html) mais
celui-ci permet de générer des signaux que sur des valeurs entières de
millisecondes.
- Est-ce grave docteur ?
- Si non mieux vaut-il couper à 1ms ou à 2 ms ?
- Si oui, connaissez vous un générateur de tonalités attaquable en
ligne de commande ayant une précision suffisante ou mieux
quelque chose équivalent utilisable en python (snack ne s'installe pas
chez moi) ?
Evidemment à couper sur des valeurs entières, les cycles ne peuvent pas
se "raccorder" parfaitement et en analysant la courbe avec audacity on
voit bien que les "raccords" ne se font pas sur 0.
Par ailleurs, la "forme d'onde" à t-elle une importance ?
- Si oui, laquelle choisir, sinus ou cosinus ou autre ?
Merci d'excuser mon vocabulaire de profane mais je suis très loin de mon
domaine de compétence.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Samuel Devulder a expliqué qu' il faillait "5 périodes à 4.5khz pour un bit à 0 et 7 périodes à 6.3khz pour un bit à 1".
Je n'ai pas de compétences particulière en electronique mais j'ai pu trouver sur le net que T=1/f.
Oui période Þfinition= inverse de la fréquence.
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
Oui cela fait qu'un bit représente la même durée qu'il soit 0 ou 1. La vitesse de transmission totale est donc de 1/1.1111ms = 900bits/secs.
Par contre, pour un reproduction il faut au minimum 2 échantillons par période (th. de shannon), donc il faut produire le son à minimum de 2*6.3Khz. Dans la pratique il faut prendre beaucoup plus. Le plus simple est de produire un fichier wav à 44.1Khz (44100 échantillons / secondes), ce qui fait qu'un bit 1 (c'est la freq max) contient exactement 7 echantillons, et un bit 0 (frequence min) contient 9.8 echantillons. On est largement au dessus du critère de shannon: ca devrait marcher impec.
L'avantage du 44.1Khz est que ca colle pile poil avec un travail en pas discrets: bit0=5 périodes qui font: 49 échantillons à 44.1Khz bit1=7 périodes qui font: 49 échantillons à 44.1Khz
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais supposons que ce soit une sinusoïde bien classique (il suffit de changer le précalc pour les autres formes d'ondes).
Du coup l'algo est tout bête: on précalcule 2 série de 49 échantillons périodiques, représentant pour l'un 5 périodes d'une sinusoïde, et pour l'autre 7 périodes. Ensuite on lit le fichier binaire bit à bit, et on recopie les 49 échnatillons représentant le bit considéré.
A la grosse louche (je suis rouillé), en pseudo perl le code pour produire un fichier PCM ressemblerait à: # précalc @bit0 = @bit1 = (); $two_pi = 2*3.14159; for($i=0;$i<49;++$i) {$bit0[$i] = 127*(1+sin(5*$two_pi*$i/49));} for($i=0;$i<49;++$i) {$bit1[$i] = 127*(1+sin(7*$two_pi*$i/49));}
# lecture du fichier K7: IN = open("fichier.k7","rb"); read(STDIN, $tmp, 100000); # hum pas beau cette limite à 100000 @K7 = unpack('C*', $tmp); # conversion caractère->nombre close(IN);
# Création du fichier wav (l'en-tete dépend de la taille) OUT = open("fichier.wav","wb"); &ecrire_entete_PCM(OUT, 1+$#K7); # remplissage de la partie "data" du format foreach $octet (@K7) { for($i=0; $i<7; ++$i) { &sortir_PCM(OUT, ($octet & 128) != 0 ? @bit1 : @bit0); $octet <<= 1; } } &fin_fichier_PCM(OUT); close(OUT);
Les détails du format PCM sont ici: https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
Les tableaux bit0/bit1 sont précalculés pour 44.1khz, et un format audio 8bits non signés.
sam.
Doug713705 a écrit :
Samuel Devulder a expliqué qu' il faillait "5 périodes à 4.5khz pour
un bit à 0 et 7 périodes à 6.3khz pour un bit à 1".
Je n'ai pas de compétences particulière en electronique mais j'ai pu
trouver sur le net que T=1/f.
Oui période Þfinition= inverse de la fréquence.
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms
quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
Oui cela fait qu'un bit représente la même durée qu'il soit 0 ou 1. La
vitesse de transmission totale est donc de 1/1.1111ms = 900bits/secs.
Par contre, pour un reproduction il faut au minimum 2 échantillons par
période (th. de shannon), donc il faut produire le son à minimum de
2*6.3Khz. Dans la pratique il faut prendre beaucoup plus. Le plus simple
est de produire un fichier wav à 44.1Khz (44100 échantillons /
secondes), ce qui fait qu'un bit 1 (c'est la freq max) contient
exactement 7 echantillons, et un bit 0 (frequence min) contient 9.8
echantillons. On est largement au dessus du critère de shannon: ca
devrait marcher impec.
L'avantage du 44.1Khz est que ca colle pile poil avec un travail en pas
discrets:
bit0=5 périodes qui font: 49 échantillons à 44.1Khz
bit1=7 périodes qui font: 49 échantillons à 44.1Khz
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais
supposons que ce soit une sinusoïde bien classique (il suffit de changer
le précalc pour les autres formes d'ondes).
Du coup l'algo est tout bête: on précalcule 2 série de 49 échantillons
périodiques, représentant pour l'un 5 périodes d'une sinusoïde, et pour
l'autre 7 périodes. Ensuite on lit le fichier binaire bit à bit, et on
recopie les 49 échnatillons représentant le bit considéré.
A la grosse louche (je suis rouillé), en pseudo perl le code pour
produire un fichier PCM ressemblerait à:
# précalc
@bit0 = @bit1 = ();
$two_pi = 2*3.14159;
for($i=0;$i<49;++$i) {$bit0[$i] = 127*(1+sin(5*$two_pi*$i/49));}
for($i=0;$i<49;++$i) {$bit1[$i] = 127*(1+sin(7*$two_pi*$i/49));}
# lecture du fichier K7:
IN = open("fichier.k7","rb");
read(STDIN, $tmp, 100000); # hum pas beau cette limite à 100000
@K7 = unpack('C*', $tmp); # conversion caractère->nombre
close(IN);
# Création du fichier wav (l'en-tete dépend de la taille)
OUT = open("fichier.wav","wb");
&ecrire_entete_PCM(OUT, 1+$#K7);
# remplissage de la partie "data" du format
foreach $octet (@K7) {
for($i=0; $i<7; ++$i) {
&sortir_PCM(OUT, ($octet & 128) != 0 ? @bit1 : @bit0);
$octet <<= 1;
}
}
&fin_fichier_PCM(OUT);
close(OUT);
Les détails du format PCM sont ici:
https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
Les tableaux bit0/bit1 sont précalculés pour 44.1khz, et un format audio
8bits non signés.
Samuel Devulder a expliqué qu' il faillait "5 périodes à 4.5khz pour un bit à 0 et 7 périodes à 6.3khz pour un bit à 1".
Je n'ai pas de compétences particulière en electronique mais j'ai pu trouver sur le net que T=1/f.
Oui période Þfinition= inverse de la fréquence.
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
Oui cela fait qu'un bit représente la même durée qu'il soit 0 ou 1. La vitesse de transmission totale est donc de 1/1.1111ms = 900bits/secs.
Par contre, pour un reproduction il faut au minimum 2 échantillons par période (th. de shannon), donc il faut produire le son à minimum de 2*6.3Khz. Dans la pratique il faut prendre beaucoup plus. Le plus simple est de produire un fichier wav à 44.1Khz (44100 échantillons / secondes), ce qui fait qu'un bit 1 (c'est la freq max) contient exactement 7 echantillons, et un bit 0 (frequence min) contient 9.8 echantillons. On est largement au dessus du critère de shannon: ca devrait marcher impec.
L'avantage du 44.1Khz est que ca colle pile poil avec un travail en pas discrets: bit0=5 périodes qui font: 49 échantillons à 44.1Khz bit1=7 périodes qui font: 49 échantillons à 44.1Khz
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais supposons que ce soit une sinusoïde bien classique (il suffit de changer le précalc pour les autres formes d'ondes).
Du coup l'algo est tout bête: on précalcule 2 série de 49 échantillons périodiques, représentant pour l'un 5 périodes d'une sinusoïde, et pour l'autre 7 périodes. Ensuite on lit le fichier binaire bit à bit, et on recopie les 49 échnatillons représentant le bit considéré.
A la grosse louche (je suis rouillé), en pseudo perl le code pour produire un fichier PCM ressemblerait à: # précalc @bit0 = @bit1 = (); $two_pi = 2*3.14159; for($i=0;$i<49;++$i) {$bit0[$i] = 127*(1+sin(5*$two_pi*$i/49));} for($i=0;$i<49;++$i) {$bit1[$i] = 127*(1+sin(7*$two_pi*$i/49));}
# lecture du fichier K7: IN = open("fichier.k7","rb"); read(STDIN, $tmp, 100000); # hum pas beau cette limite à 100000 @K7 = unpack('C*', $tmp); # conversion caractère->nombre close(IN);
# Création du fichier wav (l'en-tete dépend de la taille) OUT = open("fichier.wav","wb"); &ecrire_entete_PCM(OUT, 1+$#K7); # remplissage de la partie "data" du format foreach $octet (@K7) { for($i=0; $i<7; ++$i) { &sortir_PCM(OUT, ($octet & 128) != 0 ? @bit1 : @bit0); $octet <<= 1; } } &fin_fichier_PCM(OUT); close(OUT);
Les détails du format PCM sont ici: https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
Les tableaux bit0/bit1 sont précalculés pour 44.1khz, et un format audio 8bits non signés.
sam.
Samuel Devulder
Samuel Devulder a écrit :
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais supposons que ce soit une sinusoïde bien classique (il suffit de changer le précalc pour les autres formes d'ondes).
La lecture du manuel tehnique du TO7 (http://dcmoto.free.fr/onlinedoc/manueltechniqueto7/manueltechniqueto7.djvu)
Semble indiquer que le TO sort un signal carré, mais qu'il est par la suite filtré.. Je pense qu'il faut tester si la sinusoide passe ou pas, si elle passe pas, il faut utiliser un creneau.
sub f_onde { my($t) = @_; $t = sin($t); $t = $t<0 ? -1 : 1 if 1; # mettre 0 pour sinusoide return $t; }
Samuel Devulder a écrit :
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais
supposons que ce soit une sinusoïde bien classique (il suffit de changer
le précalc pour les autres formes d'ondes).
La lecture du manuel tehnique du TO7
(http://dcmoto.free.fr/onlinedoc/manueltechniqueto7/manueltechniqueto7.djvu)
Semble indiquer que le TO sort un signal carré, mais qu'il est par la
suite filtré.. Je pense qu'il faut tester si la sinusoide passe ou pas,
si elle passe pas, il faut utiliser un creneau.
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais supposons que ce soit une sinusoïde bien classique (il suffit de changer le précalc pour les autres formes d'ondes).
La lecture du manuel tehnique du TO7 (http://dcmoto.free.fr/onlinedoc/manueltechniqueto7/manueltechniqueto7.djvu)
Semble indiquer que le TO sort un signal carré, mais qu'il est par la suite filtré.. Je pense qu'il faut tester si la sinusoide passe ou pas, si elle passe pas, il faut utiliser un creneau.
sub f_onde { my($t) = @_; $t = sin($t); $t = $t<0 ? -1 : 1 if 1; # mettre 0 pour sinusoide return $t; }
moi-meme
Le Sun, 10 Jan 2010 17:12:11 +0100, Samuel Devulder a écrit :
Semble indiquer que le TO sort un signal carré, mais qu'il est par la suite filtré.. Je pense qu'il faut tester si la sinusoide passe ou pas, si elle passe pas, il faut utiliser un creneau.
je mets mon grain de sel : quelques infos sur le circuit hard d'entrée du TO7 et sur les boucles logicielles permettraient d'affiner.
Il y a sans doute un comparateur avec hystérésis en entrée pour retrouver du carré.
Ensuite comment se fait la détection d'un 0 ou d'un 1 ? AMHA c'est pas la durée en sortie du comparateur. plutôt la mesure du temps entre deux fronts montants par une boucle logicielle.Une IT cyclique vu la vitesse du processeur me paraît utopique.
J'arrête là ma digression : il y a sans doute des connaisseurs du hard sur ce forum qui répondront mieux que moi.
Le Sun, 10 Jan 2010 17:12:11 +0100, Samuel Devulder a écrit :
Semble indiquer que le TO sort un signal carré, mais qu'il est par la
suite filtré.. Je pense qu'il faut tester si la sinusoide passe ou pas,
si elle passe pas, il faut utiliser un creneau.
je mets mon grain de sel :
quelques infos sur le circuit hard d'entrée du TO7 et sur les boucles
logicielles permettraient d'affiner.
Il y a sans doute un comparateur avec hystérésis en entrée pour retrouver
du carré.
Ensuite comment se fait la détection d'un 0 ou d'un 1 ?
AMHA c'est pas la durée en sortie du comparateur.
plutôt la mesure du temps entre deux fronts montants par une boucle
logicielle.Une IT cyclique vu la vitesse du processeur me paraît utopique.
J'arrête là ma digression : il y a sans doute des connaisseurs du hard
sur ce forum qui répondront mieux que moi.
Le Sun, 10 Jan 2010 17:12:11 +0100, Samuel Devulder a écrit :
Semble indiquer que le TO sort un signal carré, mais qu'il est par la suite filtré.. Je pense qu'il faut tester si la sinusoide passe ou pas, si elle passe pas, il faut utiliser un creneau.
je mets mon grain de sel : quelques infos sur le circuit hard d'entrée du TO7 et sur les boucles logicielles permettraient d'affiner.
Il y a sans doute un comparateur avec hystérésis en entrée pour retrouver du carré.
Ensuite comment se fait la détection d'un 0 ou d'un 1 ? AMHA c'est pas la durée en sortie du comparateur. plutôt la mesure du temps entre deux fronts montants par une boucle logicielle.Une IT cyclique vu la vitesse du processeur me paraît utopique.
J'arrête là ma digression : il y a sans doute des connaisseurs du hard sur ce forum qui répondront mieux que moi.
GzavSnap
Salut Doug,
| J'ai salement codé un sorte de k7towav pour le TO7 (c'est plus un moche | bricolage amateur en python bien crado suivi d'un script bash qu'un | véritable programme) mais n'ayant pas le TO7 sous la main je peux pas | le tester pour le moment. | | Toutefois, à l'oreille, on retrouve bien les mélodies d'antan ;-)
J'ai travaillé sur le TO7/70 pour le site "l'Hebdogiciel, les listings." Autant, que ca te profite. Dans le Zip: <http://dskcenter.free.fr/TO7/KIT_TO7.zip> Tu trouveras un exemple de fichier K7, un wav créé par Mess, un tuto pour la conversion TXT vers K7 et un exemple de code pour du VB.
Oui, tout les exemples que je vais te donner sont en VB... Tu pourras aussi regarder les codes de "SC3K tape converter" (http://dskcenter.free.fr/sc-3000/) et "ZxSpecTape" (http://dskcenter.free.fr/zxtools.html). Ces deux programmes sont des "Wav" vers des "K7", mais on des routines de reconstruction Wav.
| - Si oui, connaissez vous un générateur de tonalités attaquable en | ligne de commande ayant une précision suffisante ou mieux | quelque chose équivalent utilisable en python (snack ne s'installe pas | chez moi) ? Pour "Sc3k tape converter" j'ai travaillé sur des fichiers de streeming sur http://www.sc-3000.com Je ne me souviens plus du nom ... "Flash steeming"...? Sinon, il y a le "Tzx", mais là, aucun programme d'émulation ne l'utilise.
| Par ailleurs, la "forme d'onde" à t-elle une importance ? | - Si oui, laquelle choisir, sinus ou cosinus ou autre ? Sinus=cosinus en matière de forme d'harmonique. Le signal est inversé et cela peu poser des problèmes en cosinus.
Dans l'urgence, et pour tester/récuperer de "bonnes" harmoniques pour la conversion, on peut utiliser "Mess" car son seul format de sortie est le "WAV".
De plus, la légende veut que les signeaux du lecteur de cassette du To7 sont en numérique! C'est vaix pour la sortie du lecteur vers la carte mère... mais, à la base, le support K7 n'est pas numérique à proprement parlé. Le signal peut être en Sinus ou en créneaux. Mais, le signal en sinus évite l'effet mémoire et de lissage magnétique du système de lecture et évite des problèmes des saturations. En deux mots, une transition trop brutale du signal peut provoquer les rebonds et des harmoniques parasites en amont du lecteur. De toute façon, il y a toujours un lissage RL dû à l'inductance de la bobine de la tête de lecture ou d'écriture (ou à la rémanence magnétique résiduelle des tête!). Donc, un signal triangle peut aussi faire l'affaire...
Xav.
Salut Doug,
| J'ai salement codé un sorte de k7towav pour le TO7 (c'est plus un moche
| bricolage amateur en python bien crado suivi d'un script bash qu'un
| véritable programme) mais n'ayant pas le TO7 sous la main je peux pas
| le tester pour le moment.
|
| Toutefois, à l'oreille, on retrouve bien les mélodies d'antan ;-)
J'ai travaillé sur le TO7/70 pour le site "l'Hebdogiciel, les listings."
Autant, que ca te profite.
Dans le Zip: <http://dskcenter.free.fr/TO7/KIT_TO7.zip>
Tu trouveras un exemple de fichier K7, un wav créé par Mess, un tuto pour la
conversion TXT vers K7 et un exemple de code pour du VB.
Oui, tout les exemples que je vais te donner sont en VB...
Tu pourras aussi regarder les codes de "SC3K tape converter"
(http://dskcenter.free.fr/sc-3000/) et "ZxSpecTape"
(http://dskcenter.free.fr/zxtools.html).
Ces deux programmes sont des "Wav" vers des "K7", mais on des routines de
reconstruction Wav.
| - Si oui, connaissez vous un générateur de tonalités attaquable en
| ligne de commande ayant une précision suffisante ou mieux
| quelque chose équivalent utilisable en python (snack ne s'installe pas
| chez moi) ?
Pour "Sc3k tape converter" j'ai travaillé sur des fichiers de streeming sur
http://www.sc-3000.com
Je ne me souviens plus du nom ... "Flash steeming"...?
Sinon, il y a le "Tzx", mais là, aucun programme d'émulation ne l'utilise.
| Par ailleurs, la "forme d'onde" à t-elle une importance ?
| - Si oui, laquelle choisir, sinus ou cosinus ou autre ?
Sinus=cosinus en matière de forme d'harmonique.
Le signal est inversé et cela peu poser des problèmes en cosinus.
Dans l'urgence, et pour tester/récuperer de "bonnes" harmoniques pour la
conversion, on peut utiliser "Mess" car son seul format de sortie est le
"WAV".
De plus, la légende veut que les signeaux du lecteur de cassette du To7 sont
en numérique!
C'est vaix pour la sortie du lecteur vers la carte mère... mais, à la base,
le support K7 n'est pas numérique à proprement parlé.
Le signal peut être en Sinus ou en créneaux. Mais, le signal en sinus évite
l'effet mémoire et de lissage magnétique du système de lecture et évite des
problèmes des saturations. En deux mots, une transition trop brutale du
signal peut provoquer les rebonds et des harmoniques parasites en amont du
lecteur.
De toute façon, il y a toujours un lissage RL dû à l'inductance de la bobine
de la tête de lecture ou d'écriture (ou à la rémanence magnétique résiduelle
des tête!).
Donc, un signal triangle peut aussi faire l'affaire...
| J'ai salement codé un sorte de k7towav pour le TO7 (c'est plus un moche | bricolage amateur en python bien crado suivi d'un script bash qu'un | véritable programme) mais n'ayant pas le TO7 sous la main je peux pas | le tester pour le moment. | | Toutefois, à l'oreille, on retrouve bien les mélodies d'antan ;-)
J'ai travaillé sur le TO7/70 pour le site "l'Hebdogiciel, les listings." Autant, que ca te profite. Dans le Zip: <http://dskcenter.free.fr/TO7/KIT_TO7.zip> Tu trouveras un exemple de fichier K7, un wav créé par Mess, un tuto pour la conversion TXT vers K7 et un exemple de code pour du VB.
Oui, tout les exemples que je vais te donner sont en VB... Tu pourras aussi regarder les codes de "SC3K tape converter" (http://dskcenter.free.fr/sc-3000/) et "ZxSpecTape" (http://dskcenter.free.fr/zxtools.html). Ces deux programmes sont des "Wav" vers des "K7", mais on des routines de reconstruction Wav.
| - Si oui, connaissez vous un générateur de tonalités attaquable en | ligne de commande ayant une précision suffisante ou mieux | quelque chose équivalent utilisable en python (snack ne s'installe pas | chez moi) ? Pour "Sc3k tape converter" j'ai travaillé sur des fichiers de streeming sur http://www.sc-3000.com Je ne me souviens plus du nom ... "Flash steeming"...? Sinon, il y a le "Tzx", mais là, aucun programme d'émulation ne l'utilise.
| Par ailleurs, la "forme d'onde" à t-elle une importance ? | - Si oui, laquelle choisir, sinus ou cosinus ou autre ? Sinus=cosinus en matière de forme d'harmonique. Le signal est inversé et cela peu poser des problèmes en cosinus.
Dans l'urgence, et pour tester/récuperer de "bonnes" harmoniques pour la conversion, on peut utiliser "Mess" car son seul format de sortie est le "WAV".
De plus, la légende veut que les signeaux du lecteur de cassette du To7 sont en numérique! C'est vaix pour la sortie du lecteur vers la carte mère... mais, à la base, le support K7 n'est pas numérique à proprement parlé. Le signal peut être en Sinus ou en créneaux. Mais, le signal en sinus évite l'effet mémoire et de lissage magnétique du système de lecture et évite des problèmes des saturations. En deux mots, une transition trop brutale du signal peut provoquer les rebonds et des harmoniques parasites en amont du lecteur. De toute façon, il y a toujours un lissage RL dû à l'inductance de la bobine de la tête de lecture ou d'écriture (ou à la rémanence magnétique résiduelle des tête!). Donc, un signal triangle peut aussi faire l'affaire...
Xav.
Doug713705
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
Oui cela fait qu'un bit représente la même durée qu'il soit 0 ou 1. La vitesse de transmission totale est donc de 1/1.1111ms = 900bits/secs.
Par contre, pour un reproduction il faut au minimum 2 échantillons par période (th. de shannon), donc il faut produire le son à minimum de 2*6.3Khz. Dans la pratique il faut prendre beaucoup plus. Le plus simple est de produire un fichier wav à 44.1Khz (44100 échantillons / secondes), ce qui fait qu'un bit 1 (c'est la freq max) contient exactement 7 echantillons, et un bit 0 (frequence min) contient 9.8 echantillons. On est largement au dessus du critère de shannon: ca devrait marcher impec.
L'avantage du 44.1Khz est que ca colle pile poil avec un travail en pas discrets: bit0=5 périodes qui font: 49 échantillons à 44.1Khz bit1=7 périodes qui font: 49 échantillons à 44.1Khz
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais supposons que ce soit une sinusoïde bien classique (il suffit de changer le précalc pour les autres formes d'ondes).
Du coup l'algo est tout bête: on précalcule 2 série de 49 échantillons périodiques, représentant pour l'un 5 périodes d'une sinusoïde, et pour l'autre 7 périodes. Ensuite on lit le fichier binaire bit à bit, et on recopie les 49 échnatillons représentant le bit considéré.
Merci pour les infos, grâce à toi il me semble que mon programme fonctionne, c'est un petit script en python (tu sais moi les hiéroglyphes du perl... ;-) ) qui est disponible ici : http://doug.letough.free.fr/to7/
Vous y trouverez également un fichier .k7 (arkanoid) et le fichier wav correspondant généré par ce fameux script.
N'ayant pas le TO7 sous la main, je n'ai pu que faire quelques tests théoriques : - chronométrage d'un bit avec audacity - Mesure des fréquences en sortie de carte son sur un oscilloscope avec xoscope.
Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Merci à vous tous, je me suis bien amusé à écrire ce script. Prochaine étape : Essai grandeur nature ! -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms
quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
Oui cela fait qu'un bit représente la même durée qu'il soit 0 ou 1. La
vitesse de transmission totale est donc de 1/1.1111ms = 900bits/secs.
Par contre, pour un reproduction il faut au minimum 2 échantillons par
période (th. de shannon), donc il faut produire le son à minimum de
2*6.3Khz. Dans la pratique il faut prendre beaucoup plus. Le plus simple
est de produire un fichier wav à 44.1Khz (44100 échantillons /
secondes), ce qui fait qu'un bit 1 (c'est la freq max) contient
exactement 7 echantillons, et un bit 0 (frequence min) contient 9.8
echantillons. On est largement au dessus du critère de shannon: ca
devrait marcher impec.
L'avantage du 44.1Khz est que ca colle pile poil avec un travail en pas
discrets:
bit0=5 périodes qui font: 49 échantillons à 44.1Khz
bit1=7 périodes qui font: 49 échantillons à 44.1Khz
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais
supposons que ce soit une sinusoïde bien classique (il suffit de changer
le précalc pour les autres formes d'ondes).
Du coup l'algo est tout bête: on précalcule 2 série de 49 échantillons
périodiques, représentant pour l'un 5 périodes d'une sinusoïde, et pour
l'autre 7 périodes. Ensuite on lit le fichier binaire bit à bit, et on
recopie les 49 échnatillons représentant le bit considéré.
Merci pour les infos, grâce à toi il me semble que mon programme
fonctionne, c'est un petit script en python (tu sais moi les
hiéroglyphes du perl... ;-) ) qui est disponible ici :
http://doug.letough.free.fr/to7/
Vous y trouverez également un fichier .k7 (arkanoid) et le fichier wav
correspondant généré par ce fameux script.
N'ayant pas le TO7 sous la main, je n'ai pu que faire quelques tests
théoriques :
- chronométrage d'un bit avec audacity
- Mesure des fréquences en sortie de carte son sur un
oscilloscope avec xoscope.
Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Merci à vous tous, je me suis bien amusé à écrire ce script.
Prochaine étape : Essai grandeur nature !
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:
Pour 6300 hz cela nous donne donc 0.15873015873015872 * 7 = 1.1111... ms quand pour 4500 hz cela donne 0.2222222222222222 * 5 = 1.1111... ms.
Oui cela fait qu'un bit représente la même durée qu'il soit 0 ou 1. La vitesse de transmission totale est donc de 1/1.1111ms = 900bits/secs.
Par contre, pour un reproduction il faut au minimum 2 échantillons par période (th. de shannon), donc il faut produire le son à minimum de 2*6.3Khz. Dans la pratique il faut prendre beaucoup plus. Le plus simple est de produire un fichier wav à 44.1Khz (44100 échantillons / secondes), ce qui fait qu'un bit 1 (c'est la freq max) contient exactement 7 echantillons, et un bit 0 (frequence min) contient 9.8 echantillons. On est largement au dessus du critère de shannon: ca devrait marcher impec.
L'avantage du 44.1Khz est que ca colle pile poil avec un travail en pas discrets: bit0=5 périodes qui font: 49 échantillons à 44.1Khz bit1=7 périodes qui font: 49 échantillons à 44.1Khz
Ensuite pour la forme d'onde, je n'ai pas de quoi vérifier, mais supposons que ce soit une sinusoïde bien classique (il suffit de changer le précalc pour les autres formes d'ondes).
Du coup l'algo est tout bête: on précalcule 2 série de 49 échantillons périodiques, représentant pour l'un 5 périodes d'une sinusoïde, et pour l'autre 7 périodes. Ensuite on lit le fichier binaire bit à bit, et on recopie les 49 échnatillons représentant le bit considéré.
Merci pour les infos, grâce à toi il me semble que mon programme fonctionne, c'est un petit script en python (tu sais moi les hiéroglyphes du perl... ;-) ) qui est disponible ici : http://doug.letough.free.fr/to7/
Vous y trouverez également un fichier .k7 (arkanoid) et le fichier wav correspondant généré par ce fameux script.
N'ayant pas le TO7 sous la main, je n'ai pu que faire quelques tests théoriques : - chronométrage d'un bit avec audacity - Mesure des fréquences en sortie de carte son sur un oscilloscope avec xoscope.
Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Merci à vous tous, je me suis bien amusé à écrire ce script. Prochaine étape : Essai grandeur nature ! -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
ols
Doug713705 a écrit :
Par contre, pour un reproduction il faut au minimum 2 échantillons par période (th. de shannon), donc il faut produire le son à minimum de 2*6.3Khz.
Ah Shannon, mon grand copain des années "électronique" :-)) Nous avons suivi les mêmes études, moi sur le banc et lui sur le tableau! Souvenirs souvenirs....
Ols
Doug713705 a écrit :
Par contre, pour un reproduction il faut au minimum 2 échantillons par
période (th. de shannon), donc il faut produire le son à minimum de
2*6.3Khz.
Ah Shannon, mon grand copain des années "électronique" :-)) Nous avons
suivi les mêmes études, moi sur le banc et lui sur le tableau!
Souvenirs souvenirs....
Par contre, pour un reproduction il faut au minimum 2 échantillons par période (th. de shannon), donc il faut produire le son à minimum de 2*6.3Khz.
Ah Shannon, mon grand copain des années "électronique" :-)) Nous avons suivi les mêmes études, moi sur le banc et lui sur le tableau! Souvenirs souvenirs....
Ols
Samuel Devulder
Doug713705 a écrit :
Merci pour les infos, grâce à toi il me semble que mon programme fonctionne, c'est un petit script en python (tu sais moi les hiéroglyphes du perl... ;-) ) qui est disponible ici : http://doug.letough.free.fr/to7/
Ah oui j'aurais pu écrire du pseudo python. J'ai confondu. Je pensais que c'etait en perl que tu avais fait tes 1er essais.
Vous y trouverez également un fichier .k7 (arkanoid) et le fichier wav correspondant généré par ce fameux script.
Est-ce que le wav mouliné par wav2k7 donne le même contenu que le .k7 d'origine?
Sinon a l'oreille ca ressemble à du thomson. Par contre je n'ai rien pour tester ton prog. Le mieux serait que tu postes un petit message sur http://www.logicielsmoto.com/phpBB/index.php Où tu aura plus de chance de tomber sur quelqu'un ayant un TO sous la main.
sam.
Doug713705 a écrit :
Merci pour les infos, grâce à toi il me semble que mon programme
fonctionne, c'est un petit script en python (tu sais moi les
hiéroglyphes du perl... ;-) ) qui est disponible ici :
http://doug.letough.free.fr/to7/
Ah oui j'aurais pu écrire du pseudo python. J'ai confondu. Je pensais
que c'etait en perl que tu avais fait tes 1er essais.
Vous y trouverez également un fichier .k7 (arkanoid) et le fichier wav
correspondant généré par ce fameux script.
Est-ce que le wav mouliné par wav2k7 donne le même contenu que le .k7
d'origine?
Sinon a l'oreille ca ressemble à du thomson. Par contre je n'ai rien
pour tester ton prog. Le mieux serait que tu postes un petit message sur
http://www.logicielsmoto.com/phpBB/index.php
Où tu aura plus de chance de tomber sur quelqu'un ayant un TO sous la main.
Merci pour les infos, grâce à toi il me semble que mon programme fonctionne, c'est un petit script en python (tu sais moi les hiéroglyphes du perl... ;-) ) qui est disponible ici : http://doug.letough.free.fr/to7/
Ah oui j'aurais pu écrire du pseudo python. J'ai confondu. Je pensais que c'etait en perl que tu avais fait tes 1er essais.
Vous y trouverez également un fichier .k7 (arkanoid) et le fichier wav correspondant généré par ce fameux script.
Est-ce que le wav mouliné par wav2k7 donne le même contenu que le .k7 d'origine?
Sinon a l'oreille ca ressemble à du thomson. Par contre je n'ai rien pour tester ton prog. Le mieux serait que tu postes un petit message sur http://www.logicielsmoto.com/phpBB/index.php Où tu aura plus de chance de tomber sur quelqu'un ayant un TO sous la main.
sam.
Samuel Devulder
Doug713705 a écrit :
Merci pour les infos, grâce à toi il me semble que mon programme fonctionne, c'est un petit script en python (tu sais moi les hiéroglyphes du perl... ;-) ) qui est disponible ici : http://doug.letough.free.fr/to7/
bbyte = bstr(ord(c)) bitnum=bitnum+1 for bit in bbyte : ...
Heu, il me semble que dans ce cas tu sort les bits avec le bit de poids fort en tête. Or dans l'une des docs que j'ai lu, un schéma d'écriture sur la bande contenait b0 puis b1 puis b2.. etc. Du coup je me demande si tu ne doit pas inverser les elements de "bbyte" ou redéfinir bstr ainsi: # Return the byte as a list of bits (lsb first) def bstr(n): return ''.join([str(n >> x & 1) for x in (0,1,2,3,4,5,6,7)])
sam.
Doug713705 a écrit :
Merci pour les infos, grâce à toi il me semble que mon programme
fonctionne, c'est un petit script en python (tu sais moi les
hiéroglyphes du perl... ;-) ) qui est disponible ici :
http://doug.letough.free.fr/to7/
bbyte = bstr(ord(c))
bitnum=bitnum+1
for bit in bbyte :
...
Heu, il me semble que dans ce cas tu sort les bits avec le bit de poids
fort en tête. Or dans l'une des docs que j'ai lu, un schéma d'écriture
sur la bande contenait b0 puis b1 puis b2.. etc. Du coup je me demande
si tu ne doit pas inverser les elements de "bbyte" ou redéfinir bstr ainsi:
# Return the byte as a list of bits (lsb first)
def bstr(n):
return ''.join([str(n >> x & 1) for x in (0,1,2,3,4,5,6,7)])
Merci pour les infos, grâce à toi il me semble que mon programme fonctionne, c'est un petit script en python (tu sais moi les hiéroglyphes du perl... ;-) ) qui est disponible ici : http://doug.letough.free.fr/to7/
bbyte = bstr(ord(c)) bitnum=bitnum+1 for bit in bbyte : ...
Heu, il me semble que dans ce cas tu sort les bits avec le bit de poids fort en tête. Or dans l'une des docs que j'ai lu, un schéma d'écriture sur la bande contenait b0 puis b1 puis b2.. etc. Du coup je me demande si tu ne doit pas inverser les elements de "bbyte" ou redéfinir bstr ainsi: # Return the byte as a list of bits (lsb first) def bstr(n): return ''.join([str(n >> x & 1) for x in (0,1,2,3,4,5,6,7)])
sam.
Thierry Sundgau [nntp]
"Doug713705" a écrit dans le message de news: hij0q6$25mq$
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait: Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Je vais tacher de trouver le temps de tester ce week end.
( en vue de sauvegarde, j'ai gravé certaines de mes cassettes physiques sur CD AUDIO ) et j'ai demonté (à cause du cable) le couvercle de mon magnéto TO7 pour acceuillir mon adaptateur BF jack3.5 -> K7 sur lequel est maintenant dédié mon 'ancien' baladeur CD
"Doug713705" <doug.letough@free.fr> a écrit dans le message de news: hij0q6$25mq$1@talisker.lacave.net...
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:
Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Je vais tacher de trouver le temps de tester ce week end.
( en vue de sauvegarde, j'ai gravé certaines de mes cassettes physiques sur CD AUDIO )
et j'ai demonté (à cause du cable) le couvercle de mon magnéto TO7 pour acceuillir
mon adaptateur BF jack3.5 -> K7 sur lequel est maintenant dédié mon 'ancien' baladeur CD
"Doug713705" a écrit dans le message de news: hij0q6$25mq$
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait: Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Je vais tacher de trouver le temps de tester ce week end.
( en vue de sauvegarde, j'ai gravé certaines de mes cassettes physiques sur CD AUDIO ) et j'ai demonté (à cause du cable) le couvercle de mon magnéto TO7 pour acceuillir mon adaptateur BF jack3.5 -> K7 sur lequel est maintenant dédié mon 'ancien' baladeur CD
Samuel Devulder
Thierry Sundgau [nntp] a écrit :
"Doug713705" a écrit dans le message de news: hij0q6$25mq$
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait: Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Je vais tacher de trouver le temps de tester ce week end.
( en vue de sauvegarde, j'ai gravé certaines de mes cassettes physiques sur CD AUDIO )
C'est pas une mauvaise idée du tout.. J'ai "backupé" mes vieilles D7 perso TO9 en fichier SAP, mais j'ai pas pensé à backuper les K7 des TO7 et TO7/70, et c'est bien dommage car je dois y trouver un certain nombre de progs "vintage" perso (enfin recopiés/adaptés de SVM-micro, Heebdogiiciel et autre bricolages en tout genres). A tous les coup il y a des trésors oubliés sur ces K7...
sam (rahhh nostalgie)
Thierry Sundgau [nntp] a écrit :
"Doug713705" <doug.letough@free.fr> a écrit dans le message de news: hij0q6$25mq$1@talisker.lacave.net...
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait:
Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Je vais tacher de trouver le temps de tester ce week end.
( en vue de sauvegarde, j'ai gravé certaines de mes cassettes physiques sur CD AUDIO )
C'est pas une mauvaise idée du tout.. J'ai "backupé" mes vieilles D7
perso TO9 en fichier SAP, mais j'ai pas pensé à backuper les K7 des TO7
et TO7/70, et c'est bien dommage car je dois y trouver un certain nombre
de progs "vintage" perso (enfin recopiés/adaptés de SVM-micro,
Heebdogiiciel et autre bricolages en tout genres). A tous les coup il y
a des trésors oubliés sur ces K7...
"Doug713705" a écrit dans le message de news: hij0q6$25mq$
Dans fr.comp.ordinosaures Samuel Devulder nous expliquait: Si quelqu'un dispose d'assez de temps pour tester ce prgramme...
Je vais tacher de trouver le temps de tester ce week end.
( en vue de sauvegarde, j'ai gravé certaines de mes cassettes physiques sur CD AUDIO )
C'est pas une mauvaise idée du tout.. J'ai "backupé" mes vieilles D7 perso TO9 en fichier SAP, mais j'ai pas pensé à backuper les K7 des TO7 et TO7/70, et c'est bien dommage car je dois y trouver un certain nombre de progs "vintage" perso (enfin recopiés/adaptés de SVM-micro, Heebdogiiciel et autre bricolages en tout genres). A tous les coup il y a des trésors oubliés sur ces K7...
