Wtfplay - misurazioni e confronti con players

[SM63]

Credo possa interessare ....

Veniamo al risultato ....i grafici che spostero racchiude un po il quadro della sistuazione ....i player sono tre ...volutamente ho preferito testare solo quelli free ....

A) Foobar ....
B) Daphile ...una delle ultime versioni stabili
C) WTFplay ...se non avessi letto questo 3d con molta propabita' mi sarei perso emozioni che non avrei mai provato ...

Hardware

1) Pc ottimizzato per misure e ascolti
2) Futro
3) Dac basato sulla interfaccia Xmos diyinhk con Ak 4490 pesantemente ottimizzato
4) Dac basato sulla interfaccia JLS 2 sempre con Ak 4490 non particolarmente ottimizzato ...

Sfortunatamente non ho potuto provare un secondo Pc ottimizzato per gli ascolti avviabile dalla USB per fare andare ( daphile-WTF)...

Finalita' ...

Vista l'evidenza differenza agli ascolti ..non nascondo le non poche difficolta' per accertare le possibili cause ...ricordo stiamo parlando di player in bit perfect ...in teoria come nella pratica dovrebbero garantire il medesimo risultato sonoro ....


Metodologia ... ( NTD) By Tom .... per chi volesse approfondire in cosa consiste consignio questa lettura “NTD”

Come molti sapranno uno dei modi per evidenziare differenze prodotte da qualsiasi forma di alterazione ....consiste in un confrotto speculare tra due segnali ...uno va tenuto come riferimento ... confrontato con quello acquisisto ...dopo essere stato opportunamento allineato .... il risultato ottenuto dalla cancellazione totale o parziale ...permette di stabilire con assoluta certezza eventuali differenze .....

Dopo questa breve illustrazione sono passato alla prima verifica ....acquisendo in digitale ...in questo modo

Riproduzione ......Player >PC >Xmox USB (JLS) >OUT spdif -----IN spdif >PC > software (Audition) ....per tutti i player questo risultato non puo essere rappresentato con la grafica visto la quasi totale cancellazione ...pero ritengo interessante farvi vedere il risultato dei log ...come potete asservare la massima cancellazioe porta un limite fermandosi a 300 dB escluso un caso ....

Player Foobar ....parameters: -5,677msec, 0,000dB.Corr Depth: 300,0 dB

Player WTF ( Condizione A). parameters: -251,5msec, 0,000dB.Corr Depth: 282,6 dB

Player WTF ( Condizione B) parameters: -531,3usec, 0,000dB.Corr Depth: 300,0 dB

La differenza deriva dalla impostazione del Player WTF precisamente

Per la condizione A ..ho impostato F a 8192 per la B ....F 1024 ....se mi chiedete agli ascolti si sente la differentra tra le due impostazioni ....SI .....anche in modo sostanziale ....

Fino qui nulla di nuovo .....non poteva essere diversamente ....siamo in bit perfect oltre questo tra la riproduzione e l'acquisizione aggancia allo stesso clock ....i problemi sorgono durante le acquisizioni con i dac USB
cioe acquisendo dalle uscita analogica passando da una doppia conversione D/A -A/D ....in questi casi e facile imbatersi nell'errore ....visto che durante il calcolo necessita compensare l'errore in ppm .....

Vediamo la prima NTD ....il confronto tra il segnale campione con il segnale acquisito dalla stesso dac in analogico riprodotto dai tre payer ....la differenza oggetiva non trova riscontro rispetto a quelle percepite

[SM63]

Visto il risultato sono andato avanti con altre verifiche ...cosi da evitare la compesazione dell'errore ppm

Non escludo altri metodi ...io sono andato avanti su questa direzione .....non piu' il confronto tra il segnale campione ..bensi tra le stesse acquisizione ....con questa procedura ....10 aquisizioni per ogni player fatte in successione ....qui le somprese non sono mancate ....ci tengo a precisare questa verifica e' stata ripetuta piu' volte nell'arco della giornata proprio per accertare la costanza ...su questo dato sono piu' che certo ...

Questa il risultato ...qui potete osservare il concentrato ....prodotto dalla centinaia di NTD ....in poche parole il confronto tra le stesse acquisizioni ...riproposte per i tre palyer ....

