La calidad de audio de los DAW

Ok, nada de frecuencias de muestreo. Cierto.

Reaper es un gran programa y admiro a su equipo de desarrollado por su filosofía, calidad y dedicación. Lo tengo instalado y lo voy trasteando. Es un futuro aspirante. Llegado el momento no me importaria usar otro DAW si me ofrece lo que necesito. Pero de momento, hoy por hoy, sigo prefiriendo usar Logic a secas.

Sea como fuere esta bien llegar a comprender estos conceptos 'científicamente' para quitarse muchas tonterías de encima.
Aunque creo que el mayor problema está cuando mezclamos el audio con la música. Son dos mundos diferentes obligados a coexistir. E imagino que de aquí salen todas las disputas y subjetividades.

Hola DeLoreal,

gracias por el saludo, no recuerdo la tal conversación en otro hilo, si lo tienes por ahí postea un link así lo revisamos.

En cualquier caso, sigo siendo exceptico incluso después de atender a la clase magistral de matemática, sobre la posibilidad o no de que dos sumas suenen distintas, con una diferencia perceptible. Más allá de toda matemática, la forma de averiguarlo es siempre la misma: dos sumas supuestamente iguales, invertida la fase en una de ellas, deberían producir silencio absoluto. Si no es así, hay diferencias. Ahora bien, si resulta que inviertes la fase de una de las mezclas y hay silencio, y sin embargo tienes la impresión de que ambas suenan diferente, es porque escuchas diferencias en tu cabeza que no exísten en la realidad. Tengo la impresión - pero puedo equivocarme - de que esto ha ocurrido muy a menudo, y se ha posteado en internet en muchas ocasiones, y lo que es más alucinante: ha dado pié a la existencia de un mercado increíble de 'sumadores', que cuestan un ojo de la cara y en la mayoría de los casos no hacen nada, o al menos nada que justifique los precios.

Salu2.

Alguien escribió:

Los sumadores digitales (caso de los DAW) no tienen cualidades propias como un sumador analógico.

En cuanto a teoría matemática binaria, tu explicación me parece perfecta.
Pero no crees que todo eso, que cualquiera puede consultarlo en Wikipedia, a un músico no le sirve para nada ?, puedes ser un experto en algebra Booleana y saber matemática quántica, etc, pero eso no te va a ayudar a hacer buenas mezclas, ni a saber elegir un buen motor de audio.

Si conoces la Tasa de Nyquist, Ley de Hartley, etc, etc, si te ayudara a mezclar y aplicar EQ’s, pero tampoco
te va a ayudar a saber elegir un buen motor de audio.

Un sumador analógico teóricamente solo tiene defectos y no cualidades (ruido termico, problemas de impedancias, inductancias, reluctancias, etc, etc)
Un sumador digital teóricamente puede ser “cuasi perfecto”.

Alguien escribió:

Sin embargo pueden perder información o no perderla. Se supone que los buenos son los que no la pierden.

Cierto…se supone, como el valor en la mili.

Y todo esto esta muy bien, pero en este debate, no veo ninguna mención a:

Desfase en frecuencias, generación/cancelación de armónicos pares (colesterol bueno), e impares (colesterol malo) que por ejemplo pueden hacer Que un LA 440 Hz, generando el primer armónico impar 660 Hz es igual a añadirle un MI desentonado, y el 2º impar añadiría un DO desentonado.
Alteraciones y distorsiones de fase, etc, etc.

Todo el asunto gira en torno al número de bits en el summing, y a mi esto me parece, utilizando un símil porno, que lo importante en un motor de audio es “quien la tiene mas grande”, esto se podría llamar “Pene_bits”, y en base a esto parece ser que el “que la tiene mas grande” es ProoTools, enhorabuena
Pero hay quien asegura siguiendo con el símil “que esto es cierto, pero no sabe follar”.
Y es esto y solo esto, lo que diferencia unos motores de otros, teniendo en cuenta que todos operan como mínimo en 32 bits coma flotante.

El que asegure que todos los motores de audio son iguales, y lo único importante son los “Pene_bits”, no sabe lo que es un motor de audio.

Por lo tanto el factor decisivo en la calidad, transparencia y ausencia de coloración de un buen motor de audio, esta en los algoritmos de calculo (el Codigo Da Vinci) de cada software, y curiosamente habéis mencionado muchos DAW’s, y habéis ignorado al que tiene el mejor motor de audio conocido a día de hoy, Samplitude.

Si queréis hacer un debate constructivo que enseñe algo a la gente, hacer una prueba con un arreglo con mucha orquestación, con instrumentos difíciles de mezclar,como secciones de metales, colchones reverberantes, pianos, guitarras eléctricas, bajos SlapFunk, baterías brutas, o sea un tema con gran densidad instrumental.
Involucrando EQ’s comprometidas, compresores, limitadores, envíos y subgrupos.

