La calidad de audio de los DAW : Grabación y mezcla página 8

Muy buen hilo!.. aunque cuesta un poquito leerlo para los simples mortales.. jaja

meneillos escribió:
hola, yo creia que entendía mas o menos el funcionamiento de los daw pero habeis arrojado demasiadas teorias voy a inmiscuirme por aqui haber que pasa, lo primero daros las gracias a todos por conpartir vuestros conocimentos,de verdad gracias.

-trabajando a 32 bits
¿el coma flotante solo se utiliza cuando necesitamos mas de 24 bits, es decir cuando pasamos de 0dfs en los buses individuales para que no se produzca sobremodulaciones?, sin embargo aunque trabajemos en 32bits en el master nunca vamos a utilizar esos 8 bits ya que no podemos enviar mas de 24, al convertidor a/d, osea que esos dawn de 32 de summing no nos sirven esos 8 bits que tenemos de mas por que no los podemos utilizar.
por lo que se pierden bits, ¿esto es asi, o me colado?

-guillermoruiz:
Cuando esos buses individuales llegan al mezclador ProTools HD los convierte a valores de 48 bits ,Una vez en ese formato el procesador multiplica o divide según el volumen de la mezcla en su registro de 56 bits (8 bits extra para headroom)Una vez ya hecha la mezcla los datos pueden ser convertidos a 24 bits otra vez

-meneillos:
- con las sumas de los buses individuales puedes conseguir niveles mayores de 0dfs, y poder representarlo debido a esos 8 bits, pero el mismo te hace una reducion a 24 bits entonces hay un problema muy grande por que esa onda por encima de 0dfs se queda sin representarla y esos 4db que tenias de headroom de la suma se van a la mierda y encima son esos son bits altos que se van a perder en la escucha.
conclusion: ¿esos de headroom como los utilices palmas ?

Ferdinanz escribió sea que segun dices conviene abrir los proyectos en 32 bits coma flotante en vez de en 24?

-guillermoruiz:
No, las fuentes de audio están perfectas en 24 bits

-meneillos: ya que nos ponemos tikismikis creo que seria mejor manejar archivos de audio en 32bits, ya que internamente estos dawn trabajan a 32 y cualquier caculo por ej. de normalizacion fade in o aut el programa lo a a realizar a 32 por lo que le va a resultar mas facil, y no va a terner que recortar bits por debajo. al igual la conversion a/d se nos puede pasar algun clipping que en el archivo de audio estara perfectamente representado.

-moa
¿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

-meneillos: esta es mi opinion, cuando se muestrean componentes de infrasonido aparecen intermodulacion ( distorsion) dentro del rango audible que algunas personas lo entienden como mas rico en agudo, no es mas que ruido a niveles muy bajos. por lo que mi consejo es que no subas de 44 para cd y de 48 para dvd, ya que cuando tengas un archivo a 48 y quieras hacer un render para cd se va a tener que volver a realizar otra toma de muestras equivalentes por lo que al unir de nuevos los puntos te van a surgir fluctuaciones respecto a las muestras tomadas a 48 por lo que provoca cambios en la forma de honda si no te queda otro remedio haz este proceso fuera de linea ( no en tiempo real ) con el mejor algoritmo que tengas, en wavelad hay uno muy potente para hacer estas cosas, si el algoritmo no es bueno te producira errores de cuantificacion y jiter.

-guillermoruiz:
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.

-meneillos:
no se si lo entendido bien realmente, cuando sumas en 32 es lo mismo que sumar en 24 , por que esos flotantes en la suma final no se utilizan , creo que me estoy repitiendo,

saludos

Lo lamento meneillos pero me parece que estas un poco confundido, comienzas hablando de 32 bits en coma flotante y lo primero que citas es a guillermo ruiz hablando de los 48 bits en punto fijo de protools. La forma de trabajar en ambos casos es diferente, no puedes hacer comparaciones analogas. No le veo logica a la secuencia de citas que haces.

