Perche 24bit/96khz suona sempre meglio ???

Dopo vari tentativi ho rinunciato (ammesso che sia possibile, cosa di cui dubito) a cercare di fare in modo che gli stream vengano riprodotti automaticamente da Win nel formato in cui gli arrivano.
Alla fine in tutta sincerità devo dire che creando un link alla scheda delle proprietà audio dove si imposta bit rate e frequenza di campionamento non se ne sente nemmeno tanto l'esigenza.
Comunque, inizio a registrare uno stream a 44.1 e dimentico di switchare da 24/96k. Fermo tutto, cambio i parametri in Audacity, reimposto win a 16-44.1 e faccio ripartire, sia per non sprecare spazio inutilmente sia perché voi mi insegnate che ogni conversione inutile (anche se teoricamente migliorativa) comporta decadimento.
Il suono e palesemente diverso. Meno "aperto", sicuramente meno dinamico e forse anche un po' più basso di volume (anche se questo potrebbe essere legato alla peggiore dinamica).
Provo qualche volta per essere sicuro di non avere le traveggole ma il suono e effettivamente diverso. Coinvolgo la moglie nella questione, che stancamente si trascina sulla poltrona di ascolto perché di tutto ciò non gliene frega niente dato che il suo concetto di musica si limita a Vasco Rossi in autoradio. La differenza la sente anche lei, e becca la differenza 2 su 2 ("suona meglio così").
Ora io mi chiedo come diavolo è possibile che ci sia questa differenza, dato che non è possibile migliorare quello che arriva in streaming ? Che per qualche ragione Windows effettui un qualche downgrade se si imposta a 16/44.1 ?
C'è qualcuno altro che ha notato questa cosa ?
Il DAC topping E30 riconosce i due formati e li visualizza correttamente sul display.

Gumbo ha scritto: Dopo vari tentativi ho rinunciato (ammesso che sia possibile, cosa di cui dubito) a cercare di fare in modo che gli stream vengano riprodotti automaticamente da Win nel formato in cui gli arrivano.
Alla fine in tutta sincerità devo dire che creando un link alla scheda delle proprietà audio dove si imposta bit rate e frequenza di campionamento non se ne sente nemmeno tanto l'esigenza.
Comunque, inizio a registrare uno stream a 44.1 e dimentico  di switchare da 24/96k. Fermo tutto, cambio i parametri in Audacity, reimposto win a 16-44.1 e faccio ripartire, sia per non sprecare spazio inutilmente sia perché voi mi insegnate che ogni conversione inutile (anche se teoricamente migliorativa) comporta decadimento.
Il suono e palesemente diverso. Meno "aperto", sicuramente meno dinamico e forse anche un po' più basso di volume (anche se questo potrebbe essere legato alla peggiore dinamica).
Provo qualche volta per essere sicuro di non avere le traveggole ma il suono e effettivamente diverso. Coinvolgo la moglie nella questione, che stancamente si trascina sulla poltrona di ascolto perché di tutto ciò non gliene frega niente dato che il suo concetto di musica si limita a Vasco Rossi in autoradio. La differenza la sente anche lei, e becca la differenza 2 su 2 ("suona meglio così").
Ora io mi chiedo come diavolo è possibile che ci sia questa differenza, dato che non è possibile migliorare quello che arriva in streaming ? Che per qualche ragione Windows effettui un qualche downgrade se si imposta a 16/44.1 ?
C'è qualcuno altro che ha notato questa cosa ?
Il DAC topping E30 riconosce i due formati e li visualizza correttamente sul display.

Mah...da quello che ho capito hai registrato la stessa cosa in 24/96 e poi in 44.1/16? E la prima registrazione suona meglio? Strano, molto strano....diciamo che il "suona meglio" credo equivalga ad un differente equilibrio tonale, un "qualcosa" sulla risposta in frq che entra in gioco in uno o nell'altro campionamento...non è di certo un suonare meglio legato alla risoluzione superiore

No, la differenza è proprio sull'ascolto dello stream. E verificata la differenza la registrazione l'ho fatta a 24/96.
Però la tua osservazione mi ha fatto riflettere, e stasera provo a impostare il campionamento di win a 24/96 e a fare una registrazione dello stream a 16/44 e una a 24/96 e poi vedo se c'è differenza nella qualità del playback della registrazione lasciando sempre win su 24/96.
Perché se e solo una questione di playback e inutile registrare a 24/96 solo per occupare più spazio. Anche se a quel punto le conversioni sarebbero due: una fatta da win per portare lo stream da 44.1 a 96 e l'altra da Audacity per riconvertire a 44.1 quello che win gli "passa" a 96.

Comunque ho letto in rete, mi pare su quel sito che recensisce tutti i DAC, che molti DAC suonano meglio a 96 che a 44 perché su quella frequenza lavorano meglio. Però purtroppo le impressioni di ascolto che si leggono in rete oggigiorno sono poco affidabili (ho letto recensioni perfino su come suonano i mobiletti) e spesso frutto di autocondizionamento, per cui rimane sempre il dubbio.

