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

[Mr.T]

Alors ça, ça m'trou l'c**, comme dirait l'autre...
Je demande à voir (ou à écouter plutôt)...Après tout c'est jamais que des 0 et des 1 (ceci dit, les convertisseurs aussi mais là tout le monde sait d'où ça vient->bit et KHz). A part la vitesse de transfert, j'ai du mal à croire qu'il y ait une réelle différence...
Je serais curieux de savoir comment le test a été réalisé et éventuellement d'en écouter le résultat.
Plus d'infos?...

[celmo]

bien, l'explication des tests:
sachant que le processeur central gere notamment l'IDE, donc se trouve oblige de bosser pas mal lors des acces disque (voir les vu metres de consommation de processing), lorsque deux ou quatre pistes sont jouees simultanement, la demande n'est pas monstrueuse, mais lorsqu'on demande au logiciel de gerer 64 voire plus (jusqu'a 128 pistes actuellement), le HD sollicite un maximum de processing et le son se comporte un peu comme lors de l'utilisation d'un demultiplexeur gerant plusieurs canaux sur une paire de convertisseurs. Comme c'est un travail effectue (quoi qu'on en dise) en mode série, les informations sont traitees l'une apres l'autre, et tout ce petit monde arrive a se bousculer au portillon.
Si on utilise une machine ultra puissante, ca posera evidemment moins de problemes qu'avec une becane "standard". de la meme maniere, tout ce qui peut aider les differents flux d'information sera bienvenu dans ce cas . genre DSP's divers, cartes acceleratrices de HD, SCSI ou IDE en RAID, etc.

[celmo]

Je continue...
Essayons pour voir, de "passer" un titre avec des sons bien ronds, bien chauds, repartis sur un grand nombre de pistes (enregistrement classique tres soft par exemple) et de provoquer une copie de HD a HD en meme temps, histoire d'enerver un peu le systeme, et vous entendrez certainement le son s'alterer de maniere assez impressionnante, et cela meme si des DSP sont en action.
Les differents logiciels de son ont aussi chacun sa particularite, coté restitution , et pourtant, comme tu le dis, ce ne sont que des 0 et des 1 !!!
mais on a vraiment interet a mettre le maximum de chances de son cote en aidant le processing autant que l'on peut, tout en restant dans la limite du convenable, autant sur le plan de la tune que sur le plan de la compatibilité.( le mieux est l'ennemi du budget, comme celui du bien)

[Mr.T]

Intéressant... Je vais tenter l'expérience... mais comment as tu fais pour réaliser un test fiable?... La copie de disque à disque ne me semble pas super fiable comme procédure ->ça révèlerait plus la différence du taux de transfert->la différence de qualité sonore viendrait donc du taux de transfert + élevé du SCSI?? C'est ce que tu veux dire par là? On aurait donc la même "qualité" sur le disque lui-même, mais c'est au moment de "monter" que le son se dégraderait?...).
Je m'explique...Imaginons que tu enregistre du son sur un disque IDE...ensuite, pour le test, tu copie le tout (session +audiofiles) sur un disque SCSI... ça restera des sons enregistrés sur un disque IDE...donc pas vraiment fiable comme test?... Il me semble que le meilleur moyen de vérifier cette théorie serait:
a: d'enregistrer exactement les mêmes sons deux fois de suite (une fois dans une session crée sur IDE+ une fois dans une session crée sur SCSI)...difficile d'enregistrer deux fois de suite exactement le même son... des sons de synthèse devraient faire l'affaire...
b: d'importer des pistes d'un CD un coup dans une session crée sur IDE, un coup etc etc... et de comparer.
Est ce que ça te parait cohérent? Ou est ce qu'il se fait tard et que je fatigue?...
En tout cas, la théorie est intriguante... C'est vrai que pour moi, jusqu'ici, la différence entre IDE et SCSI se résumait aux meilleures performances liées au taux de transfert (important quand on parle de Direct to Disk).

Définitivement à suivre je dirais...

[Francois Déchery]

Je crois que le probleme qu'évoque Celmo, est explicable par la facon dont le SCSI et l'IDE sont concus..

A ce que j'ai cru comprendre, le SCSI possede un controlleur (l'electronique qui dit a la mecanique "disque dur" quoi faire) qui fait sa vie quand le syteme lui demande d'enregister des fichiers sur le disque...

selon si le programmes est plus ou moins bien fait on arrive a des bon taux de transfert qui ont le merite d'etre stables et prévisibles, si le syteme est correctement configuré (bons cables court, terminaison correcte, drivers, etc...).