Apuntáis todos los parámetros y hacéis el mismo arreglo en 2 o mas DAW’s, con EXACTAMENTE los mismos parámetros, bounceais los audios, hacéis los Masters y los comparáis, y veréis la cantidad de sorpresas que vais a tener, y los responsables de ello no serán los “Pene_bits” del DAW, si no sus algoritmos de cálculo.

Y eso es que yo he hecho, y lo tenéis en este foro para quien le interese:
samplitude-cubase-batalla-los-motores-audio-t273305.html

Es mi opinión.
Un saludo

Fran1946 escribió:

Alguien escribió:

Los sumadores digitales (caso de los DAW) no tienen cualidades propias como un sumador analógico.

En cuanto a teoría matemática binaria, tu explicación me parece perfecta.
Pero no crees que todo eso, que cualquiera puede consultarlo en Wikipedia, a un músico no le sirve para nada ?, puedes ser un experto en algebra Booleana y saber matemática quántica, etc, pero eso no te va a ayudar a hacer buenas mezclas, ni a saber elegir un buen motor de audio.

Si conoces la Tasa de Nyquist, Ley de Hartley, etc, etc, si te ayudara a mezclar y aplicar EQ’s, pero tampoco
te va a ayudar a saber elegir un buen motor de audio.

Un sumador analógico teóricamente solo tiene defectos y no cualidades (ruido termico, problemas de impedancias, inductancias, reluctancias, etc, etc)
Un sumador digital teóricamente puede ser “cuasi perfecto”.

Alguien escribió:

Sin embargo pueden perder información o no perderla. Se supone que los buenos son los que no la pierden.

Cierto…se supone, como el valor en la mili.

Y todo esto esta muy bien, pero en este debate, no veo ninguna mención a:

Desfase en frecuencias, generación/cancelación de armónicos pares (colesterol bueno), e impares (colesterol malo) que por ejemplo pueden hacer Que un LA 440 Hz, generando el primer armónico impar 660 Hz es igual a añadirle un MI desentonado, y el 2º impar añadiría un DO desentonado.
Alteraciones y distorsiones de fase, etc, etc.

Todo el asunto gira en torno al número de bits en el summing, y a mi esto me parece, utilizando un símil porno, que lo importante en un motor de audio es “quien la tiene mas grande”, esto se podría llamar “Pene_bits”, y en base a esto parece ser que el “que la tiene mas grande” es ProoTools, enhorabuena
Pero hay quien asegura siguiendo con el símil “que esto es cierto, pero no sabe follar”.
Y es esto y solo esto, lo que diferencia unos motores de otros, teniendo en cuenta que todos operan como mínimo en 32 bits coma flotante.

El que asegure que todos los motores de audio son iguales, y lo único importante son los “Pene_bits”, no sabe lo que es un motor de audio.

Por lo tanto el factor decisivo en la calidad, transparencia y ausencia de coloración de un buen motor de audio, esta en los algoritmos de calculo (el Codigo Da Vinci) de cada software, y curiosamente habéis mencionado muchos DAW’s, y habéis ignorado al que tiene el mejor motor de audio conocido a día de hoy, Samplitude.

Si queréis hacer un debate constructivo que enseñe algo a la gente, hacer una prueba con un arreglo con mucha orquestación, con instrumentos difíciles de mezclar,como secciones de metales, colchones reverberantes, pianos, guitarras eléctricas, bajos SlapFunk, baterías brutas, o sea un tema con gran densidad instrumental.
Involucrando EQ’s comprometidas, compresores, limitadores, envíos y subgrupos.

Apuntáis todos los parámetros y hacéis el mismo arreglo en 2 o mas DAW’s, con EXACTAMENTE los mismos parámetros, bounceais los audios, hacéis los Masters y los comparáis, y veréis la cantidad de sorpresas que vais a tener, y los responsables de ello no serán los “Pene_bits” del DAW, si no sus algoritmos de cálculo.

Y eso es que yo he hecho, y lo tenéis en este foro para quien le interese:
samplitude-cubase-batalla-los-motores-audio-t273305.html

Es mi opinión.
Un saludo

Sera que en este debate no vez lo que buscas por que no es esa la orientacion que se le quiso dar al debate, si quieres discutir esos temas, pues abre un hilo con esos temas. Si consideras que esto no aporta nada a hacer buenas mezclas, pues que lastima, pero quienes queremos conversar de esto en este momento nos estamos abstrayendo de ese enfoque, aca en el foro hay cavida para los temas que los usuarios encuentren interesantes debatir (siempre y cuando se mantengan dentro de las normas) no entiendo por donde va tu inervension. Ahora de verdad me parece que sabes algo, pero hasta por ahi nada mas, podrias nombrar aquellos algoritmos de calculo particulares que hacen la diferencia de un motor de audio a otro? de cuantas formas diferentes segun tu se puede sumar en binario? sera que te refieres a los procesos aplicados? EQ? Compresion? que eso no depende ya de cada plugin y como este se relacione con el motor de audio? no se, como que me queda la duda de si eres todo un crack en la materia o simplemente tubiste una intervension a lo chavo del 8. Me confunde leer cosas com esta.