Comunque a mio avviso più che sulla frequenza la differenza e di dinamica. A 24/96 i bassi "pompano" sensibilmente di più e la risposta ai transienti sui medi (esempio chitarra acustica pizzicata) è più netta.
E lì che noto la maggiore differenza.
Dato che ogni tanto su alcuni album/generi musicali uso ancora l'espansore di dinamica anche se al minimo (+4 o +7 db) l'effetto è similare, compreso il leggero aumento di volume e di dimensione della scena sonora.
Solo che l'espansore sfuoca un po' gli strumenti, che però su roba moderna/ritmata non e un problema perché tanto i fonici si divertono a mettere il charleston a destra e il resto della batteria a sinistra, quindi...

Gumbo ha scritto:No, la differenza è proprio sull'ascolto dello stream. E verificata la differenza la registrazione l'ho fatta a 24/96.
Però la tua osservazione mi ha fatto riflettere, e stasera provo a impostare il campionamento di win a 24/96 e a fare una registrazione dello stream a 16/44 e una a 24/96 e poi vedo se c'è differenza nella qualità del playback della registrazione lasciando sempre win su 24/96.
Perché se e solo una questione di playback e inutile registrare a 24/96 solo per occupare più spazio. Anche se a quel punto le conversioni sarebbero due: una fatta da win per portare lo stream da 44.1 a 96 e l'altra da Audacity per riconvertire a 44.1 quello che win gli "passa" a 96.

Comunque ho letto in rete, mi pare su quel sito che recensisce tutti i DAC, che molti DAC suonano meglio a 96 che a 44 perché su quella frequenza lavorano meglio. Però purtroppo le impressioni di ascolto che si leggono in rete oggigiorno sono poco affidabili (ho letto recensioni perfino su come suonano i mobiletti) e spesso frutto di autocondizionamento, per cui rimane sempre il dubbio.

Comunque a mio avviso più che sulla frequenza la differenza e di dinamica. A 24/96 i bassi "pompano" sensibilmente di più e la risposta ai transienti sui medi (esempio chitarra acustica pizzicata) è più netta.
E lì che noto la maggiore differenza.
Dato che ogni tanto su alcuni album/generi musicali uso ancora l'espansore di dinamica anche se al minimo (+4 o +7 db) l'effetto è similare, compreso il leggero aumento di volume e di dimensione della scena sonora.
Solo che l'espansore sfuoca un po' gli strumenti, che però su roba moderna/ritmata non e un problema perché tanto i fonici si divertono a mettere il charleston a destra e il resto della batteria a sinistra, quindi...

OK, capisco e comprendo la tua curiosità...ma tra un brano a 44.1/16 ed uno 96/24 non c'è nessuna differenza, assolutamente nessuna differenza che può essere colta con un ascolto "normale"
Se vengono notate differenze sono, sempre a mio giudizio, da imputare a non corretta conversione AD e DA del DAC del PC, a qualche "cosa" che fa Audacity...non entro nel merito m stiamo parlando di differenze che non si rilevano neanche strumentalmente
E' vero che qualche chip DAC lavora meglio facendo un upsampling, ma è altra cosa rispetto a questo
La qualità di un evento musicale digitale è data dall'insieme del progetto/lavoro/ripresa/missaggio/masterizzazione digitale, non è subordinata al fatto se venga poi fatta in 44.1/16 o 96/24

24/44 is the way.

Qualche anno fa, anzi diversi anni fa.. i DAC montavano un unico clock e la stragrande maggioranza quelli da 12288Mhz..
Essendo divisibile (intero) solo per 48000 (e suoi multipli) molti si impippavano con le conversioni forse anche a ragion veduta (io le differenze con le diverse frequenze non le ho mai colte).

root ha scritto:
OK, capisco e comprendo la tua curiosità...ma tra un brano a 44.1/16 ed uno 96/24 non c'è nessuna differenza, assolutamente nessuna differenza che può essere colta con un ascolto "normale"

http://www.2l.no/hires/index.html?

Non servono pareri. Basta provare con il proprio setup.

bonghittu ha scritto:

root ha scritto:
OK, capisco e comprendo la tua curiosità...ma tra un brano a 44.1/16 ed uno 96/24 non c'è nessuna differenza, assolutamente nessuna differenza che può essere colta con un ascolto "normale"

http://www.2l.no/hires/index.html?

Non servono pareri. Basta provare con il proprio setup.

OK, al rientro dalle ferie lo farò...ma credo sia una cosa diversa questa...qui si parte da un Master DXD, per cui già digitale PCM 352KHz/24

Il mio discorso è relativo ad un campionamento/digitalizzazione dove si parte da master analogico, dove con lo stesso convertitore ADC si digitalizza a 44.1/16 ed anche a 96KHz/24...all'ascolto se si notano differenze è perchè il convertitore non è perfettamente lineare/di qualità, altrimenti non ci possono essere differenze ascoltabili ad orecchio umano

Io sto continuando con la dovuta calma a fare varie prove, e mi sto accorgendo che le varie cose che si leggono in rete sono delle bufale, magari anche raccontate in buona fede o perché me lo ha detto il fratello di un amico di mio cugino che è amico della sorella della moglie di Bill Gates.
Ad esempio NON È VERO che WASAPI registra gli stream bit-perfect bypassando tutte le impostazioni di Win e che registra 'in the box" prima di arrivare al DAC (che sia interno al PC o esterno).
BUFALA !!!