Osservate bene immagine ogni grafico a un colore ....sia per Foobar e daphile ...ho rappresentato il grafico con o senza la compensazione ....mentre per wtf non è stato necessario alcuna compensazione ....i dati fluiscono con costanza ....consa che non accade con daphile e foobar ....

Rosso = Foobar senza compensare l'errore ppm
Verde =chiaro o pisella scusate ho qualche difficolta con la vista = Foobar dopo la compensazione
Viola = Daphile senza compensare l'errore ppm
Arancio = daphile dopo la compesazione
Blu = WTF ...non necessita alcuna compensazione
Verde scuro = WTF ....ulteriore verifica dopo aver accertato ripetutamente la costanza ...

[antonellocaroli]

Ciao SM63, puoi spiegare a chi non capisce niente di misure e di grafici...qual ´é il risultato? che significa?

[marcoc1712]

Ciao SM63, puoi spiegare a chi non capisce niente di misure e di grafici...qual ´é il risultato? che significa?

Concordo!

In particolare, se ho capito bene, il primo percorso del segnale è stato PC (player) > USB > SPDIF OUT -> SPDIF IN -> USB -> PC (Audion), dove i clock sono 'agganciati', corretto?

Con prove analoghe, senza passare da USB, ho ottenuto risultati analoghi, ma usando AUdioDiffMaker. 280 o 300 db... la differenza è quasi trascurabile, nessun DAC ha la precisione necessaria (come videnzai il grafico successivo), ma sarebbe interessante capire 'come' si produce matematicamente la differenza, in primis perchè - viste le condizioni di prova - mi pare tu le imputi al software, che quindi quindi non sarebbe bit perfect, in seconda battuta perchè non tutte le differenze sono uguali, dal un punto di vista psicoacustico (es. il dithering/noise shaping agisce sull'approssimazione dell'ultimo bit, quindi in teoria inudibili, almeno a 24 bit, invece si sente eccome, come abbiamo anche recentemente sperimentato).

AudiodiffMaker ha il vantaggio di permetterti di 'ascoltare' le differenze rilevate, ovviamente amplificandole a dovere.

Dopo di che mi perdo:

Hai fatto conversione AD/DA sui diversi dac e quello è il risultato?

Cioè segnali che passano 2 volte per SPDIF in pratica integri, quando aliementano un dac producono differenze relative (le assolute non hanno senso) di 30 db, con una progressione, in pratica, lineare?

Nelle differenze dovresti praticamente sentire lo stesso messaggio musicale, ridotto di intensità ad 1/4...

Per errore ppm intendi il clock drift? Ma i clockdi AD e DA non sono agganciati?

Mi sfugge certamente qualcosa...

[SM63]

Il risultato abastanza ovvio ...il mio solo un modo per oggettivare quello che ormai credo tutti siano d'accordo ....eliminare per quanto possibile processi inutile da parte del sistema operativo e non solo quello ...naturalmentente al costo in qualche rinuncia ....

I grafici rappresentano la ripetibilita dello stesso evento riacquisito piu' volte ....nel caso di questo player WTF ...arriva con una ottima cancellazione senza compensare nulla ...anche perche nel normale utiizzo nulla compensare l'errore ...a discapito della costanza ....relativo con l'andamento della fase ...questo risultato va proettato per i due canali ....

[marcoc1712]

Il risultato abastanza ovvio ...il mio solo un modo per oggettivare quello che ormai credo tutti siano d'accordo ....eliminare per quanto possibile processi inutile da parte del sistema operativo e non solo quello ...naturalmentente al costo in qualche rinuncia ....

I grafici rappresentano la ripetibilita dello stesso evento riacquisito piu' volte ....nel caso di questo player WTF ...arriva con una ottima cancellazione senza compensare nulla ...anche perche nel normale utiizzo nulla compensare l'errore ...a discapito della costanza ....relativo con l'andamento della fase ...questo risultato va proettato per i due canali ....

Scusa, ma o continuo a non capire.

Stiamo sempre parlando del confronto bit per bit tra file originario e risultato del processo di trasferimento e conversione DA/AD mediante i percorsi che hai descritto, da te rappresentati come differenza in db alle diverse frequenze? O del confronto 'diretto' di segnali analogici in uscita dai dac nelle diverse condizioni?

