Mythe ou réalité

160 réponses
21 participants
7 620 vues
23 followers

Anonyme

521397

Sujet de la discussion Posté le 17/10/2007 à 12:03:09

Je lis que Pro Tools sonne et j'en déduis que sa notoriété viens de là. Cependant aujourd'hui il est difficile de comprendre pourquoi Pro Tools sonnerait et pas les autres...tous les séquenceurs actuels fonctionnent en 32 bits et si leurs algorythmes étaient moins performants on peut supposer qu'au fil des versions ils ont rattrapés leur retard.
Alors mythe ou réalité, est ce que Pro Tools sonne mieux que Cubase, Sonar, Ableton, Logic, Digital Performer...
Si vous avez eu un jour l'occasion de comparer, merci de laisser vos impressions sur ce thread :clin:

Afficher le sujet de la discussion

Anonyme

521397

126 Posté le 19/10/2007 à 11:11:44

Citation : Maintenant, en notation flottante, si ton signal est tres faible, la partie exposant fait office de "volume", et tu peux donc garder la precision meme a faible niveau

Il n'y a pas d'acquisition en flottant...le flottant c'est pour le séquenceur...donc le volume et patati patata...(extrapolation = imagination) :clin:

ceci dit les considérations que tu évoques pour l'acquisition sont importantes c'est pour cela qu'il faut surveiller les loupiottes de sa carte son quand il y en a et rester dans la plage indiquée. (le orange pour moi)

Citation : Le choix 32 vs 64 bits, c'est pas tant un probleme de CPU que de memoire: le facteur limitant, et de loin, c'est la memoire qui est trop lente. Et par definition, si tu fais tout en 64 bits, tu divises par deux le debit

Ha bon?? Parce que les séquenceurs éprouvent des problèmes de mémoire pour fonctionner? Je n'ai jamais constaté ou lu quelque part un quelconque problème de traitement du à la mémoire de la machine...ca fait bien longtemps (voir depuis toujours) que les capacités de traitement des machines répondent aux besoins de nos petites oreilles...contrairement à ce que le marketing peut diffuser comme préjugés qui perdurent.
D'ailleurs pour revenir sur l'évocation que j'ai lu quelque part dans ce thread de contraintes "temps réel" pour le développement des séquenceurs d'aujourd'hui et blabla...je voudrais juste rappeler que ni Windows XP, ni OS X, ni Linux, ni Solaris ne sont des systèmes temps réels(multitâche n'est pas temps réel)...On ne fait pas un séquenceur avec des contraintes de temps réels avec un OS qui ne l'est pas.
Hurd est une déclinaison du noyau de Linux temps réel...Pesos est un noyau temps réel utilisé dans l'industrie pour les systèmes embarqués..etc..voilà voilou (faut bien tordre le coup aux idées recues et aux préjugés que le marketing alimente et entretien depuis...bouhhh la nuit des temps) :clin:

karlos73

4273

Squatteur·euse d’AF

Membre depuis 21 ans

127 Posté le 19/10/2007 à 11:37:47

Tiens un truc marrant...comme il y a apparement sur ce thread quelques spécialistes en inginérie informatique et DSP, faudrait vous associer pour programmer un petit player/recorder tout simple avec juste le strict minimum. Ainsi on pourrait tester et verifier les dire de chacun, et savoir si avec un routing basique du son provenant d'un convertos on atteint une qualité d'enregistrement/restitution qui égale les autres softs, un truc qui prend en compte un driver générique type Asio4all... Bon je suis conscient que rien que ça doit demander pas mal de boulot, mais au moins on serait fixé une bonne fois pour toute sur cette affaire de moteur audio.

Anonyme

521397

128 Posté le 19/10/2007 à 11:56:17

