¿Por qué es importante grabar y manipular el audio a 32 bits coma flotante?

En otro hilo comentábamos sobre la importancia de grabar, y sobre todo manipular los datos digitales de audio a la mayor profundidad de bits posible. En dicho hilo comenté que últimamente se está utilizando 32 bits con coma flotante. Las razones son muchas, pero he encontrado en un foro foráneo un post de un programador que aporta otra dimensión a la importancia de esto.

El post se hizo en un hilo en el que se hablaba de que cualquier manipulación de un fichero de audio, incluyendo un cambio de volumen o uno de frecuencia de muestreo se ven positivamente afectados por un paso anterior a 32 bits coma flotante. Así, en vez de pasar una grabación a 24 bits directamente a 44.1/16 con su correspondiente dithering para optimizar el sonido se realizaría un paso intermedio en el que el fichero a 24 bits lo pasaríamos a 32 bits coma flotante y este lo convertiríamos luego directamente a 16 bits al bajar de frecuencia de muestreo. Con ello obtenemos mejor calidad.

Dicho sea de paso, lo mismo se aplicaría a cualquier manipulación que hiciéramos de un fichero originalmente grabado a 44.1/16. Lo convertiríamos a 32 bits coma flotante antes de manipularlo para luego volverlo a traer a 16 bits.

Algunas de las razones tras esto las explica el post ya mencionado del programador que cito y traduzco a continuación:

"...32 bits coma flotante suministran 24 bits de resolución de audio real y 8 bits de información para escalación permitiéndo que los 24 bits se deslicen para arriba y para abajo dentro de un campo de acción de 256 bits. Si lo estoy entendiendo correctamente, a 6 dB por bit, esto ofrecería un rango dinámico de 1536 dB, 153 órdenes de magnitud. Si habéis visto alguna vez la película "Planeta Prohibido", estamos hablando de un órden de magnitud similar al que se le atribuía a la máquina Krell!

Me parece que estos extremos dinámicos son principalmente útiles cuando se está manipulando el audio digital en una Estación de Trabajo Digital (DAW en inglés) o en algún tipo de procesador. Sé, de la experiencia programando programas de ordenador en mi trabajo, que las ecuaciones que encajan en una curva de mayor órden pueden rápidamente comerse un montón de rango dinámico. Por ello es a menudo muy útil implementar muchas funciones de transferencia con una tabla de búsqueda en vez de utilizar una ecuación polinómica de alto órden, dado que la entrada y la salida de una función de transferencia usualmente cubre tan sólo una fracción del rango dinámico requerido para resolver la ecuación".

¿Comentarios?

Creo que este programador está comparando peras con manzanas...

¿De que sirve ese rango dinámico de 1538 dB? ¿Sería mejor procesar a 64 bits? ¿Por que no a 128 bits que muchos procesadores lo admiten con extensiones multimedia?

Si la fuente no tiene ese rango dinámico de nada sirve, otra cosa es que siempre hay que procesar por encima de lo que se quiere obtener, es decir, para 16 bits sería conveniente muestrear a 20 o 24 y para 24 bits a 32 bits... Pero todo lo que pase de ahí lo veo innecesario.

La presición que puedes ganar pasando la misma fuente de 24 a 32 bits ¿cual es? Pues si la fuente está en 16 bits ninguna, eso está claro.

Lo que me parece entender de lo que escribe ese señor es lo siguiente: Al aumentar los bits evidentemente la información del fichero orígen no se incrementa (imagino que se rellena de ceros). Según entiendo, su intención ha sido extrapolar una conversación que estábamos teniendo sobre los resultados sonoros que estabamos comentando se obtienen realizando el procesamiento a 32 bits al mundo de lo que el conoce de programación.