Lo segundo, una cosa es el headroom que te da al grabar los 24 bits, pero luego al mezclar es otra cosa, los 64 o 32 bits flotantes de te dan un headroom virtualmente infinito, esto es debido a que los valores en punto flotante se representan en forma "abreviada" por decirlo de alguna manera, un valor muy grande o muy pequeño no es representado por un numero absoluto, si no por un numero elevado a un exponente, cuya escritura implica 32 bits, por tanto eso de que en punto flotante no se utilizan algunos bits no es correcto, la muestra esta representado por 32 bits siempre, ya sea que la mitad de los bits seab "0", siempre seran 32 y sumar en punto flotante no es lo mismo que sumar en punto fijo.

Por ultimo, no existe absolutamente ninguna necesidad de convertir archivos, si las muestras estan tomadas a 24 bits, en esa resolucion deben quedarse ya que como he dicho una gran cantidad de veces, el archivo original no es tocado en el procesamiento, si el motor de audio es a 32 bits float, cuando trabaje con el archivo, cada muestra será cargada en una variable, variable de 32 bits siempre, por tanto si el original esta en 16, 24, o 32 bits, siempre terminara en una variable de proceso de 32 bits utilizando la misma cantidad de bits, lo unico que conseguiras convirtiendo los archivos es utilizar mas espacio de disco, sobrecargar mas la memoria y en el mejor de los casos no obtener absolutamente nada de rendimiento extra.

Tengo una duda que seguramente será de lo más simple: ¿Todo esto de la resolución interna de cualquier DAW afecta al número de bits con los que este grabada la fuente de audio (voz, guitarras, etc.) pasando por el conversor AD? ¿Hay diferencia en que el conversor AD esté a 16 o 24 bits?.......Lo dicho, igual estoy preguntando una tonteria, pero tengo esa duda.

Por otro lado quiero hacer un comentario, al margen de la calidad del motor de audio del DAW y la resolución de los plugins que se utilicen, supongo que la "calidad" del plugin en cuestión tendrá mucho que ver, ¿no? La calidad de determinados EQ como Oxford o URS (por poner un ejemplo) creo que es bastante superior a la de otros, y supongo que será superior a la de las EQ nativas utilizadas por Reaper (de nuevo por poner un ejemplo...y ojo, que no he utilizado Reaper para nada, no tengo ni idea de como "suena").

Un hilo buenísimo, por cierto!!!!!

Salu2.

Alguien escribió:

Por ultimo, no existe absolutamente ninguna necesidad de convertir archivos, si las muestras estan tomadas a 24 bits, en esa resolucion deben quedarse ya que como he dicho una gran cantidad de veces, el archivo original no es tocado en el procesamiento, si el motor de audio es a 32 bits float, cuando trabaje con el archivo, cada muestra será cargada en una variable, variable de 32 bits siempre, por tanto si el original esta en 16, 24, o 32 bits, siempre terminara en una variable de proceso de 32 bits utilizando la misma cantidad de bits, lo unico que conseguiras convirtiendo los archivos es utilizar mas espacio de disco, sobrecargar mas la memoria y en el mejor de los casos no obtener absolutamente nada de rendimiento extra.

Bastante deacuerdo, pero si q es verdad q hay bastante gente q ha notado mejor rendimiento de la CPU al pasar los ficheros a 32float, aunq efectivamente el disco duro y la ram se veran mas cargadas, en cualkier caso, el resultado matematico es el mismo la diferencia es si la conversion de 24fijo a 32float se hace en tiempo real o no, lo q por lo visto puede influir en la carga de la CPU

slds

Alguien escribió:
¿Hay diferencia en que el conversor AD esté a 16 o 24 bits?

El DAW trabaja siempre a la misma resolución interna. Pero si cargas o grabas una muestra a 16 bits no vas a tener más resolución que esa (los bits menos significativos extras del DAW estarán a cero).

Alguien escribió:
Por otro lado quiero hacer un comentario, al margen de la calidad del motor de audio del DAW y la resolución de los plugins que se utilicen, supongo que la "calidad" del plugin en cuestión tendrá mucho que ver, ¿no?

