Re: GUERRE ST-AMIGA, FIGHT !!!

par ryosaeba Jeu 9 Fév 2017 - 20:13

@Babsimov: as-tu le lien youtube de la demo d'archi ?

par Meditating Guru Jeu 9 Fév 2017 - 20:15

On est vite traité de troll ici, encore une fois, alors que ma question est légitime. Confused

C'est la différence entre 71hz (monochrome ST, bon marché), et 60hz ou 50hz (écrans couleur).
L'Amiga n'a pas de haute résolution stable sans écran très coûteux et à compromis: autant acheter un Mac alors.

par **Zarnal** Jeu 9 Fév 2017 - 20:17

Je peux créer un topic dédié ? Ou je peux rester ici ? On parle de tellement de choses en même temps. Mr. Green

par Invité Jeu 9 Fév 2017 - 20:19

ryosaeba a écrit:@Babsimov: as-tu le lien youtube de la demo d'archi ?

par babsimov Jeu 9 Fév 2017 - 20:20

TOUKO a écrit:
ryosaeba a écrit:@Babsimov: as-tu le lien youtube de la demo d'archi ?

Merci, j'étais en train de rechercher le lien.

par Invité Jeu 9 Fév 2017 - 20:21

Meditating Guru a écrit:On est vite traité de troll ici, encore une fois, alors que ma question est légitime.
C'est la différence entre 71hz (monochrome ST, bon marché), et 60hz ou 50hz (écrans couleur).
L'Amiga n'a pas de haute résolution stable sans écran très coûteux et à compromis: autant acheter un Mac alors.

C'est pas sur ta question mais sur ça:

Les hautes résolutions de l'Amiga faisaient saigner les yeux.
Ne pas oublier ce petit détail qui ne se voit pas sur émulation, mais qui était évident sur les vrais écrans.

Si c'est pas du troll gratuit ça .
Si c'est pour déconner, mets un smiley au moins . Wink

Le 60htz progressif ne fait pas seigner les yeux comme tu dis, que je sache tu te pleins pas de ton TV full HD non qd tu regardes un film ??, bah pourtant il est en 60htz .

par stapha92 Jeu 9 Fév 2017 - 20:22

Zarnal a écrit:Je peux créer un topic dédié ? Ou je peux rester ici ? On parle de tellement de choses en même temps.

Excellente idée : un topic de comparaison et non de fight.
Tu pourrais y mettre ce que tu as fait avec Calamus/Final copy

par rocky007 Jeu 9 Fév 2017 - 20:23

Zarnal a écrit:
Les résultats parlent d'eux mêmes.

La suite un peu plus tard. Si vous avez des questions n'hésitez pas.

très intéressant, mais bon cela n'est au final pas très relevant : on constate juste que Spectre est moins bien codé que Amax

par Invité Jeu 9 Fév 2017 - 20:24

suis le seul a trouver que la demo archi casse pas des briques?

par Invité Jeu 9 Fév 2017 - 20:24

très intéressant, mais bon cela n'est au final pas très relevant : on constate juste que Spectre est moins bien codé que Amax

je croyais que les codeurs ST étaient meilleurs que ceux sur le mig ??, vous auriez menti encore une foi ?? Mr. Green

@zarnal: n'oublies pas que seules les démonstrations de rocky sont recevables . Wink

suis le seul a trouver que la demo archi casse pas des briques?

Non on est 65 999 999 de personnes à penser comme toi GUERRE ST-AMIGA, FIGHT !!! - Page 22 435303

par rocky007 Jeu 9 Fév 2017 - 20:31

TOUKO a écrit:
suis le seul a trouver que la demo archi casse pas des briques?
Non on est 65 999 999 de personnes à penser comme toi

vous êtes dur : cette demo n'était qu'un proof of concept et en aucun cas un demo finale

@zarnal: n'oublies pas que seules les démonstrations de rocky sont recevables .

pas du tout, mais je ne vois pas pq ce serait spécialement plus lent sur un ST , sinon un manque d'optimisation dans le code

par Invité Jeu 9 Fév 2017 - 20:35

vous êtes dur : cette demo n'était qu'un proof of concept et en aucun cas un demo finale

Elle devient critiquable par rapport au ton employé par archiforever,elle est pleine de défauts si tu pousses la critique jusqu'au bout .
Si c'était un codeur lambda(sans son speech anti amiga) je n'aurai rien dit .
Quand tu critiques une machine/codeurs, t'as intérêt à envoyer un minimum, et pas sortir un truc comme ça,même en proof of concept .
Le mec qui a codé QTM, ne vient pas dire toutes les 5 mins que l'archie joue mieux les mods que le mig lui .

