Originariamente inviato da
marcoc1712
E cosa potrebbe fare di diverso?
Se non correggi il sample rate, dato un punto (il centro) di collimazione, più ti allontani da esso più l'errore si accumula e diventa evidente. Proprio l'andamento a'a farfalla' è indice che stai considerando un drift, dovuto ad una differenza di sample rate nei due segnali, comunque generata. SE allineasse all'inizio, avresti la massima differenza alla fine o viceversa.
Hai segnali identici per numero di campioni allo stesso sample rate nominale, non hai differenze nel dominio del tempo, ma solo un 'residuo' di differenza (perchè minore del minimo rappresentabile in base tempo) che in qualche modo si deve distribuire... Se 'allunghi' i campioni (come fai allineando solo il tempo) ottieni questo, se ricalcoli il sample rate, ottieni una distribuzione più omogenea.
In entrambi i casi applichi un algoritmo che altera il contenuto in bit dei singoli campioni, nel modo che gli stai chiedendo tu di fare.
Quello che NON consideri è che il delta che vedi, se minore al semperiodo, NON è REALE! è li, solo come residuo, perchè la componente maggiore l'hai 'cancellata' eliminando interi campioni quando hai allinenato manualmente. In un file digitale (come è quello che stai analizzando) NON puoi rappresentare nel tempo <22.68 uSec a 44100 Hz!
ES. Se tra due acquisizione hai 1 msec di ritardo, manualmente allinei con uno shift di 44 campioni, per un totale di 997,73 uSec, inevitabilmente ne lasci 2,27 (2270 nSec), che in qualche modo devono essere rappresentati nel dominio della frequenza ed inevitabilmente questo comporta imprecisioni 'sistemiche' , dato che non riesci a rappresentere il ritardo parimenti a tutte le frequenze.
Prova a mettere quei 2,27 uSec "all'inizio", come fai? Non puoi dire ad un frame di suonare silenzio per 2.27 uSec, quindi iniziare...
Se vuoi che 617400 si 'srotolino' ESATTAMENTE in 14 secondi, DEVI avere ESATTAMENTE un sample rate di 44100, altrimenti ne ottieni 13.999 o 14.001 (del tutto ininfluente all'ascolto) per farlo non hai tanti modi, decidi tu quale vuoi appplicare, ma non è che un modo sia più sbagliato di un altro.
Diversi valori di allineamento producono diversi 'resti', del tutto scorrelati dal valore assoluto del ritardo stesso, quindi, se credi che la differenza risieda nel 'ritardo', NON devi togliere i 997.73 uSec, non preoccuparti dei 2.27.
ALtra dimostrazione? invece di togliere 1 mSec da una traccia, allineale togliendone 0.5 da una ed aggiungendone 0.5 all'altra, con silenzio.
Cosa succede? Allinei manualmente e togli 22 campioni dalla prima e ne aggiungi 22 alla seconda per un totale di 498,8662132 uSec. In questo modo le tracce hanno lo stesso numero di campioni, ma rimangono disallineate di 2.27 uSec.
Come fai ad allinearle?
C'è 'maggiore correlazione' tra le tracce a seguito del primo o del secondo allineamento?
Se il taglio diei files lo hai fatto manualmente o comunque con tools che NON agiscono nel dominio della frequenza, l'effetto che vedi è solo la minore o maggiore 'quantità' di ritardo lasciato nello stream perchè non rappresentabile nel dominio del tempo, altrimenti dipende rispetto a cosa hai allineato i divresi gruppi di tracce e da quanto era il ritardo contenuto.
Vedendo 'i numeri' si capirebbe bene.
