La calidad de audio de los DAW

MartinSpangle
#61 por MartinSpangle el 31/07/2009
Vaya, interesante: si atenúas todas las pistas antes de sumarlas (cosa supongo necesaria) lógicamente vas a perder el último bit.

¿No hay forma de atenuar recién después de la suma? Supongo que es menos drástico perder los dos bits menos significativos de una cifra de 64 bits que perder el bit menos significativo de todas las pistas a 24 bits. No sé si me explico, algo así.

Muy interesante tu experimento tío, te sigo con total atención. Y confieso que yo también esperaba resultados mejores!

Salu2.
Subir
OFERTAS Ver todas
  • -20%
    Technics SL-1200M7 Lamborghini
    1.199 €
    Ver oferta
  • -7%
    Modal Argon8 (B-Stock)
    559 €
    Ver oferta
  • -50%
    NI Komplete 15 Collector's Edition
    885 €
    Ver oferta
guillermoruiz
#62 por guillermoruiz el 31/07/2009
ElHombreRana escribió:
Vaya, interesante: si atenúas todas las pistas antes de sumarlas (cosa supongo necesaria) lógicamente vas a perder el último bit.


No, quizás no me haya explicado bien.

Recuerda que los flotantes tienen la capacidad de amplificar o atenuar la señal drásticamente sin perder resolución, mientras no se sumen flotantes de diferente magnitud.

La diferencia del bit no es que se pierda con respecto a la señal original, se pierde con respecto a la misma suma realizada en 64-bit. Y esa suma de 64-bit tiene las mismas entradas atenuadas, pero el residuo menos significativo ahí se guarda y se suma también, lo que provoca que en ocasiones pase a la parte significativa de la muestra.

Alguien escribió:
¿No hay forma de atenuar recién después de la suma? Supongo que es menos drástico perder los dos bits menos significativos de una cifra de 64 bits que perder el bit menos significativo de todas las pistas a 24 bits. No sé si me explico, algo así.


Existen formas de corregir el error de la suma, como el algoritmo de Kahan pero es más rápido usar los 64 bits. Ese algoritmo merece la pena cuando no se puede contar con acumuladores de mayor número de bits.
Subir
MartinSpangle
#63 por MartinSpangle el 31/07/2009
Hola, a ver, que parece que no había entendido nada (normal, esto es complejo para mí, pls tenme paciencia que me interesa y estoy haciéndo un esfuerzo!)

Osea que tu conclusión ha sido que en 64 bits no puedes perder nada, mientras que a 32 bits pierdes algo. Es así? Lo he pillado bien ahora?

Sobre lo de atenuar cada pista, osea que primero lo conviertes a 32 bits o 64 bits coma flotante, y solo después de eso atenúas el nivel, con lo cual, lógicamente, no pierdes nada, incluso en el caso en que tengas más de 100 pistas, en cuyo caso tendrías que atenuar más de 600 dbs, no? Impresionante las matemáticas.

Si en este hilo no he dicho ninguna barrabasada, entonces queda claro que un motor de suma de 64 bits no pierde absolutamente nada y 'deberían sonar todos iguales'. ¿Hay entonces alguna otra variable que pueda provocar las diferencias que los usuarios oyen o creen que oyen?

Tío eres un crack.

Salu2.
Subir
wzmzw
#64 por wzmzw el 31/07/2009
Gracias colegas!!! Muchas gracias por este tipo de hilos!!!

;)
Subir
guillermoruiz
#65 por guillermoruiz el 31/07/2009
Alguien escribió:
Osea que tu conclusión ha sido que en 64 bits no puedes perder nada, mientras que a 32 bits pierdes algo. Es así? Lo he pillado bien ahora?


Sí, pero lo de perder algo puede ser interpretable. Digamos que con la suma en 64-bit el resultado final de 24-bit da el mejor resultado posible. Sin embargo sumando a 32 el resultado final de 24-bit pierde algún valor.

El experimento muestra que sumando a 32-bit en el mejor de los casos un 6% de las muestras en 24-bit de salida tienen una suma incorrecta.

Recuerdo qué he hecho en el algoritmo:
  • Genero un ruido individual para cada "pista" en 24-bit entero (fuente de audio).
  • Convierto las muestras de cada pista en 32-bit flotante (inserción en el motor).
  • Atenúo las muestras en un grado proporcional al número de pistas (volúmenes de las pistas).
  • Sumo los samples atenuados de cada canal en 32-bit flotante (summing).
  • Sumo los samples atenuados de cada canal en 64-bit flotante (summing).
  • Convierto la suma de 32-bit a 24-bit entero (salida del máster).
  • Convierto la suma de 64-bit a 24-bit entero (salida del máster).
  • Obtengo la diferencia entre el resultado 24-bit generado por la suma de 64 y el resultado 24-bit de la de 32.
  • Contabilizo si hay alguna diferencia.


Cuando las pistas coinciden el error se hace más evidente.
Subir
MartinSpangle
#66 por MartinSpangle el 31/07/2009
Oye, una pregunta más, ya que estamos.

