Wtfplay - misurazioni e confronti con players

Pagina 53 di 81
prima
... 3 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 ... ultimo
Visualizzazione dei risultati da 521 a 530 su 807
  1. #521
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da gefrusti
    Il livello pari a -105db è un average spettrale del rumore (noise)...
    Domanda Secca: Quei -105 dB sono il residuo del rumore in F1 - F2, partendo da uno 0 db fissato al livello di F1 (o F2)?

    Se si, quale è il rierimento dei -97 dB di Fi-W2?


    Originariamente inviato da gefrusti
    gli spike sono relativi all'alimentazione della catena audio...i 50hz sono la frequenza di rete (Enel) il resto i suoi armonici.
    Questo era chiaro, ho parlato di un frigo che si accende...

    Originariamente inviato da gefrusti
    Non esiste alcuna "anomalia" in F1...ma molte + anomalie tra F1 e W1...tra F2 e W2...tra F3 e W3...rispetto agli incroci rilevabili con la ripetizione dello stesso segnale nel tempo.
    Si questo lo stai ripetendo, ma non lo (di)mostri.

    Cioè vuoi dire che lo spike a 50Hz ed in tutti gli armonici è presente sia in F1 che in F2 ed F3, W1, W2, W3, D1, D2, D3 ma evidentemente di ampiezza relativa molto maggiore, e diversa, visto che quello che si evidenzia è 'solo' la componente residua che da forma a quello spike e "non è una anomalia"?

    Sarebbe ben strano... A quanto è il livello assoluto di quegli spikes in F1 ed in F2? in W1 e W2? in D1 e D2? Perchè questa ENORME variabilità dell'ampiezza in ripetizioni diverse ed in players diversi?

    Originariamente inviato da gefrusti
    Vedendo le irregolarità della forma d'onda...il delay sfasa soltanto il segnale...il jitter lo deforma.
    La rappresentazione del grafico è stata messa per "far vedere" un paio di sinusoidi...ma andrebbe zoommata nel dominio del tempo per osservare meglio che vi sono delle irregolarità
    Non è vero. il delay riproducibile come tale sfasa, ma un delay NON riproducibile come ritardo almeno di un periodo (ed i 330 nSec NON LO SONO) vengono acquisiti (nel secondo campionamento) ESATTAMENTE come Jitter, cioè nel dominio della frequenza e NON del tempo, quindi modificando la forma d'onda.

    Se sbaglio, dimmi, per favore, che altro modo hai di rappresentare un ritardo di 330 nSec in uno stream 44100/16 a due canali.
    Ultima modifica di marcoc1712 : 05-07-2016 a 14:45
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  2. #522
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da gefrusti
    ...il "non può" ti fa ricadere nello stesso errore da dilettante annunciato ad inizio 3D.
    Le tue "certezze" non sono le mie...quindi io dico che può-


    Tom.
    Io sono ORGOGLIOSAMENTE dilettante e quando non so chiedo speigazioni a chi, evidentemente, è un professionista.

    Ma se un Professionista pretende di puntare il dito contro un mio errore (possibilissimo) ad inizo THD, gradirei che tale erropre mi venisse confutatao con argomenti e non solo esposto al dileggio...

    QUALE ERRORE?


    Tu stai sostenendo che il clock può essere alterato (jitter) in modo che al dac pervenga il campione relativo al canale destro al tempo 't0' ed al canale sinistro al tempo 't0+dT' all'interno della stessa frame e l'errore è è mio?

    La tua sarebbe una grande scoperta, dato che io non so proprio come possa accadere, visto che il 'frame' e le tecniche di rappresentazione dei canali al suo interno sono lì proprio ad evitare che questo possa succedere, ingenerando diversa latenza nei due canali, cosa invece CERTA usando stream diversi.

    Se lo dimostri e lo spieghi, avrai un grande sostenitore al tuo fianco, pur dilettante.

    EDIT: perchè alora non prefigurare un ritardo tra i primi 8 bit più significativi di un canale ed i secondi meno significativi? O magari ritardi alternati tra i bit pari e quelli dispari,...Quale sarebbe l'effetto?

    Perchè proprio tra i 16 del canale L ed i 16 del canale R, ma tra loro estattamente sincroni?

    Quello che, mi risulta, succedere è:

    T0> Ch1+Ch2 , T1 > Ch1+Ch2 , T2 > Ch1+Ch2 ,...

    NON c'è modo di rappresentare nel tempo un delta tra T e T1 o T1 e T2, che in teoria è sempre 1/sample rate * channels, in realtà varia per gli errori del clock. Se inserisci il processo DA/AD con 2 clock diversi, puoi certamente dare luogo a dati (bit) diversi, 'congelando' gli errori del primo clock e le differenze tra i due nei bit, differenze che si manifesteranno in 'rumore', con diverse caratteristiche, dipendentemente dal grado di correlazione dello stesso rispetto al segnale.

    TUTTO il thd si fonda su questo errore di impostazione. Pretendi di misurare fenomemi che portano a pico secondi di variazione con metodi la cui precisione è nell'ordine dei micro secondi o meno.

    Certo, io sono solo un dilettante.
    Ultima modifica di marcoc1712 : 05-07-2016 a 14:51
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  3. #523
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da gefrusti
    Almeno qui...in questo caso...nessuno ha assegnato l'oscar del vincitore tra linea viola e bianca...qui semplicemente si dimostra che tra canale SX e DX di Foobar e canale SX e DX di wtf c'è una differenza....solo questo...differenza.
    Le linee dovrebbero viaggiare assieme altrimenti-


    Tom.
    NO? e cosa vuol dire che WFT è più preciso e coerente? Non è questo grafo a dimostrarlo? allora quale (tra quelli che hai postato)?
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  4. #524
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da SM63
    Marco ...cerco molto semplicemente spiegare il fine della prove condotte domenica ....

    Questa volta si è deciso acquisire su due canali ...proprio per verificare l'andamento degli stessi ....per escludere possibili errori ...tra dac e pc per le acquisizione ...compreso l'intera catena ...si è proceduti nel seguente modo ..

    il player riproduce una traccia stereo ...identico contenuto tra i due canali ...il nul test su i canali si puo' condurre in piu modi ...

    A ) sorgente analogica Out L/R Dac ...oppure come in questo caso Out morsetti ampli L/R >Aquisisco in unico canale ....entro in bilanciato dalla scheda audio ...L+ per il canale sinistro L- per il canale destro ....il prodotto dell'acquisizione sara una cancellazione ...quello che rimane la differenza tra i due canali ...

    B) sorgente analogica come al punto A ...con la variante ...acquisisco in conteporanea due canali L/R separati ....il null test si procede invertendo di fase una delle due acquisiszioni ...audition come altri edit permette una funzione ..incolla miscela i due canali ....quello che rimane sara la differenza tra gli stessi ....


    Il nul test ottenuto dalle acquisizione ...prendiamo l'esempio F1 F2 F3 accertare la congruenza ...tra le stesse ...potendo facilmente dedurre per esclusione sia il dac e il pc atto alle acquisizioni ...non introducono errori nel sistema ....

    Stessa prassi per gli altri player ....

    Alla fine ci troviamo

    F1 F2 F3 = nul test foobar

    W1 W2 W3 = nul test WTF

    D1 D2 D3 = Nul test Daphile

    Se poniamo a confronto W1 con D1 ...vedi grafici spostati ...le differenze sono meno marcate .rispetto F1 con W1 ....questo ci sta indicare un diverso andamento tra i due canali ....

    Possiamo partire da questo ?


    Prima di proseguire vorrei sia ben chiaro il lavoro fin qui esposto .. ...
    Grazie Salvatore, io credo sia così, ma il metodo che esponi è diverso da quello che sostiene (negli ultimi post) abbiate usato gefrusti, che indica:

    a. che il segnale nei due canali non è identico, ma sfasato di 330 nSec.
    b. che NON is tratta di confronto tra canali dello stesso stream ma NTD tra due acquisizioni successive.

    Detto questo, che non è ininfluente ai fini della correttaintrepretazione dei risultati,

    1. il metodo A e B sono logicamente equivalenti, il primo è una cancellazione acustica di segnali posti in contro fase che NON risentono del secondo campionamento (lo subisce solo il risultato) mentre nel primo caso prima ricampioni ed acquisici (quindi 'fissi' l'errore nei bit dei due canali) poi estrai il delta.

    Proprio perchè il clock è comune ai due canali, hai un errore ridotto rispetto ad usare stream separati, ma hai sempre l'errore di campionamento che non è nullo. A mio avviso allo scopo è forse preferibile A, se non hai agganciato i due clock.

    2. entrambi i metodi che descrivi NON sono NTD, cioè confronto tra acquisizioni succesive, MA confronto tra acquisizioni SINCRONE, proprio perchè canali diversi dello stesso stream.

    3. Se è come dici, lo '0' in ampiezza può essere fissato al valore assoluto di uno dei canali, ad esempio L di F1, facendo assumera la grafo anche un valore assoluto di riferimento per la ocrrelazione. Tutti daccordo che non sarà precisissimo, ma trovare il risultato della cancellazione a -105 o a -30 dB è ben diverso... Mi confermi se c'è questa correlazione o meno? Se non c'è, il delta in ampiezza è comunque significativo o le curve sono state arbitrariamente spostato sull'asse dei dB?

    Questo fa una differenza ENORME, gefrusti prima dice che è come hai spiegato tu, poi dice che non ho capito nulla ed è una NTD, quindi torna ad essere il confronto tra due canali.

    Gradirei che gefrusti confermasse il metodo che avete seguito, e spieghi il significato di quanto ha scritto poco sopra, ma per me si può anche tenere per buono quello che scrivi (che mi pare molto più sensato), INVALIDANDO tutte le considerazioni conseguenti alla falsa indicazione di cui sopra.

    Ribadisco, che SE si fosse chiarito il metodo A PRIORI e postati i risultati esaustivamente, avremmo tutti perso meno tempo ed avremmo risultati più chiari.

    In questo momento io non riesco ancora ad interpretare compiutamente quanto postato, per queste lacune. Ma sono un dilettante...
    Ultima modifica di marcoc1712 : 05-07-2016 a 14:19
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  5. #525
    Moderatore L'avatar di SM63
    Registrato
    Jul 2014
    Età
    62
    Messaggi
    418
    configurazione

    Predefinito

    Marco in queste analisi il clock ovviamente non è agganciato ...

    Se ho compreso bene il tuo disappunto ..non ti spiegi come mai il segnale pur facente parte dello stesso stream risulta sfasato tra i due canali con circa 330nsec ?

    Domanda pertinente ...pero nello stesso modo di dovrebbe accertare ...in un file audio originale un eventuale ritardo tra i due canali ...credo un po interissi la latenza ....


    nulla si crea nulla si distrugge ma tutto si trasforma

  6. #526
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da SM63
    Marco in queste analisi il clock ovviamente non è agganciato ...

    Se ho compreso bene il tuo disappunto ..non ti spiegi come mai il segnale pur facente parte dello stesso stream risulta sfasato tra i due canali con circa 330nsec ?

    Domanda pertinente ...pero nello stesso modo di dovrebbe accertare ...in un file audio originale un eventuale ritardo tra i due canali ...credo un po interissi la latenza ....
    Non è che non me lo spiego, ma mi dite a fasi alterne che è lo stesso identico segnale o che è sfasato di 330 nSec. NON è lo stesso segnale se c'è il delay!
    IN ORIGINE è lo stesso segnale nei due canali o c'è un ritardo relativo di 330 nSec tra i due?

    ---

    In un file originale, intendendo con questo un file musicale, un ritardo su un canale dovuto a caratteristiche di ripresa o di missaggio che abbiano provocato maggiore latenza, si fissa nei bit o come 'shift' di n campioni (quindi NON è più all' interno della stessa frame) o - quando il delay è più piccolo del periodo minimo rappresentabile in base tempo, viene trasposto sul piano delle frequenze, come una 'variazione' di ampiezza in determinate frequenze.

    E' evidente quindi che la capacità di rappresentare delay di breve durata in base tempo è in funzione esclusiva del sample rate.

    Non può essere che così, non esiste altro modo, comunque tale ritardo sia stato introdotto. A tutti gli effetti, questo è un errore di Jitter che NON riesci più ad individuare ed eliminare, si è fissato nei bit, è parte del segnale, mentre il primo puoi riallineralo (volendo) shiftando di 'n' campioni uno dei due canali.

    Olte a questo, in un file musicale difficilmente il contenuto dei due canali è identico in termini di frequenze e dato che il jitter sinusoidale si manifesta con ampiezza funzione diretta della frequenza del segnale, è chiaro che a parità di errore di clock, l'effetto sui due segnali è diverso. Il fatto poi che in un segnale musicale stereo, la 'diversità' tra i due canali aumenta al crescere della frequenza (il contenuto in basse frequenze è spesso comune e statisticamente più simile) contribuisce ulteriormente ad amplificare le differenze del rumore provocato, proprio alle alte frequenze.

    Il punto è che il 'jitter da latenza' tecnicamente non è più jitter quando riproduciamo il file, è parte del segnale e la stessa sorte capita a TUTTO il jitter protto e raccolto in fase di riproduzione e manifestato in fase di conversione D/A: la successiva conversione A/D lo 'introduce' nel file acquisito e NON è più distinguibile come tale se non per confronto. SE i clock non sono agganciati, si aggiunge anche l'errore proprio del secondo clock e la differenza relativa tra i due.

    Per chiarezza:

    44100Hz 2 canali = 22050 Hz x canale -> 1/22050 = 0.045 mSec.

    Differenze 'temporali' inferiori a questo periodo NON possono essere rappresentate in base tempo, ma DEVONO essere traslate nel dominio della frequenza, cioè NON cambiano la distribuzione dei bit nei frame (tempo statico) ma cambiano i bit di per se.

    330 nSec sono ben al di sotto di tale limite, quindi se un canale è sfasato di tale tempo (la domanda eventualmente è come, senza DSP) , la sua riproduzione 'introduce' un delta che NON è in alcum modo rappresentabile in base tempo, quindi altera l'ampiezza del segnale a determinate frequenze, modificando la forma d'onda. ...Abbiamo introdotto Jitter, in misura molto maggiore rispetto a quanto intendiamo verificare...

    Spiegazione pedestre di un dilettante, ma fidati, a grandi linee è così.
    Ultima modifica di marcoc1712 : 05-07-2016 a 15:47
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  7. #527
    Moderatore L'avatar di SM63
    Registrato
    Jul 2014
    Età
    62
    Messaggi
    418
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Non è che non me lo spiego, ma mi dite a fasi alterne che è lo stesso identico segnale o che è sfasato di 330 nSec. NON è lo stesso segnale se c'è il delay!
    IN ORIGINE è lo stesso segnale nei due canali o c'è un ritardo relativo di 330 nSec tra i due?

    ---
    Il segnale in origine è identico ......capisco perfettamente quello che intendi dire ....infatti alle uscite analogiche tra i due canali non sono presente le stesse informazione ....appunto per questo sono servite tre acquisizione per ogni player ....se F1 -con F2 produce la stessa forma d'onda tra F1 - con F3 ...se permetti lo sfasamento rimane costante ....vedilo pure come errore ..ma pur sempre costante ... stesso discorso per le altre ...è il confrotto tra di loro che non trova congruenza ...

    Se conosci altro modo per ovviare a questo inconvenite ...basta indicare come procedere ...

    Provo con un'altro esempio ....vogliamo accertare una eventuale diversita tra due o piu distanze A-B con C-D ...pero ci manca il metro ...anche se ne avessimo uno .... da un certo punto di vista sarebbe sempre una misura relativa ...perche dipenderebbe dal grado di precisione dello stesso o dal metodo adottato ...pero possiamo stabilire con assulata certezza che ....relativamente la distanza A-B è piu lunga o piu corta rispetto C-D .....anche con un banale pezzo di filo ...questo al momento abbiamo accertato ...
    Comprendo il disappunto ..infatti le cose vanno esposte con la massima chiarezza ...basta non entrare in loop ...
    Ultima modifica di SM63 : 05-07-2016 a 16:48


    nulla si crea nulla si distrugge ma tutto si trasforma

  8. #528
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da SM63
    Scusa il ritardo queste sono le traccie audio https://drive.google.com/file/d/0B3k...ew?usp=sharing
    mmh, non ricordo più cosa dovevo fare...

    Da un rapido confronto, il contenuto di flac e wav è identico ("bit-perfect"):
    codice:
    $ shncmp 09\ Traccia09.flac 09\ Traccia09.wav
    Comparing [09 Traccia09.flac] (4:26.10) and [09 Traccia09.wav] (4:26.10) : 100% OK
    
    Contents of these files are identical.
    ...ovviamente, quella con il marker viene riconosciuta come diversa. Rimuovendo i marker (con kwave), si conferma che l'aggiunta dei marker non aveva alterato altre parti del file:
    codice:
    $ shncmp -s 09\ Traccia09\ con\ marker\ rimosso.wav 09\ Traccia09.wav
    Scanning [09 Traccia09 con marker rimosso.wav] and [09 Traccia09.wav] : 100% OK
    
    File the second file seems to have 111804 extra bytes (27951 extra samples, or 48 extra sectors)
    
    These extra bytes will be ignored in the full comparison.
    
    Preparing to do a full comparison...
    
    shncmp: warning: WAVE data size differs between these files -- will check up to smaller size
    Comparing [09 Traccia09 con marker rimosso.wav] (4:18.31) and [09 Traccia09.wav] (4:26.10) : 100% OK
    
    Aligned contents of these files are identical (up to the first 45583464 bytes of WAVE data).
    BTW: da dove viene quella traccia? Come è stata prodotta?

    (e... da che album è tratta?).
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  9. #529
    Moderatore L'avatar di SM63
    Registrato
    Jul 2014
    Età
    62
    Messaggi
    418
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    mmh, non ricordo più cosa dovevo fare...

    Da un rapido confronto, il contenuto di flac e wav è identico ("bit-perfect"):
    codice:
    $ shncmp 09\ Traccia09.flac 09\ Traccia09.wav
    Comparing [09 Traccia09.flac] (4:26.10) and [09 Traccia09.wav] (4:26.10) : 100% OK
    
    Contents of these files are identical.
    ...ovviamente, quella con il marker viene riconosciuta come diversa. Rimuovendo i marker (con kwave), si conferma che l'aggiunta dei marker non aveva alterato altre parti del file:
    codice:
    $ shncmp -s 09\ Traccia09\ con\ marker\ rimosso.wav 09\ Traccia09.wav
    Scanning [09 Traccia09 con marker rimosso.wav] and [09 Traccia09.wav] : 100% OK
    
    File the second file seems to have 111804 extra bytes (27951 extra samples, or 48 extra sectors)
    
    These extra bytes will be ignored in the full comparison.
    
    Preparing to do a full comparison...
    
    shncmp: warning: WAVE data size differs between these files -- will check up to smaller size
    Comparing [09 Traccia09 con marker rimosso.wav] (4:18.31) and [09 Traccia09.wav] (4:26.10) : 100% OK
    
    Aligned contents of these files are identical (up to the first 45583464 bytes of WAVE data).
    BTW: da dove viene quella traccia? Come è stata prodotta?

    (e... da che album è tratta?).
    Bene .....non ti resta che ascoltarle ...possibilmente con wtf .... confronta prima quella in flac ..con quella wav ...dopo la flac con il wav incluso i maker ..

    Velut Luna, la purezza del suono nella ricerca musicale


    nulla si crea nulla si distrugge ma tutto si trasforma

  10. #530
    kibibyte
    Registrato
    Jun 2016
    Età
    58
    Messaggi
    206

    Predefinito

    Vediamo...per l'ultima volta (mi sforzerò al massimo) se riesco a far comprendere a Marco tutto quanto è stato rilevato-

    Dunque...facciamo un resoconto stile "for dummies"

    Tom (gefrusti) ha mandato a Salvatore (sm63) un segnale multitono per misure di distorsione integrale...questo segnale è composto da 120 sinusoidi-
    E' stato chiesto (usando questo segnale) di ripetere 3 acquisizioni per ogni player usato...questo per poter capire quanto la catena risultasse "costante nel tempo".
    Le acquisizioni sono state prelevate dai morsetti dei diffusori (una condizione di effettivo ascolto) rigorosamente al medesimo volume e in simultanea tra canale destro e canale sinistro.
    Una volta acquisiti tutti i 12 segnali...3 ripetizioni stereo per foobar (f1, f2, f3) e 3 ripetizioni stereo per wtf...Salvatore (sm63) ha inviato a Tom (gefrusti) tutto l'intero materiale per delle analisi-
    Tom (gefrusti) rinunciando alla gita al mare con la famiglia ha bruciato un intera domenica per le verifiche...verifiche che ha ben ripetuto affinchè non vi fossero errori.
    Come detto parecchie volte i segnali sono stati passati ad una NTD incrociando sia le ripetizioni (f1, f2, f3) e poi (w1, w2, w3) affinchè si valutasse il valore intrinseco del segnale "differenza" prodotto.
    Se tra f1, f2, f3 si è ottenuto un determinato valore (costante e circoscritto entro scarti piccolissimi) questo si è ripetuto per i confronti successivi su w1, w2, w3...per cui...abbiamo la ragionevole certezza che il setup e i due player producono un segnale uguale a se stesso se ripetuto -nel tempo-
    Fatto questo si sono messi a confronto tramite NTD (che a me interessa soltanto per capire se ci sono differenze...visto che poi analizzo con altri strumenti tarati e certificati) i segnali f1 con w1...f2 con w2 e f3 con w3.
    Se prima (tramite i confronti dello stesso segnale prodotto dai medesimi player ripetuti -nel tempo-) la NTD aveva generato un segnale differenza di un determinato valore (per capirci fissiamolo a 5) successivamente incrociando i segnale riprodotti da player diversi hanno generato un segnale differenza con valore piu elevato (e costante tra i vari incroci di sequenze)...per capirci fissiamolo a 10)
    Dunque...come funziona la NTD...che il delta con valore piu elevato indica maggiori differenze nei segnali esaminati.
    A questo punto...otteniamo la prima "indicazione" del fatto che i segnali prodotti dai due player sono molto piu DIVERSI di quanto lo siano le ripetizioni degli stessi sul medesimo player (il famoso errore 5 contro 10).
    Aver osservato che sono diversi fornisce si...un indicazione preliminare...ma non il perchè lo siano...ovvero COSA cambia nel segnale per produrre un delta maggiore se confrontati i segnali da player diversi (foobar vs Wtf).
    Ecco...qui per poterlo capire bisogna utilizzare una strumentazione adatta affinchè si possa visualizzare un overlay della forma d'onda e studiarne la geometria.
    Se tra f1-f2-f3 e w1-w2-w3 il segnale risulta geometricamente congruente con SE STESSO (con i dovuti distinguo per piccole asperità sul delay...che appare soltanto come uno "spostamento lineare della forma d'onda") caricando i segnali f1 con w1...f2 con w2...f3 con w3 (ossia quelli che hanno generato un delta pari a 10) emerge (oltre a piccole asperità sul delay) che la forma d'onda NON risulta soltanto "spostata"...bensi geometricamente non lineare...quindi con difformità sia in ampiezza che nel dominio del tempo con cicli sfasati in modo non lineare-
    Jitter ? direi di si-

    Fatto questo...Tom (gefrusti) ha chiesto a Salvatore (sm63) l'acquisizione di un intero brano MUSICALE per un ascolto (volevo condurre un test in cieco) senza pensare troppo al fatto che anche questi segnali musicali sarebbero stati verificati strumentalmente.
    Tom (gefrusti) ha chiesto soltanto l'acquisizione riprodotta da FOOBAR e da WTF...Salvatore (sm63) invece ha volutamente inserito ANCHE la riproduzione tramite daphile-

    I segnali sono stati acquisiti in simultanea (canale SX e DX ai morsetti dei diffusori).
    Faceva caldo...e non mi sentivo in condizioni psico-fisiche "adatte" per poter condurre ascolti critici (i miei sono micidiali e necessitano di condizioni "favorevoli")...per cui (visto che oramai la domenica l'avevo compromessa) ho voluto spenderci qualche altra oretta per verificare COSA ci fosse in quei segnali-

    Innanzitutto i 3 files musicali non avevano la medesima lunghezza (ovvio...Salvatore (sm63) avrà premuto lo start-stop in tempi diversi)
    ...questo è ininfluente ai fini della prova...l'importante è che il file ci sia DENTRO per intero.

    Quello relativo a daphile ha una durata pari a minuti 4,22.202
    Quello relativo a foobar ha una durata pari a minuti 4,22.351
    Quello relativo a WTF ha una durata pari a minuti 4,24.097

    Analizzando il picco massimo in ampiezza (-3.14db) dei 3 files risulta essere circoscritto entro 0,01db (foobar e wtf identici...daphile -0.01db) riguardo il canale LEFT.
    mentre per il canale RIGHT lo scostamento "sale" a 0.02db.
    Queste microtolleranze appartengono alle variazioni "analogiche" dell'intera catena (un segnale analogico non si ripete matematicamente su se stesso...l'importante però che lo scostamento risulti risibile)

    Visto che la questione "geometria della forma d'onda" l'avevo gia visionata...ho voluto verificare se tra canali vi fosse uno scostamento casuale...ossia se tra LEFT e RIGHT dello stesso segnale risultasse una differenza se confrontata tra l'allineamento di LEFT e RIGHT dell'altro segnale...trattandosi di una riproduzione stereo in simultanea non doveva esserci...INVECE c'era-
    Considerando che queste cose le dovreste vedere con strumentazione adatta e NON tramite un view-editor (che fa la media sull'intervallo temporale di un sample...quindi 22.67us/2 per una frequenza di campionamento pari a 44.100hz) è emersa una differenza irregolare pari a 317ns (nanosecondi) (ricordavo 330ns...ma ho voluto puntualizzare visto che si cerca il pelo nell'uovo)
    Anche se il segnale stereo fa parte dello stesso frame..se jitterato...NON significa che tra i due canali si manifesti il medesimo errore in quanto il CONVERTITORE D/A genera una forma d'onda di due canali analogici potenzialmente non congruenti tra essi.
    Il jitter causa difformità nella forma d'onda in maniera NON prevedibile...per cui tra i due canali si possono perfettamente manifestare incongruenze di natura temporale.

    Se non sono riuscito a spiegarmi mi arrendo...più di cosi non posso.

    buona serata.

    Tom.

Pagina 53 di 81
prima
... 3 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 3 utenti che stanno visualizzando questa discussione. (0 utenti e 3 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022