Il flusso fa questo giro  (dell'oca):
Entra nella macchina, viene campionato da WIN alla frequenza impostata nelle opzioni audio (e quindi già qui addio "bit-perfect") viene processato (se ci sono processori attivi tipo un equalizzatore ad esempio), poi viene inviato al DAC e da li viene poi ripreso (prima della decodifica) e inviato alla registrazione.
Se il DAC usa drivers ASIO (o WASAPI)  gestisce lui in maniera esclusiva le impostazioni audio, ma solo a valle del campionamento, quindi ad esempio i processori non funzionano, ma l'impostazione sul campionamento in ingresso avviene a monte e non la gestisce lui (dobbiamo impostarla noi).
Se il DAC non usa drivers ASIO o WASAPI non gestisce lui in maniera esclusiva il flusso audio e quindi "funziona tutto".
Il problema è che funziona tutto ma funziona male e senza logica.

Ad esempio, voglio registrare a 24/96 uno stream che so per certo essere a 24/96 e dato che ho una certa equalizzazione per correzione ambientale voglio usufruirne anche in fase di ascolto mentre registro.
Tanto per cominciare devo impostare io bit rate e frequenza di campionamento di Win, poi  devo fare andare il DAC con drivers non WASAPI ne ASIO (se no non sento equalizzazione) e infine  devo registrare con WASAPI loopback.
Il problema e che per via del loop back di WASAPI il segnale da registrare viene preso diciamo da dentro il DAC e dunque dopo la equalizzazione e quindi  la registrazione viene equalizzata (bella furbata eh !!!).
E non c'è modo di fare diversamente. Quello dell'equalizzazione e solo un esempio, ma se ad esempio uno usa un crossover software...capite da soli cosa succede.

Praticamente bisognerebbe usare più macchine, una per ascoltare , una per registrare , una come crossover ecc.
A quel punto uno compra un DSP e fa prima (e alla fine spende anche meno).

Quindi Windows si conferma per l'ennesima volta un sistema fatto coi piedi, e bisogna diffidare da ciò che di buono si legge in rete a riguardo.
Purtroppo alcuni programmi girano solo su win e quindi se servono e non c'è alternativa bisogna piegarsi.
Va benissimo per gli audiofili minimalisti che se vedono un equalizzatore o altro gli prende un infarto, per quelli va bene perché non si renderanno mai conto di cosa succede dentro la macchina e di come windows ok sta prendendo per il XXXX,  perché sono troppo intenti a valutare come suonano i mobiletti.
Ma se si vuole mettere su una DAW scordatevi Windows.

Il discorso 24/96... la differenza sulle registrazioni a cui ho accesso c'è eccome. Non sento differenze se alimento il DAC da batteria, con un alimentatore dello smartphone da 5 Euro o da USB, non sento differenze tra i vari drivers del DAC (ASIO compreso), ne se metto i piedini sotto l'ampli o se ascolto cavi da 2000 € al metro, che ci volete fare sarò sordo !
Ma la differenza tra lo stesso disco edizione 44/16 ed edizione hi-res la sento.
Se non sono i bit o la frequenza sarà qualcosa altro ma la differenza c'è, parola di sordo !

Dipende dalla qualità del resampler e da come è implementato.Anche Sox che da tutti viene definito il migliore(?!?)varia tra player e player,ottimo in foobar e scadente in jriver. idem SRC o SSRC.Con alcune implementazioni tali resampler mantengono una fase corretta e non introducono distorsioni......in altri....non tanto..
Un saluto

Gumbo ha scritto:Ad esempio NON È VERO che WASAPI registra gli stream bit-perfect bypassando tutte le impostazioni di Win e che registra 'in the box" prima di arrivare al DAC (che sia interno al PC o esterno).
BUFALA !!!

Sì, è una bufala: WASAPI non registra ma gestisce le sessioni audio (che è ben diverso).

Gumbo ha scritto:Se il DAC usa drivers ASIO (o WASAPI)  gestisce lui in maniera esclusiva le impostazioni audio, ma solo a valle del campionamento

E ci mancerebbe altro, se così non fosse non potrei usare il DAW con le schede audio attraverso quel protocollo.

Mi sa che è il caso di studiare prima i scrivere affermazioni affrettate:

https://performerlife.com/wasapi-vs-asio/

Marco Ravich ha scritto:

Gumbo ha scritto:Ad esempio NON È VERO che WASAPI registra gli stream bit-perfect bypassando tutte le impostazioni di Win e che registra 'in the box" prima di arrivare al DAC (che sia interno al PC o esterno).
BUFALA !!!

Sì, è una bufala: WASAPI non registra ma gestisce le sessioni audio (che è ben diverso).

Ho abbreviato il concetto, mi pare inutile che tu sottolinei una ovvietà. WASAPI è una API e non un "registatore" ne una DAW, e in quanto tale non è certo WASAPI che "registra". Pero se tu facessi una ricerca in rete su vari software uno dei quali e Audacity (ma anche altri) che vengono usati per registrare, ti accorgeresti che è dato per assodato che impostando "WASAPI loopback" come dispositivo in input, la registrazione di uno stream viene effettuata "bit-perfect", e indipendentemente da qualsiasi impostazione di Windows, o da altri processi audio che vengono gestiti da Windows.
Questa è la bufala, in quanto 1) non è possibile in alcun modo escludere il ricampionamento di windows su di uno stream in ingresso, 2) non e affatto vero che l'utilizzo di wasapi loopback come dispositivo di input disabiliti tutti i processi audio che windows gestisce sullo stream.
Evidentemente non ti è chiaro il concetto di copia bit-perfect, e cioè che un contenuto  ( di qualsivoglia natura sia, audio, video, testuale ecc) viene copiato bit per bit in maniera identica all'originale. Che poi si tratti di uno stream o di un file già presente fisicamente per intero nella macchina o su di una macchina remota, questo è irrilevante, in quanto il termine stream identifica semplicemente un file che viene letto mentre non è ancora interamente scaricato, quindi dal punto di vista della lettura non c'è alcuna differenza.
La differenza sta casomai dalla parte che effettua lo stream, (lo streaming server) che deve "inviare" il file in maniera tale che possa essere letto anche prima di essere interamente scaricato, anche se a questo ci sono delle eccezioni come ad esempio i file .mkv e software (come il tanto denigrato dagli audiofili VLC) che consente la lettura di contenuti mediali mentre si stanno ancora scaricando.
Nel momento in cui si scarica un file, il sistema effettua una copia "bit-perfect", prova ne sia il fatto che ci sono sistemi e software deputati a effettuare la verifica dell'integrità dei file (Hash Tab, MD5 ecc.) e a garantire che i due file siano identici. Questo certamente non è possibile con uno stream perchè il contenuto non viene "immagazzinato" nel client e dunque non puo essere "comparato", ma questo non significa che lo streaming non possa ugualmente essere "bitperfect".

