Wtfplay - misurazioni e confronti con players

Pagina 17 di 81
prima
... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 67 ... ultimo
Visualizzazione dei risultati da 161 a 170 su 807
  1. #161
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da gefrusti
    ...mi riferisco (almeno questo è il mio scopo/interesse) a questa differenza che Salvatore percepisce tramite l'utilizzo di player diversi in determinati contesti hardware-
    non le percepisce solo lui... le abbiamo notate in molti, indipendentemente ed in contesti diversissimi tra loro.

    Originariamente inviato da gefrusti
    un fenomeno jitterale può perfettamente provocare differenze nel segnale analogico convertito nonostante i bit arrivino tutti integralmente- In una trasmissione asincrona sarà difficilissimo trovare -perdita di bit- (ma anche su un Bifase Mark Code) al contempo potrebbero innescarsi fenomeni (a monte) sulla portante che regola l'arbitraggio delle trame...quindi un disturbo che si trasmette anche negli oscillatori del device e ne compromette la costruzione di un clock preciso-
    senza dubbio. Credo che siamo tutti d'accordo nel ritenere che la causa più probabile delle differenze percepite sia da ricercare in qualche effetto "indiretto" che -con ogni probabilità- è in qualche modo legato al "timing" del flusso di dati (piuttosto che al suo "contenuto", che si presume sempre corretto).

    Sappiamo tutti che, sebbene le tecnologie di trasmissione dati impiegate non garantiscano l'assenza di errori, la probabilità di errore (o error-rate che dir si voglia) è (dovrebbe essere) talmente bassa che eventuali errori del genere -casuali ed estremamente sporadici- semplicemente non possono in alcun modo alterare la "qualità" del suono percepito.

    Per poter produrre delle differenze in tal senso (percepibili come differenze nella "qualità" del suono, quindi sempre presenti) gli errori nei dati dovrebbero essere "sistematici" o quanto meno estremamente frequenti.

    In teoria (a meno di bug o altri problemi gravi in un dato sistema specifico) è evidente che errori del genere non dovrebbero essercene. Ma siamo sicuri che sia così anche in pratica, nei sistemi che effettivamente utilizziamo?

    Rispondere a questa prima domanda basilare è il senso del test (condotto restando sempre nel dominio digitale) suggerito da Marco: per prima cosa escludiamo eventuali sorprese che non ci aspettiamo, verificando che il sistema sia realmente "bit-perfect".

    Qui nasce il primo problema: perché il "null test" sembra aver rilevato delle differenze anche in quel caso?

    Dov'è l'inghippo? C'è un errore/problema nel setup di misura, nel software (e/o nel modo in cui è stato impiegato) oppure ci sono realmente delle differenze che non dovrebbero esserci?

    Questo penso sia un primo punto che è indispensabile chiarire e capire perfettamente prima di poter andare avanti e fare qualsiasi altra cosa.

    Originariamente inviato da bibo01
    A mio parere, se ci sono differenze nette all'ascolto tra Daphile e WTF *, sarebbe meglio escludere Foobar del tutto perché gira su un hardware e su un SO diverso.
    Se poi queste differenze vengono "certificate" alle misure, sarà eventualmente più facile scavare nei settaggi del player/Sistema Operativo che creano tali differenze tra WTF e Daphile.
    senza dubbio. Dirò di più... sarebbe preferibile escludere anche WTF, ed utilizzare invece due sistemi ("bit-perfect") che mostrino "evidenti" differenze all'ascolto tra loro e che siano entrambi completamente "Open". Solo avendo la possibilità di conoscere in ogni dettaglio ciò con cui si ha a che fare si può sperare di capire se/quali correlazioni esistano tra un qualche fenomeno e le sue possibili cause...
    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.»

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

    Predefinito

    Originariamente inviato da gefrusti
    @Marco
    @sm63

    ...non posso nè leggermi attentamente il motivo del contendere sulle differenze riscontrate in digitale (un po -286...un po -300...ect..) e nemmeno posso andarle a spulciare nella cartella che mi ero scaricato....però..però....se quantomeno mi mandate i file TAGLIATI e quello originale (non piu di un paio) dove si passa da -300 a -2XX...vado a vedere se riesco a trovarne la causa-
    p.s li avete già belli e pronti...un upload e mi mandate il LINK-

    saluti, Tom.
    I file sono SEMPRE e SOLO quelli postati da Salvatore. Non posso capire io per te, però...

    A mio avviso c'è qualcosa di molto strano, ho fatto le prime indagini e semplicemnte lasciando fare ad ADM si verifica l'incongruenza.

    Quindi ho realizzato un piccolo e banale, programma che compara bit per bit i file, tenendo come riferimento la struttura dei frames e 'muovendosi' nei flussi di un frame per volta al fine di individuare il punto di offsett con la miglior corrispondenza BINARIA (non acustica, come tenta di fare ADM).

    Come ho già postato, il controllo sul file tagliato da ADM riporta:

    duration: 20.00015625
    frames: 1920015
    errors: 1824485
    frame size: 3

    Adesso è in esecuzione sul file tagliato manualmente da Salvatore, che comprende circa 21500 frames in più (224 msec), per analizzare i quali impiegherà probabilmente tutto il giorno (...non è certamente ottimizzato...). Mi aspetto che concluda ESATTAMENTE indicando lo stesso punto ottimale di offset trovato da ADM, ma staremo a vedere.

    Rimane il fatto che IN DIGITALE quel numero di errori DIFFICILMENTE può indicare una situazione bit perfect con solo errori casuali. Secondo me c'è stato qualche DSP (volontario o involontario) nel percorso che pur mantenendo il contenuto 'acustico' (stiamo parlando di null a -260 db nei range di frequenza controllati) ha distrutto il contenuto matematico, il che apre - a mio avviso a vie MOLTO PIU' dirette di quelle che citi tu per influenzare il funzionamento del DAC ma anche delle componenti acustiche a seguire, al punto che mi pare inutile proseguire senza appurare questo prima.

    Tralasciare al momento foobar per tutte le cause che hai citato, concentrandosi su due player molto simili, sullo steso hw e con lo stesso OS di base, mi pare l'opzione migliore.

    EDIT: L'ultimo capoverso non è originale, leggo che lo consiglia già BIBO ed anche Paolo, con il quale concordo pienamente in merito alla certamente maggior epossibilità di analisi mirata che potrebbe fornirci l'avere accesso ai sorgenti ed alle specifiche configurazioni, ma...

    Comunque calma e gesso, come direbbero gli amici del cannonau, facciamoci una ichnusa ed aspettiamo i risultati del 'macinino', almeno ci togliamo i dubbi sul bit perfect, immagino già che ci sarà da discutere all'infinito solo su quello.
    Ultima modifica di marcoc1712 : 23-06-2016 a 17:28
    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. #163
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Rimane il fatto che IN DIGITALE quel numero di errori DIFFICILMENTE può indicare una situazione bit perfect con solo errori casuali. Secondo me c'è stato qualche DSP (volontario o involontario) nel percorso che pur mantenendo il contenuto 'acustico' (stiamo parlando di null a -260 db nei range di frequenza controllati) ha distrutto il contenuto matematico, [...]
    ammesso (e non concesso) che non ci sia qualche altro problema nel setup di misura, l'indiziato principale potrebbe essere quello che dicevo qualche pagina indietro: ASRC (ricampionamento) nella scheda audio che fa l'acquisizione (direttamente nel ricevitore s/pdif e/o altrove).
    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.»

  4. #164
    kibibyte
    Registrato
    Jun 2016
    Età
    58
    Messaggi
    206

    Predefinito

    ...si stanno semplicemente confrontando segnali digitali NON bit perfect.

    Spostando i segnali su oscilloscopio e analizzatore di spettro e tracciando funzioni A minus B e di trasferimento...compare un residuo microscopico di DC.
    Come accade questo ?...Salvatore avrà sintetizzato un file originale (stimolo di riferimento) salvandolo a 24bit (senza dither)
    Questo è stato messo in riproduzione dal player quindi poi acquisito a 32bit (Audition lo fa di defalt).
    L'acquisizione (passando da 24bit a 32bit) comporta una riquantizzazione del segnale digitale.
    A sua volta l'operazione di "salvataggio del file" comporta una successiva riquantizzazione (perchè si ripassa nuovamente da 32bit a 24bit)


    saluti, Tom.

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

    Predefinito

    Originariamente inviato da gefrusti
    ...si stanno semplicemente confrontando segnali digitali NON bit perfect.
    questo era evidente...

    Originariamente inviato da gefrusti
    [...]L'acquisizione (passando da 24bit a 32bit) comporta una riquantizzazione del segnale digitale.
    ah... allora non ci siamo. Per il test che chiedeva Marco, è necessario evitare "pasticci" del genere... ad es. lavorando sempre a 24bit (o anche "solo" a 16bit), senza mai cambiare "risoluzione" dall'inizio alla fine.
    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.»

  6. #166
    nibble
    Registrato
    Mar 2015
    Età
    50
    Messaggi
    73

    Predefinito

    Dico anche io la mia avendo ieri ascoltato tutto il pomeriggio l'impianto di Salvatore. Prima con Foobar e poi con wft (hardware diverso) e poi con wtf con settaggio di buffer lungo.....
    Differenze enormi.......prima versione con Foobar male......artificioso un po confuso e sporco......
    Versione con wtf......la musica e' cambiata.......tanto da avere un impianto molto soddisfacente e piacevole che ci ha intrattenuto per diverse ore di ottimi ascolti......piu' chiarezza....messa a fuoco senso del ritmo trasparenza e suoni piu ricchi......secondo me e' una differenza di tale entita' che non puo' essere messa in dubbio.....io darei per scontato che esiste ed e' grande.
    Tornare indietro per un appassionato e' completamente improponibile........ad un certo punto ho esclamato sembra un vinile.......per realismo.....naturalezza e senso del ritmo......
    Foobar e' imbarazzante al confronto.
    Ora io spero che si riesca a mettere un punto fermo......e secondo me bisogna provare almeno 4 o 5 player sullo stesso hw sia in digitale che analogico.
    L'idea di Salvatore di usare un pezzo musicale e non il rumore rosa a me sembra buona.......comunque si deve giungere a dei punti fermi condivisi da tutti......pena continuare la discussione all'infinito senza risultati......collaborando credo che ci vedremo finalmente chiaro.....
    Altra prova determinante e' il cambio di hw con lo stesso player......e la verifica dell'influenza del os......

  7. #167
    kibibyte
    Registrato
    Jun 2016
    Età
    58
    Messaggi
    206

    Predefinito

    da parte mia MASSIMA collaborazione...
    Non appena Salvatore è pronto arriveremo a scoprire il perchè di quella differenza-


    Tom.

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

    Predefinito

    Originariamente inviato da UnixMan
    questo era evidente...


    ah... allora non ci siamo. Per il test che chiedeva Marco, è necessario evitare "pasticci" del genere... ad es. lavorando sempre a 24bit (o anche "solo" a 16bit), senza mai cambiare "risoluzione" dall'inizio alla fine.
    Esatto!

    Quindi punto e a capo e ripetere le misure.

    Quando invito ad andarci cauti con le conclusioni...

    Allo stato abbiamo INVALIDATO le misure che indicavano 30db di difftenza, certificando si trattasse solo di delay ed al contraio la assoluta sovrapponibilità di WFT e Daphile ma non di Foobar a causa un errore di ripresa ed in fine scartato le riprese in digitale in quanto falsate dalla fase di acquisizione ed editing delle tracce.

    Rimane da verificare solo la serie che sembra evdienziare aumento del drtift e diminuzone del delay alla sola conessione del cavo di rete, che però francamente mi lascia molto perplesso e, visto gli errori verificati negli altri casi, credo opportuno vrificare prima che se ne esac qualcuno dicendo che su nexthardware abbiamo provato che la rete ha effetto sul dirft, quindi un appassionato deve necessariamente buttare nel cesso la rete in qualsiasi sua forma e declinazione.

    A volte mi sembra di essere allo stadio invece che impegnato a capire come stanno le cose...


    EDIT: su segnalazione di gefrusti, va aggiunta alle invariabili anche la connessione o meno del cavo di rete, almeno sulla base delle misutre ottenute.

    Quindi, come ha puntualizzato lui, nessuna differenza tra WFT e Daphuile e dubbi su quella tra WFT e Foobar a causa di un errore nelle riprese.

    Io, che non amo mai le posizioni categoriche, rimango leggermente più aperto un merito agli effetti della rete: un seppur minuscolo effetto sul drift pare averlo, certo va eventualmente preso in considerazione solo DOPO aver escluso fattori ben più significativi, come l'effettiva bit perfectness su tutto il percorso e comunque non è detto che l'unfluenza si manifesti solo come drift.
    Ultima modifica di marcoc1712 : 23-06-2016 a 22:53
    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

  9. #169
    kibibyte
    Registrato
    Jun 2016
    Età
    58
    Messaggi
    206

    Predefinito

    Originariamente inviato da marcoc1712
    Rimane da verificare solo la serie che sembra evdienziare aumento del drtift e diminuzone del delay alla sola conessione del cavo di rete, che però francamente mi lascia molto perplesso e, visto gli errori verificati negli altri casi, credo opportuno vrificare prima che se ne esac qualcuno dicendo che su nexthardware abbiamo provato che la rete ha effetto sul dirft, quindi un appassionato deve necessariamente buttare nel cesso la rete in qualsiasi sua forma e declinazione.
    ...ti riferisci alla condizione Router OFF router ON ?

    Tom.

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

    Predefinito

    Originariamente inviato da UnixMan
    questo era evidente...


    ah... allora non ci siamo. Per il test che chiedeva Marco, è necessario evitare "pasticci" del genere... ad es. lavorando sempre a 24bit (o anche "solo" a 16bit), senza mai cambiare "risoluzione" dall'inizio alla fine.
    ehm... non è 'per il test che chiedo io' è per poter affermare con sicurezza che il processo è bit pefect, lo scopo è quello di mettere un punto fermo 'alle porte del dac', tutto il resto sono ipotesi più o meno fantasiose ma non verificate.

    Mi spiegate che significato ha cercare una correlazione nella ripresa analogica di uno stream che non è bit perfect? Sarò un testone io, ma...

    Comunque, allo stato abbiamo solo certificato che quelle misure sono falsate, non che WFT è o meno bit perfect, siamo punto e a capo.
    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

Pagina 17 di 81
prima
... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 67 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 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