Así, lo que el intenta explicar en sus términos es lo siguiente (de lo que en realidad se estaba comentando en el hilo de donde extraje el post): Al procesar cualquier resolución inferior a 32 bits el rango dinámico que ofrece dicha resolución hace que cualquier elemento de ruido que se produzca como resultado de los cálculos que se realizan al efectuar manipulaciones del fichero quedarían en un nivel señal/ruido tan grande que al volverlos a pasar a 16 o 24 bits serían considerablemente menos aparentes que si las manipulaciones se realizan, pongamos, en el ámbito de los 16 bits.

Que yo sepa/recuerde él no ha hecho mención de ninguna otra profundidad de bits que los 32.

¿En qué influye o beneficia esto al usuario de pie? Pues si estamos realizando un CD recopilatorio para uso personal y queremos igualar los volúmenes de las diferentes canciones que lo compondrán haríamos bien en subir la resolución de bits de dicho fichero a 24 o 32 bits, si ello fuera posible, antes de variar sus volúmenes de manera que cuando volvamos a 16 bits tendremos un fichero con el sonido menos deteriorado.

He de comentar que mi experiencia, aunque coincide con esto, no ha sido exactamente así. Me explico: yo lo que he hecho es grabar a 192/24 con almacenamiento directo a 32 bits en Auditiion y al bajar de de 192/32 a 96/24 directamente he obtenido ficheros de esta última resolución que suenan mejor que si guardo el fichero original a 192/32 a 192/24 y luego convierto este último a 96/24. Imagino que una explicación más sucinta del fenómeno sería equivalerlo a utilizar un master a 96/24 para hacer una edición de un CD. El resultado es más detalle y dinámica en el CD resultante.

Podrías decirme, "Sí, pero ahí estñas hablando de grabar a una resolución 'x' y bajar de ahí, no hacer un cambio de un fichero originalmente de 16 ó 24 bits a 32 para manipularlo. Y yo te digo que es como ensancher un patio, tirar la basura en la esquina más lejana y luego encogerlo. La basura, en este caso, queda fuera.

Un saludo :)

Hola:

A mi lo de los 32 bit me puede parecer (y de hecho me parece bien)...Lo que no tiene sentido (y ya lo he comentado alguna vez) es que los 32 bit sean en coma flotante....El rango numerico por trabajar en coma flotante, va a ser mucho menor que si esos 32 bit se usan en enteros....

Saludos

JP

Jotap_66, serías tan amable de ahondar más en los detalles de lo que comentas? Lo pregunto por curiosidad.

Un saludo :)

Cita:

---

Iniciado por Yota

Jotap_66, serías tan amable de ahondar más en los detalles de lo que comentas? Lo pregunto por curiosidad.

Un saludo :)

---

Si claro...Lo que quiero decir...es que si usas 32 bits tienes aproximadamente 4 mil millones de posibles valores a representar...pero si usas notacion en coma flotante aunque puedes representar aproximadamente (desde 10e-38 a 10e37 mas o menos) en realidad todos esos numeros no son usables, porque a la hora de operar en coma flotante se producen errores de redondeo (cosa que no pasa con los enteros, aunque parezca mentira)...

Ej. Para entenderlo, coge una calculadora y haz la siguiente operacion , 1 + 1e-16...Esta claro que no deberia haber problema...No son valores que den "problemas" ya que estan dentro del rango...¿Que pasa?... Uy!! pero si da 1.
Coge 1+1e-13....¿Que pasa? Exactamente lo mismo...

Esto es un problema intrinseco a la notacion en coma flotante...Por eso digo que aunque "en teoria" se puede pensar que es mejor la coma flotante, en la practica no esta nada claro...Depende de lo que se quiera hacer....No se que tipo de operaciones aritmeticas se hacen en el audio....Claro!! Puede darse el caso, de que esos errores que he comentado (que sobre todo se dan en las restas de valores muy parecidos) , no tengan demasiada importancia...Si esto es asi y no aparece ese tipo de operacion...entonces si tendria sentido usar la coma flotante...

