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

[bubu from bubula...]

Mr T, je pense avoir compris la manip;

mais celà dépend de la façon dont l'extraction numérique du CD s'effectue.

Un lecteur CD utilise des CRC (correction d'erreur).

C'est à dire que lorsque tu écoutes un CD, il manque des informations. D'ailleurs même au niveau de la fabrication du glass-master, il y a des erreurs (on les compte). Les fabricants estiment que tant qu'en deça d'un certain nombre, c'est pas grave.

Sur les CD audio, s'il il manque des samples, le lecteur interpole les valeur intermédiaires.

Pour faire simple si les valeurs lues sont:
23, 25, erreur, 29 ,31
la puce se dit qu'il est probable que la valeur manquante soit 27, et que de toute façon, ton oreille ne l'entendra pas.

le problème, c'est que plus le trou est important, plus l'interpolation devient n'importe quoi... Ca se traduit pas du bruit.

Je ne sais pas comment fonctionne l'extraction audio à partir d'un CD, mais j'ai remarqué que sur un cd audio en mauvais état, l'extraction peut produire des erreurs (clics), et que 2 extractions successives produisait des erreurs différentes. il semblerait donc que cette étape soit susceptible de produire des résultats différents sur le même cd et le même morceau.

Ce n'est pas le cas lorsque l'on lit un fichier audio ou image ou texte.

D'ailleurs, de la même façon, si la lecture des fichiers s'effectuait dans l'approximation, on aurait des erreurs dans les fichiers images, textes, etc... Ca serait difficile d'utiliser un traitement de texte ou une base de données dans ces conditions !...

Donc, si je disais que ton test ne me paraissait pas pertinent, c'est juste parce que dans l'hypothèse ou l'on relève des différences entre les 2 fichiers extraits du CD, ça pouvait être parceque l'extraction produise des fichiers différents, et ca ne prouvait pas que le SCSI ou l'IDE soit la cause du problème.

Celà dit, je viens de faire l'expérience décrite précédemment, avec mon disque IDE interne et un firewire externe.

Résultat : (roulement de tambour...)


Un fichier de blanc numérique.

AUCUNE DIFFERENCE entre les 2 fichiers.

Champagne !...

Le disque dur n'a aucune incidence sur la qualité du son.

C'est une bonne nouvelle, car ca veut dire que de toute façon que l'on prenne un ultra SCSI de compèt ou un ide pourrave, ca ne change rien.

Je viens de voir sur le site de DIGI qu'ils proposaient des disques durs spéciaux pour l'audio avec le logo Digidesign dessus et tout.

Ce sont peut-être de très bon disques, mais si ca marche aussi avec du firewire de chez pas cher, ca marche PAREIL !...

Comme disait mao tsé toung,
Tordons le coup aux mythes,
elles flinguent nos pulls et c'est pas sympa...
(oui, c'est moyen, mais j'assume)

[Mr.T]

Je viens de voir sur le site de DIGI qu'ils proposaient des disques durs spéciaux pour l'audio avec le logo Digidesign dessus et tout.

Ce sont peut-être de très bon disques, mais si ca marche aussi avec du firewire de chez pas cher, ca marche PAREIL !...

Tu t'rends pas compte de c'que tu dis!!! Y'a le logo de Digidesign dessus!!
Rien qu'ça, ça fait marcher le disque 27 fois mieux qu'un disque IDE et 13,5 fois mieux qu'un disque SCSI d'une autre marque ! Ils mettent un truc spécial dans le plastique utilisé pour le logo... (-;

Pour ce qui est des tests, je laisserais donc tomber la méthode "extraction" et tenterais (quand j'aurais un peu plus de temps) la méthode "son de synthèse" (expandeur, sampleur...) avec mes disques IDE et SCSI...

[celmo]

Chez Digi, ils ne recommandent pas le FireWire, mais le SCSI et pas n'importe lequeL.
Je sais qu'ils sont en train de developper un driver Firewire special pour ProTools.
Pour en revenir aux distorsions dues aux disques, je vous affirme que ce n'est pas une berlue quelconque. Mais il ne faut pas interpreter ca comme "l'IDE est moins bon que le SCSI". Car si on demandait au processeur interne de gerer directement le SCSI je suppose que le probleme serait identique. voire meme pire. Je voulais dire par la quu'il faudrait decharger le Proc central du maximum de taches.
Les anciens systemes de son numerique, lorsqu'ils rencontraient le moindre probleme, provoquaient des coupures brutales dans le son, ou meme seulement des clics. Aujourd'hui ces systemes sont plus malin et interpolent a tout va pour eviter que le son s'arrete (imaginez la tete du client cheri qui a paye son soft plus de mille balles et qui couperait le son !!!). Donc les problemes sont attenues au max. Du VST on en met autant qu'on peut pour pas cher de processur de cartes meres et de HD, et tout ca se traduit pas un Jitter phenomenal du au rattrappage des erreurs dues elles memes aux HD et plugins VST qui mettent le pied sur le tuyau du flux digital.
Tiens, pour aller a l'exterme, essayons pour voir de comparer un Mix en prise classique et acoustique (24 pistes par ex) dont une version serait realisee en natif avec plug ins VST et l'autre avec un "gros systeme"... Et pourtant ce n'est aussi que des zeros et des uns... De plus cette difference de son ne s'entend presque pas sur UNE piste isolee, mais losque toutes les pistes subissent le meme traitement, ca peut devenir horrible.
helas je ne connais pas non plus de solution miracle.
Bon faut que j'y aille. At'ta leure?

celmo

[Francois Déchery]

Je crois que ce que précise bien zelmout dans la discussion de départ, c'est que la difference entre l'IDE et le SCSI ne se passe QUE quand le processeur sait plus ou donner de la tete: ce qui patine c'est pas le boulot que fait le processeur pour gerer le disque (il ne se "trompe" pas). Par contre le logiciel audio qui est deja ras la gueule (plug-ins synthe, pistes...), et qui tout d'un coup se prend un pic de process (non prevu) du au disque dur, reagit, soit mal de facon visible (coupure, stop, clics, etc..) soit, le soft la ou il devrait 'ralentir le tempo' (mais ca la foutrais tres mal) pour pouvoir encaisser le pic qu'il se prend, prefere enbrouiller l'histoire genre: tiens si je degagais un echantillon sur 3 dans le process histoire de respirer, et vas y que t'embrouille avec une interpolation qui rattrape le coup au niveaux de l'ecoute...

Je ne pense pas que le test consistant a mettre une piste en IDE et une autre en SCSI ne demontre la moindre difference.. ca doit etre strictement pareil (avec le meme soft).
Mais par contre, prendre une session multipiste 'propre' enregistree avec un systeme serieux (...), la faire jouer dans un soft natif, en bourrant bien en plug-in synthe etc, et comparer le meme mix (meme plug, meme soft) avec IDE ou SCSI: pour le coup, je me rallie du coté des oreilles de celmo: j'suis sur que le mix final sonne pas pareil, et que du coup, la comparaison des 2 masters hors phase ne donnera pas un blanc numerique.


Le monde du DTD est decidemment trop obscur (pas de caracteristique techniques affichees, revendiquee ou mesurable...) on ne parle que de vitesse de transfert, de processeur , ou de qualité des convertisseurs X ou Y... mais on ne parle jamais de la sauce que fait le soft en interne...
ET pourtant, ca compte!

Les clients (nous) ne jurent que par 'toujours plus' dans la meme machine: l'ordinateur doit faire console numerique, 48 pistes audio, 10 synthes virtuel, et 200 plug-in, alors forcemment, pour que ca marche sur un ordinateur, qui n'a jamais ete concu dans l'optique de faire du traitement temps reel, il faut bien tricher un peu quelque part pour que le client aie plus de trucs qui clignote sur son ecran dans la nouvelle version qu'il vient d'acheter.

[Mr.T]

Tiens, pour aller a l'exterme, essayons pour voir de comparer un Mix en prise classique et acoustique (24 pistes par ex) dont une version serait realisee en natif avec plug ins VST et l'autre avec un "gros systeme"... Et pourtant ce n'est aussi que des zeros et des uns... De plus cette difference de son ne s'entend presque pas sur UNE piste isolee, mais losque toutes les pistes subissent le meme traitement, ca peut devenir horrible.

Ok, ça serait effectivement plus valable avec une session bien chargée...je vois ce que vous voulez dire.
Par contre, Celmo, sur la comparaison entre un systême natif type VST et un "gros" systême (type HD ou TDM), tu oublie quand même un paramètre important: la qualité des convertisseurs! C'est à l'évidence eux qui font le gros de la différence, beaucoup plus que les disques utilisés.
On ne peut pas comparer "d'égal à égal" les convertisseurs d'un systême à moins de 10000 balles à ceux d'un systême à plus de 50000...

[celmo]

e un paramètre important: la qualité des convertisseurs! C'est à l'évidence eux qui font le gros de la différence, beaucoup plus que les disques utilisés.
On ne peut pas comparer "d'égal à égal" les convertisseurs d'un systême à moins de 10000 balles à ceux d'un systême à plus de 50000...

Oui c'est vrai. Mais c'est encore un probleme qui s'ajoute a tout ce dont nous avons parle, puisque ce que j'ai constate se produit lors de l'utilisation de convertisseurs X ou Y (d'ailleurs je n'utilise que tres rarement les convertisseurs, hormis pour le monitoring, car je travaiille presqu'exclusivement en numerique, avec horloge de reference externe)
Encore une fois, je ne critique pas l'utilisation de l'IDE qui est trerriblement pratique et pas cher en general, De plus je deteste (un peu comme tout le monde) le SCSI et ses problemes.
Ce dont je voulais parler c'est surtout de l'utilisation qu'on en fait, en pensant que les deux systemes se valent, ce qui n'est pas le cas, ou du moins pas pour les memes raisons. Ce sont ces raisons d'ordre economique et pratique qui ont fait adopter l'IDE, et non la reference de qualite.
Mais il y a tant d'autres elements dont on n'a pas parle ici qui entrent en ligne de compte dans la qualite du reultat final, et qui sont souvent negliges... !!!

celmo
PS: mais si je me souviens bien, notre ami WFPB nous avait parle de problemes relatifs aux copies successives sur disques durs qui degradaient le son. Je me trompe?

[Mr.T]

Ben oui forcément... Je suis tellement à fond dans l'analogique à la maison (j'me fait déjà assez ch*** à mon goût à configurer les bécanes numériques dans les studios où je bosse: DAT, CD, ßNum, V1, hardware audio, processeur d'effet audionumérique....stoooop!) que j'en était venu à oublier qu'on avait pas besoin des convertisseurs pour toute numérisation... Bon j'me mets un gage à moi-même et te remercie à nouveau pour avoir amené cette discussion qui oscille délicieusement entre le technique, le mystique, le philosophique et...ok j'arrête.
A+

[bubu from bubula...]

je ne demanderais qu'à vous croire, mais si ces fameuses erreurs se produisaient, on devrait pouvoir les détecter par un moyen ou par un autre.

pour l'instant, on reste dans le domaine du mythe, et je suis un cartésien de base.

Il semblerait que même en reproduisant mon test avec le processeur à 80%, je ne pourrais pas vous convaincre

De toute façon, cubase bounce en temps différé, pas en temps réel.

ça permet d'aileurs de fabriquer l'audio d'une séquence en utilisant un synthé qui ne serait pas utilisable en temps réel. On peut ainsi tracker des instruments reaktor à 132 kHZ, avec 80 voix de polyphonie même si en temps réel, la machine ne supporte pas 2 voix de polyphonie à 22KHz.

Je veux bien croire qu'en lecture temps réel, il se passe des approximations olé olé dans cubase. Mais en export, le processeur n'est pas stressé, il fait ça à son rythme...

cette difference de son ne s'entend presque pas sur UNE piste isolee, mais losque toutes les pistes subissent le meme traitement, ca peut devenir horrible (celmo)

Je suis comme saint thomas, mais avec des oreilles. Ces différences, il faut que je les entendent pour admettre qu'elles existent...

j'ai fait aussi le test de recopier un fichier de disque à disque sur une vintaine de générations. en comparant avec l'original: zéro différence.

Celmo, ne pourrais tu pas imaginer un test qui mettrait clairement en évidence ces distortions et petits arrangements avec les samples?

[lepetitmartien]

Mes 2 centimes d'euros d'amateur éclairé au milieu des pros

- Il n'y a pas de correction d'erreur sur les CD audio, en tout cas pas au niveau du CD, contrairement aux CD données (ce qui explique la différence de place dispo), après, dans le lecteur, dans le soft de lecture… et dans le convertisseur N/A qui va abreuver nos beaux amplis à tubes qui luisent et nos belles enceintes BW… ou nos écoutes amplifiées.

- Si Digi fait ses propres salades avec le firewire vu ce qui se prépare avec le moteur audio de X, soit ils estiment qu'Apple est nul pour l'audio, ou ne sais pas faire un driver potable pour un standard qu'il a mis au point et qui vient de racheter la boite qui faisait les meilleurs contrôleurs pour firewire… Soit ils barricadent la tour d'ivoire. Je ne sais pas mais mes intuitions penchent vers la tour d'ivoire…

- Un joli test auquel vous n'avez pas pensé alors qu'il est poil dans le vif du sujet, c'est le comparatif bounce d'export final au rythme du proc qui fait son boulot tranquille, et un enregistrement de la sortie moniteur d'une session de travail. Je crois que ça sera pas joli joli…

- Après on peut faire des comparatif de sessions sur un même audio dans plusieurs softs différents avec des plugins strictement identiques règlés pareils, histoire de voir la qualité des moteurs audio des protaginistes hôtes.

Bon, c'était les 2 centimes du dilettante

vous inquiétez pas ce thread est TRES intéressant

[lepetitmartien]

J'oubliais, si vous comparez en combinant les 2 derniers points, là on se marre !