Como hay que exportar la mezcla para luego masterizar

Más que cuerpo, lo que noto es que queda más limada, menos estridente; es lógico, estamos cada vez "redondeando" más los picos por llamarlo de alguna manera. Controlar los tiempos de ataque (reales), e ir jugando con el threshold. Pero sin pasarse de la reducción total. Esto lo probé en el taller de mezclas y gustó bastante el resultado.
Ojo, no es invención mía, lo explicaron los machines en el hilo de los limitadores.

Es como la compresión en serie, además como comenta mannwe, se tiene que ser muy cuidadoso con la reducción de ganancia y los tiempos, para que no cause adicionalmente mucho bombeo o pumping en la mezcla. Y pues como bien sabes un limitador tiene el Ratio a tope y si no eres cauto te daña o caga la mezcla; pero no te olvides de conservar y controlar la etapa de ganancia.

Exportar en tiempo real sólo tiene sentido si se usa procesado o instrumentos externos que así lo requieran. Si no se sale del DAW, como en las mezclas In The Box (ITB), es una pérdida de tiempo.

Y el mejor formato intermedio es el que use el motor de audio del DAW: 32 o 64 bits en coma flotante y la frecuencia de muestreo configurada para el proyecto. No requiere márgenes de nivel ni dithering ni otros procesos, lo cual evita pifias humanas y deja la máxima libertad al que tenga que hacer el mastering.

Nethox , podrias explicar porque es eso que dices? No lo entiendo bien , porque sea en 32 bits flotante ,
por lo pronto habra que respetar no pasarse mucho del 0 dbs no?

Ademas el dither siempre que se vaya a sacar audio de Cubase por ejemplo siempre hay que ponerlo?

Disculpas por mi intervención ya que le has preguntado a Nethox y no a mi.

KING CRIMSON escribió:

No lo entiendo bien , porque sea en 32 bits flotante

Se refiere al procesamiento interno del DAW.

KING CRIMSON escribió:

por lo pronto habra que respetar no pasarse mucho del 0 dbs no?

-6 dBFS peak o -18 dBFS RMS como referencias de la mezcla

KING CRIMSON escribió:

Ademas el dither siempre que se vaya a sacar audio de Cubase por ejemplo siempre hay que ponerlo?

El dither se aplica al final del proceso de mastering, cuando bajas la profundidad de bits por ejemplo 24 bits a 16 bits

Alguien escribió:

Exportar en tiempo real sólo tiene sentido si se usa procesado o instrumentos externos que así lo requieran. Si no se sale del DAW, como en las mezclas In The Box (ITB), es una pérdida de tiempo.

No estoy de acuerdo, exportando offline noto perdida de calidad sobretodo en cuanto a reverb y delay, en la exportacion en tiempo real no la noto, quizas si se utilizan plugins que consumen poco esto no ocurra o no sea tan evidente, pero utilizando plugins que consumen bastantes recursos del ordenador a mi si me ocurre.

#21
+1
Muchos desarrolladores de software recomiendan renderizar a tiempo real.

Si exportas a 32bits (coma flotante) puedes pasarte del 0dbfs todo lo que quieras, ojo, teniendo en cuenta que posteriormente se va a masterizar.

KING CRIMSON escribió:

Nethox , podrias explicar porque es eso que dices? No lo entiendo bien , porque sea en 32 bits flotante ,
por lo pronto habra que respetar no pasarse mucho del 0 dbs no?

El 0 dB que se ve en los faders de un DAW en coma flotante no es el fondo de escala (FS) del formato, hay cientos de dBs disponibles por encima y por debajo. Es un punto de referencia arbitrario sincronizado con el 0 dBFS (esta vez sí es FS) de los formatos enteros como 24 o 16 bits para comodidad.
Mientras mantengas el formato en coma flotante al exportar, no hay clipping. Pero como buena práctica por si tienes que usar hardware analógico (escuchar por monitores incluído) y para evitar posibles bugs de plugins, es recomendable no pasarse igualmente.

#24
Oiga!! Muy bien explicado!!