Existe documentacion donde se explica esto, aunque es muy muy compleja...Es el documento IEEE-754/85, en el que esta explicada la notacion en coma flotante de los computadores actuales...

Claro, lo que no acabo de ver, es que para 16 o24 bits los valores sean enteros (o eso creo) y a partir de 32, se tenga que usar la coma flotante...Yo creo que tambien tendria sentido trabajar con enteros...

Entiendo que el tema es complicado...No me quiero "enrollar" mas...No se si se me ha entendido...Perdonad si no me he explicado bien...Es que esto da para varias clases...Uff Perdon...Me sale la rama docente....

Saludos

JP

¡Muy interesante, Jotap_66! El asunto es que se entiende que la finalidad de utilizar coma flotante es para que no se redondeen los valores lo cual darñia errores. Pero, si dices que esto en las entrañas de un ordenador no funciona exactamente así si no que funciona de una manera 'contraintuitiva', como dirían los anglosajones, entonces es otro cantar.

Con tu permiso, voy a citar tu post en un foro foráneo a ver qué me dicen los programadores de software de audio que puedan haber por allí y luego me traigo sus respuestas aquí.

He de añadir que la finalidad de la utilización de los 32 bits coma flotante, según loa programas de grabación de audio digital, es que los ficheros resultantes permiten almacenar ficheros con niveles que sobrepasan 0dB.

Un saludo :)

Jotap_66, ya tengo una interesante respuesta de un programador en un foro foráneo la cual citaré aquí y traduciré, pero la puedo postear dentro de un par de horas o así cuando termine una serie de cosas que estoy haciendo.

Un saludo :)

Cita:

---

Iniciado por Yota

Jotap_66, ya tengo una interesante respuesta de un programador en un foro foráneo la cual citaré aquí y traduciré, pero la puedo postear dentro de un par de horas o así cuando termine una serie de cosas que estoy haciendo.

Un saludo :)

---

De acuerdo...:)

Gracias

JP

Aquí está el post del programador del foro foráneo así como un comentario posterior a otro post de un forero (cito y traduzco... perdonad cualquier error que no soy traductor técnico de programación):

"El IEEE 754 no es un misterio. Lo he leído para un trabajo en lenguaje máquina que tenía que hacer para el PowerPC.

Los 32 bits coma flotante tienen, como mínimo, la misma precisión que 24 bits enteros. Cada valor a 24 bits enteros puede ser expresado exactamente a 32 bits coma flotante. Así que decir que 24 bits es de alguna forma superior para trabajo numérico es algo un poco tonto.

Cuando lo comparamos a 32 bits valores enteros, las cosas son mucho menos claras. La coma flotante puede expresar valores mucho más pequeños y mucho más grandes, pero a expensas de precisión en la mantisa. En algunas situaciones, la coma flotante funciona mejor, en otras los valores enteros serán más deseables.

En audio, los valores enteros tienen sentido en el contexto de definir 0dbFS como punto de referencia. Si todas tus señales están cerca de (o por debajo) de 0dbFS entonces los valores enteros tienen mucho sentido. Si todos están por debajo de -48dbFS (NOta: dbFS = decibelios sobre la escala total = decibles full scale) entonces sólo has perdido 8 bits de precisión y estás de vuelta a los 24 bits. Si algunos de ellos están por encima de 0dbFS estonces estás frito.

Claro está, puedes buscar soluciones alternas a muchos de estos problemas derivados de los números enteros definiendo 0dbFS para que signifique otra cosa diferente a 1, tales como otra potencia de 2 como 16 o 32, para que los pocos primeros bits del número realmente representen un número entero, y que el resto representen la mantisa. Pero eso no logra mucho salvo un montón de complicación.

