Derniers sujets
Qui est en ligne ?
Il y a en tout 1 utilisateur en ligne :: 0 Enregistré, 0 Invisible et 1 Invité Aucun
Le record du nombre d'utilisateurs en ligne est de 29 le Mer 25 Fév 2015 - 14:01
Connexion
Statistiques
Nous avons 241 membres enregistrésL'utilisateur enregistré le plus récent est ben_frog
Nos membres ont posté un total de 8921 messages dans 811 sujets
Toujours plus vite...
+5
Dom50
musepat
FredV60
kenneth
didierv
9 participants
Forum Oric :: Forums :: Forum Public
Page 1 sur 3
Page 1 sur 3 • 1, 2, 3
Re: Toujours plus vite...
Va falloir donner un nom pour l'extension des wav sur pc, pour ne pas confondre !
hires.tgv ?
Impressionnant
C'est marrant, j'ai l'impression d'etre sur une ile déserte en ce moment. Sont tous en vacances
hires.tgv ?
Impressionnant
C'est marrant, j'ai l'impression d'etre sur une ile déserte en ce moment. Sont tous en vacances
_________________
DidierV - CEO Mag
alias coco.oric sur Defence-Force
Re: Toujours plus vite...
C'est le mois d'août ! Il y a des places vides pour se garer à Paris, donc oui il y a du monde en vacances
Le chargement fonctionne aussi avec les programmes (Zorgon: 20.7 secondes), hélas cette vitesse est instable d'une machine à l'autre, donc pas exploitable.
En gros, TAP2CD était vraiment proche de la perfection: s'il est un peu plus lent, c'est parce qu'il est fiable...
Il faudrait que je voie à combien je redescends avec quelquechose qui fonctionne sur diverses machines... Mais c'est beaucoup de boulot pour gagner quelques bouts de secondes de chargement ?
Le chargement fonctionne aussi avec les programmes (Zorgon: 20.7 secondes), hélas cette vitesse est instable d'une machine à l'autre, donc pas exploitable.
En gros, TAP2CD était vraiment proche de la perfection: s'il est un peu plus lent, c'est parce qu'il est fiable...
Il faudrait que je voie à combien je redescends avec quelquechose qui fonctionne sur diverses machines... Mais c'est beaucoup de boulot pour gagner quelques bouts de secondes de chargement ?
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
ca trace ! Mon destrier, ferré comme il se doit ne ferait pas mieux
On approche des incertitudes produites par les condos et autres composants qui vieillissent différamment selon les machines...ce n est pas simple. Je pensait a un truc: Comme l Oric a une horloge précise et que les lecteurs d aujourd hui l'ont également, pourquoi ne pas codifier nos donnees envoyées sur la largeur de la sinuzoide, au lieu d 'envoyer du binaire, on augmenterai la résolution combinatoire, jusqu à 4bits par exemple:
une sinusoide pourrait avoir 16 largeurs différentes
512 microsecondes pour la plus large qui indiquerait 16 (#F)
32 microsecondes pour la plus étroite qui indiquerait zero
Deux sinusoides suffiraient pour envoyer un octet, ca irait peut etre 8 fois plus vite ?
On approche des incertitudes produites par les condos et autres composants qui vieillissent différamment selon les machines...ce n est pas simple. Je pensait a un truc: Comme l Oric a une horloge précise et que les lecteurs d aujourd hui l'ont également, pourquoi ne pas codifier nos donnees envoyées sur la largeur de la sinuzoide, au lieu d 'envoyer du binaire, on augmenterai la résolution combinatoire, jusqu à 4bits par exemple:
une sinusoide pourrait avoir 16 largeurs différentes
512 microsecondes pour la plus large qui indiquerait 16 (#F)
32 microsecondes pour la plus étroite qui indiquerait zero
Deux sinusoides suffiraient pour envoyer un octet, ca irait peut etre 8 fois plus vite ?
kenneth- Modérateur
- Messages : 878
Date d'inscription : 13/01/2013
Age : 56
Localisation : 63
Re: Toujours plus vite...
C'est déjà en partie ce que font cet algo et Tap2CD: ils encodent 2 bits par sinusoïde L'ago que je propose, en +, a une compression RLE embarquée (et des périodes de base plus courtes et rapprochées que Tap2CD, d'où sa sensibilité trop délicate).
On a donc ici 4 largeurs de sinusoide différentes (en fait 6 dans mon algo pour gérer en + le nombre de répétitions). Le problème si on en rajoute est double:
- ça complexifie grave le code en taille, le loader à charger devient donc encombrant en RAM... et "long" à charger
- le code étant plus complexe, il met plus de temps à décoder les données... Mais pendant ce temps, le signal défile ! Donc plus le code a de travail, plus tu dois ralentir ton signal pour lui laisser le temps de travailler C'est donc un équilibre difficile.
Pour te donner une idée, un octet normal dans mon algo nécessite deux bits de stop pour être traité (138µs), et un signal indiquant "répétion de l'octet précédent" (de 1 à 4 fois) nécessite lui 3 bits de stop pour laisser l'Oric bosser (207µs)... Au-delà, la compression devenait pénalisante.
Ceci dit of course, il y a certainement moyen de faire mieux ! Déjà je programme comme un pied. Et puis par exemple en analysant dans tous les sens le fichier TAP de départ pour optimiser sa compression (et donc en adaptant le loader) en prenant la méthode la plus efficace à chaque cas...
Mais comme je disais, c'est un boulot de fou - le chargement montré dans la vidéo m'a occupé pendant quasi la moitié de mes 3 semaines de vacances.
On a donc ici 4 largeurs de sinusoide différentes (en fait 6 dans mon algo pour gérer en + le nombre de répétitions). Le problème si on en rajoute est double:
- ça complexifie grave le code en taille, le loader à charger devient donc encombrant en RAM... et "long" à charger
- le code étant plus complexe, il met plus de temps à décoder les données... Mais pendant ce temps, le signal défile ! Donc plus le code a de travail, plus tu dois ralentir ton signal pour lui laisser le temps de travailler C'est donc un équilibre difficile.
Pour te donner une idée, un octet normal dans mon algo nécessite deux bits de stop pour être traité (138µs), et un signal indiquant "répétion de l'octet précédent" (de 1 à 4 fois) nécessite lui 3 bits de stop pour laisser l'Oric bosser (207µs)... Au-delà, la compression devenait pénalisante.
Ceci dit of course, il y a certainement moyen de faire mieux ! Déjà je programme comme un pied. Et puis par exemple en analysant dans tous les sens le fichier TAP de départ pour optimiser sa compression (et donc en adaptant le loader) en prenant la méthode la plus efficace à chaque cas...
Mais comme je disais, c'est un boulot de fou - le chargement montré dans la vidéo m'a occupé pendant quasi la moitié de mes 3 semaines de vacances.
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
PS: j'ai fait des tests, l'Oric ne réagit pas à une sinusoïde de moins de 69µs. Et ensuite, à 44kHz, chaque sample te rajoute 23µs. Si on veut se contenter (par souci de rapidité de traitement) à gérér le poids faible du timer du VIA, on est vite limité en combinaisons possibles :(
De + Fabrice (il a eu raison) traite des pas de 46µs pour la stabilité "tous Orics". De mon côté j'ai mis le pas à 23µs: quand ça marche bien sur un Oric, pour les autres il faut tout re-régler ! J'ai dû adapter la forme du signal généré et tester, je crois que la distinction entre les durées se fait parfois à 1 ou 2 µs près...
De + Fabrice (il a eu raison) traite des pas de 46µs pour la stabilité "tous Orics". De mon côté j'ai mis le pas à 23µs: quand ça marche bien sur un Oric, pour les autres il faut tout re-régler ! J'ai dû adapter la forme du signal généré et tester, je crois que la distinction entre les durées se fait parfois à 1 ou 2 µs près...
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
J'ai besoin de votre aide pour de rapides tests, si votre Atmos est de sortie, et prêt à charger, par le port cassette, des WAV !
Attention, ROM 1.1 obligatoire.
Le but est d'avoir des statistiques sur la façon dont les Oric lisent certains signaux cassette, pour tenter de fiabiliser le chargement super rapide.
Comment faire:
1- télécharger et déziper le package attaché à ce post
2a- CLOADer le fichier MD3456.WAV sur votre Oric (ROM 1.1)
2b- le lancer par RUN - vous devriez voir apparaitre un tableau quasi vide
3- quand l'Oric se bloque et affiche "Attente signal", jouer le fichier MD3456_test_sample_3.wav
Après un instant, vous devriez voir apparaitre des valeurs hexadécimales. Si rien ne se passe, votre player de WAV ou votre Oric ont sans doute un souci
4- notez quelque part "3" suivi des plus grand et plus petit nombres du tableau, parmi ceux qui viennent d'apparaître. Par exemple 3:[BE;AC]
5- recommencer les étapes 2b à 4, cette fois avec MD3456_test_sample_4.wav, puis MD3456_test_sample_5.wav, et enfin MD3456_test_sample_6.wav, en changeant "3" par la nouvelle valeur de sample testée (4, 5 ou 6)
6- postez vos valeurs ici.
Une fois vos ordis en route, ces tests ne devraient prendre qu'une poignée de minutes !
Par exemple j'ai fait le test sur 3 machines et obtenu ces résultats:
Atmos Paris: 3:[BE;AC] 4:[A3;9A] 5:[91;7F] 6:[76;6D]
Atmos "Reset": 3:[BE;AC] 4:[A3;9A] 5:[91;7F] 6:[76;6D]
Atmos "MB": 3:[BE;AC] 4:[AC;9A] 5:[9A;7F] 6:[7F;64]
Si vous pouvez poster quelques essais (ou signaler un non-chargement !) ce serait génial.
Merci
Attention, ROM 1.1 obligatoire.
Le but est d'avoir des statistiques sur la façon dont les Oric lisent certains signaux cassette, pour tenter de fiabiliser le chargement super rapide.
Comment faire:
1- télécharger et déziper le package attaché à ce post
2a- CLOADer le fichier MD3456.WAV sur votre Oric (ROM 1.1)
2b- le lancer par RUN - vous devriez voir apparaitre un tableau quasi vide
3- quand l'Oric se bloque et affiche "Attente signal", jouer le fichier MD3456_test_sample_3.wav
Après un instant, vous devriez voir apparaitre des valeurs hexadécimales. Si rien ne se passe, votre player de WAV ou votre Oric ont sans doute un souci
4- notez quelque part "3" suivi des plus grand et plus petit nombres du tableau, parmi ceux qui viennent d'apparaître. Par exemple 3:[BE;AC]
5- recommencer les étapes 2b à 4, cette fois avec MD3456_test_sample_4.wav, puis MD3456_test_sample_5.wav, et enfin MD3456_test_sample_6.wav, en changeant "3" par la nouvelle valeur de sample testée (4, 5 ou 6)
6- postez vos valeurs ici.
Une fois vos ordis en route, ces tests ne devraient prendre qu'une poignée de minutes !
Par exemple j'ai fait le test sur 3 machines et obtenu ces résultats:
Atmos Paris: 3:[BE;AC] 4:[A3;9A] 5:[91;7F] 6:[76;6D]
Atmos "Reset": 3:[BE;AC] 4:[A3;9A] 5:[91;7F] 6:[76;6D]
Atmos "MB": 3:[BE;AC] 4:[AC;9A] 5:[9A;7F] 6:[7F;64]
Si vous pouvez poster quelques essais (ou signaler un non-chargement !) ce serait génial.
Merci
- Fichiers joints
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Bonjour Simon,
J'ai fait les tests sur 3 Atmos et j'obtiens des mesures identiques :
3[BE, B5] 4[A3, 9A] 5[91, 7F] 6[6D, 76]
J'espère que cela t'aidera.
Je suis particulièrement intéressé par tes travaux car je constitue une biblothèque iTunes de logiciels.
S'il est facile de trouver des fichiers pour les émulateurs (TAP et DSK), il est plus rare de trouver des WAV 11kHz et la conversion n'est pas toujours simple (cf. TCC).
Cela manque si l'on souhaite simplement faire revivre un vieil Oric.
Alors, en plus, si l'on gagne du temps de chargement...
Je vais tester également TAP2F16, je te communiquerai les résultats.
Bon courage,
Fred
J'ai fait les tests sur 3 Atmos et j'obtiens des mesures identiques :
3[BE, B5] 4[A3, 9A] 5[91, 7F] 6[6D, 76]
J'espère que cela t'aidera.
Je suis particulièrement intéressé par tes travaux car je constitue une biblothèque iTunes de logiciels.
S'il est facile de trouver des fichiers pour les émulateurs (TAP et DSK), il est plus rare de trouver des WAV 11kHz et la conversion n'est pas toujours simple (cf. TCC).
Cela manque si l'on souhaite simplement faire revivre un vieil Oric.
Alors, en plus, si l'on gagne du temps de chargement...
Je vais tester également TAP2F16, je te communiquerai les résultats.
Bon courage,
Fred
FredV60- Messages : 7
Date d'inscription : 20/05/2015
Re: Toujours plus vite...
Merci Fred, déjà ça a fonctionné c'est une bonne chose !
Les mesures de ton Atmos sont encourageantes, plus que celles des machines que je teste de mon côté
En fait idéalement, il faudrait qu'aucun des intervalles mesurés ne se recoupe. Cela voudrait dire que chaque information différente est toujours lue de manière distincte.
Malheureusement sur environ 50% des machines testées, j'ai des choses comme 3:[BE;AC] 4:[AC;9A] => dans ce cas, quand le 6522 de l'Oric mesure une valeur "AC", je suis incapable de savoir si cela correspond à "3" ou "4". Le chargement hyper-rapide ne fonctionne donc pas sur ces machines... J'espérais que ces machines seraient peu nombreuses, mais sur mon parc hélas j'en ai déjà 3 ou 4 comme ça...
Je dois donc trouver des pistes pour tenter d'améliorer les choses: soit dans la forme du signal, soit dans la routine de mesure pour qu'elle soit plus rapide. A défaut, pour être fiable, il faudra se résigner à ralentir la vitesse !
En attendant, de ton côté si tu cherches un chargement très rapide et fiable, il faut que tu essaies TAP2CD. C'est je pense la quasi perfection; j'essaie de faire mieux mais comme tu vois, on perd en fiabilité, pour un gain de quelques secondes... Donc rien de probant pour l'instant.
Les mesures de ton Atmos sont encourageantes, plus que celles des machines que je teste de mon côté
En fait idéalement, il faudrait qu'aucun des intervalles mesurés ne se recoupe. Cela voudrait dire que chaque information différente est toujours lue de manière distincte.
Malheureusement sur environ 50% des machines testées, j'ai des choses comme 3:[BE;AC] 4:[AC;9A] => dans ce cas, quand le 6522 de l'Oric mesure une valeur "AC", je suis incapable de savoir si cela correspond à "3" ou "4". Le chargement hyper-rapide ne fonctionne donc pas sur ces machines... J'espérais que ces machines seraient peu nombreuses, mais sur mon parc hélas j'en ai déjà 3 ou 4 comme ça...
Je dois donc trouver des pistes pour tenter d'améliorer les choses: soit dans la forme du signal, soit dans la routine de mesure pour qu'elle soit plus rapide. A défaut, pour être fiable, il faudra se résigner à ralentir la vitesse !
En attendant, de ton côté si tu cherches un chargement très rapide et fiable, il faut que tu essaies TAP2CD. C'est je pense la quasi perfection; j'essaie de faire mieux mais comme tu vois, on perd en fiabilité, pour un gain de quelques secondes... Donc rien de probant pour l'instant.
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Bonjour ! J'ai à nouveau besoin de votre aide pour tester la fiabilité de routines de chargement cassette très rapides. Eh oui, Fabrice m'a guidé vers une piste pour fiabiliser le signal très rapide; avec la certitude qu'on ne pourra pas faire mieux en termes de mesure (précision à 3 microsecondes !).
Il vous faudra, à l'aide du kit c-joint:
- un player de fichiers WAV de qualité abslument parfaite: qualité du playback, signal non coupé au début, ni à la fin
- éloigner votre téléphone portable ou toute autre interférence audio
- charger MD3456-Interrupt.wav sur un Atmos (pas un Oric-1, ou alors avec ROM 1.1)
- faire RUN puis charger MD3456_test_sample_3_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- faire RUN puis charger MD3456_test_sample_4_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- faire RUN puis charger MD3456_test_sample_5_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- faire RUN puis charger MD3456_test_sample_6_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- et me communiquer ces 4 résultats !
Ce test me permet de savoir si tous les Atmos mesurent les mêmes intervalles de temps entre différentes combinaisons de signaux cassette très rapides. J'ai besoin de ces résultats sur un maximum de machines .
Voici un exemple de résultat sur une de mes machines:
Atmos Paris: 3:[B7-AE] 4:[A2-9C] 5:[8D-87] 6:[75-6F]
Merci d'avance !
Il vous faudra, à l'aide du kit c-joint:
- un player de fichiers WAV de qualité abslument parfaite: qualité du playback, signal non coupé au début, ni à la fin
- éloigner votre téléphone portable ou toute autre interférence audio
- charger MD3456-Interrupt.wav sur un Atmos (pas un Oric-1, ou alors avec ROM 1.1)
- faire RUN puis charger MD3456_test_sample_3_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- faire RUN puis charger MD3456_test_sample_4_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- faire RUN puis charger MD3456_test_sample_5_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- faire RUN puis charger MD3456_test_sample_6_--___.wav et noter l'inervalle indiqué après "Résultat final :"
- et me communiquer ces 4 résultats !
Ce test me permet de savoir si tous les Atmos mesurent les mêmes intervalles de temps entre différentes combinaisons de signaux cassette très rapides. J'ai besoin de ces résultats sur un maximum de machines .
Voici un exemple de résultat sur une de mes machines:
Atmos Paris: 3:[B7-AE] 4:[A2-9C] 5:[8D-87] 6:[75-6F]
Merci d'avance !
- Fichiers joints
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Bonjour Simon,
J'ai lancé chacun des tests 3 fois sur 2 Atmos.
1er Atmos :
Test 3 : C3-2D, C3-2D, C3-3D
Test 4 : C0-2A, C0-2A, C0-2A
Test 5 : FD-0, BD-0, FD-0
Test 6 : EB-2A, EB-2D, EB-2A
Sur l'autre Atmos (spécial à 2 ROMs) :
Test 3 : FD-15, FD-0, FA-0
Test 4 : C6-12, C6-12, C6-12
Test 5 : FD-0, FD-0, FD-0
Test 6 : EB-2A, EB-2A, EB-2A
J'espère que ça t'aidera .
J'ai lancé chacun des tests 3 fois sur 2 Atmos.
1er Atmos :
Test 3 : C3-2D, C3-2D, C3-3D
Test 4 : C0-2A, C0-2A, C0-2A
Test 5 : FD-0, BD-0, FD-0
Test 6 : EB-2A, EB-2D, EB-2A
Sur l'autre Atmos (spécial à 2 ROMs) :
Test 3 : FD-15, FD-0, FA-0
Test 4 : C6-12, C6-12, C6-12
Test 5 : FD-0, FD-0, FD-0
Test 6 : EB-2A, EB-2A, EB-2A
J'espère que ça t'aidera .
_________________
Ma page : https://sites.google.com/site/musepat/
PS : Je recherche pour ma collection tout ce qui a trait aux marques ORIC - ATMOS - DAI - TATUNG EINSTEIN
Re: Toujours plus vite...
Merci beaucoup Musepat!
Tout retour m'aide. Même si là, les résultats ne sont pas du tout ce que j'espérais
J'ai pu mesurer sur 3 machines et j'obtiens ceci:
Atmos Paris: 3:[B7;AE] 4:[A2;9C] 5:[8D;87] 6:[75;6F]
Atmos "Reset": 3:[B7;B1] 4:[A2;9C] 5:[8A;84] 6:[75;6F]
Atmos "MBec": 3:[B7;AB] 4:[A5;9C] 5:[8D;84] 6:[75;6F]
J'espérais que les intervalles que tu obtiendrais seraient sensiblement identiques, mais là on est très loin, bouhouhou. Il reste la possibilité que ce soit lié au player du fichier WAV plutôt qu'aux Atmos, car tes mesures d'une machine à l'autre se ressemblent. Peux-tu me dire avec quel logiciel/matériel tu as joué les fichiers ?
Ce WE je vais retrouver mon "stock" de machines, j'espère pouvoir faire le test sur 3 ou 4 autres Atmos.
Encore merci en tout cas
Tout retour m'aide. Même si là, les résultats ne sont pas du tout ce que j'espérais
J'ai pu mesurer sur 3 machines et j'obtiens ceci:
Atmos Paris: 3:[B7;AE] 4:[A2;9C] 5:[8D;87] 6:[75;6F]
Atmos "Reset": 3:[B7;B1] 4:[A2;9C] 5:[8A;84] 6:[75;6F]
Atmos "MBec": 3:[B7;AB] 4:[A5;9C] 5:[8D;84] 6:[75;6F]
J'espérais que les intervalles que tu obtiendrais seraient sensiblement identiques, mais là on est très loin, bouhouhou. Il reste la possibilité que ce soit lié au player du fichier WAV plutôt qu'aux Atmos, car tes mesures d'une machine à l'autre se ressemblent. Peux-tu me dire avec quel logiciel/matériel tu as joué les fichiers ?
Ce WE je vais retrouver mon "stock" de machines, j'espère pouvoir faire le test sur 3 ou 4 autres Atmos.
Encore merci en tout cas
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Alors oui, cela vient peut-être de là.
J'utilise un ordi sous Win7 et le player Foobar 2000 avec un long câble car ma télé est sur une autre table.
Je peux poser une petite télé près de l'ordi pour utiliser un câble plus court au cas où ça jouerait.
Pour le logiciel, dis-moi ce que tu utilises toi (pour moi, Foobar et VLC lisent sans problème les programmes sur l'Oric, mais pour ces tests, il faudrait peut-être utiliser le même logiciel et les mêmes réglages pour comparer).
J'utilise un ordi sous Win7 et le player Foobar 2000 avec un long câble car ma télé est sur une autre table.
Je peux poser une petite télé près de l'ordi pour utiliser un câble plus court au cas où ça jouerait.
Pour le logiciel, dis-moi ce que tu utilises toi (pour moi, Foobar et VLC lisent sans problème les programmes sur l'Oric, mais pour ces tests, il faudrait peut-être utiliser le même logiciel et les mêmes réglages pour comparer).
_________________
Ma page : https://sites.google.com/site/musepat/
PS : Je recherche pour ma collection tout ce qui a trait aux marques ORIC - ATMOS - DAI - TATUNG EINSTEIN
Re: Toujours plus vite...
Merci pour les infos ! Je suis pour ma part sous Windows XP, et je viens de tester avec Foobar 2000 (une version un peu ancienne: 1.1.11, de 2012), et j'ai les mêmes résultats qu'avec mon logiciel précédent. Pour te répondre d'ailleurs, j'utilise Cool Edit '96, qui pour le coup a 20 ans, et qui n'est pas gratuit.
Bref, Foobar étant a priori d'excellente qualité, je dirais que ça devrait marcher aussi pour toi, avec des valeurs proches des miennes. Surtout que je réalise que si le signal était vraiment mal lu, tu n'aurais sans doute pas de réponse du programme de test.
Ceci dit je me suis souvenu d'une chose qui était arrivée à Chema: certains players semblent inverser le signal. Non pas qu'ils jouent le son à l'envers à partir de la fin, mais les sinusoïdes sont renversées, par exemple un signal qui ferait
__--__-_-_ devient:
--__--_-_-
J'ai donc essayé et là paf, je tombe sur des valeurs qui ressemblent aux tiennes, un peu de loin, mais il y a de ça. Si c'est vraiment ce qui se passe, ça craint. Si les players ou les cartes son jouent à ça, on n'est pas sortis de l'auberge...
Bref, Foobar étant a priori d'excellente qualité, je dirais que ça devrait marcher aussi pour toi, avec des valeurs proches des miennes. Surtout que je réalise que si le signal était vraiment mal lu, tu n'aurais sans doute pas de réponse du programme de test.
Ceci dit je me suis souvenu d'une chose qui était arrivée à Chema: certains players semblent inverser le signal. Non pas qu'ils jouent le son à l'envers à partir de la fin, mais les sinusoïdes sont renversées, par exemple un signal qui ferait
__--__-_-_ devient:
--__--_-_-
J'ai donc essayé et là paf, je tombe sur des valeurs qui ressemblent aux tiennes, un peu de loin, mais il y a de ça. Si c'est vraiment ce qui se passe, ça craint. Si les players ou les cartes son jouent à ça, on n'est pas sortis de l'auberge...
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
J utilise le player de XP et un cordon que j ai fabriqué. Je vais essayer et ensuite j envoie les résultats trouvés.
kenneth- Modérateur
- Messages : 878
Date d'inscription : 13/01/2013
Age : 56
Localisation : 63
Re: Toujours plus vite...
Voici les résultats avec Windows media player, volume à moitié et volume de mon laptop Toshiba au trois quart. Sur un Atmos
3: #B7-#B4
4: #A2-#9C
5: #8A-#84
6: #75-#6F
Je précise qu en utilisant mon lecteur je n' ai jamais eu d' "ERRORS FOUND".
À plus
3: #B7-#B4
4: #A2-#9C
5: #8A-#84
6: #75-#6F
Je précise qu en utilisant mon lecteur je n' ai jamais eu d' "ERRORS FOUND".
À plus
kenneth- Modérateur
- Messages : 878
Date d'inscription : 13/01/2013
Age : 56
Localisation : 63
Re: Toujours plus vite...
Cool, merci Kenneth!
Ces valeurs sont compatibles avec celles déjà mesurées, même que les intervalles sont plus petits que ceux que j'obtiens, un rêve
Ces valeurs sont compatibles avec celles déjà mesurées, même que les intervalles sont plus petits que ceux que j'obtiens, un rêve
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
J'ai refais les tests, et cette fois avec Foobar et avec Cool Edit sous émulateur XP.
J'obtiens à peu près les mêmes résultats avec les 2 ordinateurs déjà testés.
Je viens d'en tester un 3ème et j'ai:
Test 3 : #C6-#2D
Test 4 : #C6-#2D
Test 5 : #C6-0
Test 6 : #E8-2D
J'obtiens à peu près les mêmes résultats avec les 2 ordinateurs déjà testés.
Je viens d'en tester un 3ème et j'ai:
Test 3 : #C6-#2D
Test 4 : #C6-#2D
Test 5 : #C6-0
Test 6 : #E8-2D
_________________
Ma page : https://sites.google.com/site/musepat/
PS : Je recherche pour ma collection tout ce qui a trait aux marques ORIC - ATMOS - DAI - TATUNG EINSTEIN
Re: Toujours plus vite...
Merci Musepat d'avoir testé à nouveau. J'avoue que je suis perdu sur les valeurs que tu obtiens !
Ce qui est curieux, c'est que le programme te réponde alors que dans les résultats, l'intervalle de valeurs est hyper-large. S'il détecte mal le signal, il devrait rester bloqué.
Pour vous expliquer un peu, le programme mesure le temps écoulé entre deux sinusoïdes du signal audio.
Le temps est mesuré par un registre du 6522, qui décompte les microsecondes entre deux sinusoïdes, en partant de 255 et en allant vers 0.
A chaque nouvelle sinusoïde, le décompte repart depuis 255.
Evidemment ce n'est pas une science exacte: une même sinusoïde aura une durée un peu variable selon le moment où le signal est lu, et selon les 6522 et les aléas hardware (limite de mes compétences ). De plus le programme de décodage prend du temps, et la forme des sinusoïdes qui précèdent et succèdent à celle qu'on mesure peuvent jouer aussi sur la vitesse de détection, bref il faut calibrer tout ça !
Par exemple quand le programme de test mesure "3", il mesure en fait la durée d'une sinusoïde de 3 samples pour l'Oric, soit en principe 3 fois 23 microsecondes. Il fait cette mesure plusieurs dizaines de fois d'affilée, avec un signal qui change avant et après, pour faire une statistique de robustesse.
En théorie, 3 samples = 255 - (3*23) = #BA. On voit qu'en réalité Kenneth par exemple, mesure un résultat qui varie entre #B7 et #B4
Idem, 4 samples = 255 - (4*23) = #A3, mesuré entre #A2 et #9C.
etc. , l'important étant de pouvoir distinguer ces valeurs 3 ou 4 avec certitude, donc que les intervalles ne mordent jamais l'un sur l'autre.
Le résultat idéal (et théorique) du programme de test serait qu'il affiche toujours exactement la même valeur à l'écran ! (faut pas rêver, hein)
Du coup Musepat, les intervalles que tu obtiens sont beaucoup trop larges. Ce qui serait intéressant, ce serait d'avoir une photo de l'écran de résultat du test (il affiche toutes les valeurs mesurées), pour savoir si il y a juste quelques "exceptions", ou si tout bouge complètement à chaque fois...
Ce qui est curieux, c'est que le programme te réponde alors que dans les résultats, l'intervalle de valeurs est hyper-large. S'il détecte mal le signal, il devrait rester bloqué.
Pour vous expliquer un peu, le programme mesure le temps écoulé entre deux sinusoïdes du signal audio.
Le temps est mesuré par un registre du 6522, qui décompte les microsecondes entre deux sinusoïdes, en partant de 255 et en allant vers 0.
A chaque nouvelle sinusoïde, le décompte repart depuis 255.
Evidemment ce n'est pas une science exacte: une même sinusoïde aura une durée un peu variable selon le moment où le signal est lu, et selon les 6522 et les aléas hardware (limite de mes compétences ). De plus le programme de décodage prend du temps, et la forme des sinusoïdes qui précèdent et succèdent à celle qu'on mesure peuvent jouer aussi sur la vitesse de détection, bref il faut calibrer tout ça !
Par exemple quand le programme de test mesure "3", il mesure en fait la durée d'une sinusoïde de 3 samples pour l'Oric, soit en principe 3 fois 23 microsecondes. Il fait cette mesure plusieurs dizaines de fois d'affilée, avec un signal qui change avant et après, pour faire une statistique de robustesse.
En théorie, 3 samples = 255 - (3*23) = #BA. On voit qu'en réalité Kenneth par exemple, mesure un résultat qui varie entre #B7 et #B4
Idem, 4 samples = 255 - (4*23) = #A3, mesuré entre #A2 et #9C.
etc. , l'important étant de pouvoir distinguer ces valeurs 3 ou 4 avec certitude, donc que les intervalles ne mordent jamais l'un sur l'autre.
Le résultat idéal (et théorique) du programme de test serait qu'il affiche toujours exactement la même valeur à l'écran ! (faut pas rêver, hein)
Du coup Musepat, les intervalles que tu obtiens sont beaucoup trop larges. Ce qui serait intéressant, ce serait d'avoir une photo de l'écran de résultat du test (il affiche toutes les valeurs mesurées), pour savoir si il y a juste quelques "exceptions", ou si tout bouge complètement à chaque fois...
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Dès que j'aurai un petit moment je te ferai les copies d'écran.
Je dois te préciser qu'à chaque fois, je suis obligé de lancer deux fois le test : la 1ère fois il semble ne rien se passer, et la 2ème fois j'ai les résultats.
Et ça systématiquement.
C'est peut-être de là que viennent les différences ?
Par contre le programme principal se charge dans tous les cas sans aucun problème.
Je dois te préciser qu'à chaque fois, je suis obligé de lancer deux fois le test : la 1ère fois il semble ne rien se passer, et la 2ème fois j'ai les résultats.
Et ça systématiquement.
C'est peut-être de là que viennent les différences ?
Par contre le programme principal se charge dans tous les cas sans aucun problème.
_________________
Ma page : https://sites.google.com/site/musepat/
PS : Je recherche pour ma collection tout ce qui a trait aux marques ORIC - ATMOS - DAI - TATUNG EINSTEIN
Re: Toujours plus vite...
Ah, alors tout s'explique, ça vient de làmusepat a écrit:Je dois te préciser qu'à chaque fois, je suis obligé de lancer deux fois le test : la 1ère fois il semble ne rien se passer, et la 2ème fois j'ai les résultats.
Et ça systématiquement.
C'est peut-être de là que viennent les différences ?
Cela veut tout de même dire que tes machines ont du mal à lire le signal, reste à savoir si cela vient des machines (ce serait pas de chance qu'elles soient toutes comme ça, mais ce n'est pas exclu) ou du signal (câble trop long, qualité son, que sais-je).
De mon côté, je viens de repérer un Atmos dans mon stock, qui a exactement les mêmes symptômes que ce que tu observes chez toi. Une machine sur 8, mais tu n'es plus seul
Je ne sais pas s'il peut y avoir une explication hardware ? (différents modèles de 6522, autre ?)
Sinon oui pour le programme de test lui-même, il est à vitesse normale, donc son chargement doit bien se passer. Pour te donner une idée, le signal de test va environ 8 fois plus vite, j'ai poussé la limite au maximum, donc le moindre petit souci provoque une erreur !
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Ah d'accord.
Alors je referai des tests avec des niveaux de volumes différents.
Alors je referai des tests avec des niveaux de volumes différents.
_________________
Ma page : https://sites.google.com/site/musepat/
PS : Je recherche pour ma collection tout ce qui a trait aux marques ORIC - ATMOS - DAI - TATUNG EINSTEIN
Re: Toujours plus vite...
@Symoon
La différence ne vient pas du 6522. Le signal du magnéto passe par un double ampli opérationnel, le LM358, avec des diviseurs et des filtres pour donner une forme au signal audio pour que la logique l assimile mieux. Ce que j expliquait à la visu concernant "l usure" de l oric qui pourrait altérer la lecture des .wav en mode ultra-rapide, ce n' est pas la partie logique de l'oric qui reste imperturbable avec le temps (soit tout marche soit rien), c est en fait toute la partie analogique c est à dire l ampli et les composants qui l'entourent. Bon je ne parle pas des résistances, ça ne bouge pas avec le temps, mais les deux condensateurs qui font un filtrage en fréquence et qui, en perdant quelques nanofarads, pourraient modifier un peu ton "wav" version tgv. Et cette petite déformation peut mettre à mal la lecture rigoureuse de ton signal, c est pour cela que ton échantillonnage est intéressant.
La différence ne vient pas du 6522. Le signal du magnéto passe par un double ampli opérationnel, le LM358, avec des diviseurs et des filtres pour donner une forme au signal audio pour que la logique l assimile mieux. Ce que j expliquait à la visu concernant "l usure" de l oric qui pourrait altérer la lecture des .wav en mode ultra-rapide, ce n' est pas la partie logique de l'oric qui reste imperturbable avec le temps (soit tout marche soit rien), c est en fait toute la partie analogique c est à dire l ampli et les composants qui l'entourent. Bon je ne parle pas des résistances, ça ne bouge pas avec le temps, mais les deux condensateurs qui font un filtrage en fréquence et qui, en perdant quelques nanofarads, pourraient modifier un peu ton "wav" version tgv. Et cette petite déformation peut mettre à mal la lecture rigoureuse de ton signal, c est pour cela que ton échantillonnage est intéressant.
kenneth- Modérateur
- Messages : 878
Date d'inscription : 13/01/2013
Age : 56
Localisation : 63
Re: Toujours plus vite...
Merci à vous pour les tests et explications !
Si le 6522 n'est pas en cause, c'est toujours ça de gagné Cela veut dire aussi qu'il faudra sans doute accepter le fait qu'aucun signal aussi rapide ne fonctionnera sur tous les Atmos, selon l'état de la partie analogique qui le transforme. Donc peut-être prévoir deux possibilités de génération du signal dans l'outil final, selon ce qu'on va observer avec les tests => si l'un ne marche pas, donner une chance à l'utilisateur que l'autre fonctionne.
Je perds un peu mon latin car la machine qui semblait débloquer (testée plusieurs fois) s'est mise à fonctionner peu de temps après. Mais au final j'ai un cas, entre deux machines, où sur l'une le "3" a une borne d'intervalle égale à celle du "4" sur une autre machine. C'est statistiquement faible, mais c'est une incompatibilité
Donc ce soir je vais tester une autre forme de signal, pour voir comment cela change les choses, et si c'est prometteur, j'en appellerai à nouveau à vos contributions généreuses !
Encore merci en tout cas, c'est motivant
Si le 6522 n'est pas en cause, c'est toujours ça de gagné Cela veut dire aussi qu'il faudra sans doute accepter le fait qu'aucun signal aussi rapide ne fonctionnera sur tous les Atmos, selon l'état de la partie analogique qui le transforme. Donc peut-être prévoir deux possibilités de génération du signal dans l'outil final, selon ce qu'on va observer avec les tests => si l'un ne marche pas, donner une chance à l'utilisateur que l'autre fonctionne.
Je perds un peu mon latin car la machine qui semblait débloquer (testée plusieurs fois) s'est mise à fonctionner peu de temps après. Mais au final j'ai un cas, entre deux machines, où sur l'une le "3" a une borne d'intervalle égale à celle du "4" sur une autre machine. C'est statistiquement faible, mais c'est une incompatibilité
Donc ce soir je vais tester une autre forme de signal, pour voir comment cela change les choses, et si c'est prometteur, j'en appellerai à nouveau à vos contributions généreuses !
Encore merci en tout cas, c'est motivant
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Re: Toujours plus vite...
Rien de ce que je teste comme nouvelles formes de signaux ne semble plus "robuste" que celle que nous utilisons déjà...
Voici les résultats actuels, en rouge les problèmes:
type de signal: _--____
Je pense que chez moi, vu les résultats sur les autres signaux, c'est l'Atmos "Vrrr" qui a un problème. Donc si je dois arbitrer, je dirais que A8 désignera 3 samples, et non 4.
Edit @Musepat: si tu as le courage de persister et de tenter de changer des réglages comme le volume, dans ce cas je pense qu'il vaut mieux que tu joues directement le WAV dans Windows 7 comme tu le faisais; émuler Windows XP ajoute peut-être un risque de perte en qualité.
Voici les résultats actuels, en rouge les problèmes:
type de signal: _--____
Atmos Paris: | 3:[B7;AE] 4:[A2;9C] 5:[8D;87] 6:[75;6F] |
Atmos "Reset": | 3:[B7;B1] 4:[A2;9C] 5:[8A;84] 6:[75;6F] |
Atmos "MBec": | 3:[B7;AB] 4:[A5;9C] 5:[8D;84] 6:[75;6F] |
Atmos 6522 bof: | 3:[B7;B1] 4:[A2;9C] 5:[8A;84] 6:[75;6F] |
Atmos 214102: | 3:[B7;A8] 4:[A5;9C] 5:[93;84] 6:[78;6F] A8 pour 3 ! |
Atmos 60Hz: | 3:[BA;AE] 4:[A2;9C] 5:[8A;81] 6:[75;6C] |
Atmos Vrrr: | 3:[BA;AB] 4:[A8;99] 5:[8A;81] 6:[72;6C] A8 pour 4 ! |
Musepat: | 3:[] 4:[] 5:[] 6:[] incohérences |
Kenneth: | 3:[B7-B4] 4:[A2-9C] 5:[8A-84] 6:[75-6F] |
Edit @Musepat: si tu as le courage de persister et de tenter de changer des réglages comme le volume, dans ce cas je pense qu'il vaut mieux que tu joues directement le WAV dans Windows 7 comme tu le faisais; émuler Windows XP ajoute peut-être un risque de perte en qualité.
Symoon- Messages : 779
Date d'inscription : 26/04/2014
Page 1 sur 3 • 1, 2, 3
Forum Oric :: Forums :: Forum Public
Page 1 sur 3
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum
|
|
Jeu 21 Mar 2024 - 8:51 par Dom50
» carte mère Oric (re)tracée
Mar 5 Mar 2024 - 18:54 par kenneth
» Meurtre à Grande Vitesse
Dim 25 Fév 2024 - 5:09 par Iurius
» ORIC-1 sur LE BON COIN
Ven 23 Fév 2024 - 23:01 par Mcar
» ORIC ATMOS sur LE BON COIN
Dim 4 Fév 2024 - 12:06 par kiwilevrai
» Problème d'affichage des couleurs avec un Oric Atmos
Sam 27 Jan 2024 - 1:26 par pierbail
» Bienvenue dans le Forum des Oriciens
Mar 9 Jan 2024 - 12:33 par Dom50
» Rencontre avec Laurant Weill, co-fondateur de Loriciel, et mon garçon de 12 ans
Ven 29 Déc 2023 - 14:13 par Arcade-des-Monts
» Bonnes fêtes
Mar 26 Déc 2023 - 10:21 par Dom50
» Murders in Venice / Meutres à Venise
Sam 18 Nov 2023 - 22:44 par retroric
» Un clavier PS/2 pour tester un ORIC
Dim 27 Aoû 2023 - 9:49 par Voyageur
» Disquette 3" Sedoric
Mar 1 Aoû 2023 - 14:22 par AtomeX
» faire un 6502 avec des phototransistor
Dim 16 Juil 2023 - 17:26 par Voyageur
» Oricutron linux et DSK
Jeu 29 Juin 2023 - 18:34 par Voyageur
» No Problem !
Dim 25 Juin 2023 - 17:53 par Voyageur