#21 Lo del consumo de CPU en todo caso sería al contrario. Al renderizar en tiempo real impones al software un plazo estricto que offline no existe y, por tanto, puede permitirse tardar más desactivando optimizaciones que degraden la calidad, usando impulsos más largos en reverbs por convolución, usando algoritmos alternativos, usando oversampling...
También puede tardar menos offline si la CPU va muy sobrada en potencia, ya que se elimina el limitador artificial del modo a tiempo real.
El tiempo real no sólo limita la calidad sino los procesos posibles. Por ejemplo la normalización, inversión o time stretching requieren leer gran parte o todo el clip, por eso no existen[1] en formato plugin sino nativos del DAW/editor.
#22 Me gustaría saber alguno de esos desarrolladores que recomienda renderizar en tiempo real y si lo documentan en sus manuales, por ver los motivos.

Hay DAWs como Reaper que permiten notificar a los plugins el modo de renderizado, la opción es "Inform plug-ins of offline rendering state" de Preferences/Plug-ins/VST. No sé si es API propia o lo mismo que la función audioMasterGetCurrentProcessLevel() con valor de retorno 4 de VST[2].
Un plugin con autodetección es Voxengo Tube Amp, ajustando Oversamping a Auto.
Pero la mayoría de plugins que dispongan de varios algoritmos no usarán exclusivamente autodetección sino ajuste auto/manual mediante el GUI. Así se evitan problemas con DAWs que no notifiquen correctamente el modo de renderizado, permiten alta calidad incluso en reproducción y tiempo real si se dispone de CPU potente, evitan diferencia de sonido inesperada para el usuario según el modo de renderizado, y da buena impresión.


Si el modo offline te suena peor, puede ser un bug como éste de Kontakt[3], o un bug del DAW como creo que tuvo Cubase 6.5 con la automatización en offline. O puede que un plugin de los que tienen varios algoritmos sin elección manual casualmente te guste menos en la variante de alta calidad (según los desarrolladores). Es raro pero posible, ya que hay efectos que no son mejor en todo sino un compromiso; como un filtro menos abrupto en frecuencia pero con menor distorsión temporal.

En ese caso lo mejor es probar cambiando sólo el modo de renderizado. Hay que mantener idénticos: formato de muestra (bits, entero/float), frecuencia de muestreo, SRC, plugins y parámetros, automatización, buses y niveles.
En pruebas subjetivas no hay que dejar que el tiempo de procesamiento autosugestione la calidad percibida. Tests AB o ABX.
En pruebas objetivas lo menos obvio puede ser el dithering que, dada su naturaleza aleatoria, dificulta un resultado idéntico[4], por lo que recomiendo desactivarlo o exportar a 32/64 bits en coma flotante. Posibles métodos:
- A nivel binario: cuidando que las cabeceras de los WAVEs sean iguales, un checksum como MD5 debe ser idéntico.
- A nivel de muestra: importando ambos WAVEs e invirtiendo la fase de uno, o usando la función Delta de Wavelab; el resultado debe ser silencio absoluto.

Si resultan ser distintos, se pueden ir desactivando plugins hasta encontrar al responsable, anotar y repetir con los restantes porque puede haber varios con sólo autodección (o bug). Determinar el que tiene más calidad ya requeriría análisis de señales. En caso de encontrar bug, notificar al desarrollador.


[1]: En realidad el estándar VST2.4 soporta un modo offline (distinto al flag "offline rendering state") que permite acceso a todo el clip y no sólo a un buffer pequeño como en tiempo real:
http://www.oifii.org/ns-org/nsd/ar/cp/audio_linuxsampler-cvscheckout/vstsdk2.4/doc/html/vstoffline.html
Pero sólo Wavelab parece implementarlo, creo que son los que salen coloreados en la sección Batch processing, como Meta Normalizer:
https://vstnet.codeplex.com/workitem/7404
[2]: http://www.asseca.com/vst-24-specs/amGetCurrentProcessLevel.html
[3]: http://forum.cockos.com/showthread.php?t=83815
[4]: Es posible comparar ficheros con dither si el generador pseudoaleatorio (PRNG) se inicializa con la misma semilla (seed). El software SoX lo permite con la opción -R.