Si je pensais que les choses étaient aussi simple que ca...
Le bonhomme qui a développé energyXT utilise des librairies dont il donne la référence...mais utiliser des librairies ce n'est pas tout maitriser...
Tout maitriser cela veut dire développer son propre pilote d'acquisition (admettre que pour le matériel on ne peut rien...parce qu'on peut aussi réaliser un convertisseur analog/digital c'est pas compliqué les circuits existent faut juste les cabler avec quelques précautions quand même..il y a même des kits pédagogiques qui pour quelques euros te permettent de mettre en oeuvre un convertisseur analog/digital et de regarder sur un oscillo le train d'impulsions généré)
Ensuite développer ces propres librairies ou si on a la flemme accéder directement à son pilote grace aux interruptions logicielles (la on fait dans le bas niveau...c'est de l'info indus)
Enfin ca fait un peu de travail quand même....

karlos73

4273

Squatteur·euse d’AF

Membre depuis 21 ans

129 Posté le 19/10/2007 à 12:18:11

Citation : Si je pensais que les choses étaient aussi simple que ca...

Pourtant aux dires de certains router du son est une opération somme toute genérique qui n'induit aucune variation d'un programme a l'autre du moment que ce sont des 0 et des 1 qui transitent sur un princique toujours identique? :clin:

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

130 Posté le 19/10/2007 à 12:24:12

Citation :

Il n'y a pas d'acquisition en flottant...le flottant c'est pour le séquenceur...donc le volume et patati patata...(extrapolation = imagination)

Non mais je sais bien. J'utilise le terme de volume pour bien faire comprendre le truc, mais globalement, chaque fois que tu fais des gains dans ta table de mix virtuelle, c'est bien des changements de niveau, et avec le flottant tu n'as pas besoin de te soucier de mixer des trucs a -60 dB, tu perds rien en precision.

Citation :
Pourtant aux dires de certains router du son est une opération somme toute genérique qui n'induit aucune variation d'un programme a l'autre du moment que ce sont des 0 et des 1 qui transitent sur un princique toujours identique?

L'un n'empeche pas l'autre: les difficultes sont d'une nature purement informatique. Cela dit, c'est pas tres complique, mais ca existe deja tout ca.

Citation :
Bon je suis conscient que rien que ça doit demander pas mal de boulot, mais au moins on serait fixé une bonne fois pour toute sur cette affaire de moteur audio.

C'est trivial, ca existe deja, tu prends tout simplement les exemples fournis avec le kit de dev ASIO. Sous OS X, il y a jack (qui est developpe par le developpeur d'ardour) qui fait se boulot, et un client jack, c'est a peine 100 lignes de code.

karlos73

4273

Squatteur·euse d’AF

Membre depuis 21 ans

131 Posté le 19/10/2007 à 13:06:11

Tu veux dire que l'on peut programmer facilement un routeur audio qui fasse aussi enregistreur et lecteur (Jack c'est juste un routeur), et comme le précise binsou2005, pas en utilisant des librairies toutes prêtes, en faisant comme Jorgen Aase (et d'autres)?

Anonyme

521397

132 Posté le 19/10/2007 à 13:10:12

Citation : Pourtant aux dires de certains router du son est une opération somme toute genérique qui n'induit aucune variation d'un programme a l'autre du moment que ce sont des 0 et des 1 qui transitent sur un princique toujours identique?

En principe sur la chaine que j'ai évoqué rien ne permet de supposer qu'à un moment ou à un autre on perde de l'information...le traitement est déterministe sur cette chaîne (en mettant A en entrée on aura toujours B en sortie). Donc comme le dit Pov Gabou c'est du travail sans plus.
Cependant et lorsque l'on voit la différence de son que produisent les "pilotes" des différents players sous window (à moins que ce ne soit dans la couche supérieure ..soit l'application, c'est plus probable d'ailleurs) on peut en toute paranoia se demander si le pilote que l'on utiliserait n'effectuerait pas un traitement déjà sur les données (filtrage hautes et basses fréquence enfin que sais je)Donc si l'on veut tout contrôler..il faut tout faire.

