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