Correzione ambientale, C-3PO e SOX

[m_b]

Ciao, come software per correzione cosa utilizzate/utilizzereste? Stavo guardando oltre a DRC anche Acourate e Dirac. Dirac pare veramente a prova di inesperto (e questo mi farebbe comodo per abbreviare i tempi), e non necessità particolari conoscenze, ma non capisco come potrei utilizzarlo in una configurazione a 2 PC con LMS su Ubuntu + R2 su Gentooplayer

[marcoc1712]

Ciao, come software per correzione cosa utilizzate/utilizzereste? Stavo guardando oltre a DRC anche Acourate e Dirac. Dirac pare veramente a prova di inesperto (e questo mi farebbe comodo per abbreviare i tempi), e non necessità particolari conoscenze, ma non capisco come potrei utilizzarlo in una configurazione a 2 PC con LMS su Ubuntu + R2 su Gentooplayer

Io non amo le cose automatiche, quindi - per me - sicuramente non DIRAC.

DRC + DRC Interface è già meglio, nel senso che almeno puoi impostare dei parametri, poi però il risultato è quello e non puoi intervenire.

So che può sembrare presuntuoso, ma in realtà lo stesso autore lo ammette, DRC è tutt'altro che perfetto, in molti casi fa scelte 'arbitrarie' che portano a differenze anche di 6db, quindi molto importanti e non potendo intervenire... Per me, ripeto, per me, non va bene.0

Accourate non lo conosco nei dettagli, ma produce FIR in automatico, pare senza possibilità di intervento sul risultato, magari è meglio degli altri (o peggio, chssà) ma non fa per me.

Io uso REW per generare i filtri partendo dalle misure, poi però intervengo sul risultato con correzioni manuali ed alla fine produco il FIR con linearizzazione di fase usando rePhase.

E' una scelta di fondo: se vuoi il risultato subito e senza tante preoccupazioni DIRAC, DRC o Accourate, se vuoi uno strumento che devi prima imparare ad usare ed i cui risultati saranno tanto migliori quanto più te ne saranno chiari i principi, REW o qualsiasi equalizzatore parametrico fanno al caso tuo, puoi anche decidere di usare solo rePhase, al limite.

[SimoneFil]

Mi permetto un po' di necroposting per segnalare questo -> https://www.diyaudio.com/forums/pc-b...ction-etc.html

Supporta ora anche input e output da stdin e stout; si potrebbe provare ad usare al posto di BruteFIR

[marcoc1712]

Mi permetto un po' di necroposting per segnalare questo -> https://www.diyaudio.com/forums/pc-b...ction-etc.html

Supporta ora anche input e output da stdin e stout; si potrebbe provare ad usare al posto di BruteFIR

interessante, non conosco Rust, ma pare essere uno dei tanti dialetti di Java, darò certamente un occhio. Se usa STDIN e STDOUT può già essere inserito nella catena di LMS, anche con C-3PO, hai fatto delle prove?

EDIT:

Soffre dello stesso problema di SOX: non riallinea temporalmente i diversi canali se la catena dei filtri è diversa, risultando in uno sfasamento temporale che dovrebbe essere risolto manualmente, il che è praticamente impossibile.

[SimoneFil]

interessante, non conosco Rust, ma pare essere uno dei tanti dialetti di Java, darò certamente un occhio. Se usa STDIN e STDOUT può già essere inserito nella catena di LMS, anche con C-3PO, hai fatto delle prove?

EDIT:

Soffre dello stesso problema di SOX: non riallinea temporalmente i diversi canali se la catena dei filtri è diversa, risultando in uno sfasamento temporale che dovrebbe essere risolto manualmente, il che è praticamente impossibile.

No Rust non è un dialetto di java, è compilato e molto più simile a C++, lo sto studiando in queste settimane per puro caso.
Le prove dovrei riuscire a farle in questi giorni.
Per il problema dello sfasamento temporale (per il mio uso) non è un problemone, usando filtri uguali; mi rendo conto però che chi usa filtri differenti per canale sia più una rogna. Mi preoccupava più la breve interruzione di cambio traccia che avevi notato con BruteFIR (mentre con sox era assente).
Appena trovo un po' di tempo proverò a testarlo come si deve e riferirò