pas du tout, mais je ne vois pas pq ce serait spécialement plus lent sur un ST , sinon un manque d'optimisation dans le code

Le hic, c'est que si les résultats avaient été contraires tu aurais sauté de joie, et pris ça comme preuve que le ST est mieux . Mr. Green

par rocky007 Jeu 9 Fév 2017 - 20:41

Le hic, c'est que si les résultats avaient été contraires tu aurais sauté de joie, et pris ça comme preuve que le ST est mieux .

pas faux

par Meditating Guru Jeu 9 Fév 2017 - 20:42

SVP ne pas confondre 60hz LCD, super stable, et 60hz CRT (cathodique), trop scintillant pour la bureautique...

par Meditating Guru Jeu 9 Fév 2017 - 20:46

rocky007 a écrit:
très intéressant, mais bon cela n'est au final pas très relevant : on constate juste que Spectre est moins bien codé que Amax

Pas sûr! Il y a plein de facteurs. Le blitter? Spectre fait-il plus que A-Max? Pourquoi le HD semble-t-il foirer sur Amiga? etc.

par rocky007 Jeu 9 Fév 2017 - 20:49

ah oui juste le blitter, le test n'a pas été fait avec un Ste !
( enfin même pas sûr qu'il soit pris en charge par Spectre )

par **Zarnal** Jeu 9 Fév 2017 - 20:55

Meditating Guru a écrit:
rocky007 a écrit:
très intéressant, mais bon cela n'est au final pas très relevant : on constate juste que Spectre est moins bien codé que Amax

Pas sûr! Il y a plein de facteurs. Le blitter? Spectre fait-il plus que A-Max? Pourquoi le HD semble-t-il foirer sur Amiga? etc.

Il est vrai que je n'ai pas évoqué ce point que je gardais pour la suite. Pour te répondre vite fait : il s'agit d'une image HD mac dans une Image HD winuae alors que pour spectre il s'agit d'une simple image disque directement utilisable. Je reviendrai en détail sur ce point plus tard. Il est résolu mais comme mon test initial amiga date du WE, je n'ai pas mis à jour.

@rocky je teste en mode ste+blitter dès que possible pour voir.

par babsimov Jeu 9 Fév 2017 - 21:07

TOUKO a écrit:
J'ai l'impression que tu as raison pour la 2D. Hier soir, je suis tombé en me promenant sur youtube sur la démo finalisée de d'Archiforever. Franchement je n'ai rien vu que je n'avais pas déjà vu sur un Amiga 500. Il y va même de critiquer le son, parce que c'est un module issu de l'Amiga.
Ne te fies pas à lui, d'ailleurs sur toutes ses vidéo où il critique le mig il a désactivé les coms, ça montre son courage et son assurance .
Je l'ai aussi vu se faire reprendre sur une video comparatif de pacmania (archie/amiga) par un demomaker amiga, qui lui disiat d'ailleurs qu'il racontait que des conneries .
https://www.youtube.com/watch?v=60_v6gowkKE&t=374s

D'ailleurs même sur un site de dev archimedes il se fait reprendre souvent pour son bashing constant sur l'amiga .

C'est vrai que le fait que dans les commentaires de sa démo il trouve tout génial, sauf le mod parce qu'issu de l'Amiga... bof.
S'il n'appréciait pas les musiques Amiga, il n'avait qu'à trouver un module purement Archimedes. Après tout il connait sur le bout des doigts le monde de l'Archimedes, ses utilisateurs. Il doit bien connaître un compositeur sur sa machine de prédilection. En plus si, par extraordinaire, ce module purement Archimedes avait été exceptionnel, il aurait pu légitimement dire que le son de l'Archimedes était mieux que celui de l'Amiga. Donc, c'est bien l'Archiforever dont je me souviens pendant le débat dans le sujet Archimedes vs Amiga.

kaotsuis le seul a trouver que la demo archi casse pas des briques?

C'est aussi mon avis, rien d'extraordinaire. Je ne suis pas programmeur et donc incapable de faire pareil, je ne devrait pas faire ce genre de remarque. Mais, pour avoir lu en direct à l'époque ce qu'il affirmait sur ses routines "révolutionnaires" qui poussaient l'Archimedes à fond. Qu'il allait démontrer comment l'Amiga était pitoyable à côté... ben ça tombe à plat tout ça.
D'ailleurs certains des intervenants ici me l'avaient dit à l'époque que ce serait pas folichon. Je lui avais laissé le bénéfice du doute (de moins en moins sur la fin). Il n'a pas réussi son défi de mon point de vue.

La ou l'Archimedes me semble inattaquable c'est pour la 3D, son mode chunky et son ARM lui donne un avantage qu'un Amiga 500/2000 non accéléré ne pourra pas contrer à mon avis. Mais, sortit de là, l'Archimedes ne me semble pas exceptionnel en 2D.
Là y'a même pas débat, c'est le point fort de l'archimedes .

Oui, je me suis mal exprimé, c'est vrai qu'il n'y a pas de débat en effet, la 3D est le point fort de l'Archimedes.

Je ne nie cependant pas que pour la bureautique le ST a eu plus tôt que l'Amiga des logiciels de qualité et en plus en français. Plus tard, l'Amiga a finit par rattraper un peu son retard (quoi que sur les logiciels en français, le ST me semble avoir gardé un bel avantage).
Le truc c'est que techniquement aucun logiciel pro ST est infaisable sur amiga, donc c'est un faux avantage, juste un choix du fait que le ST soit sortie avant et moins cher,et a donc été le concurrent par défaut du mac.

Je suis d'accord aussi, tout ce que faisait le ST en bureautique était faisable au moins de façon identique sur Amiga. Mais aussi en mieux, parce que le hardware avait plus de puissance.

Là où le ST avait l'avantage c'est bien sur la MAO grâce au midi en standard, même si le mig pouvait avec une carte faire la même chose, je vois pas l'intérêt de payer plus cher un mig+carte midi si le midi est tout ce qui t'intéresse .

Idem, c'est tout à fait pertinent. Je n'ai d'ailleurs pas une seule fois remis en cause l'avantage du ST pour la MAO.

@Stapha92

Je m'excuse de te demander celà à nouveau, mais si tu trouves un peu de temps, pourrais tu regarder les caractéristiques du composant graphique du prototype Thomson TO16 (à base de 68000). J'aimerais bien avoir l'avis d'un spécialiste comme toi. Je pense d'ailleurs que ça pourrait intéresser les lecteurs du forum. Une petite comparaison entre ce composant intel et les capacités graphiques du ST et de l'Amiga. Cela pourrait permettre d'imaginer si cette machine aurait pu faire de l'ombre aux deux plateformes phare de cette période. J'ai cru comprendre que c'est un composant chunky ? Je ne suis pas certain que son mode 256 couleurs soit un vrai 256 couleurs ? Les sprites semblent pouvoir être de n'importe quelles tailles et au nombre de 15 ou 16 ? Bref, tu auras compris que j'aimerais une analyse des points fort et des points faibles de ce composant que tu pourrais déduire de ce document.

Je te remet le liens :

http://www.logicielsmoto.com/documents/i82716.pdf

J'espère que tu ne m'en veux pas trop pour cette "insistance". Il ne fallait pas être aussi doué pour expliquer les choses de façon aussi didactique... maintenant j'ai pris l'habitude et donc j'en redemande Very Happy

par Invité Jeu 9 Fév 2017 - 21:17

babsimov a écrit:C'est aussi mon avis, rien d'extraordinaire. Je ne suis pas programmeur et donc incapable de faire pareil, je ne devrait pas faire ce genre de remarque. Mais, pour avoir lu en direct à l'époque ce qu'il affirmait sur ses routines "révolutionnaires" qui poussaient l'Archimedes à fond. Qu'il allait démontrer comment l'Amiga était pitoyable à côté... ben ça tombe à plat tout ça.
D'ailleurs certains des intervenants ici me l'avaient dit à l'époque que ce serait pas folichon. Je lui avais laissé le bénéfice du doute (de moins en moins sur la fin). Il n'a pas réussi son défi de mon point de vue.

j'ai pas non plus le niveau technique pour la ramener mais apres avoir lu topic en question, beaucoup de noms d'oiseaux pour ..hmm... une performance toute relative (on va dire ca comme ca Razz

)

par babsimov Jeu 9 Fév 2017 - 21:21

kaot a écrit:
babsimov a écrit:C'est aussi mon avis, rien d'extraordinaire. Je ne suis pas programmeur et donc incapable de faire pareil, je ne devrait pas faire ce genre de remarque. Mais, pour avoir lu en direct à l'époque ce qu'il affirmait sur ses routines "révolutionnaires" qui poussaient l'Archimedes à fond. Qu'il allait démontrer comment l'Amiga était pitoyable à côté... ben ça tombe à plat tout ça.
D'ailleurs certains des intervenants ici me l'avaient dit à l'époque que ce serait pas folichon. Je lui avais laissé le bénéfice du doute (de moins en moins sur la fin). Il n'a pas réussi son défi de mon point de vue.

j'ai pas non plus le niveau technique pour la ramener mais apres avoir lu topic en question, beaucoup de noms d'oiseaux pour ..hmm... une performance toute relative (on va dire ca comme ca )

C'est exactement mon avis.

par Invité Jeu 9 Fév 2017 - 21:27

rocky007 a écrit:
Le hic, c'est que si les résultats avaient été contraires tu aurais sauté de joie, et pris ça comme preuve que le ST est mieux .

pas faux

Normal ,j'aurai fait pareil Mr. Green

j'ai pas non plus le niveau technique pour la ramener mais apres avoir lu topic en question, beaucoup de noms d'oiseaux pour ..hmm... une performance toute relative (on va dire ca comme ca )

bah ouai, mais il continue encore je te rassure à dire qu'il va faire un jeu NG sur archie .
Mais bon depuis le temps faudrait que le proof of concept devienne autre chose .

SVP ne pas confondre 60hz LCD, super stable, et 60hz CRT (cathodique), trop scintillant pour la bureautique...

Mais oui, sur un moniteur PC en progressif 60 htz ça scintille pas d'un poil,comme d'hab tu pousses l'exagération à l'extrême ..

par rocky007 Jeu 9 Fév 2017 - 21:43

TOUKO a écrit:
Et tu pense que l'archi à un DAC de bonne qualité,surtout avec son fake 8 voix multiplexées ??

ben je ne sais pas, par exemple la Gravis Ultra Sound a 32 canaux sample, est-ce qu'elle a 32 DAC ? je doute fort, elle aussi doit utiliser le multiplexing;

par stapha92 Jeu 9 Fév 2017 - 21:54

rocky007 a écrit:
Le hic, c'est que si les résultats avaient été contraires tu aurais sauté de joie, et pris ça comme preuve que le ST est mieux .

pas faux

Devant tant de bonne foi je ne peux que m'incliner.

D'un coté, quand le ST dispose de logiciels meilleurs que le mig, ce n'est pas grace a un composant spécial. Donc la comparaison est recevable.

De l'autre, c'est vrai que c'est curieux. Le blitter ne peut intervenir que sur un seul test (et pour celui-ci, le mig peut même être pénalisé par la plus grande résolution). Ce n'est donc pas l'explication. Peut-être l'utilisation d'exceptions dans les appels de l'OS. En tout cas ça doit être lié à ça : au niveau matériel, le mig n'a pas d'avantage pour faire ça.

Le plus étonnant est le test cpu : il n'y a pas besoin de l'émuler (donc le code ne peut pas être en cause) et ça ne fait pas appel à l'OS (les test cpu sont souvent des routines du type tri) !

Ce test là devrait être remporté par le ST. Donc là, tout comme toi, je suis étonné.

@Zarnal,
Les bench c'est une chose mais la différence est-elle vraiment sensible à l'utilisation ?

vous êtes dur : cette demo n'était qu'un proof of concept et en aucun cas un demo finale

Je ne sais pas si tu étais là mais en fait c'était une ébauche d'un jeu qui utilisait des routines soi-disant "révolutionnaires". Quand Touko lui avait demandé des détails, il l'avait envoyé valsé, croyant qu'il tenait un trésor... MDR

Et quand j'ai donné les explications, il m'a accusé d'avoir désassemblé sa démo (soi-disant publiée mais je ne sais même pas si c'est vrai)... Avant de se rendre compte que j'avais donné (après qu'il m'ait pris de haut) d'autres optims qui correspondaient à la dernière version de sa démo. Evidemment il n'y a rien d'extraordinaire dans ce que j'ai proposé : juste du préshiftage de sprite pour un alignement sur 32 bits et un code déroulé pour les afficher...
Et ce jeu, une fois terminé devait prouver que l'archi explosait un amiga et... une NEO-GEO !!!!