Yo mencionaba arriba el tema de la sincronización de una señal con otra. Supongo que no es un problema - como decía, me lo inventé a ver que pasaba. Pero te pregunto como para confirmar: tu estás seguro 100% de que siempre sumas exáctamente la misma muestra de cada fuente? La precisión en esto es realmente absoluta, sin dificultad?

Salu2.
Subir
guillermoruiz
#67 por guillermoruiz el 31/07/2009
ElHombreRana escribió:
Oye, una pregunta más, ya que estamos.

Yo mencionaba arriba el tema de la sincronización de una señal con otra. Supongo que no es un problema - como decía, me lo inventé a ver que pasaba. Pero te pregunto como para confirmar: tu estás seguro 100% de que siempre sumas exáctamente la misma muestra de cada fuente? La precisión en esto es realmente absoluta, sin dificultad?

Salu2.


La precisión es absoluta e inherente a la arquitectura de un ordenador. Eso sí, los plugins pueden introducir un retardo en la señal pero debido a su algoritmo (por ejemplo el típico delay). Dentro del DAW el orden es estricto.

El programa puede tener problemas en procesar el búfer de forma síncrona (debido a la multitarea) pero es con todas las pistas a la vez y no se pierde el "orden". El interfaz de audio también puede tener problemas a la hora de lanzar el búfer, pero también es de todas las salidas a la vez. Eso es más fácil que ocurra con USB que por ejemplo en Firewire, por su propia arquitectura.
Subir
MartinSpangle
#68 por MartinSpangle el 31/07/2009
Pues tío, entonces, digo yo lo siguiente:

1. Como soy usuario de Reaper, y da la casualidad de que suma en 64 bits coma flotante, y todos sus procesos son también en ese estándar, lo tomo como eso: estándar. No pierde información al sumar, ni agrega, ni nada.

2. Luego, todo DAW que suene diferente (que no se cancele una mezcla igual con Reaper) suena mal (incluso si 'subjetivamente' suena mejor! Porque esto quiere decir que el DAW cambia algo, con algún material puede sonar mejor y con otro peor - un DAW tiene que ser transparente al 100%).

Y punto pelota!

Salu2.
Subir
sacio100
#69 por sacio100 el 31/07/2009
:mrgreen: =d> =d> =d>
Subir
Harpocrates666
#70 por Harpocrates666 el 31/07/2009
guillermoruiz escribió:
ElHombreRana escribió:
Oye, una pregunta más, ya que estamos.

Yo mencionaba arriba el tema de la sincronización de una señal con otra. Supongo que no es un problema - como decía, me lo inventé a ver que pasaba. Pero te pregunto como para confirmar: tu estás seguro 100% de que siempre sumas exáctamente la misma muestra de cada fuente? La precisión en esto es realmente absoluta, sin dificultad?

Salu2.


La precisión es absoluta e inherente a la arquitectura de un ordenador. Eso sí, los plugins pueden introducir un retardo en la señal pero debido a su algoritmo (por ejemplo el típico delay). Dentro del DAW el orden es estricto.

El programa puede tener problemas en procesar el búfer de forma síncrona (debido a la multitarea) pero es con todas las pistas a la vez y no se pierde el "orden". El interfaz de audio también puede tener problemas a la hora de lanzar el búfer, pero también es de todas las salidas a la vez. Eso es más fácil que ocurra con USB que por ejemplo en Firewire, por su propia arquitectura.


Tambien tenia esa duda, es decir que sin agregar procesos, solo sumando, la suma deberia dar el mismo resultado siempre, verdad? ahora me gustaria dieras tu conclusion de si en realidad tubieramos motores similares, pero de diferentes compañias, estos motores deberian hacer el mismo trabajo siempre? por ejemplo comparando una simple suma en reaper y algun otro secuenciador con la misma profundidad, el resultado deberia ser exacto si analizamos el archivo resultante?

Hasta el momento mi conclusion es que el DAW deberia ser totalmente transparente, si lo compares entre arquitecturas similares, por eso me gustaria saber cual es tu posicion al respecto. Es cierto que podemos encontrar diferencias entre motores de 32 float, 64 float, o 48 fijo, pero si las comparaciones fueran entre motores de similares caracteristicas?
Subir
--31852--
#71 por --31852-- el 31/07/2009
Lo malo esq la mayoria de motores de audio son 32 float si no me equivoco.. PTLE, nuendo, cubase, logic.. si no recuerdo mal los unicoss 64float son sonar y reaper

Alguien escribió:

Sobre lo de atenuar cada pista, osea que primero lo conviertes a 32 bits o 64 bits coma flotante, y solo después de eso atenúas el nivel, con lo cual, lógicamente, no pierdes nada, incluso en el caso en que tengas más de 100 pistas, en cuyo caso tendrías que atenuar más de 600 dbs, no? Impresionante las matemáticas.


es lo bonito de los sistemas en coma flotante, una vez q se convierte el stream de datos de 24bit proviniente del AD o del disco duro, son muy permisivos con un mal eskema de ganancias, a veces pienso q esto ayuda a q la gente no se preocupe por tener un eskema de ganancias coherente.. esto, y el prescindir de medidores VU (RMS en su defecto) es algo tipico de esta era DAW.