Citation : Non mais je sais bien. J'utilise le terme de volume pour bien faire comprendre le truc, mais globalement, chaque fois que tu fais des gains dans ta table de mix virtuelle, c'est bien des changements de niveau, et avec le flottant tu n'as pas besoin de te soucier de mixer des trucs a -60 dB, tu perds rien en precision.

Ce n'est pas la représentation d'une valeur (son codage qui pose un problème), on peut créer des types en développement (language C) et si tu veux un développeur peut créer un type Xreal de 128 bits soit 4 double.
Le problème se pose lors des opérations...Quand on fait des opérations avec des valeurs codées sur la taille des registres du processeur il n'y a pas de problème de troncature d'arrondis..etc..dès que la valeur dépasse la taille du registre c'est la que la cuisine interne commence et que tu peux supposer voir ton info sur de long calculs légèrement modifiées.
Aujourd'hui typiquement on fait des acquisitions en 24 bits pour des processeurs dont le "mot" élémentaire (on va dire la valeur élémentaire la plus petite manipulée, à ne pas confondre avec sa traduction littérale en anglais word = 2 bytes soit 16 bits) est 32 ou 64 bits donc on a un peu de marge et d'ailleurs je suppose que ce dimensionnement ne résulte peut être pas d'une donnée économique (prix des convertisseurs) mais peut être aussi de cette considération technique.En électronique un bon système est forcément un système bien dimensionné. Travailler avec des convertisseurs en 32 bits sur un système en 32 bits nous exposerait à des erreurs d'arrondis et de troncature dès les premières opérations ce qui nuirait à la qualité finale.
(si c'est pour se retrouver avec un son de ligne téléphonique à la fin...j'exagère volontairement).
A noter qu'il existe des algorithmes permettant de repousser ces erreurs de troncature vers des décimales ou elles ne sont plus significatives...mais cela implique de faire des tests sur chaque opération et des traitements lourds. (il existe probablement des bibliothèques qui le font)
voila...voilou

karlos73

4273

Squatteur·euse d’AF

Membre depuis 21 ans

133 Posté le 19/10/2007 à 13:20:38

Citation : Cependant et lorsque l'on voit la différence de son que produisent les "pilotes" des différents players sous window (à moins que ce ne soit dans la couche supérieure ..soit l'application, c'est plus probable d'ailleurs) on peut en toute paranoia se demander si le pilote que l'on utiliserait n'effectuerait pas un traitement déjà sur les données (filtrage hautes et basses fréquence enfin que sais je)Donc si l'on veut tout contrôler..il faut tout faire.