L'Amiga n'a pas de haute résolution stable sans écran très coûteux et à compromis: autant acheter un Mac alors.

Je crois que tu te trompes sur le prix d'un Mac et sur celui d'un multisync noir et blanc.

Même avec un multisync couleur haut de gamme, ça revenait bien moins cher qu'un Mac.

Quand au compromis. Tu peux préciser ?

TOUKO a écrit:
rocky007 a écrit:
Le hic, c'est que si les résultats avaient été contraires tu aurais sauté de joie, et pris ça comme preuve que le ST est mieux .

pas faux

Normal ,j'aurai fait pareil

Moi pas

Mais c'est parce que j'aime bien le ST et que je sais qu'il a été fait pour concurrencer le Mac. J'aurais donné cher pour voir la tete d'un pro-mac si je j'avais pu lui montrer çà quand j'avais mon ST : rien que la résolution et la taille de l'écran du ST lui aurait fait envie. Je me serais gardé de lui parler du prix : infarctus assuré ! MDR

Oui, je me suis mal exprimé, c'est vrai qu'il n'y a pas de débat en effet, la 3D est le point fort de l'Archimedes.

Et encore : la 3D surface pleine surtout. Quand il s'agit d'appliquer une texture, la vitesse de la mémoire et l'architecture Load&Store de l'ARM le pénalisent... A mips équivalent, le ST et le mig font mieux en 3D texturée, malgré la conversion C2P !