Alguien escribió:

podrias nombrar aquellos algoritmos de calculo particulares que hacen la diferencia de un motor de audio a otro?

Pues por ejemplo, todos y cada uno de los que se utilizan en procesadores DSP, que segun la teoria simplista, de que todo se reduce simplemente a suma binaria, pues hay compañias muy poderosas que cuentan con ingenieros en electroacustica muy cualificados y que gastan millones en investigacion, que son tan imbeciles, que no se han enterado que en vez de gastar dinero en elaborar nuevos algoritmos, lo que deben de hacer es elaborar un codigo con unas poquitas sumas binarias y hala ya esta.

[code]de cuantas formas diferentes segun tu se puede sumar en binario? [/code]

Sumar solo de una.
Pero ademas se pueden hacer con chips y cacular funciones como:
AND, OR, XOR, XNOR, NOT, NAND y NOR, todas esas, que son las unicas que una CPU tiene, aparte de buffers y cedulas de memoria (eso si son millones).
Por que un chip solo sabe sumar y restar bits, pero a una velocidad altisima, y todas las puertas que he mencionado, son las responsables de todas las operaciones matematicas del procesador numerico interno que tienen las CPU's en la actualidad (hace años ni siquiera lo tenian), por eso hoy es posible hacer emulaciones virtuales en "tiempo real" que es mentira, una CPU solo puede hacer una cosa a la vez, pero es tan rapida que parece que hace 300 en realidad.

Y como veo que desconoces por completo la logica binaria y la programacion, te dire que dentro de un DAW (cualquiera), solo hay codigo binario (que a traves de esas puertas que he mencionado) se comunican con la CPU, atraves de un lenguaje de alto nivel (en la actualidad, en mis tiempos solo en Ensamblador, y antes solo en codigo maquina) y seguro que todos los que mencionais, escritos en C.

Por lo tanto el que un DAW haga 129 virguerias en MIDI y 653 en Audio, que tenga unos VU's preciosos y una latencia bajissssima, etc, etc, es debido a unos señores que programan rutinas de codigo y algoritmos de calculo muy elaborados y complejos.
Y por eso y solo por eso... unos DAW's hacen mas virguerias que otros y suenan sus motores de audio mejor que otros.
Y tambien por eso mismo, hay Editores de video muy malos y otros muy buenos (y los procesos de videos son muchisimo mas complejos que en audio), en la mal llamada "Realidad virtual, si es real no es virtual" por sistemas informaticos, todo es codigo y algoritmos.

Si no, yo que fui programador hace ya muchos años, si supiera sumar en binario como vosotros, me pondria a hacer mañana mismo mi propio DAW, y le haria la competencia a los actuales, y ademas molaba con los amiguetes.

Y hasta aqui puedo leer.

Fran1946 escribió:

Alguien escribió:

podrias nombrar aquellos algoritmos de calculo particulares que hacen la diferencia de un motor de audio a otro?

Pues por ejemplo, todos y cada uno de los que se utilizan en procesadores DSP, que segun la teoria simplista, de que todo se reduce simplemente a suma binaria, pues hay compañias muy poderosas que cuentan con ingenieros en electroacustica muy cualificados y que gastan millones en investigacion, que son tan imbeciles, que no se han enterado que en vez de gastar dinero en elaborar nuevos algoritmos, lo que deben de hacer es elaborar un codigo con unas poquitas sumas binarias y hala ya esta.

[code]de cuantas formas diferentes segun tu se puede sumar en binario? [/code]

Sumar solo de una.
Pero ademas se pueden hacer con chips y cacular funciones como:
AND, OR, XOR, XNOR, NOT, NAND y NOR, todas esas, que son las unicas que una CPU tiene, aparte de buffers y cedulas de memoria (eso si son millones).
Por que un chip solo sabe sumar y restar bits, pero a una velocidad altisima, y todas las puertas que he mencionado, son las responsables de todas las operaciones matematicas del procesador numerico interno que tienen las CPU's en la actualidad (hace años ni siquiera lo tenian), por eso hoy es posible hacer emulaciones virtuales en "tiempo real" que es mentira, una CPU solo puede hacer una cosa a la vez, pero es tan rapida que parece que hace 300 en realidad.

Y como veo que desconoces por completo la logica binaria y la programacion, te dire que dentro de un DAW (cualquiera), solo hay codigo binario (que a traves de esas puertas que he mencionado) se comunican con la CPU, atraves de un lenguaje de alto nivel (en la actualidad, en mis tiempos solo en Ensamblador, y antes solo en codigo maquina) y seguro que todos los que mencionais, escritos en C.