Je suis bien content de lire un type qui connais la théorie (a priori ingénieur :clin:

) et qui appréhende les mêmes differences d'acquisition/restitution audio d'un soft a l'autre que l'ignare instinctif (mais qui tente d'être un peut rigoureux) et issue de formation purement artistique que je suis.

Anonyme

521397

134 Posté le 19/10/2007 à 13:28:46

Aux Etats Unis pour enseigner la philosophie il faut faire des études scientifiques avant. On ne conçoit pas que quelqu'un puisse échafauder des démonstrations philosophales de qualité si il n'a pas au préalable structuré sont esprit et développé ses qualités d'analyse dans une formation adéquate.
En France on oppose l'esprit artistique et l'esprit cartésien comme si il était impossible de conjuger les deux...ce qui est indubitablement faux.
Il y a d'ailleurs des graphistes, musiciens, etc dont on ne peut nier la sensibilité artistique et qui s'illustrent aujourd'hui dans des environnements tel le développement logiciel en complet autodidacte et de façon brillante.(je crois que le concepteur de Bryce sort des beaux arts ou arts déco)

SampleHunter

1304

AFicionado·a

Membre depuis 22 ans

135 Posté le 19/10/2007 à 16:12:29

Citation : Aux Etats Unis pour enseigner la philosophie il faut faire des études scientifiques

Oui, bon là ils n'ont pas inventé la poudre ! tout au plus ont-ils lu le Discours de la méthode écrit par un certain Français. De manière universelle, depuis le XVIIème, être Cartesien, c'est justement être philosophe et scientifique. et c'est bien une idée de chez-nous non :D:

?!.

Trop de morceaux de musique finissent trop longtemps après la fin. [Igor Stravinsky]

Anonyme

521397

136 Posté le 19/10/2007 à 16:24:31

Une idée qui n'est plus d'actualité il me semble...
Tu as fait ta philo en fac de sciences toi? :clin:

Mais on s'éloigne du sujet...tu as Pro Tools?

SampleHunter

1304

AFicionado·a

Membre depuis 22 ans

137 Posté le 19/10/2007 à 17:18:04

Non, j'nai pas protools, mais j'ai essayé un temps, la version PC qui tournait sur Windows 98.

C'était pas extraordinaire, mais à l'époque Protools et surtout ces DSP faisaient réver parceque nos modestes bécannes étaient incapable d'encaisser de gros calculs, les premiers VST n'arrivaient pas à la cheville des Waves TDM.

Evidemment, depuis, l'eau a coulé sous les ponts. La plupart des plugins reservés hier aux plateforme DSP tournent maintenant en natif sur un pauvre portable de bureau (je viens d'essayer l'EQ Oxford de Sony, un délice ).

C'est pourquoi je reste surpris devant tant de phantasme autour du logiciel Protools.

En revanche leur surface de control, c'est autre chose. J'ai une petite bcf2000 et je la trouve déjà remarquable mais l'Icon, là c'est autre chose. Il y a une vrai différence.

Trop de morceaux de musique finissent trop longtemps après la fin. [Igor Stravinsky]

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

138 Posté le 20/10/2007 à 12:48:33

Citation :
Cependant et lorsque l'on voit la différence de son que produisent les "pilotes" des différents players sous window (à moins que ce ne soit dans la couche supérieure ..soit l'application, c'est plus probable d'ailleurs) on peut en toute paranoia se demander si le pilote que l'on utiliserait n'effectuerait pas un traitement déjà sur les données (filtrage hautes et basses fréquence enfin que sais je)Donc si l'on veut tout contrôler..il faut tout faire.

Je pense peu probable que pour des drivers "pro", on fasse un traitement. De plus, faire des traitements dans les drivers, c'est un peu suicidaire je pense (sous linux, par exemple, utiliser la FPU, c'est niet dans le kernel). Apres, la couche au dessus (qui a souvent tendance a faire partie du driver sous windows il est vrai, mais bon, windows n'est pas un exemple de design fantastique en general, pour le son en particulier) peut faire des traitements, mais c'est justement ce que tu veux eviter, et ce pour quoi ASIO existe (enfin, une des raisons).

Citation :
Ce n'est pas la représentation d'une valeur (son codage qui pose un problème), on peut créer des types en développement (language C) et si tu veux un développeur peut créer un type Xreal de 128 bits soit 4 double.

En general, un double, c'est 64 bits. Et en C, tu peux justement pas creer de types (c'est une difference fondamentale avec le C++; d'ailleurs, meme le C++, tu peux pas vraiment faire de types, mais je m'egare). Et ton type Xreal, c'est ultra galere a gerer, puisque tu dois faire en soft ce qui est normalement fait en hardware (imagine emuler des double avec des float...). Il y a des librairies pour ca, mais c'est jamais utilise en audio, je pense (le temps de calcul serait au moins multiplie par 10, je pense, voire plus, comme au temps des 486 SX qui emulaient les flottants en soft).

Bref, ce que je voulais dire dans le passage que tu citais, c'est que ca n'a aucun sens de comparer les bits entre deux representations differentes: dire que 48 bits chez pro tools (il m'a toujours semble que c'etait du 24, d'ailleurs ?) c'est mieux que le 32 bits des PC, ca ne veut strictement rien dire. En fixe, la precision effective depend du niveau absolu de tes valeurs, alors qu'en flottant, non.

Citation :
Tu veux dire que l'on peut programmer facilement un routeur audio qui fasse aussi enregistreur et lecteur (Jack c'est juste un routeur),

