Printable Version of Topic

Posted by: Soif Wed 17 Jul 2002, 12:06

Mister Celmo ecrivait, dans un autre sujet:

En voila un loup interressant

Posted by: Mr.T Wed 17 Jul 2002, 18:55

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?...

Posted by: celmo Wed 17 Jul 2002, 22:13

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.

Posted by: celmo Wed 17 Jul 2002, 22:21

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)

Posted by: Mr.T Wed 17 Jul 2002, 23:49

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...

Posted by: soif Thu 18 Jul 2002, 02:41

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.

Posted by: wfplb Thu 18 Jul 2002, 02:47

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 ...

Posted by: lepetitmartien Thu 18 Jul 2002, 05:03

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

Posted by: bubu from bubuland Thu 18 Jul 2002, 09:03

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...

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)

Posted by: Mr.T Thu 18 Jul 2002, 09:46

" 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...

Posted by: bubu from bubuland Thu 18 Jul 2002, 10:17

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)

Posted by: Mr.T Thu 18 Jul 2002, 10:32

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...

Posted by: celmo Thu 18 Jul 2002, 10:59

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

Posted by: soif Thu 18 Jul 2002, 12:23

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.

Posted by: Mr.T Thu 18 Jul 2002, 12:50

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...

Posted by: celmo Thu 18 Jul 2002, 17:31

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?

Posted by: Mr.T Thu 18 Jul 2002, 17:55

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+

Posted by: bubu from bubuland Thu 18 Jul 2002, 18:23

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...

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?

Posted by: lepetitmartien Fri 19 Jul 2002, 02:35

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

Posted by: lepetitmartien Fri 19 Jul 2002, 02:36

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

Posted by: celmo Fri 19 Jul 2002, 08:21

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?

Posted by: guibson Fri 19 Jul 2002, 08:48

salut à tous !! je ramene tardivement ma fraise car je suis tres surpris par cette histoire de qualité de son à géométrie variable selons les dd employés. En effet je suis un habitué des échanges de projets entres différents studio-homestudio, essentiellement (mais pas exclusivement) sous D.Performer 3.02; Chez moi c'est de l'EIDE en ATA100 sur carte controleur et je passe souvent sur un system avec Ultra scsi 160 je n'ai jamais rencontré de différences de son d'un systeme à un autre, autant les moteurs audio des programmes sont différents et peuvents notablement changer le son (je pense que c'est un question d'algorythmes) mais jamais les dd ne m'on fait ce genre de choses. Et ce, quelque soit la taille du dit projet

Posted by: Mr.T Fri 19 Jul 2002, 09:56

Salut Guibson, alors comme ça on ramène sa fraise tardivement...c'est pas bien ça! (-; Les avis,comme tu as pu le constater, sont effectivement partagés sur le sujet...ça restera,sans doute, plus ou moins un mystère, tout test restant, à mon avis, discutable...

Celmo, qu'est ce qui t'arrive, t'as reposté exactement le même message qu'hier?...Pendant un moment, j'me serais cru dans ce film ("Un jour sans fin" je crois) où le mec se reveille tous les matins et revit la même chose...flippant...(j'ai même cherché la marmotte pendant un instant...pour ceux qui ont vu le film...).
A+

Posted by: phhelard Fri 19 Jul 2002, 21:26

Bonsoir à toutes et tous

Et le DMA en IDE ? Vous l'avez oublié ? Direct Memory Access permet aux données de ne plus passer par le processeur. Dernirement, j'ai remplacé mon système SCSI U2W par une carte RAID et 4 DD UDMA 100. Je n'y vois qu'une différence ... de prix

Philippe Hélard

Posted by: celmo Sun 21 Jul 2002, 00:46

C'est pas exactement ca. Ca m'est deja arrive aussi.
Ca vient du fait que parfois, on reparte en arriere dans le browser, puis lorsqu'on repart en avant ca recommence le processus.
Dizouli, msiou.


celmo

Posted by: wfplb Sun 21 Jul 2002, 01:48

Non sorry Celmo je parlais à l'époque de copies multiples sur 3324

Le Sujet est difficile à cerner car le probleme est complexe

C'est comme pour la synchro, quand il n'y a que 2 machine il n'y a pas de problemes (la CST l'a démontré! )

Quand il y a un TC pour l'automation d'une console num, des machines num multipistes, des Stations Informatiques, une image sur bi-phase et un Maitre virtuel, du RS422, du Midi du WordCloct, un Black-burst et une ref video, alors là! ca devient une vaste fumisterie !

Pour rapporter ca aux HD il faut regarder le probleme dans son ensemble

La comparaison entre des HD IDE FW et Ultra SCSSI ne peut se faire qu'avec une config suffisement lourde pour faire souffir tout le monde, en d'autres mots, trouver le point de rupture dans une chaine audio est toujours interessante quand on est à la recherche des extrèmes

Depuis qu'on fait du numerique, qu'on lit docs et prospectus, qu'on parle avec les fournisseurs et les techiciens en chef (qui ne parlent pas) et les commerciaux (qui parlent trop), on fini, apres les doutes, par avoir suffisement d'ennuis pour soupconner tout et tous

Un petit doute (je dis ca pour Saint-Thomas Bubu):

Je pense que le son d'un ProTools avec une 888, est different quand il est slave meme avec une ref externe WClock et en superclock
Que ce soit avec une SSL AVENT ou une DFC AMS NEVE (on reste en num)

C'est sans doute pour cette raison (entre autres) que Digi avec son HD sort une interface I/O synch qui se pretend d'une precision au sample pres quand il n'y a pas de vent....(donc la fenetre de l'USD est moins precise ?)

Pour les traitements internes evidement que les calculs sont plus precis quand sur-echantillonne, mais apres il faut revenir sur terre

Digi a deja sorti un DigiDrive FireWire 80 LVE

Je travaille depuis 2 mois avec ce type de disques sur de gros projets
s'il me reste du temps, tenterais qq experimentations fumeuses

Stay tuned fellows

Posted by: Michel Geiss Sun 21 Jul 2002, 11:16

Intéressante, cette discussion. Et tout n’a pas été dit !
D’une part, Celmar, quand tu nous parles de différence de qualité sonore entre différents types de disques durs, il me semble qu’il serait utile de préciser si tu as constaté la chose sur un système totalement natif (comme Logic), ou sur une config DSP (comme PTools TDM). Il me semble qu’il pourrait y avoir une différence sensible.
Cela dit, quand tu parles de différence, je le crois, et la question que tu soulèves est essentielle.
Ceux qui croient que ce n’est pas possible, qu’il n’y a que des 0 et des 1 à transmettre ne savent pas qu’en audio numérique, plein d’autres facteurs interviennent. A commencer par l’intégrité des données. 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 !
En tout cas, sans précautions spéciales, l’intégrité des données n’est pas garantie, malgré ce que certains peuvent penser ! N’oublions pas que notre discussion concerne un mode de fonctionnement assez rare en informatique (en dehors de la vidéo et de l’audio) : le streaming, qui est sujet à certains compromis.
Et la correction d’erreurs, ça existe aussi sur disque dur ! Depuis l’ATA 66, le CRC (Cyclical Redundancy Checking) a été adopté pour ça. Quand une différence entre ce qui est émis et ce qui est reçu est relevée, l’ordinateur peut recevoir un ordre de ralentissement du transfert, et de ré-envoi du paquet de données corrompu. 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. Le simple mode IDE lui-même ne permet pas la correction d’erreurs, alors que le SCSI le fait.
Alors, s’il est confirmé que l’Ultra DMA n’est pas géré par le G4, il reste la possibilité de passer par des cartes dédiées, comme la Sonnet Tempo ATA100
http://nav.440network.com/out.php?mmsc=forums&url=http://www.sonnettech.com/product/tempo_ata100.html
qui non seulement le gère, mais permet aussi de travailler en ATA-100, alors que le Mac est toujours apparemment en ATA-66.
Le formattage du disque peut apparemment jouer aussi un rôle, puisque certains types de softs permettent de gagner de la vitesse, mais en surchargeant le processeur.

Puisqu’il est question de SCSI, le transfert des données étant fait de manière bien plus intelligente, on peut comprendre que le débit soit moins sujet aux erreurs (sans parler de la correction incluse). D’ailleurs, Docteur Celmar, tu ne nous dis pas si tu passes par une carte ATTO en SCSI, ce qui donnerait une grande supériorité à l’IDE, bien sûr. Chez ATTO, ils ont d’ailleurs aussi des solutions intéressantes pour amener les performances des disques ATA au niveau des SCSI. Petite parenthèse : le nouveau SCSI arrive : le Serial Attached SCSI
http://nav.440network.com/out.php?mmsc=forums&url=http://www.serialattachedscsi.com/

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. Par ailleurs, il faudrait bien connaître les logiciels, pour savoir si certains n’intègrent pas leur propre algorithme de correction d’erreurs (ce qui ne m’étonnerait pas). Auquel cas, les déformations de l’audio seraient plus sournoises, puisque corrigées en partie, notamment quand on a un manque de données momentané.

Et pour terminer, je dirais qu’il ne faut pas oublier qu’un ordinateur n’est pas fait pour l’audio. Désolé, mais c’est une vérité à ne pas oublier. C’est seulement en faisant preuve d’une grande ingéniosité que les concepteurs de logiciels et de matériel arrivent à des performances correctes. Normalement, une solution dédiée, une console ou un enregistreur numériques, ça donne plus de certitudes de résultats fiables, puisque le constructeur est garant du bon fonctionnement d’un système fermé et de ses caractéristiques, des convertisseurs au disque dur, en passant par le système interne.
Mais… si on reste raisonnable et qu’on n’en demande pas trop en performances, une bonne config, même native…, c’est sûrement capable de très bien faire.
Un truc au passage (ca va peut-être en énerver quelques uns) : si vous savez que la qualité audio dépend du débit sur les disques durs, vous préférez travailler en 24 bits, au risque de déformations, ou en 16 bits de façon plus sûre ?

Posted by: Stef44 Sun 21 Jul 2002, 17:15

Salut,

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".


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 ?

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+