Por lo tanto el que un DAW haga 129 virguerias en MIDI y 653 en Audio, que tenga unos VU's preciosos y una latencia bajissssima, etc, etc, es debido a unos señores que programan rutinas de codigo y algoritmos de calculo muy elaborados y complejos.
Y por eso y solo por eso... unos DAW's hacen mas virguerias que otros y suenan sus motores de audio mejor que otros.
Y tambien por eso mismo, hay Editores de video muy malos y otros muy buenos (y los procesos de videos son muchisimo mas complejos que en audio), en la mal llamada "Realidad virtual, si es real no es virtual" por sistemas informaticos, todo es codigo y algoritmos.

Si no, yo que fui programador hace ya muchos años, si supiera sumar en binario como vosotros, me pondria a hacer mañana mismo mi propio DAW, y le haria la competencia a los actuales, y ademas molaba con los amiguetes.

Y hasta aqui puedo leer.

A ver, hay que tener cuidado con lo que se dice, conoces la arquitectura x86? sabes que la cualidad de esta arquitectura es la alta complejidad de sus instrucciones? van mucho mas allá de simples compuertas lógicas, claro que estas compuertas son la base para estas instrucciones, pero si queremos hilar fino la base de todo es el transistor. EL error en tu enfoque, es que estas mezclando lo que hace el DSP, o un plugin, con la labor del motor de audio. Ahora creo que estas dando atribuciones al motor de audio que en realidad no tiene, todos los procesos que comentas son parte de la arquitectura del secuenciador, pero no propiamente tal el motor de audio.

Bueno, Fran1946, tu preguntabas para qué sirve un hilo como este a un músico.

Yo te lo digo: para que no venga luego un cantamañanas con inventos pseudo científicos (más o menos como el concepto de 'motor de audio', que suena muy razonable pero no sabríamos decir qué es) a explicarte que o te compras un sumador Neve o no puedes mezclar bien.

Haciéndo un resumen: en este hilo se intentó explicar qué es una suma digital, y las posibilidades más usuales de implementar dicha suma en distintos secuenciadores, de lo cual se deduce que, en principio, los secuenciadores con un motor de suma con las mismas características sonarán igual, y que si hay alguna diferencia entre secuenciadores en cuanto a la suma, esta será difícilmente audible.

Luego vienes tu y más o menos tratas de decir que esto es un enfoque simplista, porque hay más variables a considerar. ¿Podrías decir exáctamente que variables son esas? ¿Cuales son los otros procesos que realiza el tan cacareado 'Motor de Audio'?

Respecto a hacer pruebas subjetivas, de mezclar del mismo modo las mismas pistas en dos secuenciadores y ver que pasa, hay una sola prueba fiable para eso: importas las dos mezclas resultantes en un daw, las pones para que se reproduzcan simultáneamente y a una le inviertes la polaridad. Lo que encontrarás es que cada vez que hagas eso el resultado será silencio (señal de que ambas sumas son idénticas), y si encuentras una diferencia será absolutamente mínima, y sería bueno apuntar qué DAW es el que ha producido esa pista (probablemente Cubendo!), que tiene un algoritmo de suma defectuoso.

La conclusión importante de este hilo es que los algoritmos de suma de audio digital no conviene clasificarlos en 'suena mejor' o 'suena peor' como si se tratara de un pedal de guitarra. Conviene clasificarlos en 'correctos' e 'incorrectos'. Porque se trata de SUMAR, y si te digo que dos más dos es tres no me dirás que suena mejor o peor, me dirás que mi suma es incorrecta.

Salu2.

Más sobre el tema del 'Motor de Audio': reaper ocupa en total un poco más de cuatro megas. Es obvio que su 'motor de audio' ha sido programado a muy bajo nivel, de otro modo ocuparía más. ¿Quiere esto decir que es mejor que el de Samplitude?

Vamos a hablar del motor de audio. Olvidate por un momento de valores de performance, como ser la latencia. Un motor de audio consiste en:

a. Leer una cantidad de pistas del disco duro.
b. Reproducirlas simultáneamente sin perder información y respetando la sincronización de cada una a nivel de sample.

Esto es lo más básico.

Luego, los 'procesos DSP' que típicamente hace un DAW son en realidad uno solo: ganancia. Porque fíjate que los faders aplican una ganancia (positiva o negativa) y el pan pot hace lo mismo: solo que lo hace de forma inversamente proporcional en dos canales).

El resto son plugins (aunque tu DAW te lo de incorporado en una pestaña, una EQ es un plugin).

Y la ganancia es una multiplicación, si no me equivoco. ¿Verdad?

