Hola que tal solo queria comentar el hecho de que en algun foro en ingles donde tambien se trata el eterno debate sobre si los DAW´s suenan diferente o no, me encontre un comentario hecho por uno de los programadores de Magix. Donde comenta sus puntos de vista sobre el porque si hay varias razones por la que un DAW puede sonar diferente a otro, el texto es un poco confuso en ingles, tal vez sea por el hecho de que el tipo es Aleman y no escribe muy bien el ingles, hice la traduccion al español lo mejor que pude, pero igual si hay alguien que pueda corregir algo, pues bienvenido sea. A pesar de todo, creo que se logra entender muy claro lo que trata de decir este programador y nos da una idea del porque puede ser posible la diferencia del sonido en diferentes DAW´s.
Ahora, si esto es verdad o solo tratan de mantener esa idea en la mente de las personas para seguir manteniendo la idea de que algunos DAW´s suenan mejor que otros, solo por marketing ( ya sabemos todos que Samplitude y Sequoia son famosos y reconocidos precisamente porque se dice que "suenan" mejor que otros, que su motor de audio es mejor) yo no lo se, y eso queda a criterio de cada quien, yo solo dejo el comentario aqui (en ingles y español) para quien le pueda interesar conocer el punto de vista de alguien que de hecho se dedica a programar un DAW.
Texto en Ingles:
(This is from an programmer of MAGIX):
This was posted on the Samplitude forum some time ago. It's the only comment on this subject by anyone who actually writes this stuff that I've personally ever seen.
I can try to give some comments here, bit I won't claim to end this debate once and for all time. This is my personal point of view, so don't take this for an official MAGIX statement:
-As programmer (and scientist) I tend to the deterministical point of view: just adding two numbers should give the same in all circumstances, and hence the basic mixing task should be the same for all 32 bit floating point DAW's - if you take the simple adding process as a common method for mixing: we know there may be other methods here.
-I also know that due to the number representation in the computer, there just is not only a limited precision but also a certain "random factor" in calculations with floating point numbers. This is basicallly caused by the representation of the compiled code in the system (initialisation of floating point registers with more than 32 bit processing, usage of registers versus usage of computer memory,...) and the execution of the code in the real system (e.g influence of other tasks, e.g. with multitasking). Both is partially depending on the used compilers, but of course also from the programmming code the application is written with. A recent example could be a problem with the master gain in the first v8 beta versions, where it changed the bit depth even when just initialized with exactly 0dB (= factor 1.0 in floating point).
-An obvious step after summing before going to the output is reducing the bit depth again to 24 or 16 bit. This consists of at least 3 steps: clipping, scaling and dithering. Every step can be implemented in various ways. *Clipping can be done straight forward or more sophisticated, both with possible hazards for the audio signal - but of course hopefully or at least commonly only present to loud parts of the audio. *Scaling can be done before or after summing (both is e.g. possible to be influenced by the user in Samplitude with the input gain options or the master fader). Since scaling also applies to the input, there's again a lot of things that can be done differently. Even the discussions about panning law settings may be put here. Since integer based engines require scaling before summing I can easily imagine different appproaches in other DAW's. *Dithering: nothing much to say here: there are more algorithms than we can think of here. A major "ditherence" may be its application for intermediate steps when necessary.
So here I see many possible reasons for different behaviour and even mis-behaviour. And often I have seen or heard the results - not only in other DAWs, but partially also in our (some still may remember a dithering problem in version 5.1x).
-An often uncommented problem seems the timeline representation of audio material. There sure is a difference between sample based or PPQ based approaches. The first gives perfect audio reproduction but possible problems with loops and BPM values while the latter more easily may sacrifice the first in favour of the BPM.
So to sum it up: yes, the simple adding of numbers should basically give the same results, but even there may be a bit of voodoo here - although it might be hard to realize the differences. The more obvious reason for sound differences are decisions about the processing at input and output stage, with a lot of different ways to go - and I neither mentioned the connection with audio drivers and other parts of the system.
Regards, Volker
Texto en Español:
(Esto es de un programador de MAGIX)
Esto fue posteado hace algun tiempo en el foro de Samplitude. Es el unico comentario que se ha hecho sobre este tema por alguien que de hecho se dedica a esto (al menos que yo haya visto personalmente)
Puedo tratar de dar algunos comentarios aqui, pero no digo que terminare de una vez y para siempre con este debate. Este es mi punto de vista personal, asi que no tomen esto como una declaracion oficial de MAGIX.
Como programador (y cientifico) tiendo mucho al punto de vista determinista: solo añadir dos numeros deberia dar lo mismo en todas cirunstancias, y dado que las tareas de mezcla basicas deberian de ser las mismas para todos los DAW´s de 32 bits de coma flotante, si tomas el simple proceso de añadir como un metodo comun para mezclar, pero sabemos que puede haber otros metodos aqui.
Tambien se que debido a la representacion de numeros en la computadora, no hay solamente una limitada precision, si no tambien hay cierto "factor aleatorio" en los calculos con numeros de coma flotante. Esto es causado basicamente por la representacion del codigo compilado en el sistema (la inicializacion de registros de coma flotante con procesamiento de mas de 32 bits, uso de registros en contra del uso de memoria de computadora...) y la ejecucion de el codigo en el sistema real (por ejemplo: la influencia de otras tareas, ejemplo: multiples tareas). Ambas dependen parcialmente de los compiladores usados, pero por supuesto que tambien del codigo de programacion con el que esta escrito. Un reciente ejemplo podria ser un problema con el volumen del master en las primeras versiones betas de la version 8 (Samplitude) donde cambiaba la profundiad de bit incluso cuando inicializaba con exactamente 0db (= factor 1.0 en coma flotante).
Un paso obvio despues de la suma, antes de ir a la salida es reducir la profundidad de bit otra vez a 24 o 16 bit. Esto consiste en al menos 3 pasos: clipping, scaling y dithering. Cada paso puede ser implementado de varias formas. *Clipping puede ser hecho sencillo o mas sofisticado, ambos con posibles riesgos para la señal de audio – por por supuesto esperando que al menos comunmente solo sea presente en las partes mas fuertes (con mas volumen) del audio. *Scaling puede ser hecho antes o despues del summing (ambos son por ejemplo posiblemente influenciados por el usuario en Samplitude con las opciones de ganancia de entrada o el fader del master. Ya que el scaling tambien se aplica a la entrada, existen muchas cosas que se pueden hacer de forma diferente. Incluso las discuciones sobre los ajustes de las leyes de paneo pueden entrar aquí. Dado que los motores basados en integros requieren el scaling antes del summing, puedo imaginar facilmente diferentes metodos en otros DAW´s. *Dithering: no hay mucho que decir sobre esto: existen mas algoritmos de los que podemos pensar aquí. La mayor “ditherencia” pudiera ser su aplicación para pasos intermedios cuando es necesario.
Asi que yo veo varias posibles razones para un comportamiento diferente y aun para un mal-comportamiento. Y muy comunmente he visto o escuchado los resultados – no solo en otros DAW´s, si no tambien parcialmente en el nuestro (algunos tal vez todavia recuerden un problema de dithering en la version 5.1).
Un problema no mencionado comunmente parece ser la representacion de la linea de tiempo del material de audio. Es seguro que existe una diferencia entre el sistema usado ya sea “basado en muestras” o “PPQ”. El primero da como resultado: reproduccion de audio perfecta, pero posibles problemas con loops y valores BPM, mientras que el ultimo puede sacrificar facilmente lo primero en favor del BPM.
Asi que para resumir: Si, el simple hecho de añadir numeros, basicamente deberia de dar el mismo resultado, pero aun puede haber un poco de voodo aquí – aunque puede ser dificil darse cuenta de las diferencias. Las razones mas obvias para las diferencias de sonido, son las desiciones sobre el procesamiento en las secciones de entrada y salida, con muchas formas diferentes de actuar – y ni siquiera he mencionado las conexiones con los drivers de audio y otras partes del sistema.
Saludos, Volker.
Ahora, si esto es verdad o solo tratan de mantener esa idea en la mente de las personas para seguir manteniendo la idea de que algunos DAW´s suenan mejor que otros, solo por marketing ( ya sabemos todos que Samplitude y Sequoia son famosos y reconocidos precisamente porque se dice que "suenan" mejor que otros, que su motor de audio es mejor) yo no lo se, y eso queda a criterio de cada quien, yo solo dejo el comentario aqui (en ingles y español) para quien le pueda interesar conocer el punto de vista de alguien que de hecho se dedica a programar un DAW.
Texto en Ingles:
(This is from an programmer of MAGIX):
This was posted on the Samplitude forum some time ago. It's the only comment on this subject by anyone who actually writes this stuff that I've personally ever seen.
I can try to give some comments here, bit I won't claim to end this debate once and for all time. This is my personal point of view, so don't take this for an official MAGIX statement:
-As programmer (and scientist) I tend to the deterministical point of view: just adding two numbers should give the same in all circumstances, and hence the basic mixing task should be the same for all 32 bit floating point DAW's - if you take the simple adding process as a common method for mixing: we know there may be other methods here.
-I also know that due to the number representation in the computer, there just is not only a limited precision but also a certain "random factor" in calculations with floating point numbers. This is basicallly caused by the representation of the compiled code in the system (initialisation of floating point registers with more than 32 bit processing, usage of registers versus usage of computer memory,...) and the execution of the code in the real system (e.g influence of other tasks, e.g. with multitasking). Both is partially depending on the used compilers, but of course also from the programmming code the application is written with. A recent example could be a problem with the master gain in the first v8 beta versions, where it changed the bit depth even when just initialized with exactly 0dB (= factor 1.0 in floating point).
-An obvious step after summing before going to the output is reducing the bit depth again to 24 or 16 bit. This consists of at least 3 steps: clipping, scaling and dithering. Every step can be implemented in various ways. *Clipping can be done straight forward or more sophisticated, both with possible hazards for the audio signal - but of course hopefully or at least commonly only present to loud parts of the audio. *Scaling can be done before or after summing (both is e.g. possible to be influenced by the user in Samplitude with the input gain options or the master fader). Since scaling also applies to the input, there's again a lot of things that can be done differently. Even the discussions about panning law settings may be put here. Since integer based engines require scaling before summing I can easily imagine different appproaches in other DAW's. *Dithering: nothing much to say here: there are more algorithms than we can think of here. A major "ditherence" may be its application for intermediate steps when necessary.
So here I see many possible reasons for different behaviour and even mis-behaviour. And often I have seen or heard the results - not only in other DAWs, but partially also in our (some still may remember a dithering problem in version 5.1x).
-An often uncommented problem seems the timeline representation of audio material. There sure is a difference between sample based or PPQ based approaches. The first gives perfect audio reproduction but possible problems with loops and BPM values while the latter more easily may sacrifice the first in favour of the BPM.
So to sum it up: yes, the simple adding of numbers should basically give the same results, but even there may be a bit of voodoo here - although it might be hard to realize the differences. The more obvious reason for sound differences are decisions about the processing at input and output stage, with a lot of different ways to go - and I neither mentioned the connection with audio drivers and other parts of the system.
Regards, Volker
Texto en Español:
(Esto es de un programador de MAGIX)
Esto fue posteado hace algun tiempo en el foro de Samplitude. Es el unico comentario que se ha hecho sobre este tema por alguien que de hecho se dedica a esto (al menos que yo haya visto personalmente)
Puedo tratar de dar algunos comentarios aqui, pero no digo que terminare de una vez y para siempre con este debate. Este es mi punto de vista personal, asi que no tomen esto como una declaracion oficial de MAGIX.
Como programador (y cientifico) tiendo mucho al punto de vista determinista: solo añadir dos numeros deberia dar lo mismo en todas cirunstancias, y dado que las tareas de mezcla basicas deberian de ser las mismas para todos los DAW´s de 32 bits de coma flotante, si tomas el simple proceso de añadir como un metodo comun para mezclar, pero sabemos que puede haber otros metodos aqui.
Tambien se que debido a la representacion de numeros en la computadora, no hay solamente una limitada precision, si no tambien hay cierto "factor aleatorio" en los calculos con numeros de coma flotante. Esto es causado basicamente por la representacion del codigo compilado en el sistema (la inicializacion de registros de coma flotante con procesamiento de mas de 32 bits, uso de registros en contra del uso de memoria de computadora...) y la ejecucion de el codigo en el sistema real (por ejemplo: la influencia de otras tareas, ejemplo: multiples tareas). Ambas dependen parcialmente de los compiladores usados, pero por supuesto que tambien del codigo de programacion con el que esta escrito. Un reciente ejemplo podria ser un problema con el volumen del master en las primeras versiones betas de la version 8 (Samplitude) donde cambiaba la profundiad de bit incluso cuando inicializaba con exactamente 0db (= factor 1.0 en coma flotante).
Un paso obvio despues de la suma, antes de ir a la salida es reducir la profundidad de bit otra vez a 24 o 16 bit. Esto consiste en al menos 3 pasos: clipping, scaling y dithering. Cada paso puede ser implementado de varias formas. *Clipping puede ser hecho sencillo o mas sofisticado, ambos con posibles riesgos para la señal de audio – por por supuesto esperando que al menos comunmente solo sea presente en las partes mas fuertes (con mas volumen) del audio. *Scaling puede ser hecho antes o despues del summing (ambos son por ejemplo posiblemente influenciados por el usuario en Samplitude con las opciones de ganancia de entrada o el fader del master. Ya que el scaling tambien se aplica a la entrada, existen muchas cosas que se pueden hacer de forma diferente. Incluso las discuciones sobre los ajustes de las leyes de paneo pueden entrar aquí. Dado que los motores basados en integros requieren el scaling antes del summing, puedo imaginar facilmente diferentes metodos en otros DAW´s. *Dithering: no hay mucho que decir sobre esto: existen mas algoritmos de los que podemos pensar aquí. La mayor “ditherencia” pudiera ser su aplicación para pasos intermedios cuando es necesario.
Asi que yo veo varias posibles razones para un comportamiento diferente y aun para un mal-comportamiento. Y muy comunmente he visto o escuchado los resultados – no solo en otros DAW´s, si no tambien parcialmente en el nuestro (algunos tal vez todavia recuerden un problema de dithering en la version 5.1).
Un problema no mencionado comunmente parece ser la representacion de la linea de tiempo del material de audio. Es seguro que existe una diferencia entre el sistema usado ya sea “basado en muestras” o “PPQ”. El primero da como resultado: reproduccion de audio perfecta, pero posibles problemas con loops y valores BPM, mientras que el ultimo puede sacrificar facilmente lo primero en favor del BPM.
Asi que para resumir: Si, el simple hecho de añadir numeros, basicamente deberia de dar el mismo resultado, pero aun puede haber un poco de voodo aquí – aunque puede ser dificil darse cuenta de las diferencias. Las razones mas obvias para las diferencias de sonido, son las desiciones sobre el procesamiento en las secciones de entrada y salida, con muchas formas diferentes de actuar – y ni siquiera he mencionado las conexiones con los drivers de audio y otras partes del sistema.
Saludos, Volker.
.
