Wtfplay - misurazioni e confronti con players

[SM63]

@sm63...

Se vuoi verificare il "bit perfect" con quello che ti trovi (parte software) ti mando un segnale adatto...segnale che registrerai dall'ingresso S/pdif...sia per WTF....sia per DAPHILE...sia per FOOBAR...
Una volta caricati su Audition non dovrai salvarli...dovrai soltanto tagliarli manualmente (cosa che ti faciliterò poichè vi saranno dei marker
inizio/fine silenzio) inserirli nel multitraccia e mettendone UNO in controfase salvare il mixdown su traccia MONO-
Se otterrai il "silenzio cosmico" significa che sono bit perfect...altrimenti qualunque microdifferenza ti farà comparire una componente di rumore attorno (come minimo) i -170db. :-)

saluti, Tom.

Perfetto

Scusa Tom in cosa cambia ...poco fa ho fatto la stessa prova con delle acquisizioni salvate a 24 bit ...sommata invertita di fase ottengo una cancellazione non visualizzabile ...esattamente come la traccia per differenza su ADM ...forse marco cerca altro ....con il software che sta testando

[marcoc1712]

...scaricalo da qui Marco --> https://mh-nexus.de/en/hxd/
Tom.

Grazie, ma è un editror esadecimale con una minima funzione di confronto: vai alla prossima/precedente differenza o mi perdo qualcosa?

La mia idea è piuttosto qualcosa come si vede nel forum linkato da Bibo, cioè qualcosa del genere:

1 1
2 5
3 9
4 0
5 11
6 ...
7
8
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
tot xxx
......|---------|---------|---------|---------|----------|----------|
0 1000
1 208
2 22
3 4
4 2
5 1
6 0
n 0

da leggersi come:

ogni - è un periodo t, es. 100 msec, | è un ordine digrandezza superiore, es. sec. Per ogni - | ed in totate vengono conteggiati:

a. i frame (semplice calcolo)
c. gli errori al bit relativo (quadro superiore, 1-24 in uno streama a 24 bit)
d. i frame conteneti 0-n errori (quadro inferiore, 0-n dove n è il massimo riscontrato in un singolo frame).

Il software per estrarre questi valori l'ho già fatto, devo solo capire come renderlo graficamente affinchè risulti utile ed intuitivo. Idee?

p.s.

Il macinino ha finito ed ha trovato il punto di maggior correlazione a 21504 frames , quindi a 215 mSec dall'inizio, non così distante da quello che trova ADM, che evdentemente però lo creca al di là del delta fisico di dimensione di due files. Per la cronaca, a quel punto riporta esattamente i 1824485 errori trovati confrontando il file tagliato da ADM, direi che il metodo sembra essere corretto.

[marcoc1712]

potresti utilizzarlo su linux...

Per verificare la bit-perfectness, ribadisco il suggerimento di utilizzare shntool. Lo utilizzo spesso proprio a questo fine (ad es. per verificare se due diversi "rip" di un CD sono uguali) e funziona benissimo. Accetta anche files di lunghezza diversa, e li allinea automaticamente.



Inviato dal mio GT-I9100 utilizzando Tapatalk

Mi sto accingendo a provarlo.

[gefrusti]

potresti utilizzarlo su linux...

Per verificare la bit-perfectness, ribadisco il suggerimento di utilizzare shntool. Lo utilizzo spesso proprio a questo fine (ad es. per verificare se due diversi "rip" di un CD sono uguali) e funziona benissimo. Accetta anche files di lunghezza diversa, e li allinea automaticamente.



Inviato dal mio GT-I9100 utilizzando Tapatalk

...e si...Paolo...ma oltre a non avere nè tempo nè linux andremo per "via veloce"
Anche perchè le acquisizioni le farà Salvatore che è provvisto di tutti i player belli e pronti-
Proverò la snhtool...e se hai anche il link evito di cercarla-


ciao, Tom.

[marcoc1712]

Confrontare se il bit sia perfetto o no per quanto interessante visto le cancellazioni mi sembra marginale ...ad ogni modo sempre utile per comprendere interazione tra player e hardware .... a questo punto la mia incertezza ....anche hardware usato per acquisizione potrebbe influenzare sul risultato .... per accertare questo ...
L'unica cosa che posso fare ...evitare qualsiasi interfaccia usb ...acquisendo in loop dalla stessa scheda audio in spdif ....

Nel caso in cui i bit risultassero sempre differenti ....mi sembra inutile continuare su questa direzione ....

gefrusti ha dato utili indicazioni ed anche Paolo, prova a seguire quelle di Tom mentre io provo quelle di Paolo e vediamo cosa ne risulta.

A mio avviso la velenza di questo test è proprio per verificare l'effettiva bit pefrfectness in ambito digitale, escludendo interventi 'a gamba tesa' di qualche componente hw o sw del sistema ospite. Ovvio che, dal punto di vista della 'semplice' corrrelazione acustica, si tratterà sempre di fattori minimali, ma noi a quelli stiamo dando la caccia, anche perchè la correlazione acustica ricostruita da software come ADM è focalizzata sul range delle frequenze udibili (o anche meno), mentre noi cerchiamo effetti INDIRETTI, quindi anche oltre i 21 KHz. Ricordi come si comportava ADM con l'anomalia di foobar?

