Originariamente inviato da
UnixMan
allora, per quanto mi riguarda (e credo sia esattamente la stessa cosa anche per Marco), l'interesse è ben altro:
1) appurare se (confermare che) le differenze evidenziate da Tom sono reali e significative; in caso affermativo ->
2) cercare di capire la natura delle differenze riscontrate, per poi ->
3) cercare di risalire alle cause, per poi ->
4) cercare di capire come controllare quei fenomeni agendo direttamente sul software (player e/o sistema).
A me - ed anche a Marco, se non ho capito male - non interessa affatto stabilire se il player/sistema X sia meglio di Y o viceversa (cosa per altro semplicemente impossibile, se per "meglio" si intende un giudizio "estetico").
Noi (di nuovo, io e Marco) non vogliamo sostituire ciò che utilizziamo con qualcos'altro. A noi interessa capire. Soprattutto, capire come dovremmo agire sui nostri sistemi per ottenere determinati risultati, in modo da poterli ottimizzare al meglio. Dal momento che usiamo software Open Source, OS compreso, abbiamo la possibilità di fare ciò che vogliamo e come vogliamo, a qualsiasi livello. Perfino modificando ALSA o il Kernel stesso, se necessario.
Ma il problema è duplice:
a) prima di tutto, evidentemente, capire cosa andrebbe fatto o non fatto, e come;
b) disporre di prove certe, chiare e convincenti, tali da convincere chiunque della concretezza del problema.
Il punto b) è particolarmente importante qualora si rivelasse utile o necessario agire "a basso livello", con modifiche a livello di software di sistema (ALSA o altro). Prova a convincere uno sviluppatore ad adottare una qualsiasi "patch" (modifica al codice) se non dimostri in modo più che convincente la sua effettiva utilità pratica... se provi a dirgli “perché così suona meglio”, quello come minimo ti ride in faccia!
Per questo la disponibilità di dati oggettivi (misure, sia pure relative) chiari, facilmente comprensibili e ripetibili sarebbe a dir poco preziosa, per non dire fondamentale.
ehm... perfettamente d'accordo sul resto ma, per questa ultima parte... sei decisamente fuori strada.
O ancora non hai capito bene come funziona l'audio digitale, oppure hai un problema "semantico": il termine "bit perfect" si riferisce, per l'appunto, esclusivamente ai "bit"!
Significa solamente che i dati numerici che arrivano al DAC non sono alterati in alcun modo rispetto a quelli (registrati nel file) di partenza. Non significa affatto e non implica in alcun modo che il segnale analogico in uscita al DAC sia "perfetto"!
Anche se disponessimo di un DAC ideale, perfetto, capace di riprodurre esattamente i valori dei campioni rappresentati dai dati numerici in ingresso ("bit"), senza alcun tipo di errore o scostamento (cosa ovviamente impossibile), il segnale analogico in uscita è dato dalla "combinazione" di tali campioni con il segnale di clock, che ne determina la successione temporale. Alterando la sequenza temporale, cambia la forma del segnale analogico ricostruito (inclusa la sua ampiezza in ogni dato istante).
Perciò, per avere un segnale analogico "perfetto" non basta avere un DAC perfetto e dati numerici esatti ("bit perfect"), ma è necessario che anche il clock sia altrettanto perfetto (cosa ovviamente impossibile, non fosse altro perché il clock è un segnale analogico).
Realizzare la condizione di "bit perfectness", cioè l'assenza di alterazioni e/o errori nei dati numerici non è difficile. Al contrario, è banale. Le tecniche digitali sono state adottate proprio per quel motivo.
Ciò che invece non solo è tutt'altro che banale ma è semplicemente impossibile da realizzare (in modo perfetto) è un DAC capace di riprodurre fedelmente il valore di quei campioni e, soprattutto, di ricostruirne l'esatta sequenza temporale (cosa che dipende in primo luogo dal segnale di clock, e poi dalla capacità del DAC stesso di agire in perfetta sincronia con questo).
Sono questi i fattori che sono all'origine dei nostri problemi. Soprattutto il secondo.
Se poi risaliamo a monte, e pensiamo al segnale analogico di partenza (quello che è stato registrato in fase di produzione), i medesimi problemi sono presenti anche in fase di conversione A/D. Per avere una riproduzione perfetta del segnale analogico originario, quindi, non solo il DAC ed il clock di riproduzione dovrebbero essere perfetti, ma dovrebbero esserlo anche l'ADC ed il relativo clock di produzione. E non basta ancora: i due clock (quello di "produzione" e di "riproduzione") dovrebbero essere perfettamente identici, cioè il clock "di riproduzione" che comanda il DAC dovrebbe essere una replica esatta di quello che a suo tempo aveva pilotato l'ADC. Cosa evidentemente impossibile.
Questi sono i problemi e le difficoltà insite nell'audio "digitale". Gli stream digitali (numerici) di per sé stessi non rappresentano affatto un problema, sappiamo perfettamente come trattarli in modo "perfetto".
Tant'è che l'assenza di errori nei dati numerici è normalmente data sempre per scontata e, normalmente, con il termine "bit perfect" non ci si riferisce affatto a questo, ma si intende banalmente indicare l'assenza di alterazioni intenzionali dello stream di dati, quali ad es. il resampling o altre elaborazioni digitali (controlli di volume, filtri, equalizzazioni, ecc).
c'è qualcosa che non capisco... e non mi torna. Se si tratta banalmente di un problema di "allineamento", questo dovrebbe implicare semplicemente un "drift" (lento) e/o un diverso ritardo (latenza). Se è così, cioè se il timing non varia "all'interno della riproduzione" (cioè se è costante oppure varia solo in tempi molto lunghi) non si può parlare di "jitter" e non ci dovrebbe essere alcuna influenza sulle caratteristiche del segnale riprodotto, e quindi sul suono.
Dov'è l'inghippo? Cos'è che non ho capito?
lo credo bene. Ma cos'è questo algoritmo (ASRC, immagino...) e, soprattutto, perché è presente? Quando/per cosa è utile?
tu cosa consiglieresti di usare?
), tutto quì.