Los plugins quedan fuera del análisis en este hilo porque no hay forma de establecer objetivamente cual es su calidad. En la ruta digital de un DAW sin embargo solo se emplean los elementos básicos del procesamiento digital (mezcla=suma, amplificación=multiplicación). Se sabe que cálculos deben hacer y por ello es posible conocer si sus resultados varían con respecto al resultado óptimo.

Chus escribió:

Alguien escribió:

Por ultimo, no existe absolutamente ninguna necesidad de convertir archivos, si las muestras estan tomadas a 24 bits, en esa resolucion deben quedarse ya que como he dicho una gran cantidad de veces, el archivo original no es tocado en el procesamiento, si el motor de audio es a 32 bits float, cuando trabaje con el archivo, cada muestra será cargada en una variable, variable de 32 bits siempre, por tanto si el original esta en 16, 24, o 32 bits, siempre terminara en una variable de proceso de 32 bits utilizando la misma cantidad de bits, lo unico que conseguiras convirtiendo los archivos es utilizar mas espacio de disco, sobrecargar mas la memoria y en el mejor de los casos no obtener absolutamente nada de rendimiento extra.

Bastante deacuerdo, pero si q es verdad q hay bastante gente q ha notado mejor rendimiento de la CPU al pasar los ficheros a 32float, aunq efectivamente el disco duro y la ram se veran mas cargadas, en cualkier caso, el resultado matematico es el mismo la diferencia es si la conversion de 24fijo a 32float se hace en tiempo real o no, lo q por lo visto puede influir en la carga de la CPU

slds

Exceptuando ProTools HD, cuando el archivo es de 24 bits el programa debe convertir los datos a flotantes de 32 bits para usarlos en el motor. Normalmente lo tiene que hacer a tiempo real porque no carga todo el audio en memoria. Por otro lado las muestras de 24 bits ocupan un 75% del tamaño de una de 32 y por ello el motor debe leer menos de disco. En un sentido práctico no sé que perjudica más al rendimiento general pero la conversión puede ser muy rápida con los procesadores y compiladores actuales. El Pentium tiene una instrucción especial para llevarla a cabo y los compiladores de C suelen aprovechar esas instrucciones.

Esto es lo que dije en el foro de reaper, lo quiteo acá

Alguien escribió:
claro, a lo que voy, es que al pasar de 24 fijos a 32 flotantes no agregas bits vacios, ya que el formato de representación cambia...

agregar bits vacios seria cierto solo si se pasaran de 24 fijos a 32 fijos, en este caso es valida esa afirmación.

Pero leyendo la wikipedia esto no es asi. Leelo te lleva poco tiempo y es muy interesante.

haciendo unas pruebas con python:

>>> 1+1

2

>>> 1.1+1

2.1000000000000001

que paso en el ultimo, la suma deberia dar 2.1 y no 2.1000000000000001, lo que pasa es que estas sumando en punto flotante y no es tan exacto como en punto fijo

Lo que dice en la wikipedia sobre coma flotante:

Alguien escribió:
La notación en coma flotante es más lenta de procesar y menos precisa que la notación en coma fija, pero dado un tamaño fijo de dígitos, permite un mayor rango en los números que se pueden representar con ellos.
fuente: http://es.wikipedia.org/wiki/Coma_flotante

Osea segun lo dicho en la wp, para poner un ejemplo (vamos con 8 bits para no hacerlo mas dificil de leer)

8 bits punto fijo:
11110101

ahora pasamos esos 8 bits punto fijo a 16 punto fijo:
11110101 00000000

ahora si queremos pasar esos 8 bits fijos a 16 punto flotante seria otra la representacion, y lo de agregar ceros a la derecha ya no aplica ya que seria

r = m * b^e

r seria el numero, m la mantisa y b seria 2 (porque es binario) y e seria la cantidad de bits...

la representación o la estructura del numero es muy diferente.

muy complejo todo esto. A lo que voy es que no es agregar bits vacios al pasar de 24 punto fijo a 32 o 64 o 128 flotantes.

post relacionado: duda-sobre-plugins-sus-bits-t286026.html