ben je ne sais pas, par exemple la Gravis Ultra Sound a 32 canaux sample, est-ce qu'elle a 32 DAC ? je doute fort, elle aussi doit utiliser le multiplexing

C'est vrai mais elle fait du 16 bits. ça aide... Et la Gravis utilise un système étrange qui fait que la fréquence baisse avec l'augmentation des canaux.
Entre nous, je pense qu'un falcon avec ses DAC 16 bits + son DSP est meilleur qu'une gravis (j'occulte la qualité de sortie, je parle juste des possibilité théoriques)

par Seb Jeu 9 Fév 2017 - 21:59

A ce rythme là on va bientôt comparer si les crottes de nez collaient mieux sur le boitier du ST ou celui de l'Amiga.

Avec bien sur encore plein de mauvaise foi à la clé et plein de désinformation :)

par Meditating Guru Jeu 9 Fév 2017 - 22:02

stapha92 a écrit:L'auteur dit plutot que Tramiel ne lui avait pas accordé les semaines supplémentaires pour implémenter tout ce qu'il voulait dans le SID.
Tramiel le roi du lo-cost... et du ST...

Le résultat est le même, n'est-ce pas? Le SID n'était pas fini. Sad

Oui c'est ton droit mais on connait ta bonne foi : si le SID avait été dans le ST, tu expliquerai que ç'est mieux qu'un DX7...