L'IDE arrive aussi a des traux de transfert considerable (pour juste 5 a 10 fois moins cher..) qui permettent de mettre plein plein de pistes sur un disque, mais la conception de l'IDE sollicite le processeur pour faire office de controlleur, et dans un souci de vitesse, n'hesite pas a ecrouler le processeur pour etre capable d'encaisser les 20 pistes que vous lui demandez (l'IDE n'a pas etété inventé dans un souci de temps de latence minime pour faire de l'enregistrement audio en temps reel. on lui demande juste d'aller plus vite, pour toujours moins cher)... pendant ce temps, si normalement le processeur devait faire des reverbs, synthe virtuels, etc... il se prend un coup dans la figure qu'il assume de facon desatreuse (forcement) en allant des clics numeriques , changements de sons, juqu'au au tempo digne d'un batteur de 2ans et demi (ce qui est quand meme un comble pour un logiciel de musique), sans vous en avertir le moins du monde.. (l'important c'est que les vumetre du cubatotoolsformer clignotte bien en 3D....)

La ou le SCSI prendra pas un gramme sur le process du disque, et si le programme est un minimum bien fait (honete) , il dira "stop" la j'peux plus'.. c 'est quand meme plus rassurant...

mais effectivement, ca coute VRAIMENT plus cher...pour finalement, une difference que la majorité des gens qui achètent des disques n'entendent sans doute même pas....

tsssssss

le dictaphone j'vous di, ya que ca de vrai!

Pour le firewire j'ai pas eu de feedback serieux.. comme c'est un disque IDE intégré avec un controlleur firewire, si le controlleur est pas trop mal fait, ca pourrais peut etre egaler le SCSI, avec la souplesse en plus, et le prix... mais il est quand meme etonnant de voir qu'aucun fabriquant de DTD serieux ne recommande le FW en disque de travail audio...

technology in progress, sans doute.

[wfplb]

C'est sur que le processing des HD n'y serait sans doute pas pour rien on peut aussi bourrer le CPU avec des plugins RTAZ et une petite image quicktime pour ralentir le rafraichissement

Aussi une chose dont on ne parle plus: l'interruption pour la correction de lecture par rapport à la dilatation du disque

- les constructeurs déclarent maintenant qu'un disque est qualifié AV seulement parcequ'il tourne +vite

J'ai un QPS 120Gig pas ventilé pour de l'image DV qui apres qq semaines intensives fait des caprices douteux: rupture de durite, disparition du desk ! Ce qui pourrait nous ammener à penser qu'un disque chaud peut devenir trop cuit

Aussi les 0 et 1 faut bien les DSProcesser pour les traduires en audio, les tamponner, Si à l'entrée, arrive un hoquet dans le debit, Quid de la synchro Wclock ? Et voila des effluves de Jitter ? qui vont refroidir le beau gros son chaud du musicos atterré

Mais quel rapport entre le debit d'un HD et de l'audio numerique qu'on entend qu'en analogique ?

le couple informatique/numerique ne semble pas si transparent et les emmerdements viennent souvent de l'accumulation de petits hoquets sournois ...

[lepetitmartien]