Nel primo caso (A) il clcok drift è eliminato se i due clock sono agganciati, quindi non c'è bisogno di compensazione alcuna, nel secondo (B) è ovvio che quella invece rappresenta la maggiore differenza, ma non è certo imputabile al player, che nulla può, in quanto tale, in merito alla 'costanza' del clock.

In merito alla 'riproduzione reale' nel corso della quale non c'è compensazione (rispetto a cosa? al tempo 'vero'?) è verissimo ed in effetti se confornti il risultato di due proceessi di conversioni eseguito con lo stesso clock in tempi diversi, probabilmente rilevi differenze di ordine maggiore, ma è un esercizio:

a. il player software nulla può in merito.
b. piuttosto dela velocità assoluta è eventualmente importante la 'costanza' del tempo in ogni ripetione.

Probabilmente continua a sfuggirmi il nocciolo, ma non riesco a capire come tutto questo sia riconducibile al player e dimostri una superiorità di uno rispetto all'altro in ragione del maggiore/minore impiego del OS, a meno che tu non sostenga che daphile e foobar causano 'più drift' di WTFplayer a causa del maggior utilizzo di risorse, nel qual caso immagino ci si trovi nel caso B.

Se è così, pur tenendomi i dubbi sul significato delle misure, segnalo che dovresti confrontare WTFPlay con la sola componente player di Daphile (Squeezelite), come andiamo dicendo da mesi in quete pagine, per correttezza dovresti anche configurare foobar per un utilizzo 'minimale'.

Per inciso, sarebbe molto più provante dimostare una differenza tra i diversi 'modi' di funzionamento di uno stesso player rispetto a quella tra due player diversi, così da individuare 'quali' processi sono efefttivamente i più dannosi e rinunciare prima a quelli.

[marcoc1712]

Player WTF ( Condizione A). parameters: -251,5msec, 0,000dB.Corr Depth: 282,6 dB

Player WTF ( Condizione B) parameters: -531,3usec, 0,000dB.Corr Depth: 300,0 dB

La differenza deriva dalla impostazione del Player WTF precisamente

Per la condizione A ..ho impostato F a 8192 per la B ....F 1024 ....se mi chiedete agli ascolti si sente la differentra tra le due impostazioni ....SI .....anche in modo sostanziale ....

Il parametro andrebbe visto congiuntamente al buffer size (-n), che per default è a 3 e minimo a 2.

Insieme determinano la dimensione del buffer di alsa, in funzione del sample rate e del bith dept.

Stando a quello che scrivi (dando per scontato il mantenimento inalterato degli altri parametri) sembrerebbe che buffer più grandi provochino minore cancellazione, il che mi sembra francamente strano. Cosa rappresentano i msec? la latenza? Se così fosse, sei sicuro doi non aver invertito le due condizioni (B = buffer più grande?).

Rispetto ai valori comunuemente usati in squeezelite, sono comunque buffer molto grandi. Hai provato a usare valori corrispondenti (da convertire) in squeezelite e ripetere la misurazione?

[SM63]

Scusa, ma o continuo a non capire.

Stiamo sempre parlando del confronto bit per bit tra file originario e risultato del processo di trasferimento e conversione DA/AD mediante i percorsi che hai descritto, da te rappresentati come differenza in db alle diverse frequenze? O del confronto 'diretto' di segnali analogici in uscita dai dac nelle diverse condizioni?

Nel primo caso (A) il clcok drift è eliminato se i due clock sono agganciati, quindi non c'è bisogno di compensazione alcuna, nel secondo (B) è ovvio che quella invece rappresenta la maggiore differenza, ma non è certo imputabile al player, che nulla può, in quanto tale, in merito alla 'costanza' del clock.

In merito alla 'riproduzione reale' nel corso della quale non c'è compensazione (rispetto a cosa? al tempo 'vero'?) è verissimo ed in effetti se confornti il risultato di due proceessi di conversioni eseguito con lo stesso clock in tempi diversi, probabilmente rilevi differenze di ordine maggiore, ma è un esercizio:

a. il player software nulla può in merito.
b. piuttosto dela velocità assoluta è eventualmente importante la 'costanza' del tempo in ogni ripetione.