Comparativamente, la coma flotante puede manejar 0dbFS, -48dbFS y +48dbFS sin ninguna dificultad. Estos es quizás más útil en un contexto científico que un uno de audio, porque puedes asociar naturalmente el valor coma flotante con una medida, que tiene unidades específicas asociadas a ellas. Así que si estás midiendo voltios, entonces sólo quieres un número que represente 1 V, 1uV y 100V sin dejar caer fuera ningunos bits de los que te importan. En el campo del audio, las acciones de ajuste de ganancia (y compresión) se aseguran de que las señales ya caigan en un rango bien conocido.

Sin lugar a dudas, esto es un asunto más importante cuando se trata de programación de DSPs, porque en ella aparecen rutinariamente números muy pequeños y muy grandes en varios algortimos. Los programadores resuelven esto en una serie de maneras diferentes. Todas ellas se conocen muy bien desde hace más de 30 años.

No utilizan 32 bits coma flotante. Utilizan 64 bits. Los algoritmos resultantes a menudo terminan siendo MUCHO más estables cuando se mueven a una precisión superior. Y, si 64 bits no son suficientes, se trasladan a precisión extendida, precisión arbitraria o cuádruple, pero eso usualmente no es necesario.

Reescriben el algoritmo para minimizar el impacto del error de cuantización. Por ejemplo, en vez de sumar 1 y 1e-13, sumas un millón de números diferentes, con rangos que van desde 1e-13 a 1. Si ordenas los números desde el más pequeño al más grande, luego los sumas juntos de más pequeño a más grande, muy posiblemente evitarás totalmente los problemas de precisión (al menos en este caso). Más usualmente, necesitas redefinir lo que la paridad entre dos números coma flotante significa, ten cuidado dónde y cuándo hagas operaciones científicas y, especialmente, estate seguro de saber exactamente lo que está haciendo tu compilador a tus espaldas, porque puede romper la precisión si no tienes cuidado".

Más adelante un forero cita a este en lo siguiente: "32-bits en coma flotante tienen, como mínimo, la misma precisión que 24 bits fijos. Cada valor a 24 bits valor entero puede ser expresado exactamente a 32 bits coma flotante. Así que decir que 24 bits es de alguna forma superior para trabajo numérico es algo un poco tonto".

y preguntó: "Así que, según esto, ¿operar en un entorno a 32 bits coma flotante es siempre superior que 24 bits a número enteros, sin excepciones"?

A lo que le respondió: "Si estás tratando con números que encajan en el dominio de 24 bits con números enteros, entonces sí. Obviamente, si estás tratando con un rango extendido de números que requiere coma flotante, entonces puede que te encuentres con problemas".

Un saludo :)

Gracias por el post...En general sabe de lo que habla y tiene razon en CASI todo lo que dice...salvo en una cosa, que es importantisima...

Cita:

---

Iniciado por Yota

Reescriben el algoritmo para minimizar el impacto del error de cuantización. Por ejemplo, en vez de sumar 1 y 1e-13, sumas un millón de números diferentes, con rangos que van desde 1e-13 a 1. Si ordenas los números desde el más pequeño al más grande, luego los sumas juntos de más pequeño a más grande, muy posiblemente evitarás totalmente los problemas de precisión (al menos en este caso). Más usualmente, necesitas redefinir lo que la paridad entre dos números coma flotante significa, ten cuidado dónde y cuándo hagas operaciones científicas y, especialmente, estate seguro de saber exactamente lo que está haciendo tu compilador a tus espaldas, porque puede romper la precisión si no tienes cuidado".[/I]

---

Efectivamente...Tiene razon en que si los sumas ordenadamente, el problema desaparece...pero claro, esto muchas veces no es posible (reescribir el algoritmo)....El ordenador esta resolviendo un problema, y una simple suma de dos numeros 1 y 1e-13 te lo fastidia todo.....Como dice esta persona, se puede aumentar la precision a 64 bits....Es una posibilidad, pero hasta hace poco no era nada facil...Hoy dia la misma notacion IEE 754 contempla los 64 bits e incluso, ciertos micros como el PowePc, hasta 96...Y hombre lo de que si tienes problemas sigues aumentando la precision, pues como que no tiene mucho sentido....