Non, jack, c'est tres balaise, ca resoud justement une partie des problemes que les systemes sous windows/mac resolvent a l'aide du "moteur audio" (synchronisation, etc...). Par contre, un programme qui est au dessus de jack, et qui dump le son qui lui arrive dans un fichier (disons fichier wav), c'est 200 lignes de code a tout casser (c'est d'ailleurs un des exemples fourni dans la doc developpeur de jack).

Le truc fondamental, c'est comme dit d'agir au niveau le plus haut qui soit commun aux deux softs qui sont compares. Donc par exemple si tu veux comparer 2 softs qui utilisent tous les deux asio (plutot courant), alors tu peux faire un petit truc qui lui aussi utilise asio.

Anonyme

521397

139 Posté le 23/11/2007 à 18:31:59

J'aimerais bien savoir qui c'est déjà permis de supprimer ce message. J'ai créé ce thread et j'entends bien ne pas laisser dire n'importe quoi dessus...Si vous voulez censurer quelqu'un...et bien censurez les mythomanes qui sévissent sur AF et répandent gratuitement la polémique.

Allez fini les gamineries...VADE RETRO MYTHO :clin:

Citation : Je pense peu probable que pour des drivers "pro", on fasse un traitement

C'est tout l'inverse..les drivers pro comme tu le dis s'entendent pour du matériel dédié que l'on trouve sur du matériel de studio haut de gamme (pyramix..etc) et au contraire question pilote..il serait logique de penser que tout y est permis, y compris de ne respecter aucun protocole standard. Avec un matériel propriétaire et sans souci de compatibilité on fait des pilotes...propriétaires..logique non?

Citation : De plus, faire des traitements dans les drivers, c'est un peu suicidaire je pense (sous linux, par exemple, utiliser la FPU, c'est niet dans le kernel)

Ha bon?? De mieux en mieux...Suivant les vieux principes utilisés en informatique (les mêmes depuis 30 ans) on utilise la FPU (unité de calcul flottante) à travers des instructions spécifiques envoyées au processeur et non directement.Celui-ci les dispatch vers la FPU. Quoi de plus logique encore une fois. Ensuite cela voudrait dire que dans le noyau on ne peut utiliser certaines instructions du processeur..ce qui est bien évidemment le contraire, le noyau représentant un environnement d'exécution possédant justement tous les "privilèges".