Acabo de empezar el dia y ya he aprendido algo:

"Hay plugins que dependiendo de los recursos disponibles pueden aplicar un algoritmo u otro"

Gracias Nethox

Joooder Nethox eso es mucho carbon para mi .
Lo voy a guardar para cuando sepa mas jejeje porque ahora me viene larguito .

Gracias.

#26

Gracias por la explicacion

Alguien escribió:

Lo del consumo de CPU en todo caso sería al contrario. Al renderizar en tiempo real impones al software un plazo estricto que offline no existe y, por tanto, puede permitirse tardar más desactivando optimizaciones que degraden la calidad, usando impulsos más largos en reverbs por convolución, usando algoritmos alternativos, usando oversampling...
También puede tardar menos offline si la CPU va muy sobrada en potencia, ya que se elimina el limitador artificial del modo a tiempo real.
El tiempo real no sólo limita la calidad sino los procesos posibles. Por ejemplo la normalización, inversión o time stretching requieren leer gran parte o todo el clip, por eso no existen[1] en formato plugin sino nativos del DAW/editor.

No me refiero a que consuma menos recuros la exportacion en tiempo real, consume mas como tu dices, me refiero que esto me pasa con plugins que consumen muchos recursos (nebula, plugins con oversampling etc)

Alguien escribió:

Si el modo offline te suena peor, puede ser un bug como éste de Kontakt[3], o un bug del DAW como creo que tuvo Cubase 6.5 con la automatización en offline. O puede que un plugin de los que tienen varios algoritmos sin elección manual casualmente te guste menos en la variante de alta calidad (según los desarrolladores). Es raro pero posible, ya que hay efectos que no son mejor en todo sino un compromiso; como un filtro menos abrupto en frecuencia pero con menor distorsión temporal.

No se que sera, siempre utilizaba el modo offline (cubase 3 y 5) pero a partir que fui utilizando plugins que consumian mas, cada vez lo utilice menos por esto que comento (cubase 5-6)

Alguien escribió:

En ese caso lo mejor es probar cambiando sólo el modo de renderizado. Hay que mantener idénticos: formato de muestra (bits, entero/float), frecuencia de muestreo, SRC, plugins y parámetros, automatización, buses y niveles.
En pruebas subjetivas no hay que dejar que el tiempo de procesamiento autosugestione la calidad percibida. Tests AB o ABX.
En pruebas objetivas lo menos obvio puede ser el dithering que, dada su naturaleza aleatoria, dificulta un resultado idéntico[4], por lo que recomiendo desactivarlo o exportar a 32/64 bits en coma flotante. Posibles métodos:
- A nivel binario: cuidando que las cabeceras de los WAVEs sean iguales, un checksum como MD5 debe ser idéntico.
- A nivel de muestra: importando ambos WAVEs e invirtiendo la fase de uno, o usando la función Delta de Wavelab; el resultado debe ser silencio absoluto.

Si resultan ser distintos, se pueden ir desactivando plugins hasta encontrar al responsable, anotar y repetir con los restantes porque puede haber varios con sólo autodección (o bug). Determinar el que tiene más calidad ya requeriría análisis de señales. En caso de encontrar bug, notificar al desarrollador.

Si, casi siempre utilizo los mismos parametros de proyecto y exportacion, como he dicho lo que se nota mas es el reverb y delay principalmente, seguramente el mayor responsable sera nebula que tiene un procesado bastante complejo.
Hare la prueba sin nebula y posteriormente sin reverb's que consuman muchos recursos, ya te contare.

No entiendo algunas respuestas a una pregunta tan simple, no es rocket science.... de hecho rocket science es facil!!

Exporta a la misma resolucion que grabaste y mezclaste. EN lo posible 24 bits - 48Khz . No hay necesidad de mas. Formato WAV (mas compatible) o AIFF (Apple)

Saludos