Lo que si me llama la atencion (volviendo al tema audio) es que dice que no esta nada claro lo de que usar los 32 bits en coma flotante sea mejor que con 32 bits enteros....

En cualquier caso, el post de respuesta es bastante bueno...

Saludos y gracias por tomarte la molestia de postearlo en otro foro :)

JP

El hilo en el otro foro no ha quedado ahí. Ha habido quien incluso ha posteado este enlace: http://www.jamminpower.com/PDF/48-bit%20Audio.htm a un trabajo que defiende el uso de 48 bits enteros en vez de 32 bits coma flotante.

Transmitiré tu comentario al otro foro. ;)

Un saludo :)

Cita:

---

Iniciado por Yota

El hilo en el otro foro no ha quedado ahí. Ha habido quien incluso ha posteado este enlace: http://www.jamminpower.com/PDF/48-bit%20Audio.htm a un trabajo que defiende el uso de 48 bits enteros en vez de 32 bits coma flotante.

Transmitiré tu comentario al otro foro. ;)

Un saludo :)

---

Gracias...

A ver si tengo un poco de tiempo para leer el articulo...Parece interesante....Por lo que he visto plantea la posibilidad de usar mas mantisa (lo que supone menos errores como el que he indicado) y menos exponente (disminuye el rango numerico de representacion). Esto ultimo me da que en audio no debe de ser tan importante....El usar formatos especiales se hacia antiguamente, cuando cada fabricante tenia que implementar todo, incluida la CPU....Entonces cada uno diseñaba el procesador segun queria...Hoy dia todos los computadores suelen llevar micros de Intel (o AMD) que para la mayoria de aplicaciones funcionan perfectamente...

Saludos

JP

Edito para comentar que ya lo he leido:

Pues despues de haberlo leido es para alucinar en colores, porque viene a decir que incluso con 64 bits en coma flotante (que es lo que usan los computadores actuales) hay filtros (DSP) que producen errores...Lo que no me queda claro, es hasta que punto esos errores influyen en audio...Parece que los filtros (o DSPs) de los que habla son genericos...

Saludos

JP

Jotap_66, a continuación la respuesta del técnico en el foro foráneo a tu respuesta a su post:

¡Hurra! He sido semi validado. :)

Cita:

---

Iniciado por jotap_66

Efectivamente...Tiene razon en que si los sumas ordenadamente, el problema desaparece...pero claro, esto muchas veces no es posible (reescribir el algoritmo)....El ordenador esta resolviendo un problema, y una simple suma de dos numeros 1 y 1e-13 te lo fastidia todo.....Como dice esta persona, se puede aumentar la precision a 64 bits....Es una posibilidad, pero hasta hace poco no era nada facil...

---

El x86 viene teniendo doble precisión desde hace ya décadas. Ciertamente, encontrar equipos de audio que funcionen internamente en doble precisión puede haber sido imposible. (Lo siento, soy del mundo de la informática, no del de audio, así que sé menos sobre ello). Y, claro está, hay grandes problemas de funcionamiento en la doble precisión en general. Pero en ausencia de estas preocupaciones, no creo que muchas personas se queden despiertos por la noche preocupados por problemas de precisión, cuando tienen un trayecto de doble precisión que funciona maravillosamente.

Estoy de acuerdo en que no todos los algoritmos pueden evitar los problemas de precisión, pero algunos de ellos sí. Muchas de las decisiones que se toman en torno al diseño de un filtro digital tienen su base en problemas de cuantización - notablemente, escoger entre las diferentes formar de filtros IIR (Respuesta Infinita al Impluso) y FIR (Respuesta Finita al Impulso).

Cita:

---

Iniciado por jotap_66

Hoy dia la misma notacion IEE 754 contempla los 64 bits e incluso, ciertos micros como el PowePc, hasta 96...Y hombre lo de que si tienes problemas sigues aumentando la precision, pues como que no tiene mucho sentido....