Muchas gracias por los aportes guillermo, ya te lo he dicho en alguna ocasion, pero da gusto tener a alguien q realmente sabe de lo q habla en estos temas digitales, este hilo deberia ser un post-it


slds
Subir
guillermoruiz
#72 por guillermoruiz el 31/07/2009
ElHombreRana escribió:
Pues tío, entonces, digo yo lo siguiente:

1. Como soy usuario de Reaper, y da la casualidad de que suma en 64 bits coma flotante, y todos sus procesos son también en ese estándar, lo tomo como eso: estándar. No pierde información al sumar, ni agrega, ni nada.

2. Luego, todo DAW que suene diferente (que no se cancele una mezcla igual con Reaper) suena mal (incluso si 'subjetivamente' suena mejor! Porque esto quiere decir que el DAW cambia algo, con algún material puede sonar mejor y con otro peor - un DAW tiene que ser transparente al 100%).

Y punto pelota!

Salu2.


Ya sé que tu programa favorito es Reaper pero hablar tanto de él en este hilo puede dar la impresión de que aquí se hace apología de ese programa. Cosa que yo no pretendo ni mucho menos, ni de ese ni de ningún otro (incluido el que yo uso). El caso es que otro usuario de Digital Performer, Sonar, Ableton Live, o cualquiera de los que suman en 64-bit podría decir los mismo. Si comparara los resultados de uno de esas aplicaciones con los de Reaper y diera diferencias podría llegar a la conclusión de que Reaper hace alguna cosa mal.

Lo cierto y verdad es que no conocemos los códigos fuentes de esos programas, y en caso de diferencia no podríamos saber que es lo que pasa y si uno u otro hace las cosas mal. Cada uno podría defender su secuenciador favorito pero eso ya no tendría nada que ver con la objetividad.
Subir
guillermoruiz
#73 por guillermoruiz el 31/07/2009
harpocrates666 escribió:
Hasta el momento mi conclusion es que el DAW deberia ser totalmente transparente, si lo compares entre arquitecturas similares, por eso me gustaria saber cual es tu posicion al respecto. Es cierto que podemos encontrar diferencias entre motores de 32 float, 64 float, o 48 fijo, pero si las comparaciones fueran entre motores de similares caracteristicas?


Hay muchos parámetros a tener en cuenta. La panoramización puede ser diferente sin que ninguna sea la incorrecta, los niveles deben ser numéricamente iguales. Cada suma que interviniera en la ruta debería realizarse en double, un descuido en algún punto del encaminamiento podría producir alguna diferencia.
Subir
guillermoruiz
#74 por guillermoruiz el 31/07/2009
Chus escribió:
Lo malo esq la mayoria de motores de audio son 32 float si no me equivoco.. PTLE, nuendo, cubase, logic.. si no recuerdo mal los unicoss 64float son sonar y reaper


No, también Digital Performer y Ableton Live. Y puede que algún otro programa que desconozca, no lo descarto. Y recuerdo que no se necesita procesado en 64-bit en toda la cadena, solo en las sumas para que no se vean alterados los 24 bits finales. Que los plugins tengan entrada y salida de 64-bit es una forma de malgastar recursos y hacer marketing. Algunos algoritmos pueden necesitar usar temporalmente 64-bit pero eso lo puede hacer cualquier sistema de bus de 32-bit.

Desde el punto de vista de la programación, no me gusta que se pierda información útil por el camino, cierto. Pero tampoco que se desperdicien recursos del sistema innecesariamente. Los escépticos con el marketing de los 64-bit tienen razón hasta cierto punto, los perspicaces con la exactitud de los 32-bit también la tienen hasta cierto punto. Aquí he querido aclarar cuando sí es necesario y cuando no lo es.
Subir
MartinSpangle
#75 por MartinSpangle el 31/07/2009
Efectivamente no es un hilo sobre Reaper.

De tus conclusiones sin embargo lo que yo extraigo es lo siguiente: una arquitectura de tipo x, digamos: suma a 64 bits coma flotante - solo puede hacerse bien o mal.

Esto parece tonto pero es importante. En el mundo analógico esto no exíste. Nadie lo hace 'bien' o 'mal' porque no hay tal parámetro. Siempre hay un trade-off entre mejorar un aspecto y empeorar otro, por poco que sea. Así es como SSL tiene un sonido y Neve tiene otro, los dos son altamente 'deseables' pero no se podría decir que uno es correcto y el otro no.

En cambio, en digital esto no es así. Siendo posible disponer de una arquitectura 'lossless', la suma debería ser siempre exáctamente igual que las partes.

Lo que te deja pensando a su vez en qué es lo que echas de menos del analógico: es la distorsión, de un tipo u otro, de una forma u otra, con unas características u otras. Pero en lo que es la suma propiamente, el digital no tiene problemas, o no debería tenerlo.

Por eso creo que son tan importantes estos hilos.

Salu2.
Subir
Hilos similares
Nuevo post

Regístrate o para poder postear en este hilo