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

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.

Pues depende de lo que hagan

[I]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.

Efectivamente...


Me llama mucho la atencion, que hay algun post previo (creo que de ese foro) que dice que la precision es vital, que incluso con 64 bits no hay suficiente y otros post dicen lo contrario

Saludos

JP

Jotap_66, debo transmitirte un pequeño post de ayer en el que tu interlocutor foráneo por interpósita persona decía lo siguiente como respuesta a que yo le decía que te había transmitido su respuesta: ¡Jo, gracias! Asegúrate también de decirle [a Jotap_66] que soy simplemente un graduado de la carrera de informática.

Tras algunos comentarios del forero que cité antes no tu 'interlocutor' para que nos entendamos, éste posteo lo siguiente: "No, lo que él [el forero que decía lo que puse en el post #15 aquí] estaba intentando decir es que la implementación de un algoritmo en coma flotante es casi universalmente más lenta que la implementación del mismo algoritmo utilizando números enteros, asumiendo que estás utilizando las capacidades de la CPU al máximo. Lo cual es cierto. De hecho, hay un algoritmo de compresión sin pérdida que es el último grito en HydrogenAudio en estos momentos (TAK), el cual funciona escandalosamente bien. Ha sido implementado casi enteramente a 16 bits utilizando números enteros, en Pascal. ¡El programador ni siquiera está utilizando SSE [Nota: instrucciones especialmente adecuadas para decodificación de MPEG2, que es el códec utilizado normalmente en los DVD, procesamiento de gráficos tridimensionales y software de reconocimiento de voz]! Y, sin embargo, se come a todo lo demás.

Tengo que pensar mucho para dar con una CPU IA32 sin una FPU [Nota: FPU (floating point unit) = Unidad de coma flotante]. Ninguna de ellas son para el desktop. Pero en CPUs integradas, y quizás en muchos DSPs, la coma flotante es algo así como un lujo. Lo que explica porque no es de uso universal en equipos de audio (todavía).

La coma flotante es más fácil de implementar en C/C++ que el código en números enteros, porque los cálculos en coma flotante están totalmente estandarizados entre el estándar C y el IEEE 754, mientras que necesitas implementar tu propia aritmética de números enteros. Eso es quizás lo que quiere decir el forero que dice que la coma flotante es más fácil de implementar para los programadores. ¡Es cierto! Pero no es necesariamente peor".

Un aclaración, creo que importante/aclaratoria, que postea otro forero en el foro foráneo: "La coma flotante a 32 bits del IEEE es una mantisa de 23 bits, 1 bit de signo y 8 bits de exponente. Para el audio digital, el signo y la mantisa juntos dan una resolución de 24 bits y el exponente de 8 bits te permite "resbalar" los 24 bits para arriba y para abajo por 256 bits para un rango dinámico total de alrededor de unos 1600 dB. La resolución en sí, jamás excede los 24 bits, pero el exponente actúa como factor de escalación permitiendo que la resolución de 24 bits (144 dB) se mantenga centrada en el área de interés en torno a un rango de algo más de 1600 dB. Todo este rango dinámico, EMO, es básicamente útil para cálculos internos. Incluso 24 bits son excesivos para grabar y reproducir. No tengo conocimiento de ningún ADC [convertidor de analógico a digital] o DAC [convertidor de digital a analógico] actualmente que se acerque ni de lejos al rendimiento de los 144 dB teóricos ofrecidos por los 24 bits".

Iniciado por Yota

Jotap_66, debo transmitirte un pequeño post de ayer en el que tu interlocutor foráneo por interpósita persona decía lo siguiente como respuesta a que yo le decía que te había transmitido su respuesta: ¡Jo, gracias! Asegúrate también de decirle [a Jotap_66] que soy simplemente un graduado de la carrera de informática.

Se agradece el saber con quien estoy hablando...Yo te he mandado un privado para que le digas al forero mas o menos quien soy...lo cual no quiere decir nada...

Iniciado por Yota

Tras algunos comentarios del forero que cité antes no tu 'interlocutor' para que nos entendamos, éste posteo lo siguiente: "No, lo que él [el forero que decía lo que puse en el post #15 aquí] estaba intentando decir es que la implementación de un algoritmo en coma flotante es casi universalmente más lenta que la implementación del mismo algoritmo utilizando números enteros, asumiendo que estás utilizando las capacidades de la CPU al máximo. Lo cual es cierto.

No siempre, pero en general si....

Iniciado por Yota

De hecho, hay un algoritmo de compresión sin pérdida que es el último grito en HydrogenAudio en estos momentos (TAK), el cual funciona escandalosamente bien. Ha sido implementado casi enteramente a 16 bits utilizando números enteros, en Pascal. ¡El programador ni siquiera está utilizando SSE

Iniciado por Yota