[gefrusti]

Grazie, ma è un editror esadecimale con una minima funzione di confronto: vai alla prossima/precedente differenza o mi perdo qualcosa?

La mia idea è piuttosto qualcosa come si vede nel forum linkato da Bibo, cioè qualcosa del genere:

1 1
2 5
3 9
4 0
5 11
6 ...
7
8
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
tot xxx
......|---------|---------|---------|---------|----------|----------|
0 1000
1 208
2 22
3 4
4 2
5 1
6 0
n 0

da leggersi come:

ogni - è un periodo t, es. 100 msec, | è un ordine digrandezza superiore, es. sec. Per ogni - | ed in totate vengono conteggiati:

a. i frame (semplice calcolo)
c. gli errori al bit relativo (quadro superiore, 1-24 in uno streama a 24 bit)
d. i frame conteneti 0-n errori (quadro inferiore, 0-n dove n è il massimo riscontrato in un singolo frame).

Il software per estrarre questi valori l'ho già fatto, devo solo capire come renderlo graficamente affinchè risulti utile ed intuitivo. Idee?

p.s.

Il macinino ha finito ed ha trovato il punto di maggior correlazione a 21504 frames , quindi a 215 mSec dall'inizio, non così distante da quello che trova ADM, che evdentemente però lo creca al di là del delta fisico di dimensione di due files. Per la cronaca, a quel punto riporta esattamente i 1824485 errori trovati confrontando il file tagliato da ADM, direi che il metodo sembra essere corretto.

...si...riporta il confronto byte-to-byte in esadecimale...quando è bit perfect segnala "i file sono identici"
Per scorrere velocemente al prossimo errore tasto F6-


ciao, Tom.

[marcoc1712]

...si...riporta il confronto byte-to-byte in esadecimale...quando è bit perfect segnala "i file sono identici"
Per scorrere velocemente al prossimo errore tasto F6-


ciao, Tom.

E' certamente ottimo per file con poche differenze, io uso saltuariamente tool analoghi integrati nell' IDE (tool di sviluppo). Se i files sono identici o con poche decine di differenze va benissimo, io pensavo al confronto di file "meno perfetti", dove dover investigare eventuali pattern ripetuti nelle differenze, così da individuare il 'tipo' di errore introdotto.

Es. un file a 24 bit che subisca un dithering, dovrebbe presentare circa il 50% dei campioni diversi dall'originale ma SOLO per l'ultimo bit, un file a 24 bit che passasse per un componente a 16 subirebbe un troncamento, riempito con silenzio (0) al successivo ritorno a 24, quindi avrebbe un numero variabile tra 0 ed 8 errori per frame, tutti concentrati nei bit 17-24. Cose di questo genere insomma, 'ritmi' particolari negli errori che 'potrebbero' evidenziare alterazioni 'sistemiche' dello stream e certamente udibili al di là della correlazione acustica in db, come avviene esattamente per il dithering, per cause psicoacustiche.

Ovviamente senza la pretesa di spiegarle, ma - forse - di individuarle.

[SM63]

[QUOTE=marcoc1712;960294]gefrusti ha dato utili indicazioni ed anche Paolo, prova a seguire quelle di Tom mentre io provo quelle di Paolo e vediamo cosa ne risulta.

A mio avviso la velenza di questo test è proprio per verificare l'effettiva bit pefrfectness in ambito digitale, escludendo interventi 'a gamba tesa' di qualche componente hw o sw del sistema ospite. Ovvio che, dal punto di vista della 'semplice' corrrelazione acustica, si tratterà sempre di fattori minimali, ma noi a quelli stiamo dando la caccia, anche perchè la correlazione acustica ricostruita da software come ADM è focalizzata sul range delle frequenze udibili (o anche meno),

mentre noi cerchiamo effetti INDIRETTI, quindi anche oltre i 21 KHz.

Perfetto ....sono d'accordo ..infatti su questo punto sono piu' che convinto ...

[UnixMan]

Proverò la snhtool...e se hai anche il link evito di cercarla-

lo avevo già messo in un post precedente... cmq eccotelo: [shntool]

[marcoc1712]

@Marco:
per confrontare bit-per-bit due file audio già allineati o quasi (a meno di uno shift iniziale non troppo grande), puoi usare anche "shncmp", dalla suite "shntool": [shntool]

a parte il fatto che evidentemente mi vuoi male (COMMAND LINE!) lo sto provando, ha un sacco di funzionalità interessanti, ma il compare in particolare non mi sembra faccia al caso nostro, o almeno non direttamente.

Posto di accettare i 3 secondi come limite di shift (mi sembra ragionevole) lavora per byte, quindi bisogna essere certi che il 'taglio' sia avvenuto congruentemente, possiamo darlo sempre per scontato? Mi pare di sì, questa è la prima ottimizzazione che copio nel mio macinino, anzi! lo faccio lavorare per frame.

L'elenco delle differenze trovate non è immediatamente riconducibile a quanto cerco io, ma forse ci si può lavorare. Recupero il sorgente e decido se partire da li o 'copiare' quello che mi serve