Con ella ocurre exáctamente lo mismo que con la suma: no hay resultados mejores y peores, o el resultado es correcto o o no lo es, punto pelota.

Y luego la sincronía o como se llame: ¿es capaz el 'motor de audio' de reproducir las pistas, luego de realizar estos procesos (multiplicaciones varias) respetando sus posiciones relativas a nivel de sample? O bien es capaz, o bien no lo es, y una cosa es correcta y la otra no. Sobre este último punto no hemos hablado, pero me da a mí que la sincro se conservará en todos los DAW salvo errores muy flagrantes. ¿No?

Salu2.

Alguien escribió:

reaper ocupa en total un poco más de cuatro megas. Es obvio que su 'motor de audio' ha sido programado a muy bajo nivel

Justamente es lo contrario de lo que dices.
El lenguaje de mas bajo nivel que existe, es Emsamblador.
Si el codigo del motor de Reaper es de 4 Mb, sin lugar a dudas esta programado en lenguaje de alto nivel (casi seguro en C), si fuera de bajo nivel (es dificil saberlo con exactitud, sin conocer y compilar el codigo), no llegaria a 500 Kb.

[code]a. Leer una cantidad de pistas del disco duro.
b. Reproducirlas simultáneamente sin perder información y respetando la sincronización de cada una a nivel de sample.[/code]

Si para ti un motor de audio es solo eso, estoy de acuerdo contigo.

[code]Luego, los 'procesos DSP' que típicamente hace un DAW son en realidad uno solo: ganancia. Porque fíjate que los faders aplican una ganancia (positiva o negativa) y el pan pot hace lo mismo: solo que lo hace de forma inversamente proporcional en dos canales).
El resto son plugins (aunque tu DAW te lo de incorporado en una pestaña, una EQ es un plugin).[/code]

Esto para mi tambien forma parte del motor de audio de un DAW, y es precisamente aqui donde estan las diferencias a las que me refiero.
Por que en motores de coche, de la misma, cilindrada, par motor, HP's, nº de cilindros, mismo tipo y combustible, etc, etc
no hay diferencias, solo giran y aportan HP's, pero un motor solo no mueve un coche, necesita "pulgins" como, cajas de cambios, palieres, embrague, transmisiones, etc, etc, y esto forma parte del motor, y es tambien lo que diferemcia las prestaciones del coche ademas de cuestiones de aerodinamica.

Alguien escribió:

Y la ganancia es una multiplicación, si no me equivoco. ¿Verdad?

O una suma o una division, y dado que la base aritmetica es suma/resta, con combinaciones de estas se hacen multiplicaciones, divisiones y todos los calculos matematicos que existen.

Alguien escribió:

Con ella ocurre exáctamente lo mismo que con la suma: no hay resultados mejores y peores, o el resultado es correcto o o no lo es, punto pelota.

Si trabajas con enteros NO.
Con enteros es imposible sumar 5.23+12.85=18.08, sin perder informacion, el resultado seria = 17, perderias 1.08, que en audio puede ser cualquier cosa menos "correcto". Por eso se calcula en coma flotante, como ya se ha comentado en el hilo, 64 bits no mejora el resultado (audible), solo carga mas la CPU, pero si tienes un quad core, no hay problema.

Alguien escribió:

Y luego la sincronía o como se llame: ¿es capaz el 'motor de audio' de reproducir las pistas, luego de realizar estos procesos (multiplicaciones varias) respetando sus posiciones relativas a nivel de sample? O bien es capaz, o bien no lo es, y una cosa es correcta y la otra no. Sobre este último punto no hemos hablado, pero me da a mí que la sincro se conservará en todos los DAW salvo errores muy flagrantes. ¿No?

Esto tiene tela, y es muy largo y complicado para discutirlo aqui, y debido a que intervienen una cantidad enorme de parametros no es tan facil ni radical como "O bien es capaz, o bien no lo es", tambien forma parte de las diferencias entre DAW's.

Un saludo.

Alguien escribió:

A ver, hay que tener cuidado con lo que se dice, conoces la arquitectura x86?

En en su dia, hace ya muchos años, perfectamente.

[code]sabes que la cualidad de esta arquitectura es la alta complejidad de sus instrucciones? [/code]

Si, a traves de nemotecnicos en Emsamblador.

[code]van mucho mas allá de simples compuertas lógicas[/code]

No, no hay mas allá, simplemente no tiene nada que ver las instrucciones nemotecnicas (que dan ordenes a la CPU) con las puertas logicas, que son meros circuitos integrados.

[code]claro que estas compuertas son la base para estas instrucciones, pero si queremos hilar fino la base de todo es el transistor.[/code]

No, en su dia, fue el diodo de germanio, luego silicio, y con la union de estos posteriormente los transistores de germanio, luego silicio, pero creo que con estas discusiones nos alejamos del tema y no conducen a nada.