[Nota: instrucciones especialmente adecuadas para decodificación de MPEG2, que es el códec utilizado normalmente en los DVD, procesamiento de gráficos tridimensionales y software de reconocimiento de voz]! Y, sin embargo, se come a todo lo demás.

Si claro, esto es posible....De todas formas tampoco tendria mucho sentido usar SSE si trabaja con enteros...De todas formas si el TAK (tengo que buscar info sobre el, porque no lo conozco) trabaja con enteros sera porque puede hacerlo...Me imagino que trabajara similar al los LZW...y Huffman, es decir contando secuencias iguales (para lo cual no necesita reales)...

Iniciado por Yota

Tengo que pensar mucho para dar con una CPU IA32 sin una FPU

Iniciado por Yota

[Nota: FPU (floating point unit) = Unidad de coma flotante]. Ninguna de ellas son para el desktop. Pero en CPUs integradas, y quizás en muchos DSPs, la coma flotante es algo así como un lujo. Lo que explica porque no es de uso universal en equipos de audio (todavía).

Desde luego CPUS de proposito general sin FPU creo que en este momento no hay...Ahora bien en integradas como tu dices si...De todas formas yo pienso que si no hay integradas con FPU...mas que por un lujo es porque no hace falta...aunque no tengo suficientes conocimientos para decir esto...

Iniciado por Yota

La coma flotante es más fácil de implementar en C/C++ que el código en números enteros, porque los cálculos en coma flotante están totalmente estandarizados entre el estándar C y el IEEE 754, mientras que necesitas implementar tu propia aritmética de números enteros.

Hombre, eso no es exactamente cierto en las CPUS de hoy dia...Practicamente todas usan el mismo tipo de entero....(4 bytes)..Y respecto de implementarte tu aritmetica de enteros, pues tampoco....

Iniciado por Yota

Eso es quizás lo que quiere decir el forero que dice que la coma flotante es más fácil de implementar para los programadores. ¡Es cierto! Pero no es necesariamente peor".

Para nada....Lo siento pero no estoy de acuerdo con eso...Hoy dia las dos son
bastante comunes, y normalmente el programador (salvo casos contados) no implementa nada de eso...¿Te refieres quiza a que la usan?....Usar la coma flotante bien, no es dificl, si se tienen en cuenta una serie de precacuciones....


Saludos

JP

Iniciado por Yota

Un aclaración, creo que importante/aclaratoria, que postea otro forero en el foro foráneo: [I]"La coma flotante a 32 bits del IEEE es una mantisa de 23 bits, 1 bit de signo y 8 bits de exponente.

No, eso no es asi...Son 24 (y no 23) de mantisa, porque esta ultima tiene segun notacion IEEE un bit implicito...es decir, se sabe (por definicion) que el primer bit (el de mas peso) necesariamente ha de ser un 1, por tanto no se almacena....

Lo que comentas del audio....pues lo ignoro...pero segun lo que comentas podrian ser hasta 25, pero aqui ya no tengo ni idea...

Saludos

JP

El famoso ingeniero de sonido Barry Diament se ha unido a la discusión en el foro foráneo y al este extracto de un post:
...Incluso 24 bits son excesivos para grabar y reproducir. No tengo conocimiento de ningún ADC o DAC actual que tan siquiera se acerque al rendimiento teórico de los 144 dB que ofrecen los24 bits".

Le responde lo siguiente:

"Hola,

Mientras que tu segunda afirmación es efectivamente cierta, mis oídos me dicen que la primera no es una con la que estaría de acuerdo. Incluso si nuestros convertidores no están bajando hasta los bits de menor orden, aún así los mejores todavía proporcionan un montón más de información a nuestros oídos que una conversión equivalente a 16 bits".

A lo que le contesta el primero:

"Oh, sí, no pretendía decir que 16 bits es lo mejor que se puede tener. Probablemente en algún lugar cercano a la resolución de 20 bits, para la resolución de presentación final, es donde lad ventajas de añadir más bits se tornan excesivamente pequeñas. Pero ciertamente 24 bits números enteros, 32 bits coma flotante, e incluso resoluciones de números enteros de 48, 56, 64 o incluso más bits pueden ser valiosas para los cálculos DSP en audio, dependiendo exactamente de qué cálculo esté involucrado. ¿Te suena esto correcto? [/I]

Y le responde Barry:

"La segunda parte me suena correcta.

En cuanto a si 20 bits serían en última instancia tan satisfactorios como 24 bits a la hora de escuchar, no lo se. Puede que tengamos que esperar a que la electrónica pueda aprovechar los 24 bits completos.

Mientras tanto, estoy muy contento con la información a 24 bits que sale de mis Metric Halo MIO. Si es excesiva, aprenderá a vivir con ello.[/I] ;-} "