C'est cela, oui... et toi, si les circuits du DX7 étaient dans le ST tu dirais encore que c'est de la m...

Rien que la commande say donne un meilleur son que ça...

Amen.

Donc la prochaine fois abstiens toi du "à coté de la plaque" quand je reprend tes affirmations...

Si tu avais des oreilles valables, tu te serais rendu compte qu'un son pareil, ça peut pas être du sample sur YM. Mr. Green

Ah bon ? N'importe quoi...
Un mélomane comme toi doit savoir que les enregistrements de studios se font en multi-pistes. Si tu fais ses enregistrements en numérique, le fait de gérer volume/panning (je ne compte pas les effets) pour chacune d'entre elles oblige à augmenter la résolution en sortie de mixage pour ne pas perdre en qualité.
Par exemple : 16 pistes en 12 bits avec un volume sur 8 bits obligent à avoir 24 bits en sortie pour garder la qualité.
Pourtant, sur le papier, 16 pistes en 12 bits ça parait pas folichon dans le monde pro...

Qu'est-ce que ce charabia? Je te parlais de la résolution des ADC. Si tu avais un bon 18bit, tu avais de la chance. Après, tu peux faire du 32bit en interne, ce qui compte, c'est que le son 16bit est presque parfait en enregistrement comme en sortie. Seules des super oreilles vont distinguer 16bit/24bit.

Et je préfère un ordinateur qui peut rivaliser avec une console juste avec des disquettes qu'un ordinateur avec un port cartouche qui se fait déposer par une NES...

Tu l'ignores certainement mais aucun jeu n'est sorti en cartouche sur le ST. Et l'Amiga ne rivalisait avec les consoles que dans tes rêves. Mr. Green

Tu supposes mal : je vais expliquer en détaillant le fonctionnement du log. Que chacun puisse se faire son opinion.
Je dois coder des routines sur mon PC pour que l'explication soit visuelle et compréhensible de tous.

Si le 8 bits log etait meilleur, pourquoi n'y a-t-il pas du 16 bits log puisque ce dernier devrait être meilleur que le 16 bits linéaire (qui lui est très répandu) ?
Le codage log est tombé aux oubliettes et n'est plus utilisé que pour la téléphone : c'est pas pour rien...
Et avant de rétorquer une betise du genre "le 16 bits a assez de dynamique" ou "le log ne marche que pour le 8 bits", attend un peu...

D'ailleurs : tu as expliqué ne rien connaitre au 8 bits log mais tu as tout à fait compris puisque tu as très bien pointé le problème.

