Wtfplay - misurazioni e confronti con players

[marcoc1712]

Per forza di cose quando acquisisci devi tagliare inizio e fine traccia ...quella che a te pare l'incogrueza è solo la differenza tra il taglio delle traccie ...

Scusa, non ho capito a cosa ti riferisci in riferimento a quanto hai quotato. Intendi dire che i msec sono diversi solo in funzione del taglio delle tracce (sono quindi una posizione relativa) e non la latenza? in questo caso sarebbero del tutto ininfluenti.

La mia perplessità è che - a parità di tutti gli altri fattori - buffer più grandi provochino maggiore cancellazione, mi sarei aspettato l'esatto contrario, eventualmente, per l'effetto di xRuns, ma in effetti si tratta di valori in assoluto alti, probabilmente i fattori sono altri. Sarebbe da investigare.

NOTA BENE: qui quello che cambia sono i bit (stai usando collegamenti asincroni), il tempo è escluso dalla questione. Hai provato a fare una comparaziuone binaria dei files? quante differenze vengono iontrodotte nelle diverse configurazioni?

E' un dato a mio avviso molto importante.

EDIT: Nelle prove fatte SPDIF/SPDIF i files rimanevano IDENTICI, nessun bit cambiato. Cosa succede qui inserendo USB e cambiando il buffer size in ALSA, al di là dell'immancabile e corrsipondente variazione della latenza?

Sarebbe interessante.

[SM63]

[QUOTE=marcoc1712;959463]Sempre per capire:

1. Nelle ripetizioni, i clock sono agganciati o no? (se si hai un drift unico, se no misuri la somma algebbrica dei due).
2. L'hw (compresi i cavi) è lo stesso per tutti i players?
3. Per compensazione di errore ppm intendi l'allineamento assoluto o qualche procedimento più invasivo?
4. WTF l'hai provato in configurazione A, B o è indifferente?
5. La curva riportata è 'la media' delle differenze? il profilo della curva è sempre così ben definito in tutte le singole rilevazioni e cambia solo il 'livello' reciproco?

Evidentemente non so spiegarmi ....come pretendi agganciare i due clock partendo dal dac USB acquisendo in analogico ...almeno questo ....nella seconda verifica si è compreso oppure no ...?

Certo sono stati mantenuti le stesse condizioni per testare tutti i player ...che senso avrebbe tutte il tempo impiegato

Errore ppm ....vedi la casella da spuntare su diffmaker ...compesate for sample rate drift

Non inacasiniamo le cosce lascia perdere per il momento la condizione A B

La curva riportata non è la media ....preso alcune come riferimento ....che senzo avrebbe riportare la media ? quello che conta mancanza nella ripetibilita' ...forse è questo che ancora non ti è chiaro ...

SE i clock sono aggangiati e l'hw è lo stesso, è effettivamente impressionante il fatto che utilizzando un player piuttosto che un'altro si riduca così sensibilmente l'errore ppm, che - in teoria - è una cartatteristica del cristallo variabile principalmente - se non esclusivamente - con la temperatura, non credo possa essere influenzata direttamente via software dal player, nel caso, quindi,. sarebbe interessante individuare ed isolare i processi che producono il drift (la rete? i dischi? il video? ) in modo così preciso e replicabile. Sarebbe un passo importante per capire COSA origina questo tipo di interferenze e prendere contromisure.

Per i motivi appena descritti i clock non possono essere agganciati ....ripeto le seconde acquisizione sono in analogico ...passando dal dac connesso in USB ....se conosci un modo per agganciare il clock ..sarei interessato