[code]EL error en tu enfoque, es que estas mezclando lo que hace el DSP, o un plugin, con la labor del motor de audio. Ahora creo que estas dando atribuciones al motor de audio que en realidad no tiene, todos los procesos que comentas son parte de la arquitectura del secuenciador, pero no propiamente tal el motor de audio[/code]

No es un error, es una apreciacion diferente, a lo sumo "un error de apreciacion", citame alguna referencia cientifica donde diga que un motor de audio, es lo que tu dices, y entonces rectificare mi "error".

P.D.
Odio escribir sin acentos, pero tengo este ordenador hecho una mierda, y no me deja ponerlos, cuando tenga tiempo lo arreglo.
Y como ya estan claras mi vision de enfoque sobre motores de audio, creo que es esteril al menos para mi, seguir polemizando sobre el asunto.

Por mi parte doy por zanjado esta discusion, que solo es una opinion mas, compartible o no, pero eso es todo.
Si he herido la susceptibilidad de alguien, le pido disculpas, no era esa mi intencion.

Saludos.

Tío, no soy experto, pero está claro que una buena parte de lo que dices no tiene pies ni cabeza, perdona que te lo diga así.

1. Reaper es el secuenciador más pequeño del mercado en cuanto a su tamaño, y no le faltan funcionalidades. En esos poco más de cuatro megas viene una considerable colección de plugins, todo el motor de edición, el MIDI, la interface gráfica, codecs, etc. ¿Cuanto ocupa Samplitude para contener lo mismo? Unas 10 veces más como mínimo, ¿Verdad? Osea que, ¿Cual está programado a más bajo nivel, a juzgar por el tamaño? El único DAW que conozco que ocupa menos es SAW, pero no tiene ni la mitad de funcionalidades. Su autor declara que está programado en Assembler. Ocupa más o menos la mitad que Reaper. Si tuviera que apostar, diría que Reaper está programado a muy bajo nivel, al menos en cuanto a su motor de audio. Por otro lado, programar en C es algo muy versátil, se puede hacer a muy bajo nivel, si utilizas tus propias librerías, que creo que es lo que hacen los de Reaper (en la web de Cockos puedes descargarte una librería hecha por ellos).

2. El motor de audio. Parece que no has entendido lo que dije. Efectivamente, el algoritmo de ganancia es parte del motor de audio, según creo, y así es como lo intenté decir en mi post anterior. Ahora bien, lo que intentaba explicar es que consiste en multiplicaciones (que, vale, se descomponen en sumas y restas - o no, como apuntaban arriba, los nuevos procesadores son un poco más complejos que un Z80 - yo también aprendí a programar en assembler hace unos cuantos años...). Como este también es un proceso matemático sin mayor complicación, nuevamente se puede hacer bien o no, pero no es que puedan haber 'diferencias': dos motores que hagan estas multiplicaciones tomando el mismo tipo de números - 64bits coma flotante, por ejemplo - tienen que dar y darán los mismos resultados.

¿Podrías explicar las diferencias exáctas a las que te refieres, sin recurrir a metáforas con coches y cosas así? Imagino que no, no puedes, y las metáforas no son muy válidas en tanto no estamos hablando de literatura sino de matemáticas. Pero igual me equivoco, vaya.

3. Lo de trabajar con enteros: por un lado es irrelevante lo que dices y por otro lado te equivocas. Como se explicó más arriba, incluso con enteros puedes tener un nivel de precisión muy alto si transformas los enteros a un número con más digitos que el original. Tomemos tu ejemplo. Dices que si trabajas con enteros es imposible hacer esto:

5.23+12.85=18.08

Efectivamente, por definición, si trabajas con enteros es imposible hacer eso porque no tendrías esos números, tendrías estos:

5+12=17

O bien tendrías estos:

523+1285=1808

Lo que no tiene ningún sentido es que tengas en la entrada números con decimales y en la salida números enteros. Es decir: lo que no tiene ningún sentido (y los motores de audio no trabajan así) es que tengas una mayor resolución en la entrada y menor resolución en la salida.

En la entrada de un motor de audio tienes típicamente números de 24 bits. El motor de audio aumenta esta resolución agregando bits: ya sea aumentando esos 24 a 32 o 48 o 64, y pasándo los números a coma flotante. Con lo cual tienes una resolución muchas veces mayor dentro del motor de audio. Sería algo así:

Quieres sumar 5.23 más 12.85, y primero los transformas en:

52300000 y 128500000, luego los sumas, te da 180800000 y luego descartas los bits sobrantes, osea que tienes 1808.

Algo así.

Si no se aumenta la resolución, pueden haber pérdida de bits, por este motivo:

101011011100101000111101
+
110010011110101001000101

Te va a dar un número con más de 24 bits.