Citation : Apres, la couche au dessus (qui a souvent tendance a faire partie du driver sous windows

Aucune couche ne fait partie d'un driver..ce serait plutot l'inverse...voir le modèle OSI ici comme exemple de décomposition en couches pour les applicatifs réseau :
http://www.frameip.com/osi/

Citation : windows n'est pas un exemple de design fantastique en general, pour le son en particulier) peut faire des traitements, mais c'est justement ce que tu veux eviter, et ce pour quoi ASIO existe (enfin, une des raisons).

Qu'est ce que tu en sais..tu n'as manifestement pas les compétences requises.

Citation : En general, un double, c'est 64 bits

C'est vrai si on se base sur une plateforme 32bits..sur une plateforme 16bits c'est 32bits, 64bits ->128, etc. Donc tout va dépendre de la plateforme (du processeur). Il n'y a pas d'en général.

Citation : Et en C, tu peux justement pas creer de types (c'est une difference fondamentale avec le C++; d'ailleurs, meme le C++, tu peux pas vraiment faire de types

C'est faux et tu ne connais manifestement ni le language C ni le C++. La primitive "typedef" permet de définir un type particulier..soit en renommant un type existant soit en définissant un type struct..voir ci-dessous pour plus de précisions :
http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C/node115.html
http://c.developpez.com/faq/?page=types

Citation : Et ton type Xreal, c'est ultra galere a gerer, puisque tu dois faire en soft ce qui est normalement fait en hardware (imagine emuler des double avec des float...). Il y a des librairies pour ca

Evidement il faut un certain niveau pour cela..Quand aux librairies ce n'est pas Jésus qui les à fait..heureusement d'ailleurs.

Citation : mais c'est jamais utilise en audio, je pense (le temps de calcul serait au moins multiplie par 10, je pense

Ha bon?? Comment tu peux savoir cela?? Un calcul multiplié par 10?.comme ca de tête...étant donné le nombre d'âneries que tu distilles lol :mdr:

Citation : Bref, ce que je voulais dire dans le passage que tu citais, c'est que ca n'a aucun sens de comparer les bits entre deux représentations différentes: dire que 48 bits chez pro tools (il m'a toujours semble que c'etait du 24, d'ailleurs ?) c'est mieux que le 32 bits des PC, ca ne veut strictement rien dire.

D'ou tu sors cela? Je n'ai jamais fait ce type de rapprochement. :oo:

Citation : En fixe, la precision effective depend du niveau absolu de tes valeurs, alors qu'en flottant, non.

Ca n'a aucun sens.Tu ne sais pas ce qu'est un nombre flottant et sa représentation dans un système informatique..comme le confirme un de tes premiers post ci-dessous.

Citation : Non, non, c'est tout en 32 bits flottant. Faut vraiment bien faire la différence entre flottant et fixe, ca ne veut rien dire de comparer les bits comme ca, sinon. Un nombre 32 bits flottant, c'est un bit de signe, 23 de precision (mantisse en termes savants) et 8 bits pour le "niveau" (exposant).

En partie faux. Dans ton argumentation tu parles de niveaux et il semblerait que tu penses qu'un flottant code une valeur fixe. Tu écris d'ailleurs que l'exposant code le "niveau". Je ne sais pas d'ou viens ce niveau. Un nombre flottant est avant tout et simplement un nombre à virgule. L'exposant code comme sur ta machine à calculer l'emplacement de la virgule, voir ici pour les détails de la repésentation de nombres (nombre à virgule) en langage C :
http://www.commentcamarche.net/c/ctype.php3

Citation : Maintenant, en notation flottante, si ton signal est très faible, la partie exposant fait office de "volume", et tu peux donc garder la précision meme a faible niveau (dans une certaine mesure, évidemment). C'est pour ca que sur PC, on utilise presque toujours du flottant

Relier une notation en virgule flottante et un signal n'a aucun sens. Le convertisseur converti le signal en présence en une valeur entière codée sur 8,10,20 bits qui sera ensuite reprise par le système informatique dans une variable propre au langage(nombre flottant). Donc aucune relation entre le signal et le codage informatique. Que ton signal soit fort ou faible..le programme derrière se chargera de récupérer la valeur délivrée par le convertisseur sans plus. Encore une fois tu parles de volume...On utilise des nombres flottants tout simplement parce que les calculs génèrent des nombres à virgule.

Citation : Par contre, un programme qui est au dessus de jack, et qui dump le son qui lui arrive dans un fichier (disons fichier wav), c'est 200 lignes de code a tout casser

Avec ce qui suit ci-dessus :mdr:

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

140 Posté le 24/11/2007 à 08:30:05

Je comprends pas tres bien ces attaques sans fondements. Tu serais pas eleve ingenieur par hasard ? ;)

Que tu ne sois pas d'accord avec mes points techniques, c'est une chose, mais m'accuser de mythomanie parce que tu ne comprends pas ce que je dis en est une autre. Tous les points que j'ai developpes sur ce thread sont fondes, et issus de ma vision des choses en programmation. A part jouer sur les mots, et faire des contre sens un peu gros, je comprends pas tres bien tes arguments.

Hors sujet :
Pour la mythomanie, je sais pas bien quoi te repondre, a part que suffisament de personnes sur AF m'ont rencontre soit en vrai, soit sur d'autres forums/communautes, entre autre de programmation.

J'ai participe a suffisament de threads techniques sur le traitement du signal qui montrent que sans etre un expert (je me pose pas en ayant lu un pdf, perso, typiquement ;) ), je connais un minimum de quoi je parle lorsque je parle de traitement du signal.

Anonyme

521397

141 Posté le 24/11/2007 à 10:46:11

A l'attention de Karlos :
je viens de récupérer une license Pro Tools 7.3 HD...me manque le matériel.
Enfin je me suis apercu que ma carte EMU 1616M est capable de générer un bruit blanc...ce qui pourrait être utile pour essayer de faire des tests.
Je m'en suis déjà servi pour tester des câbles, ca permet de dégager quelques résultats voir même de confirmer certaines différences observées avec..les oreilles ;o), malheureusement le plugin freeware que j'utilise pour afficher le spectre de fréquence n'est pas très précis.
Je vais essayer de comparer Ableton Live 6, que je possède maintenant et la beta 7 que j'ai téléchargé et installé.

Protocole :
_ j'envoie un bruit blanc sur une entrée asio de live 6. J'enregistre en 192khz 24bits le signal. Je rejoue la piste en boucle avec le plugin qui m'affiche le spectre. Je règle celui-ci dans sa résolution maximale et je lui fait mémoriser les peaks. Cela me donne un tracé --->copie d'écran

_ je recommence avec live 7 et j'essaye en superposant les deux images sous photoshop de distinguer des différences (pas terrible mais j'ai un wavelab lite qui apparement ne fait pas grand chose)

Je pourrais te fournir les deux fichiers wave si tu le souhaites..tu pourras peut être faire mieux.

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

142 Posté le 24/11/2007 à 11:07:08

Pour comparer deux waves, faut pas utiliser la representation graphique, c'est ultra imprecis. Vaut mieux utiliser un editeur audio qui permet de faire un mix et une opposition de phase (comme audacity; ca m'etonnerait que wavelab meme lite ne puisse pas le faire, cependant). Ca te donne la difference entre les deux signaux; bien sur, il faut etre sur qu'ils sont bien synchronises au depart, ce qui ne devrait pas etre trop dur avec un bruit blanc.