Al contrario que el punto fijo, la coma flotante es más difícil de analizar. Efectivamente no hay una correspondencia bit a bit con los enteros. Tiene un formato distinto, y más cuando su rango es de -1 a +1.

Con respecto a la precisión, pues es variable. Un valor cercano a cero tiene mucha más resolución que un valor cercano a 1. Así nos encontramos con que en una muestra habrá una precisión variable dependiendo de la magnitud de cada valor.

¿Hay bits transformados con una doble conversión? Habría que hacer la prueba:

Convertir los valores de 24 bits a punto flotante de 32.
Volver a convertir ese número a entero de 24 bits.
¿Es el mismo valor que antes?

Si hago la prueba con un programa en C lo publico aquí como ya hice antes con el summing 32/64.

guillermoruiz buenisimo, yo queria hacer algo, pero luego pensando me di cuenta de no se cual es el formato de los bits en punto fijo para audio, deberia analizar un archivo y la verdad que no ando con mucho tiempo...

Alguien escribió:
Si tenés floats IEEE 754 de 64 bits (los "comunes"), tenés 53 bits de mantisa para alojar los valores de los samples. Te entran cómodamente valores de 24 bits sin errores de ningún tipo. Los floats de 32 bits tienen justo 24 de mantisa, con lo cual también podés hacer la conversión sin pérdida.

En resumen:
int de 24 float de 32 o 64 no tiene razones técnicas para tener pérdida, pero si está implementado como el totó puede llegar a ser el caso.

Saludos
Fuente: http://www.pcmasmas.com/viewtopic.php?p=255126#p255126

PD: el muchacho la tiene clara, lo conozco de trabajar junto a él (en programacion)...

Perfecto, pero hasta ahora nose si trabajar a 24,32 o 64 bits... hay demasiada diferencia?.. Puesto que al final el audio va grabado en un Cd, a 16 bits 44Hz.
Pregunta al margen!, es muy diferente trabajar a 48Hz?, osea, la escucha es mejor en la mezcla?

polougo escribió:
Perfecto, pero hasta ahora nose si trabajar a 24,32 o 64 bits... hay demasiada diferencia?.. Puesto que al final el audio va grabado en un Cd, a 16 bits 44Hz.
Pregunta al margen!, es muy diferente trabajar a 48Hz?, osea, la escucha es mejor en la mezcla?

El audio final va a ser en 16 bits, pero durante la mezcla es mejor tener mas headroom... ademas haciendo el summing en 64 bits hay menos perdida... Si haces una mezcla a 16 bits lo mas probables es que te quedes con poco headroom....

pylorca escribió:

Alguien escribió:
Si tenés floats IEEE 754 de 64 bits (los "comunes"), tenés 53 bits de mantisa para alojar los valores de los samples. Te entran cómodamente valores de 24 bits sin errores de ningún tipo. Los floats de 32 bits tienen justo 24 de mantisa, con lo cual también podés hacer la conversión sin pérdida.

En resumen:
int de 24 float de 32 o 64 no tiene razones técnicas para tener pérdida, pero si está implementado como el totó puede llegar a ser el caso.

Saludos
Fuente: http://www.pcmasmas.com/viewtopic.php?p=255126#p255126

PD: el muchacho la tiene clara, lo conozco de trabajar junto a él (en programacion)...

Eso está claro. La duda no es esa sino si hay algún tipo de error en la conversión por la que no haya reciprocidad.

Segundo experimento:
He hecho la prueba generando todas las posibles correspondencias y el resultado es que todos los valores se mantienen exactos en la doble conversión. Aquí el programa en C++:



#include



int main()

{

using namespace std;

const int max_int = 8388607;

const int min_int = -8388608;



for (int v1 = min_int; v1

Podemos ir un poco más lejos. He hecho un pequeño cambio en el programa para probar con enteros de 25 bits. El resultado es que el flotante de 32 bits es capaz de representar todos los valores enteros de 25 bits. Eso ratifica lo que comenté en este hilo sobre que los flotantes de 32-bit tienen una mantisa efectiva de 25 bits pues hay un bit que queda implícito por la normalización del exponente.

hapocrates eres un tipo simpatico.