Cosa succede ai files audio se estratti con software di ripping diversi?

[ilmisuratore]

Mi sono stati inviati dei brani estratti con 3 programmi diversi:

1) wavelab

2) EAC

3) Audition

 

Il risultato è che emergono delle "differenze" e delle NON differenze

Ogni programma di rippaggio opera una sorta di "impacchettamento" il cui contenuto è l'audio...quello che alla fine si sente...e "l'imballaggio" esterno in cui possono esserci delle informazioni relative ai metadati o semplicemente spazi vuoti (padding) 

Il PC riceve il contenuto con l'imballaggio, lo scarta...prende la parte audio al suo interno e la riproduce

Diversi metadati (e padding) non li considera, dunque se alcuni sono incappati in disavventure di aver visto che un programma esce con gli stessi dati e un altro con dati "diversi"...non solo non dovrebbe allarmarsi...(magari percependo differenze inesistenti o addirittura ricorrendo ad una successiva estrazione inutile) ma cercare realmente la causa dalla quale scaturisce 

Vediamolo...

Ecco l'analisi esadecimale a confronto dei byte contenuti nei brani estratti con WAVELAB E AUDITION (cosi denominati) 

Non sono identici...ma...perchè ?

Osservate le stringhe in alto (prima delle sequenze "DATA")

Vedete la scritta "junk" ?

Presenta un chunk aggiuntivo chiamato JUNK

Questo spazio viene solitamente inserito dai software di editing o masterizzazione per allineare i dati successivi a blocchi di memoria specifici o per riservare spazio a metadati extra

Sebbene i valori siano simili, indicano una differenza nella dimensione totale del file

Il file di destra sembra essere leggermente più piccolo di quello di sinistra (di circa 68 KB), il che è coerente con l'assenza del chunk "JUNK"

Le discrepanze che vediamo nell'editor esadecimale HxD riguardano esclusivamente il "contenitore" (wrapper) e non il "contenuto" (payload audio)...che vedremo successivamente

Il blocco JUNK nel file di sinistra è puro spazio vuoto (padding)

Molti encoder (come quelli usati da Pro Tools o altri software di mastering e ripping) lo inseriscono per allineare l'inizio dei dati audio a multipli di 4KB o 2KB

Questo serve ad ottimizzare le prestazioni di lettura del disco rigido, ma non ha alcun impatto sul suono

 

 

La parte AUDIO estratta da WAVELAB E AUDITION è identica, anche a livello di offset delay

 

