IDE / SCSI / Firewire, Le son n'est pas le même?!! Options

[Francois Déchery]

Mister Celmo ecrivait, dans un autre sujet:

Tiens pour attaquer dans le gras du sujet, apres avoir il y a quelques annees, mis un certain souk en emettant l'"idee" que les logiciels eux memes n'avaient pas tous le meme son( helas et heureusement a la fois), un sujet interessant est a lancer: C'est la difference dans la qualite du son en fonction du disue dur utilisé. Eh oui, Un de nos camarades (canadien pour ne pas le citer) avait remarqué qu'un nouveau disque installe n'avait pas le meme son que celui d'origine. il avait simplement change son disque et c'en est reste la, je crois. mais depuis ce moment, j'ai fait quelques tests, et le resultat est qu'il est evident que le systeme de disques durs utilisé est tres responsable de la qualite du son. par exemple l'IDE (ou le firewire qui en decoule) est cause de degradations en fonction du nombre de pistes utilise. En revanche, le SCSI (cette chierie de skuzzi) , s'il est bien configure, respecte plus facilement le timbre original. Ca vous en bouche pas un coin ca?
helas, a qualite equivalente, le SCSI est toujours beaucoup plus cher. et plus chiatique.
En bref, ce que je voulais aussi dire par la, c'est que les systemes respectant au maximum le son tel qu'il a ete enregistre, et dans n'importe quelles conditions coute toujours tres cher, et que la regle qui fait que pour avoir dix pour cent de mieux on paie souvent dix fois plus est toujours valable.
Bon, le debat est lancé, si ca interesse quelqu'un..

En voila un loup interressant

[Stef44]

Salut,

Hé oui ! Un câble IDE n’est pas du tout parfait pour transmettre les fameux états binaires électriques. Ca aussi, il faut y penser ! 48 pistes en 16 bits à 44 khz, si je ne m’abuse, ça fait un genre de bande passante de pratiquement 34 MHz. Encore plus en 24 bits, bien sûr ! Loin d’être évident à transmettre sur un câble plat IDE ! A de telles fréquences, les fuites électro-magnétiques peuvent perturber ces états binaires et mélanger les crayons !

48 pistes en 16bits 44.1Khz, représente un débit d'environ 4Mo/s, comparé aux 133Mo/s de la dernière norme Ata, c'est ridicule. Si transmettre ces 4Mo/s sur une nappe Ide n'est pas évident, je me demande comment une chaine Ata peut fonctionner, et même comment l'ordinateur peut il rester stable puisque dans les Os moderne, une partie du contenu de la mémoire vive fait régulièrement des aller-retours dans les fichiers de Swap sur les disques durs. Je me demande même si le fonctionnement en streaming modifie quoique ce soit à la facon dont l'intégrité des donnée est préservée par rapport à un fonctionnement "normal".

Mais, les erreurs ne peuvent être reconnues et corrigées que lorsqu’on travaille en mode Ultra DMA.
Mais, dites-moi si je me trompe, sauf erreur (sans jeu de mots !) je ne crois pas que le G4 puisse le faire. Je crois qu’il faut aller dans la gamme des serveurs Apple pour y trouver ce mode, alors qu’il est courant sur Windows.

Dans le cas ou il y aurait un réel problème d'intégrité des données, ca voudrait dire qu'une station audio fonctionnant avec des HD Udma aurait un meilleur son sur un Pc avec Windows !!??
Whouahh !! vous imaginez !!

Si on suit le trajet que parcours nos '0' et '1', ca pourrait ressembler à quelque chose comme ca :
Disque dur -> nappe -> controleur Udma/adaptateur Scsi -> mémoire vive -> traitement par le Cpu -> bus Pci -> Carte audio ->sortie analogique.
Partons du principe que les systèmes de correction d'erreur et de controle de parité font correctement leur travail, sinon on ne s'en sort plus.
Où peuvent eventuellement se créer les erreurs ? A mon avis, je ne vois qu'un endroit : le couple Bus Pci -> Carte audio, et encore, je serait très très étonné qu'il n'y ait pas de vérification, de la même manière qu'il y a un contrôle de parité dans un simple signal Sp/dif. Maintenant, que ce passe-t'il lorsqu'une erreur se produit à ce niveau ?

Je reviens un peu sur ce problème d’erreurs. Quand elles se produisent sans être corrigées, il ne s’agit pas forcément d’informations manquantes et de clics dans l’audio, mais aussi des 0s à la place de 1s, et inversement.

Et bien justement, un 0 à la place d'un 1 dans un échantillon audio modifiera complètement sa valeur et aura de grande chance de provoquer un click, à moins que cette erreur se produise sur les bits de poids les plus faible. Au final, il y a quand même peu de chances que nous n'entendions pas l'erreur.

Pour exemple, j'ai rencontré 2 cas ou le son était réellement modifié :
1) Une carte Solo EX de l'ex-société Seasound qui était légèrement parasité par une carte scsi Adaptec 19160, après remplacement par une Tekram tout allait bien.
2) Un portable Dell Inspiron 8000 avec un système Rme Digiface Pccard couplé à un disque Firewire, lorsqu'était utilisé simultanément les 24 e/s de la carte ainsi qu'une lecture et un enregistrement sur ce même HD firewire, le son contenait plein de petits parasites. C'était du à un problème de bande passante du portable.

Ces 2 exemples montrent qu'il peut se produire une corruption des données sans qu'aucun élément de l'ordinateur nous alerte sur l'erreur.
Je suis presque sur que les cartes audio pourraient, via leur panneau de controle, nous afficher les erreurs de bit, les buffers vides etc... pourquoi personne ne le fait, je n'en sais rien.

A+