Pour le 32 bits vs 64 bits, j'ai retrouve un "vieux" thread qui en parle, et qui reprend en partie certaines problematiques posees par ce thread.

/mastering/forums/t.199891,moteurs-audio-32-bits-64-bits-distinguer-le-vrai-du-faux.html

Wolfen

14007

Rédacteur·trice

Membre depuis 23 ans

143 Posté le 25/11/2007 à 15:06:39

Merci à tout le monde de rester courtois :oops2:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

Anonyme

521397

144 Posté le 26/11/2007 à 23:23:35

L'oscillateur de l'EMU génère un signal qui varie...parasites..masse? Difficile dans ces conditions de s'en servir comme référence. De toute façon mon plugin n'est pas très précis.
Ci-dessous deux signaux enregistrés à quelques secondes d'intervalles dans live6(afficher l'image dans une autre fenêtre pour une vue non déformée) :

Le wavelab lite permet en effet de faire les tests du mix et de l'opposition de phase..il fallait sélectionner un sample pour voir les menus se dégriser.
Je ne m'en sers jamais, donc... :??:

Une nouvelle mesure :

La même comparaison avec un autre plugin..encore moins précis(l'échelle n'est pas la même cependant)...juste pour démontrer à quel point ces plugins relèvent du gadget, même si ils peuvent servir parfois :

Deux enregistrements live 6 live 7 comparables, comparés :clin:

Que peut on en déduire?? Que le plugin de Voxengo à l'air d'apporter plus d'information que celui de Bluecat... :clin:

Il me faudrait une source digitale...et un analyseur de spectre...avec une entrée digitale(le moindre cable, sonde est un filtre).

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

145 Posté le 27/11/2007 à 05:08:15

Le problem des analyseurs de spectre audio, c'est que tu ne sais pas tres bien ce qu'ils font: la, par exemple, bien qu'on sache la taille de la fft (block size 16834), on sait pas quelle est la fenetre utilisee, etc...