Qui sotto lo vediamo tramite la sovrapposizione delle due waveform RAW (quindi senza alcuna compensazione di allineamento dell'offset)

 

 

Questo produce a sua volta un DELTA SPETTRALE che cancella il segnale fino ai limiti di discretizzazione del software...quindi -400 dB

 

 

Nel caso ci fossero rischi di asperità diafoniche...anche questo ha dato esito negativo

 

 

WAVELAB ed EAC invece producono una differenza di offset (esattamente 0,136054ms)...vale a dire che quello di EAC inizia prima dell'altro con circa 6 samples di sfasamento, quindi se venissero riprodotti in simultanea quello derivato da EAC inizierebbe prima e di appena 136 microsecondi

 

 

Attivando la funzione di allineamento l'offset scompare e i due files si sovrappongono alla perfezione

 

 

...cosi facendo il DELTA DELLO SPETTRO risulta perfettamente cancellato fino a -400 dB

 

 

Anche se inutile ho voluto effettuare anche una prova "digitale-analogica" ponendo i due file in riproduzione simultanea con uno dei due brani invertito di 180°

 

 

Il risultato analogico vede, prima la rilevazione del rumore a vuoto (noise floor) e successivamente del rumore residuo sottratto dall'operazione di NULL TEST

Quindi nel grafico si vedrà la linea rossa relativa al rumore senza musica e la linea verde e azzura con il residuo del null test

Nessunissima differenza

 

 

Per concludere, un impianto di riproduzione funzionante riprodurrà tutti e tre i files al medesimo modo

p.s se qualcuno volesse smentire tutto quanto menzionato e testato ben venga, l'importante è che venga fatto con materiale sufficiente per rendere inaffidabile la mia analisi

p.p.s se poi qualcuno ritenesse che la parte software fosse "inadatta" possiamo registrarci direttamente sul forum dello sviluppatore, che conosco e con il quale ho messo anche il mio piccolo contributo ai tempi del perfezionamento (contributo che deriva anche da analisi incrociate con laboratorio certificato) quindi poter contestare eventuali lacune, se si ha la capacità di contestarle

 

 

 

[ilmisuratore]

I files che al tempo furono verificati anche da @one4seven saranno stati quelli relativi a WAVELAB ed EAC per il fatto che anche lui aveva notato l'offset...cosa che tra WAVELAB E AUDITION  non è presente

[antonew]

@ilmisuratore sulla sovrapponibilta’ dei dati pochi dubbi.

ma secondo me il problema viene dopo.

Nel modo in cui l'hardware (CPU/Buffer) gestisce questi diversi 'contenitori' o padding non credi che possa generare interferenze elettriche o variazioni nel jitter durante il trasporto in tempo reale? Perché alla fine noi ascoltiamo la conversione dinamica, non il file statico su disco.

Ed è lì che sento le differenze.

[ilmisuratore]

8 minuti fa, antonew ha scritto:

@ilmisuratore sulla sovrapponibilta’ dei dati pochi dubbi.

ma secondo me il problema viene dopo.

Nel modo in cui l'hardware (CPU/Buffer) gestisce questi diversi 'contenitori' o padding non credi che possa generare interferenze elettriche o variazioni nel jitter durante il trasporto in tempo reale? Perché alla fine noi ascoltiamo la conversione dinamica, non il file statico su disco.

Ed è lì che sento le differenze.

Il "contenitore" va via nel momento in cui viene riprodotto il file, e per un PC moderno impegnerebbe la CPU come il soffio di un neonato a confronto di un uragano

Tali interferenze avrebbero un senso (ma che nessuno mai ha documentato) nel caso si passasse alla riproduzione di files Lossless di tipo FLAC dove alla riproduzione è aggiunta anche una decodifica

Qui i files in esame sono tutti WAV con un paio di stringe di padding diverse (totalmente ininfluenti all'ascolto)

[ilmisuratore]

..ah...per chi volesse ascoltare basta richiedere i due brani e ve li invio

Si accettano test in cieco con almeno 16 sessioni

Ad ascoltarli e affermare che sono diversi non ci sto 

[antonew]

 

No ,non mi convince.
Anche se sulla carta la CPU neanche se ne accorge, il punto è un altro.

Anche con i WAV e i PC di oggi, quello che arriva al DAC non è solo un calcolo matematico, è un flusso elettrico continuo.

Se cambia il padding o la struttura del file, cambia comunque (anche se di pochissimo) il lavoro delle interfacce e dei buffer. Non credi che, proprio perché l'audio vive nel dominio del tempo, queste piccole variazioni elettriche possano sporcare il clock o il rumore di fondo del DAC?
Alla fine la scena acustica è la prima cosa che salta quando il segnale non è perfetto, ed è lì che molti di noi avvertono differenze che i bit uguali non spiegano

 

[ilmisuratore]

3 minuti fa, antonew ha scritto:

 

No ,non mi convince.
Anche se sulla carta la CPU neanche se ne accorge, il punto è un altro.

Anche con i WAV e i PC di oggi, quello che arriva al DAC non è solo un calcolo matematico, è un flusso elettrico continuo.

Se cambia il padding o la struttura del file, cambia comunque (anche se di pochissimo) il lavoro delle interfacce e dei buffer. Non credi che, proprio perché l'audio vive nel dominio del tempo, queste piccole variazioni elettriche possano sporcare il clock o il rumore di fondo del DAC?
Alla fine la scena acustica è la prima cosa che salta quando il segnale non è perfetto, ed è lì che molti di noi avvertono differenze che i bit uguali non spiegano

 

Non è come dici, il padding è uno spazio vuoto alla quale CPU e buffer non intacca nulla

Non avrebbe inciso nemmeno se il padding fosse stato riempito

Azz...allora quelli che operano il DSD in real time con oversampling a frequenze altissime si dovrebbero mettere l'anima in pace

Si tratta di un banale file wav a 44.1 e 16 bit...dunque soffio e uragano sono attinenti

[ilmisuratore]

@antonew ..però voglio spezzare una lancia a tuo favore

Ammettendo che in un determinato contesto uno abbia un riproduttore (PC+Player) scrauso e malfunzionante, il problema non riguarderebbe i files...ma l'hardware scrauso e incapace di gestire "un soffio"

[antonew]

2 minuti fa, ilmisuratore ha scritto:

@antonew ..però voglio spezzare una lancia a tuo favore

Ammettendo che in un determinato contesto uno abbia un riproduttore (PC+Player) scrauso e malfunzionante, il problema non riguarderebbe i files...ma l'hardware scrauso e incapace di gestire "un soffio"

 

E il punto è proprio questo: in Hi-Fi cerchiamo l'ottimizzazione estrema proprio perché sappiamo che anche un hardware 'non scrauso' reagisce diversamente a flussi diversi.

Se accettiamo che un hardware scarso fa sentire differenze, allora dobbiamo accettare che anche in un sistema top il trasporto non è un'operazione neutra al 100%.
Il padding o i metadati non cambiano i bit, ma cambiano il 'lavoro' elettrico della macchina.

Alla fine, se tutto fosse solo un banale calcolo di una CPU moderna, non staremmo qui a parlare di streamer da migliaia di euro o di interfacce USB isolate galvanicamente.

 

[ilmisuratore]

7 minuti fa, antonew ha scritto:

Il padding o i metadati non cambiano i bit, ma cambiano il 'lavoro' elettrico della macchina.

Per favore non alimentiamo queste dicerie perchè sarebbe come dire di avere una F1 e dubitare che possa andare a 50 km/h

Sono dicerie...ma liberissimo di sostenerle

Ho provato con un normalissimo PC..e pure piuttosto "anemico" in termini di CPU

[antonew]

29 minuti fa, ilmisuratore ha scritto:

Per favore non alimentiamo queste dicerie perchè sarebbe come dire di avere una F1 e dubitare che possa andare a 50 km/h

Sono dicerie...ma liberissimo di sostenerle

Ho provato con un normalissimo PC..e pure piuttosto "anemico" in termini di CPU

Il punto non è se il PC ce la fa (ovvio che ce la fa), ma se nel farlo genera disturbi minimi che un DAC sensibile poi si ritrova sul clock o sullo stadio d'uscita.
Se per te il trasporto è un'operazione asettica e ogni PC suona uguale a parità di bit, è la tua esperienza, ma la mia  (e quella di molti altri) dice che la trasparenza e la scena cambiano proprio in base a come l'hardware 'lavora' quel flusso. 
C’è un’intera sezione dedicata a quello: Computer audio.

[one4seven]

1 ora fa, ilmisuratore ha scritto:

WAVELAB ed EAC

 

Perché wavelab è scarso, cioè il ripping non è il suo focus. È un software che ha tutt'altro obiettivo.

EAC che invece nasce per fare solo il ripping, gestisce in toto le funzionalità del drive di lettura, e il "read offset" è uno di questi. Ogni drive ha il suo.

Da un punto di vista tecnico, il rip corretto è quello di EAC.

Poi sappiamo che alla fine, nella sostanza, il file audio estratto è identico.

Quindi va bene anche lo scarso wavelab.

[Oscar]

Da spostare in Computer Audio

[scroodge]

1 ora fa, antonew ha scritto:

Il padding o i metadati non cambiano i bit, ma cambiano il 'lavoro' elettrico della macchina.

No.

E anche ammesso che fosse, questo "lavoro" è del tutto trasparente.

Altri sì, forse.

[Max440]

11 ore fa, antonew ha scritto:

quello che arriva al DAC non è solo un calcolo matematico, è un flusso elettrico continuo.

 

@ilmisuratore : non so se sei l'unico con un certo livello di competenze tecnica, ma mi spieghi (tu od altri) questa affermazione? Ovvero: al dac arriva un flusso di "corrente elettrica" e non un "semplice codice" da tradurre?

Grazie,

Max