Posted by: wfplb Mon 22 Jul 2002, 01:31

J'ai peur que le gentil developpeur ne le sache pas tjrs lui-meme
et qu'il a pas envie d'avouer que la Chose est imparfaite
et il sait mieux que tout le monde que l'informatique n'est que du calcul arrondi (donc approximatif)... pas la musique

Posted by: Michel Geiss Mon 22 Jul 2002, 09:31

[QUOTE]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.

Première chose, puisqu'ici, on est sur Macmusic, on parle de l'ATA disponible sur les G4, et pas sur les PCs. Petite précision (je me répète) : il s'agit d'ATA-66 et pas d'ATA-133. Par ailleurs, le débit spécifié par la norme est seulement théorique. Le débit continu qu'on peut obtenir d'un ATA-66 est certainement plus proche de 20 Mo/s que de 66 Mo/s.
Par ailleurs, les fameux 4 Mo/s sont en réalité des mouvements électriques de 34 MBits/s. En effet, un ordinateur, c’est de l’électronique avant d’être de l’informatique. Dans notre contexte de recherche de causes d’erreurs, il me semble donc plus approprié de parler de mouvements électriques que de bytes. En ATA-66, puisqu’on est dans ce cas, les impulsions à transmettre font seulement 30 nanosecondes de largeur ! On voit bien la précision nécessaire pour les capturer au vol (et l’incidence du bruit électrique récupéré par les câbles).
Autre chose : l'accélération des transferts sur les disques IDE a récemment conduit les fabricants à remplacer la nappe précédente à 40 conducteurs par une nappe à 80 conducteurs, les 40 supplémentaires servant à intercaler des masses entre les fils actifs. Ceci pour diminuer au maximum les interférences. Celles-ci ne sont pas pour autant supprimées en totalité. La meilleure preuve, c'est qu'on a estimé nécessaire de rajouter un système de correction d'erreurs.

[QUOTE]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.

Qui peut affirmer que le fonctionnement d'un ordinateur est parfaitement stable ? La corruption de données ou de fichiers, ça existe ! Et de toute façon, ça me semble assez difficile de comparer les accès disques du fonctionnement classique d'un ordinateur, avec le streaming intense d'un système DTD en pleine activité (et qui plus est sur un disque certainement fragmenté).

[QUOTE]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".

En mode IDE standard, les transferts de données entre disque et CPU utilisent un protocole qu’on appelle Programmed Input/Output. Dans ce mode, on impose au CPU d’être très impliqué dans le processus, pour échanger des données entre la RAM et le drive. Le CPU est donc condamné à aller chercher des données et à les déverser dans la mémoire, en permanence et n'importe quand. De plus, le temps nécessaire pour mettre les données dans le cache, de lire chaque bloc de 8 bits avec le CPU, de le retourner vers le cache et de l’envoyer à la bonne adresse ralentit sérieusement les transferts.
En informatique usuelle, l’affaire se passe plutôt bien, puisque le CPU n’a pas grand chose d’autre à faire pendant ces transferts. Mais ça se gâte sérieusement quand on demande à notre machine de tranférer en continu des quantités considérables de données, et de les traiter (plug-ins, sampleurs, etc...). Le CPU est alors obligé de s’occuper simultanément du transfert de données et de leur traitement dans l’application audio elle-même, qui, du coup, se voit amputée d’une part importante de possibilités de processing audio.
Je vois là une autre possibilité de modifications de l’audio, par surcharge du processeur. En effet, il est tout à fait possible que certains algorithmes de logiciels audio incluent une détection de surcharge CPU et produisent malgré tout un son écoutable, mais au prix de certains compromis de qualité.
Un remède possible le DMA (Direct Memory Access), où la responsabilité du transfert de données est sous-traitée à des processus intelligents, qui soulagent substantiellement le processeur.

[QUOTE]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 !!

Whouahh ??
Certes, certes...
Mais même si j'aime travailler avec mon G4, jje ne crois pas qu'on soit ici pour prêcher la supériorité d'une marque, mais plutôt pour chercher des raisons à un phénomène constaté par quelqu'un qui a entendu des différences.

[QUOTE]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.

Ignorer la réalité ne l'empêche pas d'exister... Partir du principe que les systèmes de correction d'erreur font correctement leur travail, c'est ignorer qu'il n'y a peut-être pas de correction ! Si j'ai parlé du lien entre l'Ultra DMA et la correction d'erreurs CRC qui lui est associé, c'est parceque lorsque ce mode n'est pas implémenté dans une machine, la correction d'erreurs en question ne peut pas se faire.

[QUOTE]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

Rappelons que la question posée à l’origine de cette discussion n’est pas de chercher des dysfonctionnements dans le couple Bus PCI/carte audio, mais de se demander pourquoi l’utilisation de 2 types de transferts, IDE ou SCSI, pourrait produire des différences de qualité audio.

[QUOTE]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.

Une affirmation un peu rapide ! L’un des phénomènes perturbateurs en audio numérique s’appelle le jitter. Celui-ci produit des erreurs dans l’échantillonnage des bits, donc dans l’exactitude des informations. Ce n’est pas pour autant qu’on peut distinctement entendre l’effet produit (diminution du rapport signal/bruit, rétrécissement de l’image stéréo…). Et dans mon hypothèse d’erreurs de streaming, on est dans ce type de conditions.

Posted by: phhelard Mon 22 Jul 2002, 21:58

>>> Citation: >>>>>>>>>>>>>>>>>>>>>>>
"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 !"
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Les nappes utilisées en ATA 100 ou 133 sont différentes des nappes IDE ordinaires : elles ont leurs conducteurs doublés chacun par un cable de "masse" qui permet d'éviter les perturbations électro-magnétiques. Elles sont plus dures, et plus chères, et les connecteurs sont dédiés (carte-mère - master - slave)

Cordialement

Posted by: phhelard Mon 22 Jul 2002, 22:01

Oups !
j'ai répondu directement à partir du Digest de ce matin, et je n'ai pas vu la réponse de Michel avant de poster ma contribution

Toutes mes plus plates excuses.

Posted by: Michel Geiss Tue 23 Jul 2002, 09:11

Des plates excuses, c'est fort pour du câble plat !

No problemo Philippe, ton information est juste, donc elle est maintenant 2 fois plus juste

Je me permets d'ajouter une autre info, qui me semble importante aussi. Certains croient qu'entre les disques SCSI et les IDE la qualité n'est pas la même. Ceci est inexact, et c'est même le contraire pour certains modèles. L'IDE est ce qui se vend le plus, et de très loin, ce qui permet des fabrications en plus grande série, facteur de réduction des coûts.
Mais entre un disque SCSI et un IDE à vitesses identiques (genre 7200 tours/minute), la technologie a de fortes chances d'être identique.
Les recherches des fabricants bénéficient aux deux catégories. On ne va pas investir dans des labos spécialisés en drives SCSI, avec un marché aussi restreint !
Ce qui diffère surtout, c'est le mode de transmission des données, et les "controllers".
Là où je voulais en venir, c'est d'une part que si on veut des hautes vitesses de transfert, on pourra en payant le prix fort aller vers des 10 000 ou 15 000 tours/minutes chez SCSI and Co, gérés par une carte ATTO. D'autre part, toujours sur Mac, pour de très bonnes performances, une sécurité de transfert semblable à celle du SCSI et un prix très intéressant, les disques ATA-100 (ou 133) sont vraiment appropriés, du moment qu'ils sont gérés correctement, par exemple avec la carte Sonnet dont je parlais.

Posted by: Stef44 Wed 24 Jul 2002, 00:30

Bonsoir,

Heuu, on s'en fiche qu'il n'y ait que de l'ATA-66 sur un G4, de la même manière qu'il n'y a pas de l'ATA-133 sur tous les Pc. Dans tous les cas on peu ajouter une carte qui sait gérer ces normes, c'est même toi qui en parle. Sinon, les disque dur actuels dépassent assez régulièrement les 40Mo/s (ou 300Mbit/s)

Pour les 30ns de "fenêtre" pour récupérer les informations transmisent sur les nappes, je ne me rends pas trop compte, je ne suis pas un crack de l'électronique. Le simple fait d'imaginer la somme de technologie qu'il y a dans un ordinateur me donne déjà le tournis.
Pour la correction d'erreur, et juste pour info, elle est arrivée avec l'ATA-33 (et en fait partie intégrante) qui date à priori de 1997, à l'époque ou on utilisait encore des nappes 40fils. Ceci pour en arriver au fait que les Macs fonctionnent donc avec le Dma et la correction d'erreur depuis quelques temps déjà.

Je suis tout à fait d'accord, mais les corruptions de fichiers sont quand même assez rares, et on voit courament des ordinateurs "standard" rester en fonctionnement des semaines, des mois entiers sans crash système, ce qui montre bien que ces stations n'ont pas eu d'erreur non récupérables pendant cette période. Alors si je dois avoir un bit d'erreur dans l'audio tous les 6 mois, je pense que je peux vivre avec, il y aura sans doute eu beaucoup plus d'erreur humaine pendant cette période.

Le mode PIO est tout simplement inutilisable (et inutilisé) en audio.

Je suis extrement sceptique la dessus, je n'y crois pas. J'ai posé la question à un développeur de plugins ; ca ne sera pas une réponse universelle mais on aura peut être une idée plus précise.

Je n'ai pas l'impression d'avoir prêché pour une quelconque supériorité, je n'en vois pas l'intérêt.

Alors mes exemples n'étaient pas suffisament clairs ? Ce n'est pas parce que l'utilisation d'un type de transfert ou l'autre pourrait modifier d'une certaine manière le son, que la source du problème est le type de l'interface, et l'exemple de la carte scsi qui parasitait la carte audio le montre plutôt bien. C'est pour cette raison que je cherche à trouver à quel endroit pourrait se produire le phénomène de perte de qualité. Et j'avoue que pour l'instant je ne vois pas trop.

