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

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

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

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

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.

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).

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.

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.