Le fait derrière cet écran de fumée: le 8bit log a beaucoup moins de souffle que le 8bit linéaire. N'est-ce pas la conclusion? On ne parle pas de 16bit log ici. Wink

par babsimov Jeu 9 Fév 2017 - 22:06

stapha92 a écrit:
Et encore : la 3D surface pleine surtout. Quand il s'agit d'appliquer une texture, la vitesse de la mémoire et l'architecture Load&Store de l'ARM le pénalisent... A mips équivalent, le ST et le mig font mieux en 3D texturée, malgré la conversion C2P !

Je me souviens en effet que tu avais évoqué cela dans le sujet Archimedes.

par cryodav76 Jeu 9 Fév 2017 - 22:14

il faut pas oublié que l'amiga est capable d'utiliser un moniteur pc sans aucune autre manip qu'un adaptateur db23 vers db9 a 10€ et un drivers placé dans monitor , il existe de tres nombreux modes graphiques.
c'est devenu inutile avec les tv actuelle et les adaptateur scart /hdmi qui désentrelace tres bien

par stapha92 Jeu 9 Fév 2017 - 23:03

Bon, je vais expliquer en quoi consiste le 8 bits log.

J'ai codé quelques routines pour générer les images qui devraient permettre à tout le monde de comprendre le principe.

C'est partit :

Le son est une onde acoustique, qui peut se traduire par une courbe. J'ai codé le tracé d'une sinusoidale que voici :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 110

GUERRE ST-AMIGA, FIGHT !!! - Page 22 110

La ligne rouge représente le 0, la courbe oscille autour de cette ligne. Quand elle passe au-dessus ou en dessous, cela génère un courant positif ou négatif plus ou moins fort en fonction de la distance entre chaque point de la courbe et le 0. Pour expliquer différemment, la membrane du haut-parleur qui restituera le son s'avancera ou reculera plus ou moins loin de sa position d'origine. Lorsque la courbe croise le 0, la membrane est à sa position initiale.

La hauteur de la courbe représente l'amplitude du son.

Cette courbe n'est pas suivi instantanément par le haut parleur : il la suit en allant de la gauche vers la droite.
Supposons que le tracé complet dure 1/100eme de seconde : cela veut dire qu'au bout de 0,5/100eme elle aura fait une oscillation complète (elle sera à la moitié du tracé et sera revenue à 0). 0,5/100eme de secondes signifie qu'au bout d'une seconde (si la courbe se répète), elle aura fait 200 oscillations.

la vitesse d'oscillation de la courbe représente la fréquence. Dans notre cas, elle sera de 200 Hertz.

Pour info : quand on modifie l'amplitude, on parle de modulation d'amplitude (AM) et quand on modifie la fréquence, on parle de modulation de fréquence (FM)

Comment fait-on quand on veut numériser cette courbe ?
Et bien on va mesurer son amplitude à intervalles régulier et de façon rapide. Chaque mesure donnera un nombre que l'on stockera de façon binaire.
Si ce stockage se fait sur 8 bits, ce nombre pourra prendre 256 valeurs différentes : elles iront de -128 (quand la courbe passe au plus bas) à +127 (quand la courbe passe au plus haut). Quand la courbe croise le 0, ce nombre sera à 0.

Pour la suite de l'explication, on va supposer qu'on fait un échantillonnage sur 6 bits (64 valeurs) pour limiter la taille des tracés qui sont déjà bien assez grand comme ça...
Mais ça ne change rien pour la comlpréhension

Avec une numérisation linéaire, les volumes possible seront tous espacés de la même valeur. Si on représente tous les volumes possible en linéaire 6 bits, sous la forme de droite horizontales ça donnera ceci :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 210

GUERRE ST-AMIGA, FIGHT !!! - Page 22 210

On voit bien que l'espace entre chaque volume est constant (d'ou le "linéaire"). On ne pourra donc pas mesurer avec précision le volume de la courbe à chaque échantillon : au mieux la courbe croisera une des droites horizontale au moment de la mesure, au pire elle sera située pile entre 2 droites au moment d'une autre mesure. Cela génèrera donc une erreur qu'on appelle erreur de quantification

Avec une numérisation de type log, l'espace entre les volumes possibles varie : plus on est loin de 0 et plus il est grand. ça donnera ceci :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 310

GUERRE ST-AMIGA, FIGHT !!! - Page 22 310

L'espace entre les lignes n'est plus constant mais qu'il augmente de façon logarithmique (d'ou le "log").
On voit que lorsque l'on est près de 0, les lignes se touchent : l'erreur de quantification sera plus faible qu'en linéaire. A l'inverse, quand on s'en éloigne, elle sera plus élevée.