Il y a des DD "spéciaux audio" (traduisez 'achement plus cher surtout) et firewire… c'est glyph qui les fait. Mais bon côté hardware, c'est le boitier qui a le même look que ton interface audionumérique qui explique le prix.

Dedans ça reste du firewire avec un IDE. Pas que ça coit mauvais, mais bon…

Il y a des systèmes Firewire haut de gamme mais le prix est en conséquence, et ils sont conçus pour le RAID, donc… pas forcément l'audio.

De vrais disques firewire, ben, la puce contolleur n'existe toujours pas, et franchement de ce côté, je désespère un peu. Cela s'arrangera peut-être avec le firewire 2 à 800Mb/s, là ils seront bien obligés d'essayer de dépasser les 50Mb/s théoriques d'une puce oxford qui se trouve dans les disques firewire 1 "rapides"

Et puis tout ça… ce serait pas bon pour le commerce, le SCSI a fait ses économies d'échelle depuis longtemps, alors charger la balance dessus permet des marges confortables. Parce que ce n'est pas une puce reproduite à des millions d'exemplaires qui est si couteuse, non.

Il y a aussi le fait que les disques progressent plus facilement en capacité, qu'en vitesse. Il faut dire qu'avoir des gigas pour mettre les photos de bobonne et du labrador à Palavas, c'est un plus gros marché que ceux qui vivent avec disont… au hasard… le son et l'image… Après tout il existe des solutions (chères) qui marchent, alors pourquoi s'occuper vraiment d'une spec pour une niche marketing ?

Enfin, une chose n'a pas été évoquée ou à demi mot : le traitement interne du soft qui se fait sur 24, 32, 48… bits d'un côté, et certains softs qui vous laissent faire ce que vous voulez (une session avec 456623 pistes audios disont) sans vous dire que bon, le moteur audio tourne mieux avec 16 pistes maxis à gérer dans l'absolu, et que dès qu'on va lancer le dernier VST en plus des 30 pistes qui tournent ça va faire boum !

Et puis dans le moteur audio… faut aussi voir comment il s'arrange avec ses pistes… mais on a déjà coulevé le capot, et on se dit que c'est pas forcément joli-joli là-dedans.

Bon je deviens méchant, faut que j'aille dormir

[bubu from bubula...]

Je suis un peu pantois !

Bien que ne maîtrisant les sciences informatiques que très superficiellement, je suis très sceptique sur la thèse celmo (que je salue au passage).

Autant sur un cd audio, la question se pose, et on pourrait comparer l'influence de tel ou tel CDR et de différents lecteurs, autant en MAO, je ne vois pas comment le disque dur peut exercer une influence quelconque sur le son. Soit ca marche, soit ça ne marche pas. c'est binaire.

Ca me rappelle un preneur de son qui préfèrait le DD1500 au pro tools parce que les disques du DD1500 était meilleurs (?), et que le son était par conséquent meilleur.

- c'est le même qui m'expliquait qu'il changeait de câble de micro selon les comédiens qu'il perchait. mais c'est une autre histoire -

Bon, reprenez-moi si je me trompe :

Si lorsque l'on lit un fichier sur un disque dur, il se glissait des erreurs, ca serait embêtant puisqu'il serait dès lors impossible d'exécuter un programme informatique quelqu'il soit.
En effet, un bit qui change, ca veut dire un programme buggé, qui statistiquement a peu de chance d'arriver à se se lancer.

Ca peut arriver, mais ça arrive excessivement rarement.

Concernant l'audio, un bit qui saute, ca se traduit généralement par un clic numérique (c'est aléatoire). ca s'entend.

Il n'y a pas à ma connaissance de mécanisme de correction d'erreur dans les direct-to-disk ou les sampleurs.

Bref, s'il y a avait des erreurs de lecture ou d'écriture du fichier, on s'en rendrait rapidement compte et on serait tous resté à l'analogique.

Ensuite, concernant le process au sein d'un mixer numérique, il est vrai que chaque soft fait sa propre cuisine. Même s'il n'existe pas 2000 façons de faire des additions, il peut y avoir de réelles différences (nombre de bits en interne, mode d'interpolation...)

Mais à ma connaissance, l'audio est lu en flux tendu. Ca marche ou ca marche pas. Peut importe que Jacques arrive avant paul, du moment que les buffers sont suffisament remplis. Si le mixer jouait au bonto avec les échantillons, ca s'entendrait assez rapidement...

Le fait que le traitement s'effectue en série n'a pas d'incidence : le disque est toujours suffisamment en avance sur le convertisseur pour aller chercher un bout ici et un autre là. c'est l'intérêt du buffer.
En direct to disk, le son n'est jamais vraiment en temps réel. Sinon, on ne pourrait simplement pas faire de multipistes.
Donc que le disque soit mou de la fesse ou rapide comme Zorro, on s'en f…, il faut seulement qu'il soit plus rapide que la musique.
S'il manque des informations, ca fait un trou de son (sur cubase) ou ca ouvre une fenêtre avec un message d'erreur (pro tools).
Mais ca ne s'arrange pas en douce dans le dos du modeste technicien audio.

Bref, que ce soit en provenance d'un disque IDE, SCSI, FireWire ou d'une disquette, si ça marche, ça marche PAREIL !...

Un petit mot concernant les interférences électriques...

Ce sont des 0 et des 1 qui circulent en théorie, mais il ne faut pas oublier que dans le HD ce qui circule c'est du courant électrique et des flux électro-magnétiques, donc suivant la qualité des composants utilisés la façon dont ils sont assemblés, la conception du HD et le mode de transfert des données utilisé bien sûr qu'il peut y avoir au final comme résultat une différence sonore audible d'un HD à l'autre.