Per fare una copia bit-perfect non c'è dunque esigenza di alcun driver ne di alcun device (scheda audio, DAC o altro) in quanto cosi come stai facendo una copia di un file mentre lo scarichi, un sistema non fatto coi piedi potrebbe benissimo gestire l'ingresso dello stream in maniera del tutto indipendente da ciò che poi il sistema deve fare per poterlo riprodurre, registrare, processare ecc.

Marco Ravich ha scritto:

Gumbo ha scritto:Se il DAC usa drivers ASIO (o WASAPI)  gestisce lui in maniera esclusiva le impostazioni audio, ma solo a valle del campionamento

E ci mancerebbe altro, se così non fosse non potrei usare il DAW con le schede audio attraverso quel protocollo.

Quale protocollo ?
ASIO è quello che in gergo viene chiamato driver cioè un protocollo di comunicazione tra un device hardware (nel caso in questione la scheda audio) e un software.
WASAPI è come dice la parola stessa una API cioè un intefaccia di programmazione avanzata che consente a due software (e non a un software e un hardware) di comunicare tra loro
Spero la differenza ti sia chiara.
Detto questo non capisco cosa c'entri come un sistema gestisce l'ingresso di uno stream con quello che invece uno vuole fare con una DAW. Sono due cose (o per meglio dire in Windows "dovrebbero essere") due cose ben distinte.
E il problema sta proprio nel fatto che in windows non è possibile separare la gestione del flusso di dati dal punto di vista dell'acquisizione (intendendo con acquisizione il processo tramite il quale un flusso di dati entra all'interno della macchina), da quello dei processi che vengono effettuati su tale file dal sistema operativo, da altri software, o da periferiche hardware (e relativi driver).

Se sai come funzionano i file matroska (.mkv) dovresti riuscire a capire facilmente di cosa sto parlando.
I file .mkv infatti possono essere riprodotti in streaming (se si hanno i drivers/API necessarie) mentre si stanno scaricando fisicamente sulla macchina che li riceve, ma di certo non vengono, ricampionati, ne possono essere colorati di azzurro (esempio) prima che arrivino al player.  Questo lo si può fare lavorando sul file ma non sullo stream.
Questo se vogliamo è un esempio IN SENSO LATO di streaming bit-perfect (a parte ovviamente errori di trasferimento e bit che si perdono per strada, ma questo è un altro discorso).

Marco Ravich ha scritto:
Mi sa che è il caso di studiare prima i scrivere affermazioni affrettate:

https://performerlife.com/wasapi-vs-asio/

Il link che hai postato continua a parlare a vanvera di bitperfect registrando tramite WASAPI, propagando dunque la BUFALA.
Ribadisco che dal momento che, altro non fosse solamente per la questione del campionamento, che deve essere impostato dall'utente (se non si vuole che sia quello standard di Windows) non è corretto parlare di bit-perfect, che implica il fatto che la registrazione sia autonomamente e perfettamente identica all'originale anche per quanto riguarda bit-rate e frequenza di campionamento.
Solo nel momento in cui mi dimostri che 1) se lasci le impostazioni di default di windows uno stream non viene registrato (o riprodotto) a 32/44.1 (standard windows) ma nel bitrate/FC originale, e 2) i processi audio in corso sulla macchina non influiscono sul flusso di dati in registrazione scegliendo WASAPI come protocollo di comunicazione, solo allora potrò dare ragione a te, a ai vari propagatori di bufale e "click-bait" come quello che hai linkato.

