estoy con rafa 100%
Ventajas de utilizar un motor de audio de 64 bits
OFERTASVer todas
-
-11%Focusrite Scarlett 8i6 3rd Gen
-
-25%Slate Digital ML-1 Matte Black
-
-48%Behringer Powerplay P16-M Personal Mixer
Lo del paning law es un recurso ya muy viejo, a mi no me vale...
Es muy fácil, haced una mezcla en un par de DAWs, los que queráis, no tiene porque ser demasiado compleja, mismos plugins con los mismos parametros en cada canal, aseguraos de que el Paning Law también es idéntico en ambos y después renderizar asegurándoos de aplicar los mismos parámetros en el menu de Bounce de cada programa (frecuencia de muestreo, resolución en bit, calidad de renderizado, etc...), por ultimo, simplemente cargar los archivos resultantes en uno y otro programa y hacer un null test en ambos, a ver si es verdad que los archivos se anulan completamente el uno al otro.
En Samplitude por ejemplo y dependiendo del modo de monitorización en el que trabajemos, los resultados varían muy ligeramente, pero varían, y hablo de diferencias dentro de un mismo programa, así que difícilmente lo de que todos los programas suenan igual...otra cosa es que esas pequeñas diferencias sean decisivas en el contesto de una producción completa, que en mi opinión, no lo son.
Si solo tiráis de audio (sin procesos de ningún tipo), es lógico que en la gran mayoría de programas las ondas se anulen, a nivel de audio puro y duro las diferencias entre calidades en los programas Pro son realmente insignificantes...y en muchas ocasiones ni existen.
Un saludo.
Es muy fácil, haced una mezcla en un par de DAWs, los que queráis, no tiene porque ser demasiado compleja, mismos plugins con los mismos parametros en cada canal, aseguraos de que el Paning Law también es idéntico en ambos y después renderizar asegurándoos de aplicar los mismos parámetros en el menu de Bounce de cada programa (frecuencia de muestreo, resolución en bit, calidad de renderizado, etc...), por ultimo, simplemente cargar los archivos resultantes en uno y otro programa y hacer un null test en ambos, a ver si es verdad que los archivos se anulan completamente el uno al otro.
En Samplitude por ejemplo y dependiendo del modo de monitorización en el que trabajemos, los resultados varían muy ligeramente, pero varían, y hablo de diferencias dentro de un mismo programa, así que difícilmente lo de que todos los programas suenan igual...otra cosa es que esas pequeñas diferencias sean decisivas en el contesto de una producción completa, que en mi opinión, no lo son.
Si solo tiráis de audio (sin procesos de ningún tipo), es lógico que en la gran mayoría de programas las ondas se anulen, a nivel de audio puro y duro las diferencias entre calidades en los programas Pro son realmente insignificantes...y en muchas ocasiones ni existen.
Un saludo.
En primer lugar, si lo que se quiere testear es el "summing" de un DAW lo lógico es que todos procesen la misma información, o sea audio, y si se sabe que hay diferencias entre el Pan Law se haga en mono. Al fin y al cabo el pan law lo puedes modificar con un plugin al final, el "summing" y resolución interna no.
Si metes MIDI o automatizaciones de plugins, puede que los plugins se esten llamando de manera diferente, hay que ajustar muy muy bien la configuaración y entender mucho cada DAW para poder hacerlo con plugins, además cada plugin por dentro es una caja negra que no se sabe como opera, me explico.
Los plugins no funcionan de forma de lo que se diría "sample accurate", cuando tu automatizas un parámetro, este se actualiza cada N samples, N puede ser 512, 1024 o lo que sea, pero no se actualizan los parámetros a frecuencia de audio, símplemente por CPU, por ejemplo requiere mucha más potencia de cálculo actualizar los coeficientes de un filtro que calcular el filtro en si, por lo que en un simple filtro que jala un 1% de CPU, actualizar los coeficientes en cada sample chuparía un 20% de CPU como mínimo.
Así luce el código de la llamada más importante que el host hace a un plugin:
Lo subrallado en negrita, sampleframes, es el parámetro del que hablaba, son los samples que vas a calcular sin cambiar los parámetros internos.
Por lo que el MISMO motor de audio si llama a los plugins en bloques de 512 o 1024 sonará diferente, símplemente porque las automatizaciones internas de parámetros se haran con menos frecuencia.
Notese que actualizar un parametro cada 1024 samples es hacerlo cada por ejemplo 1024/44100 = 23,2ms, es más que suficiente, lógicamente en un algunos parámemtros críticos esto no es suficiente, como en un cutoff o algo así, en ese caso se van interpolando internamente los parámetros para que no suene brusco, en el attack de la envolvente de un sinte no.
Si en dos DAW de 32bit float las llamadas se hacen de la misma manera el sonido no va a cambiar, lo que a ver quien ajusta esta resolución igual, no es práctico, y requiere tener un plugin con su código enganchado a un debugger.
Si tuviera todos los DAWs del mundo, os podría decir con que frecuencia llama cada uno a los parámetros de control de los plugins configurados por defecto, con tal tarjeta a tal latencia, esto puede explicar diferencias en el consumo de CPU dependiendo de como se ajuste.
Si quereis engancho un plugin aquí que sólo saque por pantalla cada cuantos samples se están haciendo las llamadas.
Si metes MIDI o automatizaciones de plugins, puede que los plugins se esten llamando de manera diferente, hay que ajustar muy muy bien la configuaración y entender mucho cada DAW para poder hacerlo con plugins, además cada plugin por dentro es una caja negra que no se sabe como opera, me explico.
Los plugins no funcionan de forma de lo que se diría "sample accurate", cuando tu automatizas un parámetro, este se actualiza cada N samples, N puede ser 512, 1024 o lo que sea, pero no se actualizan los parámetros a frecuencia de audio, símplemente por CPU, por ejemplo requiere mucha más potencia de cálculo actualizar los coeficientes de un filtro que calcular el filtro en si, por lo que en un simple filtro que jala un 1% de CPU, actualizar los coeficientes en cada sample chuparía un 20% de CPU como mínimo.
Así luce el código de la llamada más importante que el host hace a un plugin:
void rafasynth::processReplacing (float** inputs, float** outputs, VstInt32 sampleFrames)
{
//Implementacion
}Lo subrallado en negrita, sampleframes, es el parámetro del que hablaba, son los samples que vas a calcular sin cambiar los parámetros internos.
Por lo que el MISMO motor de audio si llama a los plugins en bloques de 512 o 1024 sonará diferente, símplemente porque las automatizaciones internas de parámetros se haran con menos frecuencia.
Notese que actualizar un parametro cada 1024 samples es hacerlo cada por ejemplo 1024/44100 = 23,2ms, es más que suficiente, lógicamente en un algunos parámemtros críticos esto no es suficiente, como en un cutoff o algo así, en ese caso se van interpolando internamente los parámetros para que no suene brusco, en el attack de la envolvente de un sinte no.
Si en dos DAW de 32bit float las llamadas se hacen de la misma manera el sonido no va a cambiar, lo que a ver quien ajusta esta resolución igual, no es práctico, y requiere tener un plugin con su código enganchado a un debugger.
Si tuviera todos los DAWs del mundo, os podría decir con que frecuencia llama cada uno a los parámetros de control de los plugins configurados por defecto, con tal tarjeta a tal latencia, esto puede explicar diferencias en el consumo de CPU dependiendo de como se ajuste.
Si quereis engancho un plugin aquí que sólo saque por pantalla cada cuantos samples se están haciendo las llamadas.
Vale, tengo una duda de momento y creo que tiene que ver con lo que se está hablando aqui, tengo que releerme este hilo unas cuantas veces, me ha pasado en una mezcla que en el DAW aunque marcaba rojo en un fader de pista de vez en cuando pues no se escuchaba nada mal, o sea no se escuchaba el clip.
Esta ba trabajando a 24 bits, como debia convertir a mp3 para subir a hispasonicos lo baje a 16 bits y ahí si se escuchan los clips, y ademas bastante molesto.
Creo que tiene relacion con lo del rango dinamico que habeis explicado mas arriba, si lo he entendido bien.
Si fuese así, cual es la solucion a esto? trabajar directamente a 16bits cuando el destino va a ser de 16 bits? o guardrme un margen para que no clipee al reducir a 16 bits?
por otro lado, el audio CD va a16 bits, luego las mezclas comerciales tambien las deben reducir.
Gracias por todo
Esta ba trabajando a 24 bits, como debia convertir a mp3 para subir a hispasonicos lo baje a 16 bits y ahí si se escuchan los clips, y ademas bastante molesto.
Creo que tiene relacion con lo del rango dinamico que habeis explicado mas arriba, si lo he entendido bien.
Si fuese así, cual es la solucion a esto? trabajar directamente a 16bits cuando el destino va a ser de 16 bits? o guardrme un margen para que no clipee al reducir a 16 bits?
por otro lado, el audio CD va a16 bits, luego las mezclas comerciales tambien las deben reducir.
Gracias por todo
Parece muy lógico lo que dices, no te quito la razón, pero me gustaría añadir que no solo ocurre con las automatizaciones, excluyendo los instrumentos virtuales de la ecualización, noto que muchos VST, EQs, compresores, etc...reaccionan de manera distinta en distintos programas, es algo ligeramente similar a cuando trabajamos un mismo proyecto con distintas frecuencias de muestreo, en las que los resultados que arrojan esos procesos son distintos y generalmente más precisos trabajando a frecuencias de muestreo más altas.
En mi opinión comparar el sonido de distintos programas basándonos solo en muestras de audio no tiene demasiado sentido, quien quiera puede hacer las pruebas que crea pertinentes, pero será una perdida de tiempo, (siempre y cuando estemos hablando de programas serios), porque si bien es cierto que hay diferencias notables en la monitorización, esas diferencias nunca van a plasmarse tras realizar los respectivos Bounces y hacer una comparativa poniendo en contrafase una de las pistas, yo lo más parecido al termino "diferencias" que he obtenido en esas pruebas, han sido varios clips puntuales de no más de una fracción de segundo de duración...pero llamar diferencias a eso es un poco osado, las cosas sin embargo se complican bastante cuando tratamos mezclas complejas o semicomplejas ITB, el sonido empieza a emborronarse a medida que introducimos más pistas y los bounces dejan de ser tan precisos como cuando solamente tratábamos con audio.
En este foro y en otros muchos la mayor parte de la gente trabaja ITB, eso es una realidad, por tanto considero vital tener en cuenta como reaccionan unos y otros programas cuando tenemos 10 o 40 plugins insertados en una mezcla...y cada uno lo hace a su manera, evidentemente para aquel que solo trabaja con hard este punto es mucho menos critico.
Por cierto, que olvide comentarlo en mi primer post, desactivar cualquier tipo de dithering antes de hacer el bounce, ya que eso podría desvirtuar los resultados.
En mi opinión comparar el sonido de distintos programas basándonos solo en muestras de audio no tiene demasiado sentido, quien quiera puede hacer las pruebas que crea pertinentes, pero será una perdida de tiempo, (siempre y cuando estemos hablando de programas serios), porque si bien es cierto que hay diferencias notables en la monitorización, esas diferencias nunca van a plasmarse tras realizar los respectivos Bounces y hacer una comparativa poniendo en contrafase una de las pistas, yo lo más parecido al termino "diferencias" que he obtenido en esas pruebas, han sido varios clips puntuales de no más de una fracción de segundo de duración...pero llamar diferencias a eso es un poco osado, las cosas sin embargo se complican bastante cuando tratamos mezclas complejas o semicomplejas ITB, el sonido empieza a emborronarse a medida que introducimos más pistas y los bounces dejan de ser tan precisos como cuando solamente tratábamos con audio.
En este foro y en otros muchos la mayor parte de la gente trabaja ITB, eso es una realidad, por tanto considero vital tener en cuenta como reaccionan unos y otros programas cuando tenemos 10 o 40 plugins insertados en una mezcla...y cada uno lo hace a su manera, evidentemente para aquel que solo trabaja con hard este punto es mucho menos critico.
Por cierto, que olvide comentarlo en mi primer post, desactivar cualquier tipo de dithering antes de hacer el bounce, ya que eso podría desvirtuar los resultados.
Respecto a la pregunta original del foro, la respuesta es "depende", os dejo por aquí lo que comentó al respecto hace tiempo un ingeniero del foro oficial de Magix, para quien le pueda interesar...(in english).
"As to whether 64-bit fixed point or 32-bit floating point is superior for audio, the answer is "it depends". What it depends on is the particular algorithm being implemented. FFT-based processing is characterized by dramatic increases in dynamic range as the FFT length increases. In such applications, floating point processing is preferable. On the other hand, long FIR filters such as are used in linear-phase EQ are preferably done in 64-bit fixed point. That way, the entire multiply-accumulate loop can be done with no loss of precision, and then dithered to the output word length at the end. It's an interesting question which numeric format would be best for IIR filters (conventional EQ's). I think it probably depends on the internal signal flow graph, and of course how high a Q one must support."
"As to whether 64-bit fixed point or 32-bit floating point is superior for audio, the answer is "it depends". What it depends on is the particular algorithm being implemented. FFT-based processing is characterized by dramatic increases in dynamic range as the FFT length increases. In such applications, floating point processing is preferable. On the other hand, long FIR filters such as are used in linear-phase EQ are preferably done in 64-bit fixed point. That way, the entire multiply-accumulate loop can be done with no loss of precision, and then dithered to the output word length at the end. It's an interesting question which numeric format would be best for IIR filters (conventional EQ's). I think it probably depends on the internal signal flow graph, and of course how high a Q one must support."
Pues a mi como ingeniero (técnico) de bits, alus, acumulador y mov ds, ax
mov dx, offset int 21h la verdad es que hace tiempo que me dejaron de preocupar cualquier prueba de laboratorio que no sea mezclar y escuchar.
LA base es imprescindible, pero de verdad, lo mejor de todo (y lo más científico) sigo pensando que es el ensayo/error, pues adecuar un trabajo con altísimo porcentaje creativo (por no decir todo) a métodos científicos no lo veo.
Por supuesto sin menospreciar ningún dato, que todo lo que sea aprender siempre está bien. Y por supuesto siempre que nos dediquemos a mezclar/masterizar, si es dirigido a un ingeniero creador de daw, plugs, o lo que sea ya es otra cosa.
Creo que lo mejor de todo es que cada uno aporte lo que sabe, si a alguien no le interesa no tiene porque leerlo, pero ahi queda para quien le interese.
mov dx, offset int 21h la verdad es que hace tiempo que me dejaron de preocupar cualquier prueba de laboratorio que no sea mezclar y escuchar.
LA base es imprescindible, pero de verdad, lo mejor de todo (y lo más científico) sigo pensando que es el ensayo/error, pues adecuar un trabajo con altísimo porcentaje creativo (por no decir todo) a métodos científicos no lo veo.
Por supuesto sin menospreciar ningún dato, que todo lo que sea aprender siempre está bien. Y por supuesto siempre que nos dediquemos a mezclar/masterizar, si es dirigido a un ingeniero creador de daw, plugs, o lo que sea ya es otra cosa.
Creo que lo mejor de todo es que cada uno aporte lo que sabe, si a alguien no le interesa no tiene porque leerlo, pero ahi queda para quien le interese.
Alguien escribió:Confirmación verbal, si no se quiere tener la posibilidad de perder muestras si. Recuerda que el + 48 es en el master y el - 48 en la pista, también recuerda que ese ejemplo es punto fijo, en flotante es otra cosa.
Gracias por el tiempo y las respuestas, me queda todo muy claro. Esta pregunta era precisamente por el tema de protul, que tenia entendido que en versiones antiguas por lo menos trabajaba a 24 bits, no recuerdo donde lo escuche, entonces me inquietaba saber si la forma de trabajar en ese secuenciador permitía hacer grabaciones a 24 bits, o solo era posible registrar audio a 16 bits.
Alguien escribió:Primero que para el rango dinámico deberías tener cuenta si hablas de un float32 o un int32, el rango dinámico de un float es brutalmente mayor que el de los int, aproximadamente 1500dB, eso te da un headroom que no te lo acabas, por eso se dice que el float no clipea.
Dicho esto, lo que hace el motor de audio al llegar a la pista de master, en caso de ser un motor int, adecua su resolución interna a los bits de salida, truncado - aproximando los bits de diferencia.
En el caso del float, convierte su valor a int, como el rango de trabajo es de -1 a 1, se multiplica la mezcla por la mitad del número de posibles estados de los bits, p.ej 16bits -> 65535/2 , se le suma la mitad de número de posibles estados para que el rango vaya de 0 a n, en vez de de -n/2 a n/2 , y una vez se tiene ese valor se pasa a punto fijo, lo ideal sería redondear los decimales si los hay (64float), es en esta fase donde se producirá el clipping, ya que los valores por encima de -1 a 1 darán fuera de rango de la resolución final.
En realidad el rango dinámico no es parte de mis inquietudes, el mayor rango dinámico lo doy por hecho, por eso di un ejemplo colocándome en una situación hipotética en donde el rango dinámico quedara fuera de la ecuación, mi inquietud es respecto a que tan destructivo puede ser para un archivo pasar por el motor de audio de un secuenciador.
Alguien escribió:En teoría el wav y el aiff son lo mismo a nivel de que son una manera de ordenar bits creo que uno es Big Endian y el otro Little, pero nada más, no llevan ulaw-alaw ni compresión por defeto. El pan law puede ser lo que varíe entre secuenciadores, de hecho es lo que hace que suenen diferente.
No sabia que wav y aiff eran lo mismo, pero no importa solo era un ejemplo para saber si en verdad las conversiones a otros formatos obtendrían el mismo resultado en diferentes plataformas. Lo del pan law, pues muchos secuenciadores te presentan diferentes opciones seleccionables, si en dos secuenciadores que tengan esa opción seleccionas la misma ley de panoramizacion, debería quedar sanjado ese inconveniente?
Alguien escribió:Depende del pan law del secuenciador el archivo puede variar, estas pruebas se deberían hacer en mono, también supongo que te refieres a un archivo de menos de 32 bits, por ejemplo 24 bits.
Preferiría también hablar del mismo secuenciador trabajando a 32 o a 64bits.
Dicho esto del archivo y al tratarse de solo el doble no debería variar, ya que sean int o float ambos tienen como mínimo 24 bits de significado. En punto fijo el resultado sería un archivo igual con los bits desplazados una posición a la izquierda.
Alguien escribió:De nada, me gustaría que te tomaras la paciencia también de enteder la diferencia entre punto flotante y fijo ya que la escribí, te ayudará a resolverte solo alguna de tus preguntas.
La diferencia entre punto flotante y fijo la tengo clara, pero no así cuales son las diferencias al manejar un archivo. Si codifico a 24 se cuantos intervalos de cuantización tendré, pero no me queda claro como aplica eso al ser punto flotante, se que utilizar punto flotante me permite expresar cualquier valor en forma de exponente y la cantidad de bit determina que tan pequeño o que tan grande sera el numero que podre representar, pero el archivo en si es un conjunto de valores enteros, no es así? un proceso como amplificar, como el ejemplo que das de amplificar por +48 o - 48, cuando es sobre un archivo de 24 bits enteros, moverá los valores de ese archivo a través de intervalos enteros? es esa mi principal duda, si es así, utilizar un motor de 32 o 64, ya sea float o int, dará lo mismo en este tipo de procesos (recuerdo que mi intensión es establecer que tan destructivo es el motor de audio y en procesos mas complejos es obvia la diferencia entre usar valores int o float) eso es lo que necesito tener claro, como se distribuyen los intervalos de cuantización cuando el motor es float, son infinitos, o están acotados, de 32 a 64 solo tengo un mayor headroom o mas intervalos entre intervalos? Se realizan aproximaciones? bueno eso creo que ya me lo comentaste, eso quiere decir que si comienza a ser destructivo el motor de audio al no ser interger?
Lo otro es que si float no hace clipping, como se controla no sobrepasar el valor máximo soportado por los conversores?
Bueno si me haces diagramitas y ejercicios matemáticos me quedara mucho mas claro, como ingeniero en telecomunicaciones me he habituado un poco a pensar en binario. Saludos y gracias de nuevo.
tacatun escribió:Pues a mi como ingeniero (técnico) de bits, alus, acumulador y mov ds, ax
mov dx, offset int 21h la verdad es que hace tiempo que me dejaron de preocupar cualquier prueba de laboratorio que no sea mezclar y escuchar.
LA base es imprescindible, pero de verdad, lo mejor de todo (y lo más científico) sigo pensando que es el ensayo/error, pues adecuar un trabajo con altísimo porcentaje creativo (por no decir todo) a métodos científicos no lo veo.
Por supuesto sin menospreciar ningún dato, que todo lo que sea aprender siempre está bien. Y por supuesto siempre que nos dediquemos a mezclar/masterizar, si es dirigido a un ingeniero creador de daw, plugs, o lo que sea ya es otra cosa.
Creo que lo mejor de todo es que cada uno aporte lo que sabe, si a alguien no le interesa no tiene porque leerlo, pero ahi queda para quien le interese.
El que quiere aprender soy yo, así que callate
... jejeje, es broma. Yo soy ingeniero en teleco (que no es la misma teleco que se estudia en españa, que al parecer esta mas ligada a multimedia, lo que veo yo son antenas, routers, BSC, BTS y esas cosas incluso mucho terreno, construir torres de telecomunicaciones, calculo estructural y tal, tambien estudie programacion, pero en los tiempos de clipper en DOS, pero nunca ejercí
) y a la vez soy músico, así que ambas cosas me apasionan por igual, tanto ser creativo y componer, como el funcionamiento del software y los cacharros así que déjame disfrutar enterándome de cosas que no tengo por que saber pero me apasiona saberlas, te parece? 
D.W escribió:Parece muy lógico lo que dices, no te quito la razón, pero me gustaría añadir que no solo ocurre con las automatizaciones, excluyendo los instrumentos virtuales de la ecualización, noto que muchos VST, EQs, compresores, etc...reaccionan de manera distinta en distintos programas, es algo ligeramente similar a cuando trabajamos un mismo proyecto con distintas frecuencias de muestreo, en las que los resultados que arrojan esos procesos son distintos y generalmente más precisos trabajando a frecuencias de muestreo más altas.
En mi opinión comparar el sonido de distintos programas basándonos solo en muestras de audio no tiene demasiado sentido, quien quiera puede hacer las pruebas que crea pertinentes, pero será una perdida de tiempo, (siempre y cuando estemos hablando de programas serios), porque si bien es cierto que hay diferencias notables en la monitorización, esas diferencias nunca van a plasmarse tras realizar los respectivos Bounces y hacer una comparativa poniendo en contrafase una de las pistas, yo lo más parecido al termino "diferencias" que he obtenido en esas pruebas, han sido varios clips puntuales de no más de una fracción de segundo de duración...pero llamar diferencias a eso es un poco osado, las cosas sin embargo se complican bastante cuando tratamos mezclas complejas o semicomplejas ITB, el sonido empieza a emborronarse a medida que introducimos más pistas y los bounces dejan de ser tan precisos como cuando solamente tratábamos con audio.
En este foro y en otros muchos la mayor parte de la gente trabaja ITB, eso es una realidad, por tanto considero vital tener en cuenta como reaccionan unos y otros programas cuando tenemos 10 o 40 plugins insertados en una mezcla...y cada uno lo hace a su manera, evidentemente para aquel que solo trabaja con hard este punto es mucho menos critico.
Por cierto, que olvide comentarlo en mi primer post, desactivar cualquier tipo de dithering antes de hacer el bounce, ya que eso podría desvirtuar los resultados.
A mi me sirve plantear primero el escenario con pistas independiente, no mezclas, ya que quería eliminar el elemento subjetivo, aquel que lleva a hacer afirmaciones de que un motor de audio es malo o es bueno sin tener idea de como funciona, poco a poco quería ir integrando elementos a mis planteamientos para así en todo momento mantener mi planteamiento acotado y no se me escapara de las manos sin poder defender mi posición, luego al ir agregando mas elementos a la ecuación mas subjetivo se vuelve el asunto. Lo que quiero demostrar es que no se puede hacer una aseveración como esa de decir por ejemplo "El motor de reaper es mejorable" y luego responder "Te parece mejorable un ruteo de señal a 64 bits de inicio a fin" sin esgrimir mas argumentos que el propio auto convencimiento de que lo que yo digo es la unica verdad y yo se mas que todos los demas, me gustaría que este hilo quedara como precedente de que en algún momento se detallo que es lo que define la calidad de un motor de audio.
Alguien escribió:Lo que quiero demostrar es que no se puede hacer una aseveración como esa de decir por ejemplo "El motor de reaper es mejorable" y luego responder "Te parece mejorable un ruteo de señal a 64 bits de inicio a fin" sin esgrimir mas argumentos que el propio auto convencimiento de que lo que yo digo es la unica verdad y yo se mas que todos los demas
totalmente de acuerdo contigo harpocrates666, es la segunda leida que le doy al hilo, y ya voy comprendiendo mejor todo.
gracias rafa como siempre!
salu
harpocrates666 escribió:
El que quiere aprender soy yo, así que callate
... jejeje, es broma. Yo soy ingeniero en teleco (que no es la misma teleco que se estudia en españa, que al parecer esta mas ligada a multimedia, lo que veo yo son antenas, routers, BSC, BTS y esas cosas incluso mucho terreno, construir torres de telecomunicaciones, calculo estructural y tal, tambien estudie programacion, pero en los tiempos de clipper en DOS, pero nunca ejercí
Pero si no dije que estuviera de más.
Digo que en el fondo, a mi en la parte técnica me gusta tener base, pero no obsesionarme porque teóricamente es mejor. Me gustan los resultados, se hagan con más o menos bits y mejores o peores cacharros.
Por cierto tu eres de teleco y yo soy de informática, en la actualidad ejerzo de técnico de sonido (aparte de que compongo también). Por eso me tiro más a lo del sonido. Precisamente la teoria me cansó durante una carrera donde vimos mucha teoría y después en el mundo laboral las cosas eran muy distintas.
Saludos y todos a aprender
D.W escribió:Respecto a la pregunta original del foro, la respuesta es "depende", os dejo por aquí lo que comentó al respecto hace tiempo un ingeniero del foro oficial de Magix, para quien le pueda interesar...(in english).
"As to whether 64-bit fixed point or 32-bit floating point is superior for audio, the answer is "it depends". What it depends on is the particular algorithm being implemented. FFT-based processing is characterized by dramatic increases in dynamic range as the FFT length increases. In such applications, floating point processing is preferable. On the other hand, long FIR filters such as are used in linear-phase EQ are preferably done in 64-bit fixed point. That way, the entire multiply-accumulate loop can be done with no loss of precision, and then dithered to the output word length at the end. It's an interesting question which numeric format would be best for IIR filters (conventional EQ's). I think it probably depends on the internal signal flow graph, and of course how high a Q one must support."
Esto está fuera de contexto, está hablando de 32 vs 64 en un contexto general, o sea en un algoritmo de procesamiento cualquiera, dicho de otra manera, dentro de un plugin.
Cuando uno programa un plugin, el motor de audio del DAW no pone ninguna restricción, en VST tu solo tienes que entregar un floats y te vienen arrays de floats, es el desarrollador el que en base de los requirimientos de precisión del algoritmo concreto del plugin decide la resolución necesaria.
En cambio en este hilo se está hablando de la resolución en bits aplicada al motor de un plugin, o sea summing de pistas puro y duro, no FFT´s, FIRs, convoluciones etc.
Hilos similares
Nuevo post
Regístrate o identifícate para poder postear en este hilo