Ahora bien, en términos de audio, la resolución que te dan 24 bits son 144 db, que implican un rango dinámico prácticamente imposible de abarcar para el oído humano. Si escucharas audio a 24 bits de forma que fueras realmente capaz de escuchar el noise floor producido por el último bit, osea:

000000000000000000000001

Entonces el sonido más alto:

111111111111111111111111

Estaría muy por encima del umbral del dolor. No sé si me explico.

3. Por último, lo de la sincronía. Dices que hay mucho que discutir sobre este punto: parecería que sabes sobre el tema. Te invito entonces a que expongas. Te aclaro una cosa: nunca había leído ni escuchado nada sobre el hecho de que mantener la sincronización entre pistas pueda ser un problema dentro de un DAW - me lo inventé en mi post anterior a ver que decías.

En fin. Lo dicho: yo que no se tanto he leído encantado este hilo, donde gente que sabe mucho más que yo intentaron explicar un tema muy complejo, y les invito a que prosigan, que me interesa leer.

A tí también te invito a seguir leyendo.

Salu2.

dientedesierra escribió:

moa escribió:

Pues ya que estamos y ya veo que dominas un montón sobre el tema, una preguntita sobre el dithering. ¿Puede llegar a ser contraproducente grabar a elevadas frecuencias de muestreo cuando luego el resultado final ha de reducirse a la frecuencia de muestreo del CD? ¿Se pueden producir pérdidas de información en esa transformación mas graves que la información extra que hemos añadido previamente durante el proceso de grabación?

Vaya tela... esto yo creo que es interminable debido a lo subjetivo del asunto, pero voy a decir la mía a ver que me contestan los 'eruditos':

Hasta donde yo llego, la idea por la que grabo y mezclo a 24 bits, es simplemente para aprovechar ese 'margen dinámico' y, de este modo, poder trabajar de un modo mas preciso la mezcla. Es decir, para oír con mas claridad y así tomar decisiones mas acertadas tanto en en la aplicación de dinámica, eq, y demás. Las ventajas de usar mayor resolución y mayor freq de muestreo no se limitan únicamente a la mezcla (o edición, etc..) ya que, aunque posteriormente esa mezcla acabará en 16bit/44KHz, esa quantización se hará sobre el resultado anterior...
Como en un cuadro... Trabajaré mejor en un lienzo de 1,5x1,2 m que en un dinA4, aunque luego la foto la vaya a exponer en dinA4.

Todo esto teniendo en cuenta que se trabaja con el equipo adecuado.

Casi que da miedo soltar este comentario...
1 porque debe ser una delas preguntas mas repetidas en foros de mastering y
2 porque igual estoy diciendo una barbaridad

Ahí lo dejo.

El problema es que al ser convertido a la frecuencia menor debe pasar por un proceso de filtrado, el cual puede hacerse de diferentes maneras. Aquí ya interviene la subjetividad, porque no se puede decir que haya un método que sea el "objetivo".

En todo caso seguiré tu metáfora del lienzo. Si vas a crear una versión de icono de 16x16 píxeles (de los pequeños que salen en Windows), ¿es más preciso trabajar con una imagen grande y luego reducirla? La imagen grande es más precisa desde luego, pero la reducción tiende a crear una imagen difuminada. El caso es que yo algunas veces he tenido que crear uno de esos pequeños iconos para algún programa. A pesar de tener las versiones de 64x64 y 32x32 casi siempre he tenido que diseñar una versión propia trabajando directamente sobre el 16x16, de otra manera se perdía el detalle del concepto visual que tenía que representar. Ahí queda la reflexión.

Alguien escribió:

Pero no crees que todo eso, que cualquiera puede consultarlo en Wikipedia, a un músico no le sirve para nada ?, puedes ser un experto en algebra Booleana y saber matemática quántica, etc, pero eso no te va a ayudar a hacer buenas mezclas, ni a saber elegir un buen motor de audio.

El hilo surgió por el interés compartido de analizar que factores influyen en las posibles diferencias cualitativas de los motores de audio entre diversos DAW. Es lo que es y cada uno que valore si le es de interés este hilo.

Alguien escribió:

Y todo esto esta muy bien, pero en este debate, no veo ninguna mención a:

Desfase en frecuencias, generación/cancelación de armónicos pares (colesterol bueno), e impares (colesterol malo) que por ejemplo pueden hacer Que un LA 440 Hz, generando el primer armónico impar 660 Hz es igual a añadirle un MI desentonado, y el 2º impar añadiría un DO desentonado.
Alteraciones y distorsiones de fase, etc, etc.

No sé qué tiene eso que ver con lo que se habla aquí. Los plugins quedan fuera del análisis, pues hay miles de ellos y con muchos algoritmos diferentes.

Alguien escribió:

Todo el asunto gira en torno al número de bits en el summing, y a mi esto me parece, utilizando un símil porno, que lo importante en un motor de audio es “quien la tiene mas grande”, esto se podría llamar “Pene_bits”, y en base a esto parece ser que el “que la tiene mas grande” es ProoTools, enhorabuena