Lo que si me llama la atencion (volviendo al tema audio) es que dice que no esta nada claro lo de que usar los 32 bits en coma flotante sea mejor que con 32 bits enteros....

---

De nuevo, todo depende de para qué lo estás utilizando. A veces necesitas más mantisa, en otras ocasiones precisas más exponente. Yo soy de los que creen que cualquier cosa por encima de 16 bits no es necesario para la música final, pero durante su procesador puedo pensar en montones de razones por las que me gustaría tener esos 8 bits extra dedicados a un exponente en vez de mayor precisión. En otras situaciones, por ejemplo en trabajo con filtros IIR, dependiendo en los que estás haciendo querrás mucho tener una mantisa de 32 bits. Todo depende de la situación.

Existe un fascinante paralelo a esto en el mundo de las tarjetas de vídeo. Como todos probablemente sabéis, el vídeo en los ordenadores empezó como 4 bits (CGA), luego 8 bits (VGA), luego 16 bits depués 24 bits y 32bits. Todo esto era con números enteros. Comenzando alrededor del año 2000 hubo un empuje por parte de los programadores gráficos, insignemente notably John Carmack, para que nVidia/ATI implementara un trayecto de color en coma flotante, empezando con color a 64 bits -16 bits por color, compuesto de 1 signo, 10 mantisas, 5 exponentes.

A continuación una cita de un post de Carmack, hace más de 7 años. Mucho de lo que cuenta en ella es anáñogo al audio. Noten, específicamente, cómo la renderización de un videojuego se ha trasladado de donde las texturas y el color tienen un bien definido rango (0,1) a un rango ilimitado. Y también cómo aunque puede que necesites esta precisión añadida para tus cálculos, no la necesitas para el formato de salida final. La analogía en el mundo del audio es que utilizar 32 bits coma flotante en el trayecto de datos al procesar no justifica la utilización de más de 16 bits en el formato de salida.

Cita:

---

Range is even more clear cut. There are some values that have intrinsic ranges of 0.0 to 1.0, like factors of reflection and filtering. Normalized vectors have a range of -1.0 to 1.0. However, the most central quantity in rendering, light, is completely unbounded. We want a LOT more than a 0.0 to 1.0 range. Q3 hacks the gamma tables to sacrifice a bit of precision to get a 0.0 to 2.0 range, but I wanted more than that for even primitive rendering techniques. To accurately model the full human sensable range of light values, you would need more than even a five bit exponent.

... "Do we need it in the front buffer?" Probably not. Going to a 64 bit front buffer would probably play hell with all sorts of other parts of the system. It is probably reasonable to stay with 32 bit front buffers with a blit from
the 64 bit back buffer performing a lookup or scale and bias operation before dithering down to 32 bit. Dynamic light adaptation can also be done during this copy. Dithering can work quite well as long as you are only performing a single pass.s.

---

Me traigo otro interesante post de otro forero del foro foráneo:

"Parte de la confusión surge de la distinción entre las matemáticas y el formato de datos. Es más deseable que los cálculos matemáticos se lleven a cabo con más bits disponibles como intermediarios de los resultados contenidos en el formato de los datos. No estoy seguro si existe suficiente información disponible para decir que 32 bits coma flotante es más preciso que 24 bits números enteros sin saber más detalles sobre los cálculos matemáticos y la forma en la que se trata a los resultados intermedios.

Dos cosas son seguras:

El dither tendrá un efecto matemático muy diferente ya se trate de coma flotante o no. Puede que esto no importe mucho con tantos bits disponibles.

La coma flotante es más fácil para aquellos que venden el hardware y el software. Todas las bibliotecas de cálculos matemáticos del hardware y el software corren y tienenla velocidad optimizada para ella. No me llevaría de su palabra cuando se trata de la superioridad de la coma flotante - a ellos les interesa (por sus propios intereses) promocionarla como una virtud.