La précision que l'on gagne d'un coté est forcément perdu ailleurs : le log n'est pas magique, comme je l'ai déjà expliqué...

Maintenant, numérisons notre courbe.

Supposons que nous choisissions d'effectuer une mesure tous les 1/26 000eme de seconde. On aura 26 000 mesures par secondes. On dit qu'on aura 26 000 échantillons (ou "samples") par secondes (on comprend mieux d'ou vient ce terme d'échantillon). On dira qu'on a une fréquence d'échantillonnage (ou "sampling rate") de 26 Kilo-Hertz.

Souvenons-nous que notre courbe durait 1/100eme de seconde dans le premier tracé. Cela signifie qu'elle utilisera pour sa numérisation 260 samples (26 000/100).

Avec une numérisation linéaire, cela donnera ceci :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 410

GUERRE ST-AMIGA, FIGHT !!! - Page 22 410

On voit bien les erreurs de quantification qui sont constantes (en gros les carrés ont la même taille).

Et en "log", ça donnera ceci :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 510

GUERRE ST-AMIGA, FIGHT !!! - Page 22 510

On voit bien que près du 0, les erreurs de quantification sont plus faibles et qu'elles deviennent bien plus grandes quand on s'en éloigne.

Soyons honnêtes : la forme de la courbe ne permet pas de bien voir les gains que l'on a près de la ligne du 0.

Je remet donc 2 tracés avec une courbe plus étirée, afin que ce soit plus visible.

Linéaire :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 610

GUERRE ST-AMIGA, FIGHT !!! - Page 22 610

Log :

GUERRE ST-AMIGA, FIGHT !!! - Page 22 710

ça se voit encore plus.

Donc le log réduit les erreurs de quantization près du 0 et les augmente quand on s'en éloigne...

Mais quel est l'interet ?
Et bien il est physiologique : l'oreille humaine est moins sensible à ces erreurs quand le volume est élevé. Or le volume est élevé quand la courbe est loin du 0 (sauf quand la courbe reste loin mais c'est une autre histoire).
C'est le but du log : on sacrifie de la précision a un endroit ou elle est moins importante et on utilise ce que l'on a récupéré pour l'augmenter là ou elle s'entend plus.

faisons une pause pour aborder un point important et clarifier quelque chose.

Qu'est-ce que la dynamique d'un son ? Et bien c'est l'écart qu'il y a entre le son le plus fort et le son le plus faible.

Qu'on soit en linéaire ou en log, le son le plus fort correspond à un passage du point le plus bas au point le plus haut, c'est l'amplitude maximum. C'est ce que fait (presque) notre courbe.

Pour le son le moins fort, c'est différent :
- Avec le linéaire, vu que l'espace entre toutes les valeurs possibles est identique, c'est l'espace entre 2 valeurs.
- Avec le log, c'est l'espace entre le 0 et la première ligne (au dessus ou en dessous) puisque ce sont les plus proches.

Donc dans notre exemple, en linéaire l'écart sera de 64 fois (36 db). En log, les lignes près du 0 sont 8 fois plus
proches que celles du linéaire. L'écart sera de 512 fois (54 Db).
Normalement, pour avoir un ecart comme ça, il faut du linéaire 9 bits alors qu'on est en log 6 bits.
Mais, en 9bits, toutes les lignes se toucheraient ! La courbe numérisée n'aurait pas du tout le même aspect !

C'est pourquoi on peut dire que du 6 bits log a une dynamique de 9 bits bit linéaire (ou 8 bits logs une dynamique de 12 bits linéaire). Mais on ne peut pas dire que ça a la qualité d'un 9 bots linéaires. Pas du tout !

(donc le 15 bits de l'archi : on peut oublier...)

Je ne dis pas ça pour attaquer Rocky : l'affirmation 8 bits log = 12 bits linéaires apparait souvent mais est un raccourci totalement faux ! (et c'est pourquoi je lui avais dit que j'appréciais sa démarche. Je ne le tenais pas pour responsable de propos tenus partout).

mais continuons : notre courbe est on ne peut plus simple. Or un son est composé de pleins de courbes simples qui, associées, forment une courbe complexe.

Construisons donc une deuxième courbe :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 810

GUERRE ST-AMIGA, FIGHT !!! - Page 22 810

On un son plus aigu et moins fort. Ce n'est pas hasard : les sont graves sont forts et les aigus faibles. Jetez un oeil sur une enceinte : le haut parleur de grave est bien plus grand que celui des aigus. Et quand on monte le son, ce sont les sons graves qui génère des vibrations que l'on perçoit sans nos oreilles...

Cumulons cette courbe avec la première, ça donne ceci :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 910

GUERRE ST-AMIGA, FIGHT !!! - Page 22 910

Les 2 courbes sont cumulés. Faisons la numérisation maintenant.

En linéaire :
GUERRE ST-AMIGA, FIGHT !!! - Page 22 1010

Notre courbe des aigus perd de la résolution de façon homogène

En log
GUERRE ST-AMIGA, FIGHT !!! - Page 22 1110

Près du 0, la courbe d'aigu est plus fidèle. Mais quand on s'éloigne, elle est totalement détruite !
Et cette fois ça va s'entendre. A cause de la différence de fréquence : notre oreille la détecte sans problème. De plus un son aigu est directif et pas un son grave (en gros, l'oreille parvient à situer l'origine des sons aigus mais pas des sons graves, c'est pourquoi on se moque de la stéréo pour les graves quand on utilise des caissons)