Le plus simple, c'est d'enregistrer ce qui arrive dans ton soft avec un plugin vst style tape-it: http://www.silverspike.com/?Products:TapeIt (il y a une version gratuite). Ca enregistre directement ce qui arrive en VST au point ou tu utilises le plugin, dans un fichier wave (en utilisant un wave 32 bits, tu ne perds aucune info a priori, vu qu'aucune convertion n'est necessaire; si t'es parano, tu peux checker auparavant en utilise un fichier test).

Apres, tu peux comparer les fichiers wave correctement en les synchronisant deja, puis en utilisant un analyseur de spectre que tu peux controler. Mais pour que ca ait un sens, il faut que ce soit le meme signal dans les deux softs que tu consideres.

Anonyme

521397

146 Posté le 27/11/2007 à 13:08:04

Citation : Le problem des analyseurs de spectre audio, c'est que tu ne sais pas tres bien ce qu'ils font: la, par exemple, bien qu'on sache la taille de la fft (block size 16834), on sait pas quelle est la fenetre utilisee, etc...

Peu importe la fenêtre utilisée (Hamming,...) lorsque l'on cherche à mettre en évidence des différences...l'important étant que le même traitement soit appliqué au signal, ce qui est le cas.

Citation : Le plus simple, c'est d'enregistrer ce qui arrive dans ton soft avec un plugin vst style tape-it: http://www.silverspike.com/?Products:TapeIt (il y a une version gratuite). Ca enregistre directement ce qui arrive en VST au point ou tu utilises le plugin, dans un fichier wave (en utilisant un wave 32 bits, tu ne perds aucune info a priori, vu qu'aucune convertion n'est necessaire; si t'es parano, tu peux checker auparavant en utilise un fichier test).

Si on ne veut pas faire d'export de la piste, le wave est directement disponible dans le répertoire du projet sous le folder "recorded" donc pas besoin de Tape it.

Citation : il faut que ce soit le meme signal dans les deux softs que tu consideres.

Tu as tout compris.

La fouine

1192

AFicionado·a

Membre depuis 20 ans

147 Posté le 28/11/2007 à 11:05:57

J'suis sur qu'on a va faire de vous deux potes inséparables du traitement du signal au bout du compte :clin:

Anonyme

521397

148 Posté le 28/11/2007 à 12:59:47

Chunkyheels

119

Posteur·euse AFfiné·e

Membre depuis 20 ans

149 Posté le 06/11/2009 à 14:09:46

Truc drôle!!!!
Créez une piste audio stéréo et une piste master stéréo
sur la 1ère balancez un bruit rose et sur la master un analyseur de spectre.
Logiquement le tracé devrait être plat...
et là surprise!!!! je vous laisse découvrir
Voilà à mon avis pkoi PT sonne plus "brillant" comme on l 'entend souvent.

Chunk

Chunkyheels

Mrben

493

Posteur·euse AFfamé·e

Membre depuis 22 ans

150 Posté le 06/11/2009 à 15:13:34

Si je puis apporter ma noble contribution, j'ai une Digi 003 avec PT LE7 et logic pro 7.
Je mixe plus aisément sous protools, et donc au final le mix sonne mieux que sous Logic.
La raison? Et bien, à mon avis, c'est parce que le master de PT est en 48 bits. Au final la dynamique globale su mix est plus facile à gérer et parfois j'ai """""""presque l'impression"""""" (avec pleins de guillemets) qu'on peut "rentrer de dedans" comme dans une console analogique. Attention, pas de faux débats, je n'ai pas dit que PT valait une SSL, qu'il n'y ait pas de mal entendu. Alors qu'aec Logic, on sature le master beaucoup plus rapidement et au final la dynamique est vraiment compliquée à gérer.

Sinon je n'ai pas remarqué de différence quant à l'enregistrement d'une même souce sur ces deux soft, et je ne vois pas pourquoi il y en aurait: l'interface audio est la même, la source est la même, la partie musicale aussi et le format de fichier est aussi identique (48Khz, 24 bits).

< Liste des sujets
Charte

Liste des modérateurs