Le jitter qui produit des erreurs dans les bits ? Ce n'est plus du jitter, c'est une erreur. A ma connaissance, le jitter est uniquement une mauvaise stabilité dans le domaine temporel. Dans un ordinateur tout est reclocké sans parler du fait que le seul endroit ou il y a une référence à une horloge audio physique, c'est sur la carte audio, et puis pas mal de convertisseurs ont eux aussi leurs systèmes de reclocking grâce à leurs petits buffers. Du coup la liaison avec le streaming ne tient plus. Mais bon, je ne demande qu'à être contredit, si ca fait avancer le débat.
Mais bon michel, s'il te plait, pas de référence au monde Mac/pc, la discussion est valable pour les 2 plates formes. J'ai l'impression de m'être fait poser une étiquette Pc sur le front et de me faire tirer dessus à vue
En plus je ne me rappelle pas avoir dit si je travaillais sur Pc ou Mac.

Posted by: Stef44 Wed 24 Jul 2002, 00:35

Re bonsoir,

Aller, j'en rajoute un couche (bien plate bien sur)
Les disques Scsi sont effectivement bien souvent basés sur la même mécanique que les disque durs IDE, mais les plateaux sont utilisés sur une plus faible surface. Ah vi, on pert en capacité, mais la chute de débit lorsqu'on se rapproche du centre est moins sensible puisqu'on s'arrête plus tôt. Le débit reste plus constant qu'une mécanique utilisée sur un disque IDE.

A+

Posted by: phhelard Wed 24 Jul 2002, 11:17

J'ai un PC sous Windows 2000 Pro.
Le contrôleur qui gère les ports IDE et la carte RAID est un ... SCSI Adaptec 2930 CU PCI. La carte RAID est classée dans : "périphériques SCSI et RAID".
Ce qui, à mon avis, prouve qu'il y a de moins en moins de différences entre IDE et SCSI. D'ailleurs, c'est plutôt la norme IDE qui a repris les avantages du SCSI à son compte.

Posted by: Michel Geiss Thu 25 Jul 2002, 09:33

Alors, renseignements pris, Docteur Stephane, il semble que le mode PIO tombe en désuétude, et qu'il va être définitivement remplacé par du DMA.
Sur Windows, il a été depuis un moment fortement recommandé d'activer le mode DMA pour faire de l'audio. On dit très peu de choses à ce sujet sur le Mac, et donc on peut admettre qu'on est d'office en DMA.

Hé oui ! Le jitter introduit des erreurs dans l'audio ! Résultat : mauvais échantillons au mauvais ou au bon moment. C'est logique : on peut considérer qu'en sortie de convertisseurs les données numériques sont parfaitement calibrées en timing, et donc qu'une variation de stabilité n'est pas ce qu'on entend, mais la causse de ces erreurs.

Et je me suis aperçu d'une chose qui n'a pas l'air très connue. Sur un G4, il y a 2 bus disques durs : 1 Ultra DMA/66 (ATA-5), et un ATA-3 aux performances plus modestes. Normalement, le disque système est connecté d'emblée sur l'Ultra DMA. Puisqu'il est déconseillé de faire de l'audio sur le disque système, dans ce cas, il est préférable de travailler sur un disque indépendant, en esclave sur celui-ci. Mais l'activité sur le bus est assez intense, à cause des appels fréquents au système. D'où un intérêt à travailler sur l'autre bus, mais puisqu'il est moins performant... J'en reviens donc à mon info sur la carte Sonnet. J'ai vu qu'une carte plus récente que celle que j'avais mentionné est en vente, en ATA-133.

Posted by: Stef44 Fri 26 Jul 2002, 00:17

Hello !

Après avoir pas mal farfouillé sur le net, j'en suis arrivé à cette conclusion :
Lorsqu'on note une perte de précision, de la distortion, un resserement de l'image stéréo, il s'agit du "sampling jitter" qui se produit au niveau du convertisseur numérique analogique, il n'y a pas d'erreur de 0 ou de 1 à ce niveau, juste une imprécision temporelle.
Par contre pour le "transfer jitter", on peut (si le taux est assez élevé) en arriver à des erreurs de transmission du signal numérique, et là, suivant le type de signal transmit, le résultat sera un fichier défectueux, un crash système, un clic dans l'audio...
En résumé, tout dépend de quel jitter on parle.
Pour ceux que ca intéresse, il y a pas mal d'informations sur cette page :
http://nav.440network.com/out.php?mmsc=forums&url=http://www.nanophon.com/audio/
Je n'ai pas encore tout lu, la veille des vacances, ca serait du masochisme
Un petit extrait qui résume assez bien :
Often sampling jitter is confused with data link jitter. They are linked because inappropriate clock recovery circuits are often used for deriving sampling clocks from the interface signal - which will often have relatively high levels of jitter as a result of the information being carried. This data link jitter need not affect the quality of the finally reproduced signal - until it is so large that the data errors are produced - and measurements of data link jitter may not give any clue as to sampling jitter in the associated equipment.

Bref, si on revient au sujet de départ, ca voudrait dire que si un type d'interface donnait un moins bon son qu'une autre, alors c'est qu'elle parasite l'horloge de la carte audio. Ca me parrait assez invraisemblable, il faudrait vraiment appeller Mulder.
Maintenant, on a peut être oublié un élément quelque part.


Huuuuuu !!??? Ils sont bizarre chez Apple.
copier coller de http://nav.440network.com/out.php?mmsc=forums&url=http://www.ivitex.com/faq2.htm
The original ATA specification used a data transfer technique called Programmed Input/Output Mode 0 (usually abbreviated to PIO Mode 0), with a maximum transfer rate of 3.33MB/sec.
Fast ATA drives boosted the maximum transfer rate to 11.1MB/sec using PIO Mode 3 or to 13.3MB/sec using Multiword DMA Mode 1.

ATA-2 added PIO Mode 4 and Multiword DMA Mode 2, which both offer a maximum of 16.6MB/sec.

ATA-3 is essentially an upgraded version of ATA-2 without any boost in transfer rate, except that some ATA-3 drives that also offer Ultra DMA/33, for a 33MB/sec transfer rate.

ATA-4 officially adds Ultra DMA Mode 2, the 33MB/sec mode that underlies Ultra DMA/33 drives.

ATA-5 adds Ultra DMA Modes 4 and 5. Mode 4 boosts the maximum transfer rate to 44.4MB/sec. Mode 5 boosts it to 66.6MB/sec. Drives with Mode 5 are also called Ultra DMA/66 or Ultra ATA/66 drives.

Ce qui voudrait dire que le second port Ide des G4 serait uniquement en 33Mo/s ? Bon 33 Mo/s il faut déjà en avoir besoin.
Une petite chose m'étonne, je n'ai jamais rencontré un controleur Ide qui ne gère qu'un seul canal, ou bien un controleur avec 2 canaux ayant des supports de norme ATA différents entre eux.
Michel, comment en es-tu arrivé à cette conclusion ? Je me demande si le fait que par défaut il y a uniquement un graveur sur cette chaine dans les G4 (fonctionnant très souvent en ATA-3) déclare la chaine comme ATA-3 uniquement alors qu'elle pourrait très bien supporter de l'ATA-5.

Pour en revenir à la suspicion d'algorithmes de moins bonne qualité dans les plugins en cas de surcharge Cpu, http://nav.440network.com/out.php?mmsc=forums&url=http://www.vb-audio.com me dis "pourquoi pas" ; mais une chose me chiffonne : Et le plugin, comment il fait pour savoir qu'il y a une surcharge Dsp ? Si il attend un manque de buffer, c'est déjà trop tard.

A+

Posted by: Michel Geiss Fri 26 Jul 2002, 10:32

C'est sur le site Developer Apple.
Je cite
The Power Mac G4 computer has an Ultra DMA/66 (ATA-5) interface and an ATA-3 interface for internal mass storage and removable media devices. The enclosure includes data and power connectors for the boot drive and a second internal drive on the Ultra DMA/66 interface. It also has a power connector for a third internal drive. The enclosure has data and power connectors for the internal ATAPI DVD-ROM or DVD-RAM drive and an internal ATAPI Zip drive. Those drives are connected to the ATA-3 interface.

The enclosure includes three drive bays for mass storage devices. One bay is occupied by the boot drive. A drive in one of the other bays can be connected to the second drive connector on the Ultra DMA/66 cable assembly or to an optional or user installed third-party PCI controller card. None of the drive bays can be modified to support removable drive bay kits.

The Ultra DMA/66 bus supports PIO Mode 4, DMA Mode 2, and Ultra DMA Mode 2 data transfers. The ATA-3 bus supports PIO Mode 4 and DMA Mode 2 data transfers.

The ATA-3 channel supports two ATA devices. The devices are configured in a ATA Device 0/1 configuration. The ATAPI DVD-ROM and Zip drive, when installed, occupy both device locations on the ATA-3 channel. The ATAPI DVD-ROM is Device 0 (master), and the Zip drive is Device 1 (slave). If the Zip drive is not factory installed in the system, a power and data cable is available for adding a Zip drive to the ATA-3 bus in the Zip drive bay. The device must be device-select jumpered as Device 1 (slave).

J'en déduis que le second bus est surtout destiné aux sauvegardes.

Je constate aussi qu'Apple mentionne sur le port Ultra DMA/66 la compatibilité PIO Mode 4. Je me demande donc s'il faut en déduire que ce mode peut être utilisé actuellement, et dans quelles conditions.


A mon avis, c'est plutôt un travail que doit faire l'application hôte, et non pas le petit ouvrier qu'est le plug-in

Posted by: igor Sat 27 Jul 2002, 12:16

salut,
Pour entendre la difference entre de l'ATA33/66 ou Udma y a pas à dire, vous etes tous BIONIC des oreilles... !



ZgOgOr

Posted by: wfplb Sat 27 Jul 2002, 17:35

Ben à priori non

dans ce cas tout le monde semble jouer à "ni vu ni connu"

Un exemple vécu ces derniers jours (ou nuits)

une automation d' EQ sur un plug relue sur PT en slave eh bien c'est tout autre chose !
J'en suis réduit à ne faire plus que des "audio suites"

Pas le temps de développer une méthode expérimentale pour prouver la chose... Mais à force on devient suspicieux