Sul fatto invece che prima di scrivere bisogna studiare mi trovi perfettamente d'accordo, è una buona regola per evitare brutte figure, insieme a quella di riflettere e magari evitare risposte dal tono poco garbato e saccente.
Anche perchè non si sa mai a chi stai rispondendo, e non è facile capire se la persona a cui stai rispondendo fa finta di essere stupido per modestia o se lo è veramente.

Gumbo ha scritto:impostando "WASAPI loopback" come dispositivo in input, la registrazione di uno stream viene effettuata "bit-perfect"

E' un'operazione insensata: gli stream (come i CD), essendo già digitali, NON si registrano ma - semmai - si rippano.

Gumbo ha scritto:Per fare una copia bit-perfect non c'è dunque esigenza di alcun driver ne di alcun device (scheda audio, DAC o altro) in quanto cosi come stai facendo una copia di un file mentre lo scarichi, un sistema non fatto coi piedi potrebbe benissimo gestire l'ingresso dello stream in maniera del tutto indipendente da ciò che poi il sistema deve fare per poterlo riprodurre, registrare, processare ecc.

La qualità "bit-perfect" si deve necessariamente riferire esclusivamente al flusso dei bit (eventualmente decodificati/trattati prima) da/verso l'hardware di codifica/decodifica.

Gumbo ha scritto:I file .mkv infatti possono essere riprodotti in streaming (se si hanno i drivers/API necessarie) mentre si stanno scaricando fisicamente sulla macchina che li riceve, ma di certo non vengono, ricampionati, ne possono essere colorati di azzurro (esempio) prima che arrivino al player.  Questo lo si può fare lavorando sul file ma non sullo stream.
Questo se vogliamo è un esempio IN SENSO LATO di streaming bit-perfect (a parte ovviamente errori di trasferimento e bit che si perdono per strada, ma questo è un altro discorso).

File = rip
Registrazione = digitalizzazione

...è chiara la differenza ?

Gumbo ha scritto:
Il discorso 24/96... la differenza sulle registrazioni a cui ho accesso c'è eccome. Non sento differenze se alimento il DAC da batteria, con un alimentatore dello smartphone da 5 Euro o da USB, non sento differenze tra i vari drivers del DAC (ASIO compreso), ne se metto i piedini sotto l'ampli o se ascolto cavi da 2000 € al metro, che ci volete fare sarò sordo !
Ma la differenza tra lo stesso disco edizione 44/16 ed edizione hi-res la sento.
Se non sono i bit o la frequenza sarà qualcosa altro ma la differenza c'è, parola di sordo !

WOW! complimenti per le info che ci restituisci...non fanno che confermare il motivo per cui ho bannato da tempo Winzozz per leggere musica Hi-Res

Per il discorso differenze all'ascolto sulle registrazioni ci credo, per l'amor del cielo, ma credo nel tuo caso siano dovute ad un differente processamento, a qualcosa di esterno...non credo siano dovute solo ed esclusivamente alla differente risoluzione del campionamento

@ Marco Ravich, sei persona intelligente e preparata, oltre che disponibile a dare consigli sulla base della tua esperienza, quindi non attaccarti alle parole, hai capito perfettamente di cosa sto parlando.
Non c'è alcuna ragione per cui un flusso di dati non possa essere riconosciuto nelle sue caratteristiche e di conseguenza il sistema adegui "automaticamente" il campionamento senza interventi da parte dell'operatore.
Così come non c'è nessuna ragione per cui una API (guardacaso di Microsoft) che dicono abbia lo scopo di prendere il controllo esclusivo dei processi audio non lo faccia veramente.
A parziale discolpa di Microsoft il fatto che da nessuna parte Microsoft dichiari questa caratteristica di WASAPI.
Dunque è probabile che sia il solito meccanismo delle bufale, che uno le inventa (e ad averla inventata non è Microsoft) e in mille gli fanno da grancassa, come quell'articolo che hai linkato.

Sul fatto che la registrazione avvenga sul flusso di dati da/verso il DAC, già lo sapevo, e infatti l'ho scritto nel mio primo post.
Sul fatto che si possa riferirsi come "bit-perfect" a un flusso di dati decodificati/trattati più o meno autonomamente dal sistema operativo o dall'utente permettimi di dissentire, non tanto sul meccanismo (perché purtroppo così avviene) ma sul termine che ingenera confusione lasciando intuire una copia fedele bit per bit all'originale e non a un segnale ricampionato e processato a piacere dal sistema operativo o dall'operatore.
Prova ne sia che in rete trovi discussioni (anche furibonde) sull'argomento registrazione bit-perfect di stream in ingresso, e se sia veramente possibile e come.

Gumbo ha scritto:sei persona intelligente e preparata, oltre che disponibile a dare consigli sulla base della tua esperienza, quindi non attaccarti alle parole, hai capito perfettamente di cosa sto parlando.

Grazie dei complimenti, ma sono solo un perito informatico che "tratta" - da qualce decennio - contenuti multimediali digitali.
Certo che ho capito, per questo provo a farti capire che usi un approccio informaticamente errato.

Gumbo ha scritto:Non c'è alcuna ragione per cui un flusso di dati non possa essere riconosciuto nelle sue caratteristiche e di conseguenza il sistema adegui "automaticamente" il campionamento senza interventi da parte dell'operatore.

Il sottosistema audio di un SO si deve adeguare alle impostazioni che l'utente desidera, non "automaticamente".

