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

[celmo]

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

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

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

[guibson]

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

[Mr.T]

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+

[phhelard]

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

[celmo]

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+

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

[wfplb]

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

[Michel Geiss]

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://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://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 ?

[Stef44]

Salut,

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

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

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

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

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

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

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

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

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

A+

[wfplb]

esque 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+

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

[Michel Geiss]

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