Même chose. Pour le processeur, c'est soit 1 soit 0. Soit les interférences entrainent des erreurs, et le disque dur ne marche tout simplement pas, soit elles ne sont pas suffisamment importantes pour changer le 1 en 0, et ça n'a alors AUCUNE incidence sur le son.

Pour finir, le test de Mr T ne me semble pas completement pertinent. En effet, si les 2 fichiers fabriqués à partir du CD sont différents, ca peut provenir de la capture sur le CD et pas nécessairement du type de disque utilisé. ca ne prouve donc rien.

Je vous en soumets un autre qui à mon sens devrait (je l'espère) clore la controverse :

Prenez un fichier audio mono quelconque sur un disque. Copiez le sur un autre disque. Importez les 2 dans protopoulz, en collant un eq digidesign sur chaque piste, et en activant l'inverseur de phase Ø sur l'une des pistes.

Si les fichiers diffèrent ou si ca se bouscule au portillon, on devrait entendre les erreurs. on peut même bouncer pour analyser le son résultant.

je n'ai pas testé mais je prend les paris pour pour un beau fichier de blanc numérique.

Auquel cas, le mythe du "disque dur qui change le son" serait à mettre sur le compte de l'illusion purement psycho-acoustique...

N'oublions pas que le son, c'est comme le sexe,
Ca ne se pratique pas avec les oreilles, mais avec la tête !

(je suis formel)

[Mr.T]

Pour finir, le test de Mr T ne me semble pas completement pertinent. En effet, si les 2 fichiers fabriqués à partir du CD sont différents, ca peut provenir de la capture sur le CD et pas nécessairement du type de disque utilisé. ca ne prouve donc rien.
Je vous en soumets un autre qui à mon sens devrait (je l'espère) clore la controverse :
Prenez un fichier audio mono quelconque sur un disque. Copiez le sur un autre disque. Importez les 2 dans protopoulz, en collant un eq digidesign sur chaque piste, et en activant l'inverseur de phase Ø sur l'une des pistes.
Si les fichiers diffèrent ou si ca se bouscule au portillon, on devrait entendre les erreurs. on peut même bouncer pour analyser le son résultant.

je n'ai pas testé mais je prend les paris pour pour un beau fichier de blanc numérique.

" si les 2 fichiers fabriqués à partir du CD sont différents..."
Je suis pas sûr qu'on se soit bien compris... Il s'agirait d'extraire (via PT par ex.) la MÊME piste d'un MÊME CD, un coup sur IDE, un coup sur SCSI.
Donc les deux fichiers seraient exactement les mêmes (même fichier source, même méthode d'extraction...).Ca pourrais se faire au sein de la même session (pour une comparaison +rapide)->il suffirait de changer (dans PT en tout cas) l'allocation disque (destination) des dites pistes (IDE puis SCSI), ainsi on aurait deux pistes similaires, une que PT irait chercher sur IDE, l'autre sur SCSI.L'inversion de phase pourrait effectivement alors donner une première indication (les deux fichiers résultant sont ils exactement les mêmes?).
Ceci dit mon test "a" me semble plus interessant (son de synthèse, ou CD d'ailleurs, à enregistrer) puisqu'il inclut la procédure d'enregistrement sur disque (en suivant la théorie de Celmo, la dégradation pourrait aussi venir de là... de l'écriture sur le disque...procédure lors de laquelle processeur et autres ressources sont "mises à mal"-> la simple "extraction" est, en général, une procédure plus "légère" puisque le disque est "prévenu" qu'il va devoir bosser et que le tout se fait souvent en deux étapes->extraction puis conversion pour usage dans le soft->en record, on prévient pas et le tout se fait d'un coup...).
J'ai du mal à croire que la dégradation éventuelle du son ne vienne que du taux de transfert en lecture; comme dit plus haut, ça marche ou ça marche pas=>ça produits des erreurs (clics num., trou de son, plantage...) ou pas.
En tout cas, c'est bon de se poser se genre de question...ça fait marcher le cerveau et ça remet un peu en cause des choses qu'on croit acquises...
ça permet aussi de se rendre compte à quel point tout le processus lié au Direct to Disk reste flou et assez insaisissable...Des questions similaires avaient été posées sur le site de Digidesign (De quoi s'occupe exactement la mémoire vive? les processeurs?...); les réponses étaient plus vagues qu'on aurait pu le croire, même quand elles venaient du fabricant lui-même...
Mystique, vous avez dit mystique??...comme c'est mystique...