[marcoc1712]

No Rust non è un dialetto di java, è compilato e molto più simile a C++, lo sto studiando in queste settimane per puro caso.
Le prove dovrei riuscire a farle in questi giorni.
Per il problema dello sfasamento temporale (per il mio uso) non è un problemone, usando filtri uguali; mi rendo conto però che chi usa filtri differenti per canale sia più una rogna. Mi preoccupava più la breve interruzione di cambio traccia che avevi notato con BruteFIR (mentre con sox era assente).
Appena trovo un po' di tempo proverò a testarlo come si deve e riferirò

Per filtri identici sui diversi canali SOX è perfetto ed applica sia FIR che IIR senza problemi, nemmeno di gapeless, comunque facci sapere, grazie.

[UnixMan]

Soffre dello stesso problema di SOX: non riallinea temporalmente i diversi canali se la catena dei filtri è diversa,

e perché mai dovresti voler fare due xover diversi per i due canali?

risultando in uno sfasamento temporale che dovrebbe essere risolto manualmente, il che è praticamente impossibile.

perché impossibile? Non vedo la difficoltà. Una volta fatti i filtri misuri la (differenza di) latenza ed aggiungi banalmente un ritardo corrispondente nel canale che ha la latenza minore...

[marcoc1712]

e perché mai dovresti voler fare due xover diversi per i due canali?


perché impossibile? Non vedo la difficoltà. Una volta fatti i filtri misuri la (differenza di) latenza ed aggiungi banalmente un ritardo corrispondente nel canale che ha la latenza minore...

1. Io non lo uso per Xover ma per la correzione ambientale, per un Xover perchè non andrebbe bene SOX?

2. Prova. Se lo fai da software in RT è esattamente come dici, ma il processo in se aggiunge ulteriore latenza, di cui devi tenere conto, cosa impossibile da fare e controllare compiutamente (con tolleranza accettabili, cioè inferiori ad una rotazione di fase) a mano con un controllo 'statico', senza contare che fino a 800Hz è magari fattibile, oltre...

Il punto è che in digitale si ha il vantaggio del frame, che contiene tutti il campione di tutti i canali al tempo t, che quindi sono per natura sincroni, se 'rompi' il frame e produci stream indipendenti nasce il problema della sincronia e qualsiasi tentativo di ricrearla è imperfetto.

Dov'è il vantaggio nel farlo?

Solo il ridurre al massimo la latenza assoluta, ma in riproduzione non ce ne frega assolutamente nulla, quindi un DSP (o mixer) deve mantenere l'integrità dei frames tenendo conto dei ritardi introdotti dai filtri.

Ovviamente il 'come' ricostruisci i frame ha un effetto, ma almeno è concluso all'interno della catena di effetti del DSP, trasparente a valle.

[UnixMan]

per un Xover perchè non andrebbe bene SOX?

chi l'ha detto? Non io. È solo un'altra opzione.

[...] ma almeno è concluso all'interno della catena di effetti del DSP

ma infatti intendevo dire di farlo (aggiungere il delay compensativo) proprio all'interno della catena degli effetti di questo "CamillaDSP", così come penso intendesse dire l'autore:

If there are different FIR filters for different channels, they need to be matched so they have the same latency. It would also be ok to add a simple delay to a channel to make up for a shorter FIR latency. I guess that in most cases a crossover will be designed in matched pairs, so there is no relative delay between the high- and lowpass filters. But if you then add a FIR room correction to only the LF channels, the HF will be too early and needs a delay. This isn't done automatically.

BTW: non so se si possa riuscire a fare altrettanto utilizzando l'effetto "delay" di SoX all'interno della catena... hai provato?

[marcoc1712]

non so se si possa riuscire a fare altrettanto utilizzando l'effetto "delay" di SoX all'interno della catena... hai provato?

Si, con pessimi risultati, una volta che hai separato i due stream, li tratta separatamente e quello che succede quando tenti di rimetterli insieme è un macello, almeno in RT, magari funziona meglio se lo usi su files statici, ma 1 non mi serve, 2 ho i miei dubbi.