Bounce Ou Pas?, la meilleure façon d'enregistrer un morceau |
Sun 29 Apr 2007, 23:39
Post
#101
|
|
Junior Member Group: Members Posts: 157 Joined: 05-Sep 04 From: Paris - FR Member No.: 50,294 |
J'ai l'impression que soit tu es informaticien, soit utopiste (c'est la mode en ce moment ) Et que cette évidence, que tu nous affirmes, nous range au rang de vieux caméléons dérivants au fil du vent.... (ça c'est pour Maurice ) Trève de joke et de plaisanterie.... Après la ou les théories, il y a l'expèrience... Et le monde change si rapidement qu'il faut se méfier, même de ce qu'on a pu affirmer la semaine dernière... Sans vouloir ni désirer enfoncer qui que ce soit ni détenir aucune vérité, on ne peut prétendre être expèrimenté que si on l'a prouvé Tu impressionnes bien, je suis informaticien à l'origine. Rassure moi, ça ne va quand même pas devenir une tare pour comprendre et expliquer ce qu'il est possible ou pas qu'un dispositif numérique fasse , si ?? Donc arrêtez avec vos microprocesseurs qui se trompent une fois sur 100, ou qui se trompent moins et font mieux sonner les algorithmes quand ils sont plus puissants : ça n'EXISTE PAS ok ? Et non, les affirmations techniques ne changent pas d'une semaine sur l'autre, si elles le font c'est qu'elles étaient incomplètes ! Bref : à moins que le DAW n'ait explicitement prévu de faire des approximations de calcul quand il est en lecture/bounce temps réel, et d'aller plus loin dans la finesse et l'exactitude quand il est en bounce offline, là où il a tout son temps, je vois pas pourquoi ce serait différent... Pour compléter ce que je dis : vous êtes tous d'accord pour dire que la taille de buffer n'a aucune incidence sur la qualité du son, ça passe ou ça casse, non ? Voilà comment ça se passe dans un DAW natif (non TDM donc), schématiquement : je suis dans une song Logic à 44.1Khz avec 256 samples de taille de buffer (c'est à dire la taille du bloc qu'on doit absolument envoyer à la carte son toutes les 256/44100 = 5,8 ms). Ca veut donc dire que pour ne pas avoir de rupture dans le son (craquement ou message de surcharge coreaudio) et arriver à suivre, le processeur doit être capable de calculer en moins de 5,8ms top chrono ce que va donner ta song sur les 5,8 prochaines ms de son (les synthés, les plugs d'effet, la reverb, le mixage, etc ...), et de balancer ça à la carte son à temps pour qu'elle puisse faire le raccord avec le bloc précédent. Si tu as un processeur ric rac, il va te faire le calcul et hop il a le résultat en 4ms disons... il envoie à la carte son et il se roule les pouces jusqu'à la prochaine demande de calcul... dans 1.8ms. Si tu as un processeur 2 fois plus rapide, qui te torche le meme calcul de 5,8ms d'audio en seulement 2ms, eh ben.... il va se rouler les pouces plus longtemps, il a de la marge quoi !! MAIS LE LOGICIEL LUI A FAIT FAIRE LE MEME CALCUL, IL NE S'AMUSE PAS A VARIER SUIVANT LA VITESSE DU PROC EN DESSOUS Conséquence : le 2e processeur ben tu peux ptet te permettre de profiter de sa rapidité de réaction pour descendre ta latence : il torche le résultat en 2ms ? Eh bien tu peux peut-etre baisser ton buffer à 128 samples, soit 2,9ms de latence à 44.1Khz. Le bounce offline / non temps réel ? L'intérêt c'est que tu t'en fous du temps que met ton processeur à cracher l'audio, tu n'as aucune contrainte que ça arrive à temps à la carte son, aucun problème si ce morceau de 3:00 met 3:15 à être calculé sur ton processeur poussif. C'est comme avoir une taille de buffer infinie. Bon j'ai simplifié le truc et vous allez me dire : le DAW, si il voit qu'il a de l'avance à chaque fois, qu'il nage dans le gros buffer qu'on lui a donné, il peut peut-être se dire qu'il va bosser plus dur et faire des calculs plus poussés qui améliorent le son ? En théorie oui, c'est pas impossible, en pratique non : le mixer de Logic ou la Space designer n'ont pas 15 versions différentes de leur algorithme, plus ou moins poussées suivant le temps de calcul qu'on s'accorde. Ca se saurait This post has been edited by reno08: Sun 29 Apr 2007, 23:41 |
|
|
Mon 30 Apr 2007, 00:14
Post
#102
|
|
Moderator Group: Moderators Posts: 3,768 Joined: 07-Dec 00 From: PARIS - FR Member No.: 23 |
...Bref : à moins que le DAW n'ait explicitement prévu de faire des approximations de calcul quand il est en lecture/bounce temps réel, et d'aller plus loin dans la finesse et l'exactitude quand il est en bounce offline, là où il a tout son temps, je vois pas pourquoi ce serait différent... Pitié!On va reparler de la virgule flottante QUOTE Rassure moi, ça ne va quand même pas devenir une tare pour comprendre et expliquer ce qu'il est possible ou pas qu'un dispositif numérique fasse , si ?? Si En général on apprend, par le constructeur même, quand il sort une nouvelle version de soft, que c'est beaucoup mieux et que certains problèmes, qu'il niait lui-même au paravent, comme inexistant, sont résolus L'informatique musicale a ceci de particulier (à la différence d'une programmation - même très complexe - dans d'autres domaines, c'est qu'elle traite un "ersatz" de signal analogique découpé en tranches... Par ailleurs et pour vraiment simplifier à l'extrème: il est admis que dans une sommation (un bounce) dans un ou plusieurs circuits DSP, il puisse y avoir quelques approximations de calculs perdues... Et que plus il y aura de pistes à mélanger, de plugins rtaz ou autres, plus grande pourra être l'approximation. Ce déperditions sont considérées comme négligeables en programmation puisqu'elles sont inévitables.... Mais, dans le principe, elles introduisent des inexactitudes Après se rajoutent les variables inhérentes aux diffèrents processeurs qui utiliseront le même DAW Plus quelques malheureux "do while" dont les conditions de sortie n'auront pas pu être toutes cernées etc... etc.... etc... On peut tout prévoir, sauf l'imprévu ! (Sacha Guitry) -------------------- Plombier, DéZingueur de HP, ferblantier
|
|
|
Mon 30 Apr 2007, 01:24
Post
#103
|
|
Junior Member Group: Members Posts: 157 Joined: 05-Sep 04 From: Paris - FR Member No.: 50,294 |
Si En général on apprend, par le constructeur même, quand il sort une nouvelle version de soft, que c'est beaucoup mieux et que certains problèmes, qu'il niait lui-même au paravent, comme inexistant, sont résolus Là tu me parles d'un problème marketing, de mentir à ses clients. Les ingénieurs connaissaient depuis le début les limites de leur ancienne version, s'ils sont pas trop cons QUOTE L'informatique musicale a ceci de particulier (à la différence d'une programmation - même très complexe - dans d'autres domaines, c'est qu'elle traite un "ersatz" de signal analogique découpé en tranches... Ca n'a absolument rien de particulier, c'est le domaine mathématique bien maitrisé du traitement du signal discret. QUOTE Par ailleurs et pour vraiment simplifier à l'extrème: il est admis que dans une sommation (un bounce) dans un ou plusieurs circuits DSP, il puisse y avoir quelques approximations de calculs perdues... Et que plus il y aura de pistes à mélanger, de plugins rtaz ou autres, plus grande pourra être l'approximation. Oui, mais c'est connu et maitrisé, et surtout *déterministe* : ca ne va pas changer en fonction du temps qu'il fait ou du processeur en dessous. Et tout ceci se calcule, se prévoit, est connu *au minimum* des concepteurs, et fort heureusement de beaucoup d'utilisateurs éclairés QUOTE Ce déperditions sont considérées comme négligeables en programmation puisqu'elles sont inévitables.... Mais, dans le principe, elles introduisent des inexactitudes Après se rajoutent les variables inhérentes aux diffèrents processeurs qui utiliseront le même DAW Plus quelques malheureux "do while" dont les conditions de sortie n'auront pas pu être toutes cernées etc... etc.... etc... On peut tout prévoir, sauf l'imprévu ! (Sacha Guitry) Là désolé, mais je crois que tu pars complètement en vrille sur un sujet pas très maitrisé |
|
|
Mon 30 Apr 2007, 02:00
Post
#104
|
|
SuperHero Group: Members Posts: 9,465 Joined: 04-Nov 01 From: Paris - FR Member No.: 2,244 |
Oui, mais c'est connu et maitrisé, et surtout *déterministe* : ca ne va pas changer en fonction du temps qu'il fait ou du processeur en dessous. Et tout ceci se calcule, se prévoit,... Si tout est si carré et prévisible, comment explique tu que, parfois, pour une même tache que l'ordinateur a déjà effectué sans problème (lire une session lambda par exemple), il puisse soudain (et même qqls minutes seulement plus tard) se mettre à ne plus y parvenir sans qu'on ai rien modifié entre temps?... Je pense que nous avons tous expérimenté ce genre de situations désespérantes qui laissent à penser que, non, les calculs ne se font pas toujours de la même manière, même sur une même machine... De même dire que tout se calcule et se prévoit pourrait être infirmé par l'usage de bétas testeurs (utilisateurs) qui continuent souvent à expérimenter des comportements étranges, voire inexpliquables (je sais ça fait peur quand on croit à la science exacte) des mois, des années après la sortie d'un soft. Enfin, il me semble... -------------------- |
|
|
Mon 30 Apr 2007, 10:06
Post
#105
|
|
Junior Member Group: Members Posts: 107 Joined: 28-Mar 04 From: Paris - FR Member No.: 39,609 |
Je suis prêt à parier une bouteille de Jack Daniels (la boisson de l'élite ), que tu vas trouver "moins l'infini". J'ai déjà fait ce test et avais déjà dit ici même dans une discussion similaire qu'il n'y avait AUCUNE différence entre les deux fichiers... Le silence complet... La bouteille de Jack est donc remportée haut la main par Mr. T ! (eh ho, j'avais pas parié, moi ) Donc, si on résume, entre faire un bounce et router le mix sur 2 pistes qui enregistrent en interne, c'est 100% tout pareil, et si on entend quand même – pourquoi pas – une différence, c'est 100% tout dans la tête. Et ça répond parfaitement à la question initiale ! Montjoie, St Denis et pot de départ, l'ingénieur embrasse le philosophe, on échange les adresses et on se dit qu'on remettra ça l'année prochaine, avec deux ou trois questions pour moi (pardonnez mon ignorance) encore sans réponse, genre : - Tout support de reproduction audionumérique (CD, MD, DAT, etc) est susceptible d'introduire des erreurs (il manque un 0 ou un 1 par-ci par-là), compensées par des calculs plus ou moins élégants - Est-ce aussi le cas dans un DAW, ou bien toute erreur est-elle immédiatement perceptible (ou signalée), ou bloque carrément le bazar ? - Car s'il y a bien correction d'erreurs, ces erreurs n'étant pas nécessairement constantes, ça pourrait expliquer certaines différences de son, non ? j'ai dit une bêtise ? -------------------- "Si nos rêves ne se réalisent jamais, autant rêver l'impossible"
|
|
|
Mon 30 Apr 2007, 10:36
Post
#106
|
|
SuperHero Group: Members Posts: 9,465 Joined: 04-Nov 01 From: Paris - FR Member No.: 2,244 |
A la fois, c'était mes tests, je n'en tirerais pas une vérité absolue.
De plus, je pense, justement, que rien n'est définitif et certain avec l'informatique contrairement à ce qu'affirme Reno. Pour autre exemple, j'ai récemment eu une étrange expérience avec une Rverb (Waves) sur PTHD. Soit une session bien chargée avec, entre autre, une reverb automatisée (Bypass, Wet/Dry et Time). Bien. Cette session joue parfaitement en lecture, les automations font ce qu'on leur dit de faire, etc... Vient le temps de la sortie qu'on me demande de faire en fichier "informatique", Bounce donc. Je lance le Bounce, écoute d'une oreille distraite (c'est mal) et susrsaute soudain en me rendant compte que la reverb fait n'importe quoi. Elle ne se bypasse pas comme elle devrait et le reste de ses automations semblent décalées... J'arrête tout, relance le Bounce. Itou. N'ayant que peu de temps pour finir mon ouvrage, je décide d'enregistrer dans la session. Pas de soucis. QQls jours plus tard, alors que je retravaille au même endroit, je réouvre la session en question et retente le bounce pour ma culture personnelle. Ca marche... Calculé et prévisible?... -------------------- |
|
|
Mon 30 Apr 2007, 10:38
Post
#107
|
|
Moderator Group: Moderators Posts: 3,768 Joined: 07-Dec 00 From: PARIS - FR Member No.: 23 |
...désolé, mais je crois que tu pars complètement en vrille sur un sujet pas très maitrisé Oui désolé aussi
-------------------- Plombier, DéZingueur de HP, ferblantier
|
|
|
Mon 30 Apr 2007, 10:57
Post
#108
|
|
SuperHero Group: Members Posts: 2,748 Joined: 04-Sep 02 From: Elancourt - FR Member No.: 7,376 |
Comme souvent, je subodore qu'il y a malentendu.
Tranquillement assis dans mon fauteuil et avec ce que m'a appris l'école primaire et secondaire, je fais les hypothèses suivantes: - Je comprends assez bien comment un microprocesseur accomplit les 4 opérations: addition, soustraction, multiplication, division (ou 2 opérations algébriques seulement). Et, à mon avis, il ne fait que ça. Les autres opérations, élever au carré, calculer 'l'intégrale" et la "dérivée", atténuer quand le signal dépasse une certaine valeur, etc ... sont des développements en série (une somme de termes) que l'ont calcule avec ces 4 opérations. - Il n' y a pas d'autres moyens de faire ces 4 opérations que d'utiliser les algorithmes (dit Euclidiens) que tous les enfants sont censés manier avec dextérité. Comment fait-on pour détecter des erreurs ? La preuve par 9 laisse passer une erreur d'un multiple de 9. On se rallie à l'opinion de la majorité ? Eeeeuuuuuuhhhhh ..... - J'arrive ici dans un domaine dont je n'ai qu'une très vague notion. C'est la redondance. Un cerveau humain fait, paraît-il, un même raisonnement avec plusieurs circuits parallèles, et il élimine celui qui donne un résultat non conforme à l'expérience. - Ce n'est pas comme ça que fonctionne la vérification dans un ordinateur, il me semble. D'après moi, il n'en fait pas. Si on veut comprendre le mécanisme, il faut l'étudier longuement (après avoir fait de longues études sur les sytèmes non linéaires pendant lesquelles on ne fait pas de musique ). En gros, on rajoute plein d'informations aux "mots", ou/et on les répète ou dilue dans le temps (c'est de la redondance) pour que les défauts inévitables des "composants", ne puissent donner lieu à une erreur que tous les 10 000 ans (c'est une image .... . Et là, il faut faire confiance aux savants qui prédisent seulement une "probabilité" d'erreur. - Les défauts, vous les avez déjà vus quand un logiciel vous dit que sur un disque dur, il y a tant de secteurs mauvais. Maintenant, en MAO, ces calculs ne doivent pas durer plus d'un certain temps. Moi, j'ai l'impression que Pro Tools me prévient quand il n'a pas eu le temps (your drive is too slow, etc ...). Mais le fait-il systématiquement ? En sciences dites "exactes", il est impossible de prévoir si un calcul va durer 10s ou 10 ans (lire les continuateurs de Türing ou von Neumann) Ce doit être là que le bât blesse. Donc, vous avez tous raison. Yoooooooppppppyyyyyyyeeee !!! (Vous avez vu comment je suis un lundi matin ??? ) La bouteille de Jack est donc remportée haut la main par Mr. T ! (eh ho, j'avais pas parié, moi ) T'as rien compris, hé, banane !!! (je dis ça très affectueusement ), on est du même avis !!! |
|
|
Mon 30 Apr 2007, 15:54
Post
#109
|
|
Junior Member Group: Members Posts: 157 Joined: 05-Sep 04 From: Paris - FR Member No.: 50,294 |
Oui, mais c'est connu et maitrisé, et surtout *déterministe* : ca ne va pas changer en fonction du temps qu'il fait ou du processeur en dessous. Et tout ceci se calcule, se prévoit,... Si tout est si carré et prévisible, comment explique tu que, parfois, pour une même tache que l'ordinateur a déjà effectué sans problème (lire une session lambda par exemple), il puisse soudain (et même qqls minutes seulement plus tard) se mettre à ne plus y parvenir sans qu'on ai rien modifié entre temps?... Je pense que nous avons tous expérimenté ce genre de situations désespérantes qui laissent à penser que, non, les calculs ne se font pas toujours de la même manière, même sur une même machine... Euh oui je te l'explique sans problème : ton DAW ne fonctionne pas sur du matériel dédié à 100% à la tâche en cours, où il est seul maître à bord. Ca c'était vrai à l'époque de l'Atari, ou dans les studio multipistes numériques dédiés. Ton DAW moderne lui il fonctionne au dessus d'un système d'exploitation généraliste multi-tâches qui a une multitude de choses à faire à un instant t, des accès aux disques durs, d'autres applis en parallèle, des choix de priorité à faire, du nettoyage dans la mémoire, etc. L'ensemble de ce qui se passe sur ton ordinateur au moment où tu vas jouer la session la première fois ne sera pas pareil la 2nde fois, et ça sera peut-etre trop pour réussir à calculer le buffer dans les temps, et ça casse. C'est aussi bête que ça. Tout a une explication au final, toujours, même si la complexité des systèmes d'exploitation actuels peut donner une impression de "vaudou". Mais un calcul lancé 2 fois de suite donnera fatalement 2 fois le même résultat... je ne sais pas comment vous convaincre, c'est comme ça que ça marche quoi, c'est ça la réalité, si vous ne me croyez pas sur parole allez lire des bouquins sur la théorie de l'informatique Mais là je vous avoue que je me sens un peu désarmé comme un défenseur de la théorie de l'évolution et de la science en face d'un créationniste : l'un parle de faits, de preuves démontrables et de comment marchent les choses, les autres de croyances et de feeling.... Pour autre exemple, j'ai récemment eu une étrange expérience avec une Rverb (Waves) sur PTHD. Soit une session bien chargée avec, entre autre, une reverb automatisée (Bypass, Wet/Dry et Time). Bien. Cette session joue parfaitement en lecture, les automations font ce qu'on leur dit de faire, etc... Vient le temps de la sortie qu'on me demande de faire en fichier "informatique", Bounce donc. Je lance le Bounce, écoute d'une oreille distraite (c'est mal) et susrsaute soudain en me rendant compte que la reverb fait n'importe quoi. Elle ne se bypasse pas comme elle devrait et le reste de ses automations semblent décalées... J'arrête tout, relance le Bounce. Itou. N'ayant que peu de temps pour finir mon ouvrage, je décide d'enregistrer dans la session. Pas de soucis. QQls jours plus tard, alors que je retravaille au même endroit, je réouvre la session en question et retente le bounce pour ma culture personnelle. Ca marche... Calculé et prévisible?... Ca s'appelle juste... un bug. Pour une raison que seuls les programmeurs de Digi peuvent réussir à trouver, les dizaines de milliers de variables que contient Pro Tools à un instant t se trouvaient dans un état qui faisait que le programme ne se comportait pas comme prévu par les programmeurs dans ce cas de figure. Mais l'erreur revient forcément au programmeur qui n'a pas prévu tous les cas, et le bug a toujours une explication logique au final, même si on a pu mettre des semaines à le trouver... Tout ça pour dire que le processeur fait toujours ce qu'on lui demande dans le logiciel, toujours de la même manière et toujours bien, quelle que soit sa vitesse. Ca n'existe pas un processeur qui "bâcle" un calcul, ok ? |
|
|
Mon 30 Apr 2007, 18:26
Post
#110
|
|
Maniac Member Group: Members Posts: 501 Joined: 20-Sep 03 From: Paris - FR Member No.: 25,065 |
Quoi qu'il arrive, une erreur en numérique PCM induit un click, donc je pense que vos oreilles la détecteront ;-)
|
|
|
3 User(s) are reading this topic (3 Guests and 0 Anonymous Users)
0 Members: