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

Ya, pero el caso es que el resultado final no es que suene mal si no haces las cosas mal, y por otro lado es un secuenciador muy práctico para trabajar. Mira que me he aplicado un huevo, y me lo estudiado a fondo, pero aunque con Reaper voy bastante rápido (muchísimo más rápido que lo que iba en Nuendo) aún voy más lento que en ProTools. Lo bueno de ProTools no es el sonido, que no es malo tampoco, sino el programa en sí, cómo funciona y lo rápido que resulta editar en él.

Salu2.

Alguien escribió:
El hilo surgió por el interés compartido de analizar que factores influyen en las posibles diferencias cualitativas de los motores de audio entre diversos DAW. Es lo que es y cada uno que valore si le es de interés este hilo.

Nada que objetar.

Alguien escribió:
No sé qué tiene eso que ver con lo que se habla aquí. Los plugins quedan fuera del análisis, pues hay miles de ellos y con
muchos algoritmos diferentes.

Me remito a lo anterior.

Alguien escribió:
No hay ningún algoritmo extravagante de DSP en un motor de audio. Otra cosa son los plugins (aunque vengan integrados), que aquí no vamos a comparar, obviamente.

Si no considerais los plugins, estoy de acuerdo, "error mio de interpretacion".

Alguien escribió:
Perdona, pero creo que no se dice eso aquí. Se dice cuando son necesarios más bits y cuando no. En cuanto a ProTools se habla de él para estudiar el caso del punto fijo (y porque se cuenta con más información de su motor que otros), no se dice que sea el mejor. Tampoco es el que mayor profundidad de bits tiene.

Tienes razon, me deje llevar por la vehemencia, y ademas el comentario ha sido "un tanto desafortunado"
Mis disculpas.

Alguien escribió:
Al C no se le considera lenguaje de alto nivel.

Aqui difiero.... no lo consideras tu.... pero mira la definicion actual:

http://es.wikipedia.org/wiki/Lenguaje_de_alto_nivel

http://es.wikipedia.org/wiki/Lenguaje_de_bajo_nivel

Alguien escribió:
Con enteros se puede trabajar con la precisión que quieras mientras tengas bits disponibles

Teoricamente cierto, pero no mencionas los inconvenientes.

http://es.wikipedia.org/wiki/Coma_fija

Alguien escribió:
el programador debe modificar el factor de escala cuando alguna operación produce un resultado fuera del rango de
representación. Por ejemplo: si la suma de dos números en punto fijo produce acarreo, se debe modificarel factor de
escala si no se quiere perder significación en el resultado. Esto implica modificar el factor de escala de todos los números
en punto fijo que utiliza el programa con la consecuente pérdida de precisión. Estos sistemas de representación ofrecen
un rango y una precisión limitados.

Alguien escribió:
Este sistema presenta un cierta dificultad al operar con sumas y restas. El computador debe analizar el signo de los
operadores para decidir la operación que tiene que hacer. Así, si la operación es una suma, pero uno de los operadores es
negativo, se ha de cambiar por una resta. Por el contrario, las operaciones de multiplicar y dividir se tratan sin dificultad, operándose, por un lado, con las magnitudes, y por otro, con los signos.

Alguien escribió:
En el caso anterior no podremos representar números enteros mayores o iguales que 32 (25) ni números más pequeños
que 0,125 (2-3). Debido a este problema, su uso se vio reducido con la aparición de la representación en coma flotante.

Aquí un algoritmo en C++ de summing de pistas en mono (para simplificar). Usa coma flotante, que internamente es más complejo que el punto fijo, pero su manejo aritmético en el código es más sencillo.

[code]

for (track_type::const_iterator track = tracks.begin(); track != tracks.end(); ++track) {
float* in_ptr = track->buffer;
double* out_ptr = mix_buffer;
double level = track->level;
for (unsigned int n = buffer_size; n > 0; --n)
*out_ptr++ += static_cast(*in_ptr++)*level;
}

[/code]

No tenéis que saber C++, lo explico. Es un doble bucle, se recorren las pistas, y de cada una de ellas se recorre su búfer. Cada valor del búfer de pista se convierte en double (64 bits), se multiplica por el nivel de pista y se suma al búfer de mezcla (que es también de 64 bits). Total, en mono el kernel del summing tiene una suma y una multiplicación. Hasta comparado con el filtro más sencillo es simple. Obviamente un código real tiene muchos más detalles de implementación, pero el concepto es el mismo. El motor de audio real de un DAW es sofisticado, pero no a nivel de procesado digital de la señal. Aunque si no se manejan los tipos de datos correctamente se puede perder información.

Alguien escribió:

Ya, pero el caso es que el resultado final no es que suene mal si no haces las cosas mal, y por otro lado es un secuenciador muy práctico para trabajar. Mira que me he aplicado un huevo, y me lo estudiado a fondo, pero aunque con Reaper voy bastante rápido (muchísimo más rápido que lo que iba en Nuendo) aún voy más lento que en ProTools. Lo bueno de ProTools no es el sonido, que no es malo tampoco, sino el programa en sí, cómo funciona y lo rápido que resulta editar en él.

Ningun DAW creo q suene tan mal como para joder el buen hacer de alguien q sabe lo q hace.

Tienes razon, protools es un buen DAW, pero el motor TDM no es para tirar cohetes, nada mas. En cualkier caso, por su politica monopolistica sigue siendo un cancer para la industria.

Alguien escribió:

Alguien escribió:
No hay ningún algoritmo extravagante de DSP en un motor de audio. Otra cosa son los plugins (aunque vengan integrados), que aquí no vamos a comparar, obviamente.

Si no considerais los plugins, estoy de acuerdo, "error mio de interpretacion".

Ah! pues acabaramos!

slds

Alguien escribió:

Aqui difiero.... no lo consideras tu.... pero mira la definicion actual:

http://es.wikipedia.org/wiki/Lenguaje_de_alto_nivel

http://es.wikipedia.org/wiki/Lenguaje_de_bajo_nivel

Has olvidado un artículo:
http://es.wikipedia.org/wiki/Lenguaje_de_medio_nivel

Al C se le considera un lenguaje de medio nivel. En cuanto al C++ depende del paradigma que uses. Pero no quiero terminar con discusiones bizantinas.

Con respecto al punto fijo, no hablamos de cual es más fácil de programar. En todo caso ProTools lo usa porque sus DSP Motorola dan facilidades para ello, igual que en el ordenador se dan facilidades para el flotante. Cada uno tiene sus pegas.

Impresionante explicacion interna de la mezcla de los DAWS. Hay gente muy bien documentada en este foro que ademas de tener una mente muy abierta para ententder y sobre todo explicar esa serie de temas , lo publica para el resto.
GRACIAS por el aporte, genial.

Chus escribió:

Alguien escribió:

Yo uso Reaper, y lo recomiendo a todo el mundo, salvo a los que tengan Protools HD. Solo Protools HD es mejor, a mi juicio, aunque cuesta unas 40 veces más que Reaper en su versión más cara (la versión más cara de Reaper y la versión más barata de Protools HD, digamos).

Pues yo lo dudo, si PTHD realmente fuese 48bit de principio a fin estaria deacuerdo, pero un motor de audio q entre un proceso TDM y otro (incluida la suma) añade dither y trunca de 48 a 24 solo porq su obsoleta arquitectura hardware no permite el flujo a 48 bit entre DSP y DSP, siempre me parecerá una basura, reaper le da mil patadas al motor de audio de PTHD. En PTHD si en cualkier parte del motor de audio TDM pasas de 0dBfs se produce un clip, porq aunq los precesos sean a 48bit el motor trunca a 24 con dither para pasar al siguiente proceso.. y los tios te lo cuentan asi y se quedan tan anchos, oye mira q no vas a tener headroom por encima de 0dBfs y ademas entre cada proceso un poco de ruido dither y racatá truncamiento... PTHD en mi opinion es un cancer.

el PDF q lo explica de la propia digidesign

http://akmedia.digidesign.com/support/d ... _26688.pdf

slds

Efectivamente, aunque el summing lo hace como debe (en HD), los canales individuales están lastrados por su antigua arquitectura. El bus de canal no posee headroom. Eso supone que puedas hacer clipping con facilidad, al contrario que con los demás que sus flotantes de 32-bit les dan un margen dinámico enorme.

La ventaja competitiva de ProTools no es de calidad de sonido sino de reputación. Incluso en cuestiones de latencia hoy en día se puede evitar recurrir a una arquitectura de procesadores dedicados.

Con respecto a su software en sí personalmente es lo que más valor real le doy esa plataforma.

ProTools LE trabaja en coma flotante pero desconozco si su bus de mezcla va a 64 bits.

El valor de ProTools, por mucho que lo odies (me refiero a mi mismo!!!

), acaba siendo evidente en cuanto tienes un proyecto con mucha edición (y como llevamos años escuchando baterías pasadas por beat detective, casi todos los proyectos acaban necesitando un huevo de edición). Yo me conozco Reaper a esta altura bastante bien, y la verdad es que trabajo bastante rápido, pero así y todo tengo la sensación de que ProTools es más rápido para trabajar, acaba siendo más práctico, de un modo u otro. Este es el principal valor, creo yo, amén del márketing y del hecho de que todos los estudios 'pro' lo tienen.

Porque el tema es el siguiente: solo si trabajas 'mal' pondrás tus pistas individuales en clipping. 24 bits son de por sí un huevo de headroom. Vale que sea de puta madre que una arquitectura como Reaper sea prácticamente 'imposible' de clippear (el clipping ocurre en el DAC, creo, pero no en la arquitectura del programa), pero el caso es que TU como técnico deberías trabajar de forma que no necesites eso, y no es tán dificil tampoco.

Un buen técnico empieza por conocer bien el gain staging como concepto, y creo que siempre ha sido así. No es que sea difícil tampoco.

Con todo, yo me sigo quedando ahora mismo con Reaper. La última versión es acojonante, y desde luego que se trabaja en Reaper muchísimo más rápido, mejor y con más flexibilidad que con Cubendo, que al final parece que tiene el motor de audio más cuestionable (aunque lo dicho: con todos los DAWs puedes obtener resultados decentes, si sabes lo que te haces - y si no sabes, no lo lograrás con ninguno!)

Salu2.

[ Editado por la moderacion | normas de los foros ]

harpocrates666, eso que has dicho es muy feo, la opinión de Fran1946 es tan valida como la de cualquiera de los que han intervenido en este hilo, desconoces su experiencia y solo por su edad (el numero que ha puesto en su nick no esta escogido al azar) deberías mostrar un poquito más de respeto hacia el, el no te lo ha faltado a ti en ningún momento.

Por favor, no empañen el buen desarrollo del hilo, luego nos quejaremos de que los expertos se van de Hispasonic.

Alguien escribió:
Harpocrates dijo:
Editado por la moderacion

jajaja xro k koño habras soltado harpocrates
Dejadle es un buen tipo, solo "un poco" violento, pero parece que tiene buen corazon

Alguien escribió:

Con respecto a su software en sí personalmente es lo que más valor real le doy esa plataforma

+1

Me gustaria saber q tienen pensando para cuando renueven HD, supongo q son conscientes de q su hard esta anticuado, q no se puede hoy en dia seguir con buses TDM de 24 bit y q el procesamiento en punto fijo (al q les estan obligando los motorala q en su momento eran DSPs asequibles) no tiene mucho sentido ya q por lo q tengo entendido es mucho mas complicado programar algoritmos para punto fijo q para flotante, es estupido insistir en obligar a la gente q programa plugs tdm a currar mas de lo q en realidad hace falta. Los DSPs float ahora son asequibles, solo hay q ver los DSPs de la UAD2. Deberian aprender de la plataforma de harrison q combina muy bien procesado 64float tanto nativo como DSP (usan lDSPs TI shark muy similares alos q usan las UAD2).

Alguien escribió:

Porque el tema es el siguiente: solo si trabajas 'mal' pondrás tus pistas individuales en clipping. 24 bits son de por sí un huevo de headroom. Vale que sea de puta madre que una arquitectura como Reaper sea prácticamente 'imposible' de clippear (el clipping ocurre en el DAC, creo, pero no en la arquitectura del programa), pero el caso es que TU como técnico deberías trabajar de forma que no necesites eso, y no es tán dificil tampoco.

No puedo estar del todo deacuerdo con esto H. rana, Es cierto q si llevas un esquema de ganancias clasico, derivado del analogico, no te hace falta demasiado headroom por encima de 0dBFS, pero algo si q hace falta, porq trabajando en analogico si aprietas un bus de suma un poco mas de la cuenta no pasa nada si se enciende puntualmente el indicador de clip de tu mesa de hecho en muchas mesas se usa como una tecnica. Normalmente en analogico te fijas mas en los niveles VU y no tanto en el pico ¿porq? por q un pico puntual en la zona no lineal del amplificador de suma no suena mal, es mas, usar esta zona de los summing amps como "limitador/coloreo" en ciertos buses es todo un clasico en SSLs G/E y en muchas otras mesas analogicas, en digital no pasa esto desgraciadamente asi q no queremos el minimo clip digital, tener q estar vigilando cada canal es un poco coñazo, sobre todo porq al contrario de una mesa analogica los previos de liena y buses de suma no hacen q la mesa sea un compresor/limitador y por lo tanto es mucho mas facil terminar con un factor de cresta mayor q en analogico. A lo q voy es q en mi opinion cierto headroom por encima de 0dBfs es necesario, incluso aunq uses un eskema de ganancias de libro, ya q facilita mucho las cosas. No digo q haga realmente falta el headroom brutal q da el procesado en coma flotante, de hecho con el menor headroom q ofrece los 48bit int. respecto al punto flotante tendriamos de sobra, pero para eso no se puede usar un bus de 24bit entre proceso y proceso, ademas, nadie lo ha comentado, pero ¿y la perdida de calidad en el audio por añadir dither y truncar? a mi es lo q mas aberrante me parece.

slds

Bueno, he hecho un pequeño programa en C que analiza empíricamente el error que se produce al hacer summing en 32-bit flotante. Cuando termine publico los resultados en este hilo.

Ferdinanz escribió:

Alguien escribió:
Harpocrates dijo:
Editado por la moderacion

jajaja xro k koño habras soltado harpocrates
Dejadle es un buen tipo, solo "un poco" violento, pero parece que tiene buen corazon

No ha pasado nada, harpocrates hizo un comentario un poco fuera de lugar, nada más, se ha disculpado por ello y ha demostrado ser todo un señor.

Saludos.

El programa cuyo código fuente aquí expongo realiza una simulación numérica de lo que es un proceso de suma en coma flotante de 32 y 64 bits.

He probado con dos versiones. Una genera un ruido diferente en cada "pista" en 24 bits y la convierte la muestra a 32-bit flotante para procesarla. Cada canal se atenúa de forma proporcional al número de pistas más una. Eso quiere decir que si se prueba la suma de 2 pistas, cada una estará atenuada algo más 6dB., con 4 pistas serán algo mas de 12dB, etc. En el sumador se tiene un acumulador de 32-bit flotante y otro de 64-bit flotante. Una vez hecha la suma se convierten los dos resultados otra vez a enteros de 24 bits y se restan para obtener el error del resultado entre la suma de 32 y la de 64. Esos errores se contabilizan para obtener el porcentaje del número de samples que han tenido un error de 1 bit o más.

Esa prueba se realiza con 2, 4, 8, 16, 32, 64, 128 y 256 pistas (todo mono). Cada pista tiene un ruido diferente (descorrelacionado). Los resultados son:
Porcentaje de muestras con error de 1 bit
He realizado una variante del programa donde introduce el mismo ruido en todas las pistas (correlación de 1), atenuándolas de la misma forma que en la versión anterior. Aquí los resultados son mucho mas drásticos acrecentándose la magnitud del error conforme se añaden pistas:
[code]
2: 13.8854%
4: 20.6459%
8: 29.7468%
16: 42.7539% 3.65476%
32: 58.6403% 22.8456% 0.602419%
64: 74.1061% 46.4723% 14.0073% 0.134732%
128: 84.1367% 66.0554% 41.0052% 12.1478% 0.0226757%
256: 90.7555% 79.6116% 62.8389% 38.276% 11.4212% 0.00657596%
1 bit 2 bits 3 bits 4 bits 5 bits 6 bits
[/code]

Como puede observarse en cualquier caso hasta con dos pistas y correlación a cero se produce una diferencia entre el summing de 32-bit y el de 64-bit. La cuestión es si una mezcla real se parecerá a la prueba descorrelacionada o tenderá en algún grado a dar errores mas significativos acercándose a la estadística de la mezcla de pistas iguales.

Sería interesante hacer pruebas con fuentes sonoras diferentes como ondas o audio real. Pero por ahora aquí queda esta demostración. La verdad es que esperaba que los porcentajes fueran menores.

Pongo el código fuente por sí a alguien le interesa (la versión de un ruido diferente por pista). Y por cierto, no me funciona la vista previa del foro, no sé porqué.

[code]
#include
#include
#include
#include

using namespace std;

void do_summing(size_t num_tracks)
{
const size_t num_count = 23;
const size_t num_samples = 44100*60;

size_t count_e[num_count];
for (size_t *ptr = count_e; ptr != count_e+num_count; ++ptr)
*ptr = 0;

float level = 1.0/(num_tracks+1);
for (std::size_t n = num_samples; n > 0; --n) {
double sum_d = 0.0;
float sum_f = 0.0;
for (std::size_t i = 0; i < num_tracks; ++i) {
int sample_i = (rand()&0xFFFFFF)-0x7FFFFF;
float sample_f = static_cast(sample_i)/8388607.0;
sum_f += sample_f*level;
sum_d += static_cast(sample_f)*level;
}

long sum_fi = sum_f*0x7FFFFF;
long sum_di = sum_d*0x7FFFFF;
unsigned int abs_error = fabs(sum_di-sum_fi);
size_t *pcount = count_e;
for (size_t mask = 0x7FFFFF; mask > 0; mask