ça: c'est soit (à priori) un probleme de jitter, soit une incapacité de l'automation à réagir en temps réel, soit qu'il ne faut pas trop nous prendre des vessies pour des lanternes et revenir aux bons vieux pultec en analogique

Le sampling jitter (maintenant qu'on peut préciser ) serait donc bien la source de tous nos maux

Posted by: Michel Geiss Mon 29 Jul 2002, 10:39

Dans ce cas, il faut peut-être mettre en cause le type de synchro. J'ai constaté aussi une différence sensible en synchro externe USD. Dans ce mode, il me semble qu'on fait une conversion de fréquence d'échantillonnage en temps réel, pour rectifier en permanence les écarts de vitesse entre master et slave.
Si cette conversion est d'une qualité... aproximative, on peut effectivement y voir la cause de cette différence.
Autre alternative à l'Audiosuite : peut-être essayer en synchro interne.

Posted by: toby Mon 29 Jul 2002, 14:02

moi, j'ai remarqué quand branchant mon halogène AVANT mon Mac je gagnais 20% de cpu sur un DVerb
dans protools .. et quand mon caht passe dev

Posted by: celmo Mon 29 Jul 2002, 14:57

Ca m'interesse,
C'est quoi comme halogene?
Penses tu qu'en mettant deux halogenes devant le mac, au lieu d'un, ca ferait encore gagner de la puissance?

Bigre, bigre !!

Posted by: celmo Fri 2 Aug 2002, 23:14

Histoire d'en rajouter une petite couche, et apres une petite enquete aupres d'utilisateurs chevronnes, c'est a dire ceux qui utilisent leur systeme pour de gros projets, du genre 40/80 pistes, il s'avere que le Firewire n'a pas l'air de donner toute satisfaction pour l'instant.
Par exemple, l'erreur 9600 rencontree sur les dernieres versions de PT LE a de fortes chances de venir d'une mauvaise adaptation des drivers ou du formatage des disues. J'ai cru comprendre qu'il fallait presque systematiquement virer les drivers autres qu'Apple, et de toute maniere formater les HD uniquement avec l'outil disque dur Apple. Ceci d'une maniere quasi generale, sauf cas tres speciaux.
Donc, les disques firewire ne sembleraient pour l'instant pas etre la panacee qu'on pourrait imaginer.
Ralentissements du systeme, erreurs systeme diverses, etc seraient dus a leur utilisation.
Ceci parait etre la raison pour laquelle Digidesign etudie actuellement un driver specifique a l'utilisation de l'audio en flux constant et eleve.
Oh, et puis, un de ces quatre, ca va etre au point, et on pourra esperer de tres gros debits.
Ne pas perdre de vue neanmoins que le firewire n'autorise pour l'instant , qu'un debit maximum de 400 Kb, c'est a dire environ 50 Mega octets par seconde. Theoriquement tres suffisant pour la majorite des applications , mais s'averant plus "coincable" que ces memes caracteristiques ne le promettent.
La bonne methode pour l'instant resterait de travailler sur le bus principal, en IDE interne, ou sur une carte SCSI si les moyens le permettent.
Et hop, on y retourne.

Posted by: wfplb Tue 6 Aug 2002, 00:44

Et encore une couche

2 Firewire 80 DIGIDRIVE sur gros projets depuis juin... sur 2 Proots = no problemes
Digi ne garantie la chose que sur G4 AGP et 24 pistes simultanées par disque
mais sur un G4 800 semblerait qu'on peut +

Par contre avec d'autres Marques, evidement 911 Oxford aussi, ca peut devenir moins drôle surtout ceux annoncés compatibles qu'on ne peut reformater que sous OSX et pas sous OS9

Posted by: celmo Tue 6 Aug 2002, 00:52

Ca m'interesse a mort...
C'est quoi la parcularite des Digidrive en Firewire?
Passeque avec des firewire "normaux" , et meme des Oxford 911, ca donne l'impression de marcher du feu de dieu, sauf que, a certains moments, ca arrive a coicer pour des conneries, genre on ne peut pas bien bouncer sur le meme disque ou trucs du genre...
Ils auraient mis des controleurs speciaux a eux tout seuls????????
Ou encore y a t'il un driver particulier dont on pourrait faire profiter les autres drives, ou un truc comme ca?


celmo

Posted by: Michel Geiss Tue 6 Aug 2002, 10:31

Il semble que Digidesign n'ait pas de technologie vraiment spécifique pour leurs drives, en dehors du QuietDrive (baisse du niveau de bruit de ventilation).
Ils garantissent le FireWire 80 pour 24 pistes en 24 bits/44.1 kHz, et recommandent d'en utiliser un de plus pour 48 pistes. Il n'est pas question de 96 kHz ou de 192 kHz dans cette info.
Plus péoccupant : je me demande comment ils ont résolu (ou pas) le problème du jitter, inhérent au mode de transmission du FireWire.

As FireWire is a packet-switched bus, there’s no synchronous clock carried along to convey timing. And there are a myriad of sources of jitter within the 1394 transport protocol, the main source being that you have a free-running oscillator in every node on the bus. Says design consultant and engineer Julian Dunn, “The IEEE 1394 format uses asynchronous clocks at each node. The interaction of these clocks with each other and with the sample (word) clock generates jitter.”

Autre citation :
Not all of FireWire is sweetness and light. As with most standards, the IEEE 1394 specification for audio is unfortunately so broad that there are numerous ways to accomplish any particular function. To make matters worse, FireWire audio interfaces often have to contend with ASIO, in all it’s geeky glory. In addition, while stereo audio carriage over 1394 is a no–brainer, multichannel transport is a whole ’nother matter and requires some serious brain baking to control jitter and interchannel delays.

So, while CE (Consumer Electronics) support for FireWire is a speeding juggernaut, the audio community is, not surprisingly, slow to follow.

Une société, Digital Harmony, avait commencé à passer des accords avec des fabricants d'audio pour un principe qui permettait d'éliminer le jitter en FireWire, mais a semble-t-il disparu...
Crest Audio avait même proposé une interface FireWire basée sur ce principe, avec des connections ADAT, mais elle n'a jamais vu le jour.

Pour ma part, je trouve un peu étrange de voir sur le site de Digi, au sujet du FireWire 80 la phrase suivante :

DigiDrive FireWire 80 also frees up a PCI slot (making room for another Pro Tools® card) and provides a fast, inexpensive means for SCSI drive backup.

En lisant entre les lignes, il y a de quoi se demander si le SCSI n'est pas considéré comme préférable au FireWire, qui lui serait pratique pour faire les back-ups.

Posted by: celmo Tue 6 Aug 2002, 13:10

Houlaaaahhh ! Alors la, bravo pour l'informatio, Michel Geiss Pro...
Ceci confirme ce que nos oreilles avaient ressenti avant nous.
Bon, on peut supposer que ca va s'arranger dans l'avenir.
Bravo encore.

celmo

Posted by: wfplb Wed 7 Aug 2002, 02:37

Michel tu nous fais froid dans le bas du dos Je suis ravis, va falloir que je refasse tout le mix !

Un autre petit détail: AVID ne recommande le Firewire que pour le DVCAM et les stations Xpress bas de gamme...

Certains gros utilisateurs en Normandie ont reconverti leurs Disques FW en supports de sauvegarde, sur de gros projets ca peut se discuter !

Mais tout ça ne résoud pas les anomalies de transmission en 48/24bits même en Ultra

Posted by: Michel Geiss Thu 8 Aug 2002, 13:21

Je confirme l'existence de problèmes éventuels de jitter dans une liaison Firewire. Mais sorry... mon post n'était pas complètement en rapport avec le sujet des drives.
Le jitter concerne comme on le sait l'arrivée d'informations au mauvais moment, mais essentiellement par rapport à une horloge.
Ce qui veut dire qu'en AES/EBU, S/PDIF, ADAT ou autre mode de transmission d'audio numérique, en FireWire l'audio risque fort d'être affecté sans précautions particulières au niveau du protocole de communication.
Mais en ce qui concerne le flux d'informations d'un disque dur, et pour rester dans le sujet des différences possibles entre types de disques (ce qui était quand même le sujet d'origine), le problème ne se pose pas de la même façon. Les données sont transmises par paquets, bufferisées, et si le débit est suffisant, il ne devrait pas y avoir de problème dans l'audio.
Il serait malgré tout intéressant de connaître la charge CPU pour la gestion d'un drive FireWire par rapport à celle d'un IDE ou d'un SCSI.

En conclusion, ça m'étonnerait que tu doive refaire ton mix

Posted by: Pc Fan Sun 11 Aug 2002, 04:57

Bonjour

Un Troll

Ide vs SCSI. Je ne vais pas pouvoir m'empécher de répondre.

Je reprends en vrac, je ne cite pas toujours les auteurs.

Bonjour
Il y a 2 types différents de DD qui peuvent se connecter sur du firewire. Les DD classiques fiables "à 100%" et les "DD" AV/C Audio/Video isochrone (temps réel en gros) qui eux du fait de leur caractéristique isochrone sont plus sujets aux erreurs. Quelques infos ici:
http://nav.440network.com/out.php?mmsc=forums&url=http://www.1394ta.com/Download/Technology/Specifications/2000/AVCHDD1.0Final.pdf
Peut-être que Digi fait une norme dérivée de celle-ci mais adapté à l'audio pro histoire de vérouiller la tour d'ivoire comme dit le petit martien.

Les DD Firewire actuels sont les mêmes que ceux des comptables donc vous pouvez y aller tranquille, ils sont parfaitement valables en support de sauvegarde.
Les problèmes de jitter que peuvent rencontrer les interfaces audio, tables de mix, etc... ne viennent pas de là simplement ce n'est pas toujours évident de faire de l'isochrone sur de l'asynchrone.



De l'isochrone sur de l'asynchrone c'est vraiment mal parti. Ca sera toujours un platre sur une jambe de bois. Il faut attendre que la norme évolue, comme rien n'est intégré au 1394b, ce sera au minimum avec le 1394c. Entretemps des techniciens géniaux auront troucés des bisouilles pour améliorer la situation mais la nature des transmissions reste foncdamentalement différente.



Le Sampling Jitter est une erreur induite par l'horloge des convertisseurs. Au lieu d'échantilloner tous les 1/44100s , c'est un coup un peu plus un coup un peu moins.


Qu'il y ai du ATA-3 pour les lecteurs de CD/DVD/Zip est "normal", enfin pas génant.
Pour la compatibilité PIO4 c'est tout à fait normal qu'il soit présent, cela fait partie de la norme ATA5 donc sans compatibilité PIO4 pas d'ATA5.
Cela signifie que les softs (y compris l'OS) peuvent envoyer au choix des commandes PIO ou des commande DMA. C'est surtout pour une histoire de compatibilité des vieux softs et vieux DD, donc le mode DMA est utilisé par tous les softs qui ne demandent pas expréssement du PIO.


Oui sur Windows le mode DMA était désactivable uniquement pour des histoires de compatibilité avec de vieux DD. Encore une fois cela n'empèchait pas un vieux soft d'envoyer des commandes PIO (généralement les softs ne pilotent pas directement les DD, ils font appel a des fonctions du système d'exploitation qui elles utilises le mode DMA ou PIO de façon transparente).


Le SCSI doit être l'un des standards les plus copiés.
Pourquoi réinventer la roue?
Donc actuellement dans l'UDMA on trouve TOUT ce qui existe dans le SCSI (en ce qui concerne les DD/CD/DVD le SCSI est plus flexible) à l'exception de la réorganisation des files d'attentes, ce qui sert uniquement pour l'utilisation intensive des bases de données.
Par contre le protocole RAID n'est pas un protocole ATA c'est un protocole RAID et le RAID vient du SCSI.
Il a été ensuite adapté pour supporter des DD IDE.



C'est surtout une histoire de marché. Les DD SCSI dont le marché haut de gamme. En partie parce que du SCSI tu en mets jusqu'à 16 dans un serveur, en partie pour une histoire d'image (comme les Mac , bon je m'arrête là avec les sujets qui fachent ).
Donc effectivement les dernières technologies ne se retrouvent que sur les DD SCSI. En SCSI on trouve du 15000tr/min à 4,5ms de temps d'accès, sur du IDE c'est 7200tr/min avec 7ms de temps d'accès.
Les petits plateaux sont dus aux vitesses élevées (contraintes mécaniques) et à la recherche de temps d'accès faible. Actuellement d'ailleurs c'est un peu de l'arnaque car la densité de données ne doit pas être tellement différente (pour ne pas dire égale) entre un SCSI 15000 mais 36Go et un UDMA 72000 mais 120Go.


Exactement plus on monte en fréquence plus les signaux sont "affaiblis" et plus les rayonnement sont importants. Le blindage des cables à partir d'une certaine fréquence est tout à fait normal.

Posted by: Pc Fan Sun 11 Aug 2002, 05:44

Cela ne change pas grand chose les normes ATA sont un standard.
http://nav.440network.com/out.php?mmsc=forums&url=http://www.t13.org/project/d1410r3a.pdf
Les 496 pages de normes.


C'est en effet un temps court mais pas critique pour l'électronique moderne. La norme PCI en 66Mhz impose des contraintes non pas de 30ms mais de 3 ms. Là ça devient "chaud". 30ms ça va, il suffit de prendre quelques précautions, ce qui est fait dans les normes.



Pas tout à fait. Il y a des systèmes de correction d'erreurs depuis le PIO0. Par contre les CRC ont étés ajoutés avec le mode Burst. Dans ce mode on envoie une grande quantité de données en une fois. Ce qui est plus beaucoup moins fiable, d'où l'utilisation des CRC.


Il y a pleins d'endroits dans un ordinateur où les données ne sont pas controlés. En mémoire et dans le CPU notamment (à part dans le cas des mémoires ECC pour serveur). Bien sur le taux d'erreur n'est pas nul, mais suffisament faible pour être négligeable. Les systèmes de correction ou de détection d'erruers ne sont nécéssaires que si des erreurs apparaissent à une fréquence génante.





Exactement, la consommation CPU baisse considérablement en UDMA. Mais les sauvegardes DD ne sont pas vraiment soumises aux contraintes temps réel du traitement audio. Tant que le cache n'est pas plein ce n'est pas génant. Les transferts peuvent être différés.


Les DD ne font pas de streaming. Rien dans la norme ATA ne permet de différencier un enregistrement de guitare d'une feuille de calcul.
Il n'existe pas de mode streaming comme l'UDP sur Internet par exemple. Sur un bus électronique il y a des phénomènes équivalents au Jitter (ils ne s'appellent pas comme ça) mais le protocole avec ses divers signaux d'aquiescements par exemple et les erreurs retournés si il n'es pas respecté s'assurent de l'intégrité des données. Cette partie ne pas de problème.

Posted by: Pc Fan Sun 11 Aug 2002, 05:49

[quote=wfplb,Jul 22 2002, 00:31][QUOTE=Stef44,Jul 21 2002, 17:15]
et il sait mieux que tout le monde que l'informatique n'est que du calcul arrondi (donc approximatif)... pas la musique [/quote]
Oui et non. Je préfères erreur quantifiable.
Il se trompe mais il sait de combien. :-)
L'arrondi du numérique n'est pas vraiment génant, il se situe (ou devrait se situer) en dessous du "flou" (du bruit) de l'analogique.
Cela dit le numérique ajoute d'autres erreurs que l'analogique n'a pas.

Posted by: Pc Fan Sun 11 Aug 2002, 05:57

Si il y a aussi une correction d'erreurs sur les CD audio: CIRC (Cross Intervalle Red Solomon). Elle est moins importante que dans les CDROM où là la moindre erreur est catastrophique.

Posted by: Pc Fan Sun 11 Aug 2002, 06:16

Mouais.
Je n'y crois pas trop.
Simple test: Réduit la taille des buffers au maximm et tu entends des craquements "en charge".
Preuve que ce n'est pas lissé comme avec la lecture d'un CDA.

Je ne vois pas trop l'intérêt théorique. Perdre du temps à surveiller des niveaux de partout alors que de toute façon le résultat final sera dégradé. Surtout qu'un crak en bisouillant on le répare avec certainement plus d'intelligence qu'un soft.

D'autre part ce n'est pas pour rien que les softs audio sont équipés de jauge CPU/DD. (Ce sont les seuls softs qui on ce genre de joujoux). Autrement dit on demande à l'utilisateur de surveiller son ordinateur de façon à ne pas risquer un "trop-plein".
Parce que de toute façon si le traitement demande plus de 100% du temps algo où pas l'ordinateur sera incapable d'effectuer le boulot en temps réel.

Actuellement l'ATA est un poil plus gourmand en ressources CPU que le SCSI. Le problème ne vient pas de là (c'est de l'ordre de 1 à 2).
Les 2 standards sont parfaitement surs. Encore une fois il n'y a pas de différences entre la sauvegarde de l'état d'un compte bancaire et l'enregistrement audio (du point de vue DD).

Je ne connais pas tous les logiciels du marché mais ce pour les raisons explicitées plus haut cela me parait improbable (jusqu'à preuve du contraire )

Ce qu'il reste comme possibilité:
Psycologique? pourquoi pas.
Mécanique? DEs problèmes de vibrations du nouveau DD entraineraient un disfonctionnement autre part? Pourquoi pas
Electronique. Des commutations pas trop bien filtrées (un moteur comme celui d'un DD est avant tout un bobinage fortement inductif), possible dans le cadre d'uin dsyfonctionnement du DD ou d'une alim à genoux. Il faudrait mettre un oscilloscope sur l'alim et comparer avec les SCSI.
A distance cela restent des hypothèses.

Posted by: Michel Geiss Sun 11 Aug 2002, 10:52

A ma connaissance, "isochrone" concerne non pas un type de disque, mais un mode de fonctionnement de transmission de données. La norme FireWire comporte ce mode isochrone en plus du mode asynchrone.
En isochrone, une partie de la bande passante de transmission (jusqu'à 80%) peut être réservée au streaming. Cela garantit l'efficacité de transferts à densité d'informations élevée, comme en audio ou en vidéo, un peu comme le fait le DMA.
Ce qu'on appelle habituellement "AV" pour un disque dur concerne spécifiquement les recalibrations thermiques intempestives, qui peuvent se produire pendant un transfert de données critique sur un disque ordinaire.

Posted by: Michel Geiss Sun 11 Aug 2002, 11:06

Comprenons-nous bien ! De même que SCSI est un standard autant que l'ATA, les machines n'ont pas le même type de performances de communication.
Comme je le disais sur l'un de mes posts, sur le g4, c'est de l'ATA-66, ce qui n'est pas la même chose que de l'ATA-100 ou 133 ! Ca fait quand même une différence !

Posted by: Michel Geiss Sun 11 Aug 2002, 11:36

Un disque dur peut stocker des données en bloc, de façon statique et les restituer de la même façon. Exemple : un fichier audio qu'on copie d'un disque vers un autre.
Mais ce même fichier peut être lu (et éventuellement traité) en temps réel, à partir du disque dur, qui à ce moment-là fonctionne en streaming. Il doit débiter en permanence suffisamment d'informations pour faire face à la demande correspondant au nombre de pistes, à la résolution et à la fréquence d'échantillonnage.
C'est pour cette raison que le DMA existe, entre autres.
La feuille de calcul n'a évidemment pas besoin des mêmes performances

Posted by: Pc Fan Mon 12 Aug 2002, 05:36

Désolé d'avoir été aussi confus.
Oui isochrone permet cela. Basiquement c'est une transmission de données asynchrone sur un canal de transmission synchrone. Cela ne garantit pas vraiment un gros débit mais permet de faire passer des données dépendant du temps comme l'audio ou la vidéo.C'est pour cela que ce mode de transmission est utilisé en streaming et non pas pour une histoire de débit.
Le problème avec le firewire c'est qu'il est entièrement asynchrone, l'isochronie n'est qu'une bidouille, alors forcément pour les transmissions isochrones cela pose problème lorsque l'on a besoin d'excellentes performances.
Le DMA c'est autre chose, un bus interne n'a pas vraiment les mêmes contraintes, à commencer par le fait que c'est un bus parallèle (voir post suivant).

J'ai parlé d'isochronie dans le cadre des DD AV/C.
C'est bien particulier ce sont les futurs DD embarqués dans les appareils multimédias, des magéntophones ou des magnétoscopes sous formes de DD. Pour faire cela ces DD n'utilisent plus les commandes PIO, UDMA ou SCSI mais les commandes AV/C. En fonctionnalité c'est très proche d'un lecteur/enregistreur de Mp3. Record, Play, Pause, Stop, Aller à telle position et pour les fonctions avancées faire un catalogue des pistes, créer des marqueurs etc....
Cela permettra par exemple de remplacer les K7 DV des camescopes numériques et de lire directement les enregistrements en branchant le DD sur une TV. Dans ces conditions les communications doivent être isochrones, mais c'est un cas particulier.
J'évoquais la possibilité pour Digidesign de proposer un "standard" équivalent non pas pour du multimiédia grand public mais pour de l'audio pro.



Oui. Mais c'est obsolète tous les HD modernes ce passent de recalibration thermique.

Posted by: Pc Fan Mon 12 Aug 2002, 06:20

Ce n'est pas du streaming c'est du burst (mode rafale).
C'est d'ailleurs aussi utilie pour la copie de fichier que pour la lecture temps réel (voir plus).
DMA signifie Direct Memory Access. Les informations passent du DD à la mémoire sans transiter par le CPU. Le CPU n'a pas a s'en ocucper il donne juste les ordres et va récupérer les données.
Il y a 3 modes DMA. Normal, multiword et burst.
Normal transfère une donnée par commande, multiword un nombre fixe de données par commandes.Il faudra que je vérifies mais je pense que c'est ce mode qui est utilisé en Audio/vidéo.
Le nom mode rafale est image bien ce qu'il se passe.
Tu appuie sur la gachette, ca part à intervalle régulier, jusqu'à ce que tu relaches la gachette à ce moment la commande est finie.
Il n'y a absolument rien d'isochrone là-dedans, ce n'est absolument pas du streaming, tu ne peux pas décider de la vitesse de transmission c'est celle du bus PCI.
Comme "particularité" par rapport à une mitrallette le receveur indique qu'il a bien reçu chaque donnée en envoyant un signal Stobe ce qui permet à l'emmeteur d'envoyer la suivante.Tout ça doit rentrer dans des timings précis, si le strobe tarde trop cela provoque une erreur.
Et 2eme particularité les 2, emmetteurs et récepteurs, peuvent arréter le transfert, dans le cas d'une écriture par exemple, le DD peut arrêter la commande burst parce que son cache est plein donc il n'arrive plus à écrire les données ou le controleur peut stopper cette commande parce que la fin du fichier est atteinte. Le mode burst se ternmine alors et dans le cas d'une interruption par le DD, c'est le controleur UDMA qui lance une nouvelle écriture en burst, une nouvelle commande.

Que ce soit un fichier de tableur (contrainte l'utilisateur qui attend la fin du chargement de sa feuille par exemple) ou un fichier audio en temps réel (j'espère d'ailleurs que tu m'enverras une copie de tes dernières productions, même en streaming ), c'est exactement le même processus.

Posted by: Michel Geiss Mon 12 Aug 2002, 09:00

On n'a peut-être pas la même définition du streaming...
Pour moi, le mot streaming, souvent utilisé en diffusion web, s'utilise aussi dans toutes les applications DTD, où on débite de l'audio en continu, avec un ou des buffers intermédiaires.
S'il faut que je cite un exemple, voici un petit extrait de texte :
Now suppose you have an activity known as "streaming" going on which is pulling lots of data from the drive in real time while the application doing the streaming is simultaneously attempting to process the data as it arrives.
Et puis il y a aussi les définitions de l'ASIO et de l'EASI :
Audio Stream Input Output
Enhanced Audio Streaming Interface

Posted by: Pc Fan Mon 12 Aug 2002, 09:44

C'est un peu ça.
Une application peut faire du streaming mais le DD lui n'en fait pas.
l'ASIO et le EASI sont effectivement des protocoles de streaming, de flux pour parler français, tu ouvres un canal ASIO (ou EASY) et tu peux déverser en continu des données isochrones dedans.

Posted by: Michel Geiss Mon 12 Aug 2002, 09:59

Juste pour revenir un peu sur l'utilisation éventuelle de disques FireWire en DTD, il me semble quand même que c'est loin d'être idéal.
Deux modes peuvent être utilisés pour la transmission des données : le mode isochrone et le mode asynchrone.
En mode isochrone, on envoie beaucoup de données, avec un débit maximum, mais sans possibilité de correction d'erreurs ni de renvoi d'informations mal transmises.
En mode asynchrone, les corrections d'erreurs sont possibles, mais le traffic est bien plus lent.
L'UDMA n'a pas ces inconvénients. Ma conclusion : entre un disque IDE interne et le même monté dans un boîtier FireWire, y compris avec un chip Oxford 911 (visiblement ce qu'il y a de mieux aujourd'hui), en faveur de la version FireWire, je ne vois que l'avantage du disque externe. D'autres avis ?

Posted by: Michel Geiss Mon 12 Aug 2002, 10:17

Excellente contribution ! C'est vrai qu'il est plus approprié de parler de streaming (je dirais plutôt "diffusion en flux continu" que flux tout court) pour un mode d'utilisation des données audio. Dans ce cas, le disque dur est un maillon de la chaîne (quelquefois le maillon faible )
Mais pour moi, en mode DMA, on fait du streaming. Question de définition

Posted by: Pc Fan Mon 12 Aug 2002, 22:46

C'est vrai en plus que l'appli fait du streming mais pas le DD.
Plus précisement entre l'appli et la carte son (+l'éventuel réseau audio-numérique derrière) les communications sont isochrones c'est du streaming.
(c'est valable pour la vidéo aussi).
Entre l'appli et le DD, les communications se font sur un bus asynchrone ce n'est pas du streming.

Ce n'est pas histoire d'ergoter sur le vocabulaire, c'est que la nature et les propriétés de ces modes de communications sont fondamentalement différents.

L'ASIO, l'AES, l'ADAT sont des protocoles de streaming, des vrais isochrones.
Ce que l'on cherche avec un tel protocole c'est que le numérique se comporte "comme" de l'analogique:
En temps réel les données pouvant arriver à n'importe quel moment. Pour faire cela on ouvre un canal de transmission synchrone (on envoit en permanence une horloge) et l'on envoie les données dessus quand elles se présentent.
Cela a plusieurs conséquences. Comme tu l'a dit il est impossible de retransmettre une donnée éronnée. Donc il n'y a aucun accusé de réception de la destination et les les signaux de controle s'appliquent uniquement à la partie synchrone du canal pas aux données.
Il est impossible de multiplexer les canaux plusieurs données pouvant arrivés au même moment. (A cet égard la stéréo de l'AES est "limite").
Une autre implication est qu'étant isochrone tout le monde a le même temps et que les réseaux sont très difficiles à synchroniser. C'est pour cela que l'on emploie des "horloges universelles" comme la WorldClock.
La perte de données informatiques n'est pas génante en tant que telle sur un tel canal. Cela revient toujours a un signal analogique (que ce soit la voix de Florent Pagny ou la température d'un four à pizza), Quand on perd un bit ce qui compte c'est quelle dégradation cela va amener au signal analogique numérisé. Ces liaisons s'étudient exactement comme des liaisons analogiques en Bande Passante, THD, phase et Jitter (au lieu de pleurage et scintillement).
La bufferisation existe parce qu'un ordianteur est actuellement incapable de traiter les données plus rapidement que le "pas de l'horloge".Mais c'est une bufferisation synchrone (une latence constante).

Dans le cas d'un transfert sur le DD c'est toujours un transfert asynchrone. Le problème est là de recopier un paquet de données à travers une liaison le plus rapidement possible. Si on arrive à le faire avec un débit moyen supérieur au débit du flux audio isochrone on peut faire du DtD.
Mais cela reste une liaison asynchrone. A savoir le controleur peut initier une commande à n'importe quel moment mais tout ce qui va se passer lors de la commande obéi à des délais et des actions dont les timings sont entièrement décris par le protocole.
Le moment où les données sont transférés ne dépend pas d'une horloge donc en cas d'erreur les données peuvent être renvoyés ou dans le cas du burst la transmission interrompue et reprise une donnée avant. Il peut dans ces conditions avoir des dialogues controlant le processus (donnée disponible en sortie, donnée reçue, donnée valide etc...). Dans le cas du mode burst si une erruer intervient la commande est stoppé puis reprise à la dernière donnée valide.
Ce qui fait que le taux d'erreur de ce type de liaison est proche de zéro (de l'ordre de 10^-15/-20, 1 sur un milliard de milliard).
Comme ce type de liaison n'est pas dépendante du temps on peut bouncer plus vite que le temps réel chose impossible à travers un asio par exemple.
De même les réseaux sont "faciles" à faire. il n'y a pas besoin d'une horloge globale comme le worldclok.
La bufferisation peut-être énorme et permet de traiter les données quand on a le temps de le faire contrairement à la bufferisation isochrone qui ne permet que de reporter , mettre un délai fixe sur les données.
On peut faire tous les multiplexaages que l'on veut, là encore il suffit que la vitesse de traitement soit suffisante. C'est aussi ce qui explique que le nombre de canaux est limité de façon absolu sur une carte Asio et dépend uniquement des limites de performances de l'ordinateur dans les cas du nombre de pistes sur DD. (Les logiciels imposent certaines limites parfois genre Nuendo 200 pistes).


Voilà pourquoi aussi je dis que de l'isochrone sur du Firewire, entièrement asynchrone, c'est loin d'être gagné.

Par contre tu as raison le Firewire isochrone est plus rapide que le firewire asynchrone, comme tu l'a expliqué parce que les données en erreurs ne sont pas réémises. Je pense que ce n'est pas la raison de l'utilisation de l'isochrone seulement un avantage induit, le but est plutôt l'isochronisme afin de piloter un ampli Hi-fi ou une TV avec des entrées Firewire ou d'interfacer une liaison isochrone comme l'ASIO.

Posted by: Michel Geiss Tue 13 Aug 2002, 10:43

En cherchant des infos sur les disques FireWire, je suis tombé sur un site qui m'a rendu perplexe. Avec un disque identique, visiblement, les vitesses de transfert FireWire sont très différentes, en fonction du type de machine (et de processeur).
Résultats du test : en "Sustained Read" (lecture continue) le G4 533 Bi-Processeur 35.8 MB/s, le Sawtooth G4 500 34.5 MB/s, mais le Powerbook Titanium plafonne à 22.9 MB/s.
En "Sustained Write" (écriture continue) le G4 533 Bi-Processeur 32.9 MB/s, le Sawtooth G4 500 22.1 MB/s, et le Powerbook Titanium 16.4 MB/s seulement ! Du simple au double ! Et la différence est certainement encore bien plus considérable avec les Bi-Processeurs 1 GHz.
Par ailleurs, ce qui est plus inquiétant, c'est qu'en matière de drives, il semble que les performances réelles ne soient pas forcément celles indiquées par le constructeur. Il peut visiblement y avoir des rapports du simple au double en vitesse d'écriture continue sur un modèle identique ! Donc... normalement, quand on achète un drive (ce que je vais faire dans les heures qui viennent), il est conseillé de le tester immédiatement (genre Express Pro Tools "Benchmark Volume"), et d'envisager son retour au magasin en cas de problème.

Posted by: Michel Geiss Sat 24 Aug 2002, 09:53

Autre info qui me semble intéressante. Dans le numéro d'août de SOS, un test est publié sur les performances de disques FireWire en audio. Les tests ont été faits sur Logic et DP3.
On se rend compte qu'entre les 2 softs, la gestion du débit audio est différente. DP3 a tendance à pénaliser les sessions avec de nombreux fichiers audio, alors que Logic semble moins bien optimalisé pour les fichiers longs et ininterrompus. Résultat : un nombre de pistes disponibles en rapport avec le contenu des sessions.
A préciser que les tests en question ont été réalisés sur 2 Macs, un iMac 800 et un iBook 600.
Je constate au passage qu'on a utilisé le FireWire sur des machines qui n'ont pas d'autre option pour des disques supplémentaires. Par ailleurs, les tests ne montrent pas d'avantage significatif de la solution FireWire sur le disque interne, pourtant pas très performant.

Posted by: burns Sun 25 Aug 2002, 19:22

Au fait le jour ou vous trouvez le bon disque dur qui fait vendre 25 million d'albums, j'achete la cargaison

Burns

(Promis, à Noël je commande des oreilles pour entendre les différences entre SCSI,IDE,FW,RAID etc)

Posted by: jeff parent Sat 7 Sep 2002, 07:43

Salut à tous,

Parrallèlement à ce débat, si j'enregistre toutes mes pistes sur des disques durs SCSI (2x18 Go pour un projet 56 pistes) mais que je les stocke après coup sur un disque dur Ide ou FW, je ne risque rien en faisant des allers-retours si j'en crois la discussion. Les fichiers ne sont apparement altérables/affectés qu'à la lecture ?

En allant un peu plus loin, je peux travailler sur mon gros disque IDE tout le temps de l'édition (un percussioniste qui parle à son voisin tout en jouant du triangle !! imaginons ce que je vais découvrir sur 56 pistes:=)

Par la suite, dès que le mixage ou les reports ont lieu, je repasse en SCSI

Caisse zan Panccez ?????????????????

Posted by: wfplb Mon 9 Sep 2002, 01:07

Ben a priori semblerait que c'est une bonne idée
Mais en reflechissant..... : On pourrait se dire que le FW étant asynchrone (je sais c'est du data, pas de l'audio toto )

On pourrait donc se dire que ca pourrait être comme pour un fichier PhotoShop qu'on converti en JPG puis reconverti en PhotoShop
Evidement ça n'a rien a voir et faut pas trop se turlupiner le citron pour sifflet 3 fois

Mais quand même

Donc c'est comme avec un tambour de pluie, vaut mieux le secouer de temps en temps ... On ne sait jamais

Cit: "Quand il n'y a pas de réponse à une question sensée: sortons le jeu de carte des stratégies latérales" Brian ENO.

Posted by: Michel Geiss Mon 9 Sep 2002, 17:58

Heuuuu.... Comme je le disais précédemment, en FireWire, deux modes peuvent être utilisés pour la transmission des données : le mode isochrone et le mode asynchrone. Le mode isochrone ressemble au DMA, mais il ne permet pas la correction d'erreurs.
Cela dit, en fait, l'idée de garder le SCSI pour les opérations audio semble bonne. Sauf que bien sûr tout dépend du standard SCSI en action, de l'interface (ATTO ou pas ATTO), et... du disque dur, évidemment.

Posted by: jeff parent Wed 11 Sep 2002, 07:15

Donc,

Peux t-on imaginer un classement des différentes solutions d'acquisition ?

On veut bien acheter des disques SCSI mais si le fait de les brancher sur le bus "rapide" d'un 9600 n'est pas plus fiable que l'IDE d'un G4 ou si c'est mieux avec une carte Adaptec en SCSI 2 ou ....... ou bien ?!?!?!?!?

Caisse Zan Dite ?!?

Posted by: Michel Geiss Wed 11 Sep 2002, 09:42

Sans prendre trop de risques, sur un G4 je dirais :

1- SCSI rapide avec carte ATTO (toujours)
2- IDE rapide + cache avec carte Sonnet
3- IDE rapide sans carte Tempo Sonnet
4- FireWire avec chip Oxford911
5- Autres (IDE standard, SCSI avec carte ancienne, etc...)

P.S. Maxtor annonce la sortie de drives SCSI 15 000 t/mn, les Atlas 15k.

Posted by: Han Solo Thu 26 Sep 2002, 17:57

Salut tout le monde,
Pourquoi une carte atto serait elle mieux qu´une adaptec en scsi ?

Posted by: Michel Geiss Thu 26 Sep 2002, 22:35

ATTO a une gestion des transferts de données très sophistiquée qui rend ses cartes bien plus performantes en vitesse, notamment grâce à leur technologie "Advanced Data Streaming" et un chip RISC coprocesseur spécial.

Posted by: igor Fri 27 Sep 2002, 09:14

les cartes ATTO semblent subirent qq problemes en ce moment...
en effet, il y a qq patch sur patch notament rev2 vers rev3 à cause de compatibilitée Protoolsienne...

chaque marque possède SON petit truc en plus...

personnelement, mon Adaptec (2940U2) a été reconnue instantanement dans le MAGMA alors que l'ATTO n'a jamais fonctionnée ! pourtant c'est l'ATTO qui est recommandée !!!
bref, mieux vaut tester les deux, si possible et eviter les pièges marketing.

M2euro'S

Posted by: celmo Fri 27 Sep 2002, 10:40

Je crois que tu as raison. Je dirais meme plus, il faudrait avoir les deux, pour etre bien sur. les deux cartes dans un meme Mac.
Et pour etre encore plus sur , il faudrait avoir deux macs identiques, avec deux cartes dans chacun. Comme ca on n'est pas pris au depourvu. Plus deux claviers et deux souris, evidemment, et deux fois aussi le mec devant l'ecran, ah non, les ecrans. Comme ca on est vraiment sur qu'il n'arrive rien de facheux.
Tiens , c'est bizarre... J'entends encore des Shlapp Shlapp...!!
Et je vois encore des cendriers qui se vident tout seuls...
Bizarre... Bizar-zar-zar-zar-zar-zar-zar-zar-zar--- Pfouit
Skusez, je m'etais pris la manche dans le bouton de feedback...

celmo
PS: a part ca, c'est peut etre pour bientot la 3° guerre mondiale, mais on n'a qu'a pas y penser,
non?

Posted by: Mr.T Fri 27 Sep 2002, 11:11

Tant qu'on est dans l'OT, une petite question sur le Firewire (pas si OT que ça finalement). J'ai récemment acquis un Firewire La Cie 120Gb/7200t (330 € !!...) et ait fait un test de performance. Je travaille actuellement à la maison sur un 52 minutes...L'image (QT) pèse plus de 13Go.
Normallement pour la vidéo, j'utilise mes disques SCSI (UWII+carte Adaptec 29160) et ça marche nickel. Là j'avais plus trop de place sur les SCSI (je bosse aussi sur 3 courts métrages en même temps...faut bien s'occuper quand y'a pas d'boulot...). J'ai donc essayé de mettre la vidéo sur le Firewire... Ben j'peux vous dire que j'ai fait en sorte de faire de la place sur les SCSI ! Sautes d'image, dégradation globale de l'image... Le Firewire n'a pas été à la hauteur. Ma question (y'en a une!) est la suivante: y'a t'il un moyen d'augmenter les performances du Firewire (Michel parle de deux modes différents...est ce que ça peut jouer)?
Pour l'instant, j'ai formaté et créé trois partitions via Silverlining et ai ensuite effacé les 3 partitions via le menu spécial de Finder (PT ne supportant pas d'autres drivers sur les disques que ceux du Mac et je pourrais avoir besoin un jour de travailler des sessions PT sur ce Firewire).

J'ai bien conscience que le débit n'est pas le même que sur les SCSI (quoique, j'ai réduit le débit de ceux-ci à cause de problêmes avec PT, toujours lui... réduit à 40 Mb->Ultra II) mais de nombreux monteurs images travaillent pourtant avec du Firewire (quel est le débit des Firewire-IDE, me souviens plus)...
Une idée, une suggestion, un conseil, une insulte, une blague de mauvais goût?...

Posted by: Michel Geiss Fri 27 Sep 2002, 11:22

Les logiciels s'occupent du transfert eux-mêmes (ton image est certainement gérée en mode Isochrone, le plus rapide). Deux facteurs peuvent jouer sur la vitesse : d'abord ton interface FireWire sur le disque dur. Comme l'a dit Celmar depuis longtemps, il vaut mieux éviter tout ce qui n'a pas le fameux chip Oxford911. Et la carte mère a aussi son influence, donc le CPU.
Mais quand on travaille avec de la vidéo, surtout avec une compression réduite, il me semble qu'on devrait mettre la vidéo sur un disque SCSI indépendant et performant.

Posted by: igor Sat 28 Sep 2002, 09:22

celmo dit :
Et pour etre encore plus sur , il faudrait avoir deux macs identiques, avec deux cartes dans chacun. Comme ca on n'est pas pris au depourvu. Plus deux claviers et deux souris, evidemment, et deux fois aussi le mec devant l'ecran, ah non, les ecrans. Comme ca on est vraiment sur qu'il n'arrive rien de facheux.
*************
ben franchement une carte à 3000 balles ça se test !
moi j'hesite pas à demander...
j'aime pas perdre 400euros... enfin je n'en ai pas les moyen personnelement.

Posted by: Mr.T Sat 28 Sep 2002, 10:03

Merci pour la réponse Michel. Mon disque a effectivement le sus-mentionné chip Oxford 911. Je pense donc que je vais tout simplement continuer à gérer la vidéo depuis mes disques SCSI. Je voulais juste m'assurer que je ne passais pas à côté d'un réglage particulier.

Posted by: heral Sat 28 Sep 2002, 10:46

as tu essayé de lire ta video avec FCP ou bien avec Imovie?
y a pas de problemes?
ce que tu demandes à ton mac, c'est de gerer un flux important de données (la video native, c'est quand meme pas leger ) et de gerer ton logiciel (PT?) favori.
c'est pas forcement seulement le firewire qui est à remettre en cause, mais la puissance de nos processeurs/bus pour se deme...der de tout ça .
dans Nuendo , il existe une chose interessante, c'est la gestion de la sortie video (on n'est pas obligé de passer par une appli du style echofire pour router la video vers un ecran PAL)
c'est moins pire.
on ne peut travailler que le montage son, sans aucun VST, avec titanium 400).
si tu veux rester avec de la video quasiment non compressée, comme le dit michel, point d'alternative au Scsi
dans protools , il te reste néanmoins les priorités pour la lecture de la video, mais ça t'as du deja l'essayer.

Posted by: Michel Geiss Sun 29 Sep 2002, 10:45

13 GO pour 52 minutes de film... Sauf erreur, ça fait à peu près 4 MB/s. C'est peut-être quand même un peu gourmand en débit dans l'absolu, surtout quand tu dois gérer beaucoup de pistes audio. Pas seulement pour une question de débit, mais aussi dans le cas où c'est le CPU qui s'occupe de la décompression. Si la résolution suffisait, l'une des solutions serait de réduire le débit à 1 ou 2 MB/s. Celmar a beaucoup d'expérience là-dessus et pourra peut-être nous en dire plus.
L'idéal serait de lire la vidéo avec une interface spécialisée.
Si tu utilises Pro Tools, une option permet de donner la priorité à la lecture du film : "Movie Playback Priority". Si tu la mets sur Medium ou High, tu favorises la vidéo par rapport aux animations écran, genre mouvements de faders.
Par ailleurs quand je parlais d'un disque SCSI séparé, c'est une condition optimale, mais un disque séparé IDE peut aussi faire l'affaire.
Evidemment, il faut éviter de laisser ouvertes toutes les fenêtres non indispensables, ou de laisser actifs extensions inutiles, Appletalk, Partage de Fichiers, etc...

Posted by: Mr.T Sun 29 Sep 2002, 12:35

Encore une fois Michel, merci pour tes réponses. Pas d'inquiétude, ma question ne portait QUE sur le Firewire, les 13(énormes)Go tournent plutôt bien sur mes disques SCSI, je ne rencontre donc pas de problême dans l'absolu et connais effectivement tous les trucs pour faciliter la tâche au CPU (desactiver les moving faders, désactiver le calcul de la taille des dossiers, pas de scrolling pendant le playback, fermer les fenêtres inutiles, réduire l'edit window à sa plus simple expression, etc etc...).
Quant au disque IDE qui "peut aussi faire l'affaire", j'ai déjà tenté l'expérience; ça marche avec de petits formats mais dès qu'on dépasse le 1/4 d'heure, commencent à apparaitre les sempiternelles erreurs "DAE unable to reliably communicate..." ou autres "PCI Bus too Busy" (pas fatales, mais franchement énervantes...).
Pas mécontent d'avoir du SCSI le garçon !...
Et pas mécontent non plus d'avoir opté pour une carte Dual Head AGP (et non PCI), ça ausssi ça aide !

Posted by: Sophia Sun 29 Sep 2002, 19:45

Parfois il est inutile d'aller chercher des résolution formidables, la qualité n'est pas proportionnelle `a la taille du fichier.

Ici un long métrage tient dans 4 ou 5 GO.
Acquisition Aurora fuse. La qualité n'est pas celle du DV, mais de toutes façons je reçois toujours des bandes sortie AVID ou autre, et la qualité n'est dors et déjà pas top.

Le tout tient a merveille dans une session Protools LE, avec en plus les pistes audio des mix éclatés, sur un disque Firewire qui date d'avant 911 et sur G3/350 tuperware.

Et ca marche tellement bien que je ne touche pas a cette configue du tout.

J'ai un copain qui suit le meme principe avec le film en DV.
Powerbook 667, Protools Free, Film sur Firewire 911.
Impec. Mais il ne tourne pas les mix dans PT free ;-)
Sur son G4 400, sous Logic, il y avait des phenomenes tres etrange au niveau des sortties audio ??? et le proc etait a genoux en moins de 2.

Sophia

Posted by: burns Sun 29 Sep 2002, 21:59

Eh ben si tu passes peut etre à cotê de qque chose....En fait j'utilise Director cut 2 pour numériser en dV d'un beta, dans final cut. Le movie créé en DV est envoyé dans protools pour etre bruité,musiqué et tout et tout. Le movie est numérisé et stocké sur un disque Firewire LaCie 120 Go (les derbies). Ce disque n'a qu'une partition. L'audio est lu sur le disque interne du mac (environ une trentaine de pistes).Pour finir le tout est incroyablement fluide, en plus grace à echo fire je visualise le tout sur un moniteur video. franchement je suis épaté du résultat (ne pas oublié de compenser le retard du à la convertion D/A du boitier Director cut, "set movie sync offset" de 28 qtr frame pour ce dernier.)

Voila je n'apporte pas de réponse à ton probleme, désolé, mais peut etre grace à des machines un peu puissante,ça marche grave de chez grave...

Matos utilisé :

G4 933 1Go de ram, protools 24 Mix+, disque externe firewire 120Go laCie

Mr T si tu veux que je check un truc spécifique dans ma configue pour voir si on ala meme chose, n'hésite surtout pas.

à+

Burns

Ps : mes 13 min de video font en gros 2.3 Go en DV, ça commence à faire cette histoire

Posted by: wfplb Mon 2 Dec 2002, 03:17

Voici quelques info, bien que ce n'est pas de l'audio, ca devrait s'y appliquer aussi quand on pense au debit necessaire pour faire du multipistes

FinalCut, OSX, OS9: dernieres versions...

OSX, Capture de fichiers AV sur HD FWire dernier modele, bench tests parfaits, = sur certains fichiers.... pertes de TC ou pertes d'images

Un indice curieux, le parametre "choix de trame" s'affiche comme "inconnu" quand on regarde les info du fichier (apres capture)

Reponse sur le forum FCP = "si l'image vous semble bonne ignorez la chose"

Memes captures sous OS9.2.2 FW .... certains fichiers acceptent de se faire enfin capturer

Meme capture sur un HD Ultra scsi ... Miracle aucun problemes

et bizarrement le "choix de trame" qui était inconnu via FW devient OK mysterieusement reconnu

Je decide d'acheter un IDE ATA100 interne chez mon grossiste préféré, lequel installe beaucoups de reseaux mixtes... Le Dir tech m'informe de problemes de pertes de Data sous OSX avec les buss scsi
(genre ce qu'on a connu avec certaines versions OS7x avant la guerre

Posted by: olafnoise Mon 2 Dec 2002, 09:54

Mr T

J'utilise le même set up que Burns (mix + , echofire, sur 933), et la video sur firewire est absolument nickel (le 911 doit gérer vraiment sans souci les 3.5 M/s du DV.

Est ce que tu renvoies l'image sur un moniteur externe ou sur un écran du Mac?? Sinon, peut être que la surcharge de travail pour l'affichage te ralentit le bouzin

Ølaf

Posted by: dddamiennn Wed 4 Dec 2002, 20:03

LE SON EST IL DONC DIFFERENT SELON LES DSIQUES DURS? UNE PETITE CONCLUSION S'IMPOSE!

Posted by: wfplb Sat 14 Dec 2002, 02:05

C'est en lisant les caracteristiques des nouvelles versions (de soft, de hard etc) qu'on en apprend enfin plus sur les faiblesses des precedentes

par exemple le nouveau protocole FireWire 1394b qui va bientot arriver dans les chaumieres

Tiens donc.... ils ameliorent la detection des erreurs et le temps de latence !!

Posted by: shimone Sat 14 Dec 2002, 12:33

Il est sur que le firewire II va améliorer pas mal de chose, mais il faudra que la machine absorbe les différents flux d'info. D'ou un bus système robuste et rapide. Ce n'est pas innocament qu'apple a des bus pci 64bits sur ces machine et a 66Mhz sur le xserve... Quand on voit les cartes scsi et ide qui sortent. De la donnée dans tout les sens!!! Sans parler des cartes digi... j'veux pas etre à la place du bus
pour en revenir au firewire, la correction d'erreur a été améliorées pour pouvoir supporter des cables plus long et des milieus plus parasité. En effet l'industrie automobile s'interresse de très pret a ce protocole. Un simple petit cable FW pourra transmettre les commandes de feux, le son, la video et meme la direction, les freins. Il y a interet à ce que le protocole soit robuste
Pourvu qu'ils prevoient une prise FW pour connecter mon Titanium G5 avec PT 7 pour piloter rmon futur bolide