Alors quand on me dit que 8 bits logs, c'est mieux je réponds : pas dans tous les cas.

Or, dans la musique, on rencontre ça constamment : des graves forts mélangés avec des aigus plus faibles.

Mais il n'y a pas que la musique : en téléphonie on n'a pas besoin de restituer pleins de fréquences différentes.
Du coup, le cas que je viens de décrire se produira moins.

Ce n'est pas un hasard si, dans ce domaine, le log n'a pas été abandonné...

Un point sur l'archimede. Un avantage du log concerne la gestion du volume. En effet avec le log, si on divise le volume par 2, on voit dans le 3eme tracé que l'on perd 10 lignes. Il nous en reste donc 54/64. Avec le linéaire, on en perd la moitié : il nous en restera 32/64.

Mais pour profiter de ce système il faut que le sample soit stocké sur 16 bits (car une fois converti en log, on a perdu les informations qui se trouve en haut de la courbe) et le convertir en temps réel APRES avoir appliqué le volume. Mais dans ce cas, c'est beaucoup plus gourmand en ressources (et en taille à cause des samples 16bits et des tables de conversion).

Mais Paula a plus d'un tour dans son sac : si on veut baisser le volume, elle peut le faire pour nous SANS AUCUNE PERTE de résolution. On pourrait prendre notre courbe et diviser par Paula son volume par 64 qu'elle garderait exactement la même forme...

par rocky007 Jeu 9 Fév 2017 - 23:38

chapeau pour le temps que tu as passé à créer tous ces illustrations et les explications détaillées.

je suis tout à fait d'accord avec tes explications et ce depuis le début : malgré ce que tu continues à essayer de faire croire, j'ai toujours affirmé que du 8 bit log ne valait pas du 12 bit lineaire.

la théorie c'est bien, ce que tu expliques est tout à fait correcte. Mais force de constater qu'en pratique, car le son c'est bcp plus complexe que 2 sinus à fréquences différentes, un sample en 8 log est supérieur à son équivalent 8 lineaire. Plusieurs exemples ont été posté ici, le 8 bit log est systématiquement supérieur. mais tu as raison, dans ton exemple précis, l'artefact sera perceptible.

tu n'as pas non plus relevé les samples log utilisé dans les synthés ( dont tu m'as bassiné à te fournir la preuve, pour après l'ignorer après l'avoir postée)... ce choix a été fait pas des grands noms de la musique.

pour qu'on puisse bien juger de la différence dans ton exemple précis :
( j'ai généré un sinus 200hz et un de 4000hz )

original :
www.webzigner.com/sinus.wav

8 bit
www.webzigner.com/sinus-8.wav

8 bit log
www.webzigner.com/sinus-a.wav

par Meditating Guru Ven 10 Fév 2017 - 8:54

Bon, je me lance, mes pauvres oreilles de gourou ne détectent pas de différence... Sad

par Invité Ven 10 Fév 2017 - 9:15

ben je ne sais pas, par exemple la Gravis Ultra Sound a 32 canaux sample, est-ce qu'elle a 32 DAC ? je doute fort, elle aussi doit utiliser le multiplexing;

C'est pas faux, mais bon tu vas pas comparer la GUS qui a autant de chips qu'un ST avec le chip son de l'archimedes ??
Le multiplexage est un système basique,déjà pas vraiment adapté à l'audio et encore moins sur 32 voix, à cause de la latence que ça induit .
Vu le nombre de chip dans cette carte je pense que ce doit être bcp plus complexe que ça,surtout en 93.

je pense que tu devais avoir 2 DAC(1/canal) et que le mixage audio était fait en hard via un chip dédié, mais pas un multiplexeur,la chute du nombre de voix liée à la fréquence d'échantillonnage me fait pencher pour cette solution.