Probabilmente continua a sfuggirmi il nocciolo, ma non riesco a capire come tutto questo sia riconducibile al player e dimostri una superiorità di uno rispetto all'altro in ragione del maggiore/minore impiego del OS, a meno che tu non sostenga che daphile e foobar causano 'più drift' di WTFplayer a causa del maggior utilizzo di risorse, nel qual caso immagino ci si trovi nel caso B.

Se è così, pur tenendomi i dubbi sul significato delle misure, segnalo che dovresti confrontare WTFPlay con la sola componente player di Daphile (Squeezelite), come andiamo dicendo da mesi in quete pagine, per correttezza dovresti anche configurare foobar per un utilizzo 'minimale'.

Per inciso, sarebbe molto più provante dimostare una differenza tra i diversi 'modi' di funzionamento di uno stesso player rispetto a quella tra due player diversi, così da individuare 'quali' processi sono efefttivamente i più dannosi e rinunciare prima a quelli.

La prima parte non riferita a questo intervento è corretta ....per la secondo mi scuso evidentemente non sono riuscito essere chiaro ....

La seconda verifica consiste nel confrontare la costanza tra due o piu acquisizione senza cambiare nessuna condizione al di fuori del tempo necessiario per riacquisire ..in questo caso in analogico alle uscite del dac (X) ....per questa verifica ne ho fatte 10 in successione per ogli player ...ottenendo 10 file da analizzare 1 -10 .....il primo si lascia fisso come riferimento ....quindi si procede con le 9 verifice ...confrontando dal 2-10 ....ripeti la stessa procedura questa volta sostituendo il riferimento dal 1 si assa al 2 .... da confrontare partendo dal 3 fino al 10 ....fino arrivare al 9 --confrontato solo con il 10 ....stessa procidimento con le acquisizioni con gli altri player .....

Il risultato finale è stato questo ....con daphile e foobar per ogni verifica necessita la compensazione nell'errore in ppm ..mentre con WTF non è stata necessiario compensare ....spero di essere stato chiaro ....cosa potrebbe voler dire ..si nota la costanza solo esclusivamente con il palyer WTF .....

[SM63]

Il parametro andrebbe visto congiuntamente al buffer size (-n), che per default è a 3 e minimo a 2.

Insieme determinano la dimensione del buffer di alsa, in funzione del sample rate e del bith dept.

Stando a quello che scrivi (dando per scontato il mantenimento inalterato degli altri parametri) sembrerebbe che buffer più grandi provochino minore cancellazione, il che mi sembra francamente strano. Cosa rappresentano i msec? la latenza? Se così fosse, sei sicuro doi non aver invertito le due condizioni (B = buffer più grande?).

Rispetto ai valori comunuemente usati in squeezelite, sono comunque buffer molto grandi. Hai provato a usare valori corrispondenti (da convertire) in squeezelite e ripetere la misurazione?

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

[marcoc1712]

La prima parte non riferita a questo intervento è corretta ....per la secondo mi scuso evidentemente non sono riuscito essere chiaro ....

La seconda verifica consiste nel confrontare la costanza tra due o piu acquisizione senza cambiare nessuna condizione al di fuori del tempo necessiario per riacquisire ..in questo caso in analogico alle scite del dac (X) ....per questa verifica ne ho fatte 10 in successione per ogli player ...ottenendo 10 file da analizzare 1 -10 .....il primo si lascia fisso come riferimento ....quindi si procede con le 9 verifice ...confrontando dal 2-10 ....ripeti la stessa procedura questa volta sostituendo il riferimento dal 1 si assa al 2 .... da confrontare partendo dal 3 fino al 10 ....fino arrivare al 9 --confrontato solo con il 10 ....stessa procidimento con le acquisizioni con gli altri player .....

Il risultato finale è stato questo ....con daphile e foobar per ogni verifica necessita la compensazione nell'errore in ppm ..mentre con WTF non è stata necessiario compensare ....spero di essere stato chiaro ....cosa potrebbe voler dire ..si nota la costanza solo esclusivamente con il palyer WTF .....

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?

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.

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

Piuttosto, il valore assoluto GENERALE, considerando che si tratta di due conversioni successive, mi pare di buon livello (86 db a 40KHz).

Se la correzione è, invece, più invasiva, vale la pena di approfondire.