Gumbo ha scritto:Così come non c'è nessuna ragione per cui una API (guardacaso di Microsoft) che dicono abbia lo scopo di prendere il controllo esclusivo dei processi audio non lo faccia veramente.
A parziale discolpa di Microsoft il fatto che da nessuna parte Microsoft dichiari questa caratteristica di WASAPI.
Dunque è probabile che sia il solito meccanismo delle bufale, che uno le inventa (e ad averla inventata non è Microsoft) e in mille gli fanno da grancassa, come quell'articolo che hai linkato.

Non è così che funziona: WASAPI è un'interfaccia che - come tutte le API - "semplifica" il controllo da parte degli sviluppatori di terze parti del layer audio di Windows:
"The Windows Audio Session API (WASAPI) enables client applications to manage the flow of audio data between the application and an audio endpoint device."
fonte: https://docs.microsoft.com/en-us/windows/win32/coreaudio/wasapi

Gumbo ha scritto:Sul fatto che la registrazione avvenga sul flusso di dati da/verso il DAC, già lo sapevo, e infatti l'ho scritto nel mio primo post.

E' qua il problema: un flusso dati digitale che arriva al PC da un file remoto è un conto, diverso è quello che arriva da un convertitore (che quindi passa necessariamente attraverso dei drivers).

Gumbo ha scritto:Sul fatto che si possa riferirsi come "bit-perfect" a un flusso di dati decodificati/trattati più o meno autonomamente dal sistema operativo o dall'utente permettimi di dissentire, non tanto sul meccanismo (perché purtroppo così avviene) ma sul termine che ingenera confusione lasciando intuire una copia fedele bit per bit all'originale e non a un segnale ricampionato e processato a piacere dal sistema operativo o dall'operatore.

Il trasferimento "bitperfect" si può avere - semplificando - nel flusso dei dati fra un PC ed una periferica ADC/DAC hardware, altrimenti è proprio concettualmente errato chiamarlo in causa.

Se copio un file da una memoria ad un'altra - irrilevante se remota o locale - il "bitperfect" non c'entra nulla, visto che la copia è per sua natura 1:1...

Per capirsi: se per "dumpare" un CDaudio lo metto in play/rec ed uso un cavetto (irrilevante se reale o virtuale), ho proprio sbagliato approccio.

Gumbo ha scritto:Prova ne sia che in rete trovi discussioni (anche furibonde) sull'argomento registrazione bit-perfect di stream in ingresso, e se sia veramente possibile e come.