Perdona, pero creo que no se dice eso aquí. Se dice cuando son necesarios más bits y cuando no. En cuanto a ProTools se habla de él para estudiar el caso del punto fijo (y porque se cuenta con más información de su motor que otros), no se dice que sea el mejor. Tampoco es el que mayor profundidad de bits tiene.

Alguien escribió:

Alguien escribió:

podrias nombrar aquellos algoritmos de calculo particulares que hacen la diferencia de un motor de audio a otro?

Pues por ejemplo, todos y cada uno de los que se utilizan en procesadores DSP, que segun la teoria simplista, de que todo se reduce simplemente a suma binaria, pues hay compañias muy poderosas que cuentan con ingenieros en electroacustica muy cualificados y que gastan millones en investigacion, que son tan imbeciles, que no se han enterado que en vez de gastar dinero en elaborar nuevos algoritmos, lo que deben de hacer es elaborar un codigo con unas poquitas sumas binarias y hala ya esta.

No hay ningún algoritmo extravagante de DSP en un motor de audio. Otra cosa son los plugins (aunque vengan integrados), que aquí no vamos a comparar, obviamente.

Alguien escribió:

El lenguaje de mas bajo nivel que existe, es Emsamblador.
Si el codigo del motor de Reaper es de 4 Mb, sin lugar a dudas esta programado en lenguaje de alto nivel (casi seguro en C), si fuera de bajo nivel (es dificil saberlo con exactitud, sin conocer y compilar el codigo), no llegaria a 500 Kb.

Al C no se le considera lenguaje de alto nivel, es el más bajo que hay después del ensamblador. Las diferencias de tamaño del código no vienen dadas por el lenguaje utilizado sino por las librerías de código que incluyen. Un compilador de C actual genera un código muy eficiente, prácticamente a la par de uno optimizado directamente en ensamblador, pero mucho más mantenible y estructurado. Solo para puntos claves de un algoritmo puede ser necesario insertar código en ensamblador. En el resto no va a ver diferencia apreciable. Y el C++ con plantillas es capaz de generar versiones muy especializadas de código usando una misma metaclase. Hoy en día escribir un programa entero en ensamblador es de masoquistas, además de un nido de bugs.

Alguien escribió:

Si trabajas con enteros NO.
Con enteros es imposible sumar 5.23+12.85=18.08, sin perder informacion, el resultado seria = 17, perderias 1.08, que en audio puede ser cualquier cosa menos "correcto". Por eso se calcula en coma flotante, como ya se ha comentado en el hilo, 64 bits no mejora el resultado (audible), solo carga mas la CPU, pero si tienes un quad core, no hay problema.

ElHombreRana te lo ha explicado. Con enteros se puede trabajar con la precisión que quieras mientras tengas bits disponibles. Solo es cuestión de desplazar los bits a la izquierda para alojar lo bits decimales. A eso se le llama punto fijo. En el caso de PTHD (que es el que trabaja en ese formato) tiene 24 bits "decimales" en el bus de mezcla. Lo pongo entre comillas porque la aritmética es la misma que considerando a todos los bits enteros.

Alguien escribió:

Yo uso Reaper, y lo recomiendo a todo el mundo, salvo a los que tengan Protools HD. Solo Protools HD es mejor, a mi juicio, aunque cuesta unas 40 veces más que Reaper en su versión más cara (la versión más cara de Reaper y la versión más barata de Protools HD, digamos).

Pues yo lo dudo, si PTHD realmente fuese 48bit de principio a fin estaria deacuerdo, pero un motor de audio q entre un proceso TDM y otro (incluida la suma) añade dither y trunca de 48 a 24 solo porq su obsoleta arquitectura hardware no permite el flujo a 48 bit entre DSP y DSP, siempre me parecerá una basura, reaper le da mil patadas al motor de audio de PTHD. En PTHD si en cualkier parte del motor de audio TDM pasas de 0dBfs se produce un clip, porq aunq los precesos sean a 48bit el motor trunca a 24 con dither para pasar al siguiente proceso.. y los tios te lo cuentan asi y se quedan tan anchos, oye mira q no vas a tener headroom por encima de 0dBfs y ademas entre cada proceso un poco de ruido dither y racatá truncamiento... PTHD en mi opinion es un cancer.

el PDF q lo explica de la propia digidesign

http://akmedia.digidesign.com/support/d ... _26688.pdf


slds

Alguien escribió:

¿Podrías explicar las diferencias exáctas a las que te refieres, sin recurrir a metáforas con coches y cosas así? Imagino que no, no puedes, y las metáforas no son muy válidas en tanto no estamos hablando de literatura sino de matemáticas. Pero igual me equivoco, vaya.

+1