Interactions Software/Harware, quels effets sur le son ?
- 113 réponses
- 14 participants
- 6 309 vues
- 25 followers
Phil443
ihbar
Phil443
Bon, alors vu qu'il m'était difficile de résumer tout ce qui s'est passé précédemment dans l'autre thread (un peu long...
), j'apporte quelques précisions que tu soulèves avec pertinence.1/ Il est hors de question de mettre de côté le travail en temps réel. Le débat a été soulevé dans une filière traîtant de pre-mastering. Or chacun sait qu'en la matière, on peut être amené à faire tourner plugs et hardware dédié simultanément. L'informatique se doit par conséquent de pouvoir suivre le reste...
2/ On définira par hypothèse de départ que hard de bonne qualité = PC de marque référenciée (donc reconnue) ou Mac, équipé de périphs internes ou externes un tant soit peu "pros". Mauvais hard = PC acheté en soldes chez Lidl avec périphs grand public ou venant de je-ne-sais-trop-où.
Citation : Si vous voulez être sur de votre coup : faites 2 fois les processing et vérifiez que vous avez bien le même fichier résultat à la fin.
Certains tests cités dans le thread précédent ont accusé des écarts en code machine ou dans le binaire.
Citation : Si le soft est mal concu, le résultat sur des hardware différent peut donner un résultat different.
Sous-entendrais-tu qu'un soft parfait existe ?
Citation : L'utilisation d'un harware dedié evite ce problème a 100% car il n'y a qu'un driver possible !
Là, je pense que l'on se rejoint assez bien.
PS : As-tu pris le temps d'examiner le thread de départ et les documents mis en lien plus haut ?
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
Pov Gabou
Anonyme
Pov Gabou
Anonyme
saimonn
Je suis assez d'accord avec Ihbar.
Je pense qu'on est à peu près tous d'accord sur le fait qu'il est possible d'obtenir des résultats faux avec un hardware X ou Y. Mais pour moi la vraie question c'est : quelle est la probabilité que ça arrive en utilisation réelle (en dehors du labo justement) ? Posée autrement : est-ce que la fréquence des erreurs est propre à alterer le son (de façon pernicieuse) ?
Mais là on est toujours dans des suppositions. Et je me disais que vu qu'il est assez peu probable qu'on réussisse à démontrer logiquement une thèse ou l'autre, il serait peut-être interessant, en parallèle du débat, de mettre ça sur le terrain de l'expérience, pour éventuellement arriver à une démonstration empirique
Ca veut dire qu'il faudrait se mettre d'accord sur une série de calculs (incluant la contrainte temps-réel) et faire un programme qui effectue ces calculs et qui stocke les résultats. On lance tous ça chez nous et sur autant de machines qu'on peut, et on compare.
Je précise que je n'aurais pas le temps de m'y coller
Phil443
Citation : Phil, honnetement, je vois pas trop le lien entre les trucs dont on parle et le probleme present.
Et moi, franchement, je ne vois pas à quoi tu fais allusion...
Citation : Oui, il y a des differences entre differents hardware pour les calculs,
Nous sommes donc d'accord, ce qu'il nous manque, c'est de pouvoir quantifier cette différence et en apprécier les conséquences exactes.
Citation : Maintenant, pour le temps reel: si ca decroche pas,
Voilà : pour moi, un son qui coupe, c'est une affectation notoire de la qualité.
Maintenant, je soumets une pure hypothèse à votre opinion ou expérience :
Admettons qu'un bon hard réalise des calculs en temps réel sur un fichier donné. Tout se passe bien, évidemment, le son en sortie est nickel.
Et on renouvelle l'opération sur une bécane de supermarché. Ce dernier arrive à se démmerder à peu près mais pas tout à fait : il est un peu juste parce que la piètre qualité de ses composants lui fait perdre un peu de vitesse processing alors qu'il aurait besoin de toute sa puissance (une RAM "exotique" peut altérer la vitesse d'un proc, j'espère que l'on est d'accord là dessus sans démonstration...). Au résultat, plein de micro-coupures inaudibles à l'oreille, certes, mais repérables à l'examen du fichier résultant.
Pensez-vous que ce type d'aventure n'est pas de nature à modifier la perception qualitative du son en sortie (impression de dureté, ou de ramollissement, altération de la dynamique etc...).
L'expérience proposée par Saimonn serait intéressante à réaliser dans ce sens, effectivement, mais je n'aurais pas le temps de my coller non-plus, du moins en ce moment...
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
Anonyme
Phil443
Bon, ben on va dire que le fichier est récupéré par une autre bécane : DAT, autre ordi, workstation, balladeur MP3 (
)...NA !!!
Citation : en general, quand ça decroche, c'est maousse, et pas elegant
Ca, c'est bien vrai. Mais au même titre que l'on peut avoir des "chtics" numériques, ne peut-on pas avoir des micro-coupures, de l'ordre de un ou quelques échantillons, ce qui nous fait des trous de 1/44,100° de seconde, difficiles à entendre mais modifiant le signal puisque le rendant incomplet ?
As-tu des infos qui relateraient que les coupures numériques ne peuvent pas être inférieures en temps au seuil audible ?
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
saimonn
saimonn
Phil443
Phil443
Citation : C'est justement ça le truc : Un trou de 1 seul échantillon est parfaitement audible par un petit clic.
Exact, faudrait que je trouve un autre exemple...
Citation : Si tu en as à répétition, c'est insupportable.
Rassure-toi : un, c'est déjà de trop pour moi.
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
saimonn
Pov Gabou
Phil443
Anonyme
Anonyme
Phil443
Citation : Les cds qui sautent, c'est souvent un probleme d'optique plutot que dedonnées corrompues.
Euh ? J'ai un lecteur de salon qui se démmerde comme un manche avec certains CD gravés (c'est pas une histoire de protection...) mais qui est nickel avec les prods du commerce ou les CD gravés en vitesse lente...
Citation : et d'ailleurs c'est souvent les lecteurs les moins exigeants (ou a l'optique la plus mal réglée) qui passent au dessus de certains defauts du support.
Ca arrive, ça, c'est vrai.
Sinon, j'ai eu une carte son qui a flanché y'a pas longtemps. Au début, ça m'a fait planter certains softs (traîtement de textes, navigateur internet...), mais curieusement les logiciels orientés son tournaient tous sans problème !
Puis ça s'est aggravé, l'ordi a fini par refuser de booter, point.
Ce n'est qu'après que j'ai constaté que certains fichiers -sauvegardés alors que ma carte commençait à flancher- ne chargeaient plus, plantaient carrément le soft, ou comportaient des erreurs (style un dessin où les intersections de droites n'étaient plus respectées etc...). Troublant non ?
Citation : Honnetment, je le redis, les erreurs dont on parle ne sont pas significatives en audio. Elles sont 1)tres rares, 2)insignifiante sur le signal
C'est là que subsiste un doute dans mon pauvre esprit torturé, aaargh !
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
Phil443
Citation : mais si tu changes un gain sur une piste de 0.01 db, ton fichier a la sortie est completement different(ou presque),
Nein, achtung : toutes les opérations étaient strictement identiques, des informaticiens de haut niveau se sont occupés des moindres détails pour respecter ce point capital : garanti.
(J'aime bien le "ou presque"...
)Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
Anonyme
Citation :
Nein, achtung : toutes les opérations étaient strictement identiques, des informaticiens de haut niveau se sont occupés des moindres détails pour respecter ce point capital : garanti.
ce que je voulais dire c'est qu'un changement apeine audible modifit le fichier completement, alors deux fichiers presque semblables, y'a de bonnes chances qu'ils sonnent pareils, malgréles quelques bits de difference.
Citation : Ce n'est qu'après que j'ai constaté que certains fichiers -sauvegardés alors que ma carte commençait à flancher- ne chargeaient plus, plantaient carrément le soft, ou comportaient des erreurs (style un dessin où les intersections de droites n'étaient plus respectées etc...). Troublant non ?
hey moi il m'arrive ça je fais venir un exorciste!! le dessin (s'il s'agit d'un format bitmap ou d'un de ses cousin compressé) dont les intersections se deplacent suite a des données corrompues, c'est un peu comme si tu jetais un tas de briques en l'air et qu'elles retombaient en forme de maison...
ihbar
ihbar
La première est interessante pour ce topic, car elle décrit une etude de fiabilité sur un système informatique. Cependant, elle ne nous aide pas énormement : Le sujet est un système de controle critique pour un avion. Forcément, dans ce cas on a besoin du risque 0. On ne peut pas demander la même fiabilité pour un outil de traitement de son. (à moins d'être millionaire et de doubler tout le cablage du studio
)D'autre part, l'exemple de la table 5 montre que le défaut analysé conduit à un plantage/ redémarrage du calculateur ("this will lead to bus exception being raised,followed by orderly shutdown of affected processor."; "Processors remaining in sync. will force orderly shutdown of affected processor"; ....) Donc si on applique cette analyse à notre cas, on aura pour le defaut étudié un plantage du soft et pas une corruption de l'audio.
La deuxieme et la troisième sont moins intéressantes : Elle traitent de la répartition software/hardware flexible de systemes électroniques.
-Deuxième doc : Une modélisation unifiée des traitements à effectuer dans un ensemble hard+soft afin de pouvoir l'implementer avec plus ou moins de parties softwares et hardwares. Intéressant pour la description d'un péripherique de mastering HW, mais pas trop applicable à un PC complet.
- La troisème :
Citation : Les systèmes intégrés sur puce (“Systems-on-Chip”) reconfigurables offrent la possibilité d’accélérer des applications en combinant du logiciel avec des accélérateurs spécifiques implémentés en matériel.
Cette docs est sur le même thème que le précedente, mais traite de la facon dont les accélérateurs matériels peuvent profiter d'un Os virtuel pour avoir acces à des ressources similaires à celle utilisée dans les process software.La quatrième doc est intéressante, mais quelque peu philosophique. (Je conseille de regarder les ppt sur le site indiqué dans la doc, c'est plus digeste). Cette présentation met en évidence la dualité software/hardware, la notion plutot floue de limite entre HW et SW, et la difficultée d'avoir une interface bien definie, structurée, assurant un bon fonctionnement de l'ensemble. Mais cela reste très philosophique et ne va pas nous aider énormement. Au moins, cela confirme qu'on peut débattre longuement de la question !
Finalement, je n'ai pas trouvé de partie très enrichissante pour ce débat, mais j'ai peut-etre raté un chapitre. Si quelqu'un voit un point intéressant, ce serait sympa de préciser la page / chapitre.
J'ai quand même changé d'avis : finalement, les sytèmes dédiés en HW (le cas du calculateur d'avion ou un processeur de mastering) sont aussi affectés par un problème de fiabilité de calcul. Donc la difficultée sera d'évaluer l'écart de fiabilité entre le processeur hardware dedié et le PC.
C'est une histoire de fous ce post !- < Liste des sujets
- Charte