Again: se il flusso in ingresso è analogico, allora si può "chiamare in causa" il bitperfect (limitatamente al trasferimento fra l'ADC ed il software di registrazione), altrimenti no.

Se ne è parlato molte volte. Tutti i SO, tendono a trattare i segnali audio convertendoli ad una unica frequenza, tipicamente 44/16. E' una questione di praticità, per gestire facilmente segnali diversi, che nel 99% dei casi va bene, poi, se uno vuole riprodurre musica ad alta qualità, no.
Windows (ma anche Linux, e suppongo anche Mac che non conosco), possono cambiare questa impostazione ma comunque, da quello che ho visto, il server audio di sistema (Pulseaudio nel caso di Linux), ricampiona preventivamente il segnale, anche se la frequenza è la stessa, prima di inviarlo al DAC, facendo ovviamente danni, o comunque vanificando in parte la maggiore qualità del convertitore esterno.
L'unica maniera per evitare questo inconveniente è escludere il server audio di sistema, con Linux si fa inviando il segnale direttamente ad ALSA (Advanced Linux Sound Architecture), con Windows usando per esempio dei driver ASIO.
Con un DAC con il display, come il Topping E30, si vede subito, perché deve indicare la frequenza del file nativo e non quella di default delle impostazioni audio.

La faccenda del bitperfect riguarda essenzialmente l'estrazione di tracce audio digitali da supporti come il cd audio. Ricordo che i lettori audio, leggono il disco al volo, sulla base delle specifiche del red book elaborato da Philips e Sony, risalente al 1980. Essendo allora complicato bufferizzare i dati, per evitare interruzioni nella riproduzione, gli errori di lettura trovati dal laser, sono corretti riempiendo praticamente i buchi come possibile, in parte utilizzando la ridondanza dei dati, in parte degradando il segnale.
Dovendo estrarre le tracce di un cd audio, si usano in genere programmi che garantiscono il bit perfect, che, in caso di errori, rileggono i dati fino ad assicurare la rispondenza tra le tracce originarie e quelle estratte. In caso di impossibilità, tipo disco danneggiato, danno un messaggio di errore.
Se invece copiamo un file da un hard disk ad un altro, a prescindere dal tipo di file, la copia è sempre identica all'originale, a meno di errori di I/O, che verrebbero segnalati.

fileo ha scritto:Essendo allora complicato bufferizzare i dati, per evitare interruzioni nella riproduzione, gli errori di lettura trovati dal laser, sono corretti riempiendo praticamente i buchi come possibile, in parte utilizzando la ridondanza dei dati, in parte degradando il segnale.

Vuoi far schiattare un esercito di boomers convinti che il CD suoni
meglio degli altri formati digitali?

Parecchi anni fa, feci delle prove con diversi lettori CD, erano tutti sensibili alle vibrazioni, perché il suono, interponendo tra l'apparecchio ed il piano di appoggio, gommini o punte di metallo, cambiava, in maniera leggera, ma udibile. Per riprova, usai come test mia moglie, assolutamente impermeabile alle seghe mentali degli idiofili, e lei mi confermò le mie impressioni.
L'unico apparecchio insensibile a questi trattamenti, si rivelò uno Studer Revox ex Rai, che avevo avuto in prestito, ma suppongo dipendesse dal peso (circa 16 kg).
Poi possiamo disquisire se preferiamo un suono più asciutto o più caldo, ma il sistema di lettura al volo del laser sul cd, risente delle vibrazioni dell'ambiente oltre che delle imperfezioni del supporto e le difficoltà del sistema di lettura.
Io a parità di classe degli apparecchi, che significa non confrontare un dac da 20 € con un cd player da 10000, ho sempre trovato vincente la musica su hard disk, quella cosiddetta liquida.
Poi se qualcuno trova più poetico maneggiare il dischetto ed inserirlo nel lettore, lo capisco, anche se a questo punto è meglio maneggiare il discone da 30 cm, facendolo roteare agilmente sui polpastrelli che lo tengono per i bordi, senza metterci sopra le "ditacce unte".

fileo ha scritto:
Io a parità di classe degli apparecchi, che significa non confrontare un dac da 20 € con un cd player da 10000, ho sempre trovato vincente la musica su hard disk, quella cosiddetta liquida.

Idem. Non vedo come potrebbe essere diversamente.
Penso sia più che altro un discorso di nostalgia.
Questa passione per molti - me compreso - rappresenta
una passione giovanile e sembra assurdo che un mito
del passato sia oggettivamente superato.

fileo ha scritto:
L'unica maniera per evitare questo inconveniente è escludere il server audio di sistema, con Linux si fa inviando il segnale direttamente ad ALSA (Advanced Linux Sound Architecture), con Windows usando per esempio dei driver ASIO.
Con un DAC con il display, come il Topping E30, si vede subito, perché deve indicare la frequenza del file nativo e non quella di default delle impostazioni audio.

Questo che dici è vero soltanto in parte in Windows, e cioè succede solamente nella riproduzione di files ma non nella riproduzione di streams, che è dove risiede il problema. Faccio un esempio per farti capire meglio.
Vai su un sito dove ce un file audio test sia 24/96 che a 16/44 disponibile sia in download che per l'ascolto diretto, cioè puoi cliccare su download per scaricarlo o su play per sentirlo. Scarichi le due versioni.
Imposti il bitrate di win a 24/96.
Nel player (Foobar) selezioni ASIO come drivers del tuo DAC e poi riproduci il file scaricato in entrambe le versioni.
Il display del DAC indica correttamente il bit rate cioè quando riproduci il file da 44/16 il display indica 44/16 e quando riproduci quello da 24/96 indica 24/96.
Ora torni (tramite browser ovviamente) sul sito dove hai scaricato i due file, ma stavolta anziché scaricarli li riproduci (clicchi su play).
Quando riproduci il file da 24/96 il display indica 24/96, quando riproduci il file a 44/16 il display anziché indicare 44/16 indica sempre 24/96.
Ergo il sistema nel caso dello stream ha ricampionato il segnale in ingresso con le impostazioni che tu gli hai dato e quindi quando arriva al DAC non e più 16/44 come era in origine, ma e stato "trasformato" in 24/96. Questo ovviamente non avviene nel caso del download.
Per questo motivo difatto in Windows è impossibile riprodurre un file in streaming in quella che molti intendono come modalità bit-perfect e cioè identico all'originale senza ricampionamenti.

Se questo accada o no anche in Linux non lo so perché non ho ancora fatto verifiche di questo tipo su tale sistema. Secondo molti usando Alsa Linux non ricampiona. Viste le bufale che circolano io finché non provo non credo, perché magari è uguale alla questione della registrazione tramite WASAPI che in teoria bypassa tutti i processi audio di win mentre in realtà non bypassa una mXXXa, compresi processori e suoni di sistema, per cui ti ritrovi i suoni delle notifiche e le equalizzazioniall'interno della registrazione "bit-perfect".

fileo ha scritto:
La faccenda del bitperfect riguarda essenzialmente l'estrazione di tracce audio digitali da supporti come il cd audio. Ricordo che i lettori audio, leggono il disco al volo, sulla base delle specifiche del red book elaborato da Philips e Sony, risalente al 1980. Essendo allora complicato bufferizzare i dati, per evitare interruzioni nella riproduzione, gli errori di lettura trovati dal laser, sono corretti riempiendo praticamente i buchi come possibile, in parte utilizzando la ridondanza dei dati, in parte degradando il segnale.
Dovendo estrarre le tracce di un cd audio, si usano in genere programmi che garantiscono il bit perfect, che, in caso di errori, rileggono i dati fino ad assicurare la rispondenza tra le tracce originarie e quelle estratte. In caso di impossibilità, tipo disco danneggiato, danno un messaggio di errore.
Se invece copiamo un file da un hard disk ad un altro, a prescindere dal tipo di file, la copia è sempre identica all'originale, a meno di errori di I/O, che verrebbero segnalati.

Verissimo, probabilmente e in questa direzione che bisogna lavorare per risolvere il problema dello streaming. O forse ci stanno già lavorando, perché che il sistema audio di Win sia lacunoso lo sa benissimo anche Microsoft che infatti ci sta lavorando.
Prova ne sia che Win 11 e un totale disastro e la maggior parte dei processori e DAW su Win 11 ha problemi o non funziona per niente per via dei cambiamenti apportati rispetto a win 10.
Considerando che win11 fa parte di quei sistemi operativi più bacati degli altri che Microsoft rilascia a scadenza regolare (come Windows ME, e Windows Vista), la speranza e con Windows 12 si abbia finalmente un sistema audio degno di tale nome.
Penso che sia un esigenza sentita e verso la quale immagino stiano spingendo fortemente i grandi fornitori di musica di qualità in streaming, a cui immagino non faccia molto piacere che i loro sforzi per proporre contenuti hi-res in streaming vengano vanificati dal sistema operativo (anche se sembra che il 99.9% dell'utenza non se sia ancora accorto).

fileo ha scritto:Windows (ma anche Linux, e suppongo anche Mac che non conosco), possono cambiare questa impostazione ma comunque, da quello che ho visto, il server audio di sistema (Pulseaudio nel caso di Linux), ricampiona preventivamente il segnale, anche se la frequenza è la stessa, prima di inviarlo al DAC, facendo ovviamente danni, o comunque vanificando in parte la maggiore qualità del convertitore esterno.

Non proprio: le impostazioni del server audio sono gestibili dal'utente.

fileo ha scritto:L'unica maniera per evitare questo inconveniente è escludere il server audio di sistema, con Linux si fa inviando il segnale direttamente ad ALSA (Advanced Linux Sound Architecture), con Windows usando per esempio dei driver ASIO.

Esattamente: su Windows, in modalità DirectSound o Kernel Streaming, i parametri non possono essere gestiti dalle applicazioni (il che non vuol dire però che l'audio venga manipolato, se non in base alle impostazioni dell'utente).
Anche per questo fu introdotto WASAPI.

fileo ha scritto:La faccenda del bitperfect riguarda essenzialmente l'estrazione di tracce audio digitali da supporti come il cd audio. Ricordo che i lettori audio, leggono il disco al volo, sulla base delle specifiche del red book elaborato da Philips e Sony, risalente al 1980. Essendo allora complicato bufferizzare i dati, per evitare interruzioni nella riproduzione, gli errori di lettura trovati dal laser, sono corretti riempiendo praticamente i buchi come possibile, in parte utilizzando la ridondanza dei dati, in parte degradando il segnale.

...quello però è il famigerato jitter...

fileo ha scritto:Dovendo estrarre le tracce di un cd audio, si usano in genere programmi che garantiscono il bit perfect, che, in caso di errori, rileggono i dati fino ad assicurare la rispondenza tra le tracce originarie e quelle estratte. In caso di impossibilità, tipo disco danneggiato, danno un messaggio di errore.

I software di ripping NON hanno niente a che fare con il "bitperfect" (che invece riguarda il flusso audio da/verso le periferiche audio hardware), ma in quel caso trattasi delle tecniche di estrazione Accuraterip o CDparanoia.

fileo ha scritto:Se invece copiamo un file da un hard disk ad un altro, a prescindere dal tipo di file, la copia è sempre identica all'originale, a meno di errori di I/O, che verrebbero segnalati.

La copia di un contenuto digitale (file) da un supporto di memorizzazione - solido, magnetico od ottico che sia - ad un'altro è SEMPRE così.

Marco Ravich ha scritto:
Esattamente: su Windows, in modalità DirectSound o Kernel Streaming, i parametri non possono essere gestiti dalle applicazioni (il che non vuol dire però che l'audio venga manipolato, se non in base alle impostazioni dell'utente).
Anche per questo fu introdotto WASAPI.

Potresti ampliare questo argomento sul funzionamento di WASAPI, e spiegare come funziona esattamente, visto che mi sembra che hai già approfondito la questione ? Come interfaccia il kernel con le applicazioni e quali applicazioni interfaccia e quali no ?
Vorrei capire bene come funziona e perchè ad esempio se si riproduce un file le manipolazioni gestite da applicativi vengono disabilitati (perche come si dice in gergo "prende il controllo esclusivo") ma solo limitatamente ad alcune applicativi e non altre (ad esempio il volume e quindi credo il "mixer").
E perche invece nella riproduzione degli stream non vengono disabilitate ne le une ne le altre.

Sicuramente la domanda poteva essere posta meglio e in maniera più circostanziata, ma penso che hai capito.
Puo sembrare una cosa tecnica che magari ha piu senso su un forum di informatica che su uno di Hi-Fi, però credo che sia comunque interessante, e inoltre capire il funzionamento di qualunque cosa, aiuta sempre a capire cosa può e cosa non può fare.

Riposta veloce: semplicemente i browser NON usano WASAPI, mentre i software specialistici sì.

Puoi provare a installare Jriver come software,attivi il driver WDM e selezioni Jriver come periferica.Da li puoi gestire lo streaming con i drive che il tuo pc utilizza,Asio,Wasapi,Kernell ecc.In pratica dirotti l'audio che passa tutto su JR e ci puoi anche inserir equalizzazioni,crossover....tutto