Se la correzione consiste in un allineamento temporale assoluto, ci andrei cauto a formulare correlazioni con l'ascolto. L'allineamento in se non è discernibile (ritaro o anticipo dell'evento) ed a seguito di quello le curve diventano quasi sovrapponibili (+/- 2 db a 40KHz).

Osservali con maggiore attenzione il secondo grafico ....curva rossa Foobar senza compensazione ....verde pisello compensato ....non sono +/-2 dB ... quello che ancora non si è compreso WTF curva Blu ..tra una acquisizione l'altra purche fatta in successione come le altre non necessita' alcuna compensazione ....mi sembra di aver parlato della ripetibilita'.... stesso evento ripetuto nel tempo ...gli altri player associati allo stesso hardware ...non si comportano alla stesso modo ...mancano nella costanza ...

Le mie conclusioni sono molto semplice il player come software per forza di cose interagisce con hardware PC incluso il sistema operativo ....forse non sara un caso l'autore del palyer la ridotto volutamente nei minimi termini ...

Ps : scusa conosci bene diffmaker ...prova acquisire ripetutamente lo stesso file due tre quantro ..quante volte vuoi ...confrontali tra gli stessi ....ai fini della ripetibilta' cosa ci dobbiamo aspettare ...?

[campa2]

Mi permetto di intervenire non perche' sia tecnicamente all'altezza ma perche' ho seguito da vicino le prove ed ho avuto i risultati direttamente.....
Il lavoro di Salvatore e' estremamente interessante e ci permette di mettere dei punti fermi su questioni importanti.........traduco per la plebe magari sbagliando.....
I player sono tutti uguali quando in bit perfect.....le differenze ci sono con upsampling e filtri (misurate e in alcuni casi di grossa entita').
Le differenze nel digitale pre dac (che ancora molti negavano fino a poco tempo fa e che ora trovano precisi riscontri nelle misure oltre che negli ascolti )sembrano essere nell'interazione hardware sistema operativo e player in particolare nella gestione dei processi.....cioe' sono questi 3 elementi che insieme producono il risultato......e quando le cose funzionano, come nel caso di wtf il risultato e' costante e non variabile nel tempo come invece per gli altri player-so provati. Wtf sembra annullare le interazioni negative (a livello di clock) e annullare tutto l'offuscamento prodotto da altri player-so
Credo di poter dire che fino a qualche mese fa si metteva l'accento sull'isolamento dell'usb dal pc (naa e simili....con convertitori ottico elettrici) ora credo che il punto non sia tanto quello del rumore prodotto dal pc o dalla qualita' dell'alimentazione del pc (cose che comunque dovrebbero essere significative) ma nell'ottimizzazione e semplificazione estrema dei software.....su questo ora abbiamo un preciso riscontro.
Interessante anche "scoperta" della variabilita' dei risultati.......c'e' una spoegazione alla variabilita' degli ascolti in diversi momenti....utilizzando gli stessi identici apparecchi e software.......chi l'avrebbe detto.......
Sono comunque risultati un po in divenire e da elaborare.......vedremo se saranno confermati e approfonditi....

[bigtube]

Mi permetto di intervenire non perche' sia tecnicamente all'altezza ma perche' ho seguito da vicino le prove ed ho avuto i risultati direttamente.....
Il lavoro di Salvatore e' estremamente interessante e ci permette di mettere dei punti fermi su questioni importanti.........traduco per la plebe magari sbagliando.....
I player sono tutti uguali quando in bit perfect.....le differenze ci sono con upsampling e filtri (misurate e in alcuni casi di grossa entita').
Le differenze nel digitale pre dac (che ancora molti negavano fino a poco tempo fa e che ora trovano precisi riscontri nelle misure oltre che negli ascolti )sembrano essere nell'interazione hardware sistema operativo e player in particolare nella gestione dei processi.....cioe' sono questi 3 elementi che insieme producono il risultato......e quando le cose funzionano, come nel caso di wtf il risultato e' costante e non variabile nel tempo come invece per gli altri player-so provati. Wtf sembra annullare le interazioni negative (a livello di clock) e annullare tutto l'offuscamento prodotto da altri player-so
Credo di poter dire che fino a qualche mese fa si metteva l'accento sull'isolamento dell'usb dal pc (naa e simili....con convertitori ottico elettrici) ora credo che il punto non sia tanto quello del rumore prodotto dal pc o dalla qualita' dell'alimentazione del pc (cose che comunque dovrebbero essere significative) ma nell'ottimizzazione e semplificazione estrema dei software.....su questo ora abbiamo un preciso riscontro.
Interessante anche "scoperta" della variabilita' dei risultati.......c'e' una spoegazione alla variabilita' degli ascolti in diversi momenti....utilizzando gli stessi identici apparecchi e software.......chi l'avrebbe detto.......
Sono comunque risultati un po in divenire e da elaborare.......vedremo se saranno confermati e approfonditi....

Mi permetto di dire che la questione dell'influenza dell'hardware PC è stata intuita da molto tempo. Un esempio il Cmp2 dove tutto il lavoro dell'autore era rivolto a
ridurre al minimo il funzionamento della cpu durante il processo di elaborazionne dello stream massacrando tutto quello che non serve .
Il giovane Polacco autore di Wtfplay a parte scriversi autonomamente il player ha saputo compilarsi un kernel dove probabilmente ha eliminato tutto l'eliminabile
per far girare solo il minimo indispensabile. Questa è la strada maestra e non lo sappiamo da ieri l'altro.....I kernel linux disponibili sono tutti o quasi generici cioè
fanno di tutto in macchine sempre piu' complesse e dedicate a un mucchio di cose che a chi ascolta musica non gliene frega un accidente.

[marcoc1712]

[QUOTE=SM63;959465]

Sempre per capire:




Evidentemente non so spiegarmi ....come pretendi agganciare i due clock partendo dal dac USB acquisendo in analogico ...almeno questo ....nella seconda verifica si è compreso oppure no ...?

Certo sono stati mantenuti le stesse condizioni per testare tutti i player ...che senso avrebbe tutte il tempo impiegato

Errore ppm ....vedi la casella da spuntare su diffmaker ...compesate for sample rate drift

Non inacasiniamo le cosce lascia perdere per il momento la condizione A B

La curva riportata non è la media ....preso alcune come riferimento ....che senzo avrebbe riportare la media ? quello che conta mancanza nella ripetibilita' ...forse è questo che ancora non ti è chiaro ...




Per i motivi appena descritti i clock non possono essere agganciati ....ripeto le seconde acquisizione sono in analogico ...passando dal dac connesso in USB ....se conosci un modo per agganciare il clock ..sarei interessato



Osservali con maggiore attenzione il secondo grafico ....curva rossa Foobar senza compensazione ....verde pisello compensato ....non sono +/-2 dB ... quello che ancora non si è compreso WTF curva Blu ..tra una acquisizione l'altra purche fatta in successione come le altre non necessita' alcuna compensazione ....mi sembra di aver parlato della ripetibilita'.... stesso evento ripetuto nel tempo ...gli altri player associati allo stesso hardware ...non si comportano alla stesso modo ...mancano nella costanza ...

Le mie conclusioni sono molto semplice il player come software per forza di cose interagisce con hardware PC incluso il sistema operativo ....forse non sara un caso l'autore del palyer la ridotto volutamente nei minimi termini ...

Ps : scusa conosci bene diffmaker ...prova acquisire ripetutamente lo stesso file due tre quantro ..quante volte vuoi ...confrontali tra gli stessi ....ai fini della ripetibilta' cosa ci dobbiamo aspettare ...?

Sia chiaro che io non voglio confutare quello che riporti come esperienza provata, ma semplicemnete capirlo ed inquadrarlo, perchè a mio avviso si corre il rischio di saltare troppo rapidamente alle conclusioni.

Per agganciare lo stesso clock nel caso di conversione DA/AD occorre che almeno uno dei dac consenta l'utilizzo di un master clock. Se i due clock sono indipendenti, stai misurando la somma algebrica dei due drift.

Come ti ho già scritto, nelle prove che feci tempo fa con SPDIF (per verificare la questione FLAC/WAV, nell'occasione) la differenza nel dominio digitale, in terminidi bit è risulatta nulla, come ci si aspettava. Il file acquisito è sempre risultato identico a se stesso. Inserendo la conversione AD/DA SENZA aggangiare i clock, il peso dei drift si faceva sentire Potevi ascoltare chiaramente la 'musica' dal file di differenza. Anche AudioDiffMaker ha una funzione di riallineamento, attivando la quale le differenze si assotigliavano molto, ma non spariscono mai, dato che i fattori ambientali - principalmente la temperatura - influiscono sulla precisione e costanza del clock. Due conversioni successive non danno MAI lo stesso risultato sonico ed - ovviamente - la riconversione in digitale non produce mai esattamente lo stesso file di origine. Può risultare 'sconvolgente' perr i sostenitori dei bit che sono bit, ma di fatto è così.

Cosa diversa è sostenere che tali differenze sono udibili. Se hai semplicemente un clock che invece di fornire esattamente 48.000 Hz, vibra a 48.005 o 47.995, l'esecuzione sarà leggermente più veloce o lenta, esattamente come avviene conun giradischi che vada leggermente più forte o più piano di 33 gpm. Fintanto che la velocità è costante all'interno di una esecuzione è irrilevante, se invece varia hai un fenomeo 'tipo' il wow and flutter, che diventa ben udibile.

Nel primo caso la 'corezzione' è 'semplice' (a condizione di avere un riferimento) nel secondo meno.

Ora, tutto questo però non prende atto in riproduzione (anche se teoricamente sarebbe possibile prevedere una funzione di feedback, come avviene in certi DSP, al prezzo di aumentare la latenza) e quindi è completamente al di fuori delle possibilità di controllo del player software.

Se lo stesso hw, nelle stesse condizioni ambientali produce differenze più sensibili tra una riproduzione e l'altra usando SOLO player software diversi ma verificati 'bit perfect' in digitale, allora è evidente che le variazioni si originano nel (nei) dac e con ogni probabilità nel (nei) clock per via assolutamente indiretta.

Se questa differenza è solo o preminentemente dovuta al drift del (dei) clock ed è costante nel breve periodo è ininfluente all'ascolto ed eliminabile mediante un semplice algoritmo matematico, altrimenti si 'fissa' nel contenuto in bit del segnale riacquisito, originando una differenza di contenuto vera e prorpia.

Spero che su questo ci sia accordo.

Più allarmante è la differenza in puro ambito digitale originata dalla modifica dei parametri di ALSA.

[SM63]

[QUOTE=marcoc1712;959483][QUOTE=SM63;959465]

Cosa diversa è sostenere che tali differenze sono udibili. Se hai semplicemente un clock che invece di fornire esattamente 48.000 Hz, vibra a 48.005 o 47.995, l'esecuzione sarà leggermente più veloce o lenta, esattamente come avviene conun giradischi che vada leggermente più forte o più piano di 33 gpm. Fintanto che la velocità è costante all'interno di una esecuzione è irrilevante, se invece varia hai un fenomeo 'tipo' il wow and flutter, che diventa ben udibile.

Piemamente d'accordo ...come giustamente riporti nel primo caso il problema oltre a non porsi a livello percettivo ... sarebbe pure di facile soluzione ....infatti quello che ho rilevato con la seconda prova è proprio la non costanza del clock ....le cause possono essere le piu' svariati ....

A) instabilita dello stesso setup per l'acquisizione (PC1)
B) Hardware (pc) dove installato il player
C) Hardware (dac)

Ipotesi A da escludere per due motivi ....

Primo - se non si ha la certezza dello stadio ADC che garantisca ripetibilita... mi sembra inutile cimentarsi in queste prove .....
Secondo - questo trova conferma dallo stesso risultato ottenuto analizzando il player wtf .....

In automatico esclude l'ipotesi (C ) perche in comune per tutte le acquisizioni come lo stesso (PC1) usato per le acquisizioni ....

Rimane come unica sola ...l'ipotesi (B) ....non è forse quello che tutti cerchiamo ottimizzare con le piu' bizzarre soluzioni ?

Nel primo caso la 'corezzione' è 'semplice' (a condizione di avere un riferimento) nel secondo meno.

Non sono del tutto d'accordo .... anche nella seconda ipotesi disponiamo un riferimento certo ....le stesse acquisizione fatte in successione ....in questo caso poco importa se il clock va piu' avanti o piu' indietro ...l'importante mantenga la stessa cadenza ....questo riscontro punta esclusivamente nella costanza ....non piu' rispetto alla congruenza con il segnale in origine ...come risulta nel primo grafico

Forse questo passaggio non è ancora chiaro ....

Rinnovo l'invito a provare ..visto che conosci bene diffmaker ....ritengo molto interessante incrociare i risultati .... se trovi difficolta' per rappresentare i grafici ..ci penso io ....mi bastano i file dopo elaborati ....vale anche per il segnale da utilizzare come test ...

[marcoc1712]

I player sono tutti uguali quando in bit perfect.....le differenze ci sono con upsampling e filtri (misurate e in alcuni casi di grossa entita').

A me non risulta sia così ed anzi mi pare che una conferma (da investigare) l'abbia riportata lo stesso Salvatore proprio con WTF usando diversi parametri ALSA.

Le differenze nel digitale pre dac (che ancora molti negavano fino a poco tempo fa e che ora trovano precisi riscontri nelle misure oltre che negli ascolti )sembrano essere nell'interazione hardware sistema operativo e player in particolare nella gestione dei processi.....cioe' sono questi 3 elementi che insieme producono il risultato......e quando le cose funzionano, come nel caso di wtf il risultato e' costante e non variabile nel tempo come invece per gli altri player-so provati. Wtf sembra annullare le interazioni negative (a livello di clock) e annullare tutto l'offuscamento prodotto da altri player-so

Mentre concordo (e credo nessuno lo neghi, almeno qui) che sistema operativo, palyer ed hardware interagiscano e producanio effetti sul lavoro del dac, rimane a mio avviso da indagare e dimostrare che:

a. siano sempre e solo 'indiretti' cioè i bit alle porte del dac siano sempre precisamente identici a quelli contenuti nel file originario (molto probabile sia così, nella maggioranza dei casi, ma quanto suggerisce l'esperienza con WFT e ALSA che è stata riportata è l'inverso).

b. escludendo il punto precedente e parlando di collegamenti ASINCRONI, il veicolo siano primariamente 'disturbi' al funzionamento del clock (Jitter).

c. Andrebbe verificata la 'natura' di questi disturbi, che in presenza di isolamento galvanico sarebbero da ricercare in: EMI, RFI, vibrazioni meccaniche, alterazioni della temperatura ambientale. sarebbe bene anche correlarne l'entità con gli effetti sul suono (ben difficile).

d. Andrebbe dimostrata la correlazione tra 'lavoro' del software (compreso il SO) e diversa entità di emissione di quesi fattori di disturbo.

Altrimenti possiamo solo affermare di sentire variazioni del suono (nessuno lo nega) ed osservare alcune caratteristiche nelle misure, ma NON dimostrare una correlazione precisa tra le due cose, sarebbe un grave errore però saltare alla conclusione.

Ciò non toglie che io sia CONVINTO che in conbdizioni 'bit perfect' l'utilizzo di diverse applicazioni produca effetti diversi sul suono, a partite dal playback diretto di WAV o mediante conversione 'al volo' da flac a parità di hw, sw e so, motivo per cui INSISTO che la migliore strategia è quella di tenere TUTTO QUANTO e' possibile su un server remoto e lasciare il solo play dello stream per com'è sul renderer (o client o naa o ...).

Non dubito WTF possa suonare 'meglio' (soggettivo) di squeezelite, ma NON credo sia dimostrato da quelle riportate, anzi...

Credo di poter dire che fino a qualche mese fa si metteva l'accento sull'isolamento dell'usb dal pc (naa e simili....con convertitori ottico elettrici) ora credo che il punto non sia tanto quello del rumore prodotto dal pc o dalla qualita' dell'alimentazione del pc (cose che comunque dovrebbero essere significative) ma nell'ottimizzazione e semplificazione estrema dei software.....su questo ora abbiamo un preciso riscontro.

Mi spiace, non mi pare sia così.

a. In che senso hai " semplificazione estrema dei software" rispetto a squeezelite? Funzionalmente WTF fa di più (ha una simil gui! e prevede la presenza di KVM, notoriamente le maggiori fonti di disturtbo in un PC) niente è più semplice di nulla, mentre brutto non è sinonimo di minimalista.

b. Come ripeto da un bel po, chi suona in primis è ALSA, tant'è che al variare dei suoi parametri avvertite differenze (e riportate anche che non sono bit perfect).

c. l'unico 'orpello' che squeezelite ha in più rispetto a WTF è la rete. Provate a collegare la rete e trasferire un file mentre suona WTF e vediamo se tutto torna 'normale' come per gli altri player. (cioè si evidenziano variabilità di 30 db) Io non credo, ma posso sbaglaire.

Io non posso vedere il sorgente di WTF, qundi non so dire COME è scritto, ma so anche che la magia non esiste, specie in programmazione. Le chiamate ad ALSA sono le stesse per tutti i player, il resto è contorno.

Interessante anche "scoperta" della variabilita' dei risultati.......c'e' una spoegazione alla variabilita' degli ascolti in diversi momenti....utilizzando gli stessi identici apparecchi e software.......chi l'avrebbe detto.......

Non è una novità, AudidiffMaker esiste almeno dal 2001, ma dubito che in quelle misure risiedano le spiegazioni alla variabilità degli ascolti, almeno non nella misura ripor

Sono comunque risultati un po in divenire e da elaborare.......vedremo se saranno confermati e approfonditi....

Mi piacerebbe farlo! ma con ordine e senza saltare a conclusioni affrettate.

Iniziamo ad escludere differenze nei bit alle porte del dac, quindi escludiami il clock driff nel processo DA/AD (o andiamo a vedere perchè WTF sembra esserne maggiormente immune), quindi cerchianmo di stabilire quali sono le vere differenze, da cosa sono originate e come vengono veicolate.

p.s. Squeezelite può riprodurre anche files locali, senza la rete, ma sfido chiunque ad accorgersi della differenza, però possiamo verificare le misure. Lo stesso - ovviamente - vale per foobar.

[marcoc1712]

Non sono del tutto d'accordo .... anche nella seconda ipotesi disponiamo un riferimento certo ....le stesse acquisizione fatte in successione ....in questo caso poco importa se il clock va piu' avanti o piu' indietro ...l'importante mantenga la stessa cadenza ....questo riscontro punta esclusivamente nella costanza ....non piu' rispetto alla congruenza con il segnale in origine ...come risulta nel primo grafico

In quetso caso non mi sono spiegato io, intendevo che la correzione di disallineamenti o semplici 'drift' costanti nel sample rate sono eliminabili tramite semplice algoritmo a condizione di avere un riferimento, mentre le variazioni casuali in tempi brevi no, quindi non si possono eliminare matematicamente (forse stocasticamente, ma è un altro discorso).

Di fatto è quello che succede con la correzione che apporti, quello che rimane è quello che può avere effetto sul suono, mentre il resto, anche se in riproduzioone 'vera' non viene eliminato, è ininfluente.

Chiedo scusa per l'equivoco.

[marcoc1712]

....infatti quello che ho rilevato con la seconda prova è proprio la non costanza del clock ....le cause possono essere le piu' svariati ....

A) instabilita dello stesso setup per l'acquisizione (PC1)
B) Hardware (pc) dove installato il player
C) Hardware (dac)

Ipotesi A da escludere per due motivi ....

Primo - se non si ha la certezza dello stadio ADC che garantisca ripetibilita... mi sembra inutile cimentarsi in queste prove .....
Secondo - questo trova conferma dallo stesso risultato ottenuto analizzando il player wtf .....

In automatico esclude l'ipotesi (C ) perche in comune per tutte le acquisizioni come lo stesso (PC1) usato per le acquisizioni ....

Rimane come unica sola ...l'ipotesi (B) ....non è forse quello che tutti cerchiamo ottimizzare con le piu' bizzarre soluzioni ?

A è vero per definzione (come anche C) Qualsiasi clock è instabile e la tolleranza 'migliore' è del 1%, tra quelli commerciali.

Per rendere un'idea, l'applicazione del dithering su uno stream a 24 bit modifica 1/24*2 bit -> 2%, ma si limita a farlo SOLO sui bit meno significativi, la variabilità di cui parliamo è casuale, quindi può interessare anche quelli maggiormente significativi, con effetti ben più distruttivi.

Il punto è che facendo conversione DA e quindi AD SE i due clock non sono sincronizzati, nel flusso in uscita i drift (anche se si tratta di un ritardo minimo, non influente all'ascolto) viene 'staticizzato' nei bit, quindi il risultato 'sembra' molto peggiore di quello che è in realtà.

La non costanza l'hai rilevata, ma la differenza 'ENORME' di 30db tra i diversi player è in realtà falsa, dimostrato dal fatto che l'algoritmo di riallineamento la elimina. Usando un siolo clock, non la avresti proprio rilevata. Quella vera (come somma algebrica dei due) è quella compresa tra +/- 2db a 40 KHz.

Quella e solo quella è dovuta - presumibilmente - alle interazioni tra hw, sw (ma anche il resto dell'ambiente circostante) ed I (plurale) dac.

Sarebbe bene concentrarci su quella e cercare di capire da dove si origina , come si propaga e che effetti specifici comporta all'ascolto, iniziando a verificare l'effettiva bit perfectness in ogni condizione.



.

[bibo01]

Qualche considerazione personale sul test effettuato da Salvatore (SM63)...

Innanzitutto, grazie.

I tre players - Foobar, Daphile e WTF - devono essere visti come OS+player. (A proposito, quale versione di Windows viene usato per Foobar? ...ricordo che Tom aveva "problemi" con Seven)
Paradossalmente, ci potrebbe essere una situazione in cui i tre players sono uguali, ma l'ambiente (OS) con il quale interagiscono è progressivamente più "ottimizzato".

Ammettendo anche le differenze di drift del clock, il test ha valore solo relativo al sistema playback utilizzato - Futro+DAC - e non assoluto. Ad esempio, sarebbe interessante verificare se la discrepanza di drift tra i vari OS+player viene mantenuta al cambiare del PC. Successivamente verificare se tale discrepanza può essere abbattuta da variazioni specifiche del software e/o dell'hardware.

Ammettendo la veridicità del drift o, nel caso di WTF, del minore drift, cosa abbiamo scoperto?! Niente che non si sapesse di già! Cioè che software e hardware contano; che un OS ottimizzato va meglio di uno standard; che un segnale che arriva al DAC con meno drift gli fa fare meno lavoro e possibilmente genera meno rumore nel convertitore; che ci sono varie maniere (vedi a esempio il sistema server+audio end point) per combattere alcune variabili che non conosciamo pienamente o di cui non abbiamo pienamente controllo.