Reference libFlac 1.3.1

già dopo i primi minuti di ascolto e dopo anche qualche ora di ascolto (che mi ha potuto confermare il tutto ancora di più) ho notato questa "strana" situazione:

il RIP dei CD tramite EAC in formato FLAC avviene per mezzo di un compressore esterno che utilizza delle librerie: le famose "Refence libFlac".
Queste librerie secondo la mia esperienza determinano la qualità finale del RIP in quanto ho notato differenze tra un CD rippato con librerie 1.2.0 o 1.2.1 (e versioni precedenti tipo 1.1.3 o 1.1.4) rispetto a un CD rippato con librerie 1.3.0 / 1.3.1.
le ho notate anche (e questa è stata un ulteriore conferma) tra file flac scaricati, anche se qui non si sa se per rippare sono stati usati settaggi uguali.

In termini sonori voglio dire che mentre le 1.3.1 riescono a far perdere praticamente niente (o comunque ha un risultato molto molto soddisfacente) al file estratto, le 1.2.0 invece non riescono e il che si tramuta in uno spazio sonoro minore con un suono che non è musicale e "completo" quanto un brano estratto con le librerie 1.3.1...
son comunque differenze a mio parere udibili e penso siano anche sufficientemente evidenti.

Voi avete esperienze in merito??

umh... le libflac servono per l'ending/decoding e la gestione dei metadati, non per il rip.... ovvero, preso uno stream pcm lo encodano in formato lossless e preso il lossless lo decodano nel formato pcm iniziale. da questo punto di vista non ci puo' essere differenza tra lo stream iniziale e quello decodato (e non c'e', provato diverse volte...)

quindi la differenza non puo' essere nella specifica funzione, quanto forse nel contorno, ovvero come il ripper si interfaccia con la libflac (ovvero una eventuale mancanza di bit perfect tra il ripper e la libflac) e il carico che questa impone sulla cpu/cache/ram che modifica la figura di rumore che il pc spara poi sulla connessione al dac (che ovviamente sara' udibile solo in riproduzione e solo con un pc non ben filtrato).

aspetta un secondo, semplifichiamo i termini, o almeno.... per quanto ho capito praticamente le libFlac servono per il decoding ovvero decodificano quanto è già stato rippato (in wav presumo da EAC come solitamente fa) e lo fanno diventare Flac... o almeno, io la sapevo così.
su questo mi pare di aver capito leggendo la tua spiegazione tecnica che stiamo dicendo la stessa cosa (anche se potrei sbagliarmi nel senso che tu intenda decoding proprio come riproduzione)
l'ultima parte della tua prima frase "e preso il lossless lo decodano nel formato pcm iniziale" non so se l'ho capita bene, nel senso che ho capito che riprendono il formato appena trasformato in flac e lo rendono pcm, ma perchè lo fanno?? per rendere digitale uno stream già digitale?? cioè... su questo non ho conoscenza tecnica purtroppo

per quanto riguarda il rumore dato dal carico della CPU il carico lo faccio diventare il minimo indispensabile nel senso che i processi/servizi inutili li arresto e termino sempre ad ogni avvio (evitando di terminare quello che non so cosa sia ). se riguarda poi quale cpu ho o hanno gli altri che rippano e che mettono i file online allora è un'altro discorso. la mia dovrebbe poter andare in scioltezza, ho un i5 3570k @3.4 ghz.
per quanto riguarda invece la riproduzione va, direi, eccelsamente a mio parere.

Cortex ha scritto:

per quanto riguarda il rumore dato dal carico della CPU il carico lo faccio diventare il minimo indispensabile nel senso che i processi/servizi inutili li arresto e termino sempre ad ogni avvio

non mi dirai che ogni volta che rippi un cd entri nel bios e arresti i processi inutili per poi riavviarli quando termini il ripping
.....ho capito male ?

Hai capito male!
Termino e arresto da task manager ;) ho un sacco di processi e servizi inutili che si avviano automaticamente all'avvio di windows, 111 processi per l'esattezza e anche servizi che non mi servono. Se devo solo ascoltare senza essere connesso a internet, tra terminare e arrestare questo e quello + l'ottimizzazione di fidelizer arrivo a 35 processi foobar mi arriva a essere stabile a 28 ms di latenza senza click e pop e il suono che ne esce mi fa essere molto contento :)
Nel bios ho disabilitato tutto ció che mi è inutile, ma li disabilitato ci rimane.

Quando rippo termino tutto l'inutile tranne le cose di rete in modo da permettere anche l'AccurateRip. Buona cosa sarebbe anche scollegare tastiera e mouse in modo da avere ancora meno dpc latency (anche per la riproduzione)

Cortex ha scritto:Hai capito male!

ah beh !  

Cortex ha scritto:
.. ho un sacco di processi e servizi inutili che si avviano automaticamente all'avvio di windows, 111 processi per l'esattezza e anche servizi che non mi servono.

pensa che su WS2012R2 ho 24 processi attivi !
( quelli inutili me li ha fatti fuori un'amico )

Sto proprio cercando quell'OS! Sistemazione con regedit, jplay o jriver poi e via... L'unica incognita è la compatibilità dei driver dell'interfaccia usb/spdif

Cortex ha scritto:aspetta un secondo, semplifichiamo i termini, o almeno.... per quanto ho capito praticamente le libFlac servono per il decoding ovvero decodificano quanto è già stato rippato (in wav presumo da EAC come solitamente fa) e lo fanno diventare Flac... o almeno, io la sapevo così.
...................

la libflac fa tre cose:
- encoding, ovvero preso uno stream in formato pcm (wav e' solo un contenitore per il pcm, ce ne sono altri) lo trasforma in uno stream compresso lossless in formato flac; questa operazione la fai una volta sola quando crei il flac;
- decoding, ovvero preso uno stream in formato compresso lossless flac lo trasforma in uno stream pcm identico all'originale; questa operazione la fai tutte le volte che riproduci un flac;
- gestione metadati.

pensa ad un gestore di file compressi come 7-Zip o simili, il concetto e' simile (encoding = compressione, decoding = decompressione). un file flac non puo' essere riprodotto direttamente, cosi' come non puoi leggere direttamente un file txt che e' stato compresso in un file zip se prima non lo decomprimi, benche' tutto il contenuto sia ancora li dentro.

la minimizzazione dei servizi e' cosa buona e giusta, il mio win7 ha praticamente solo l'essenziale     pero' io non mi riferivo a quello. quando riproduci un file flac stai usando la libflac che attraverso un algoritmo real time decoda lo stream flac in uno stream pcm. questo non lo puoi evitare. a seconda di come e' fatto questo algoritmo, usi la cpu in modo differente. la mia ipotesi era che e' proprio il differente algoritmo presente nelle diverse libreire a generare un differente "rumore" sul pc e questo si ripercuote sulla riproduzione. ovviamente (e ribadisco: ovviamente) e' solo un problema elettrico, un pc molto ben isolato e un dac molto ben isolato sono immuni a questo.

domanda 'gnurante: anche quando carichi prima i brani sulla ram usi la cpu per il decoding durante la riproduzione appena successiva?
voglio dire, l'uso della cpu per il decoding avviene durante il caricamento nella ram o continua anche durante la riproduzione?
parlo di solo decoding, non di uso della cpu per altre cose

dipende da come e' fatto il player.....

ad esempio foobar ha due aree di memoria distinte che usa in modo diverso.
la prima e' un file buffer, ovvero carica il file da disco in ram ma il file resta nel formato originale (flac, mp3, etc..). puoi dire a foobar di caricare l'intero file in ram prima di avviare l'esecuzione, in modo da non avere accessi al disco durante la riproduzione. questa area di file buffering e' definita in termini di spazio allocabile, ovvero MB di ram massimi utilizzabili.
la seconda area e' in realta' uno staging (o meglio una coda fifo) in cui foobar appoggia lo stream pcm decodato per applicarci eventuali elaborazioni (volume, filtri, etc..) e poi costruire il pacchetto da mandare al dac. questa area e' definita in termini di ms, perche' essendo una coda avrai anche una latenza in-out definita dalla lunghezza della stessa (cosa del tutto indifferente se parliamo di un player casalingo, ma se parliamo di un player usato in modo pro il ritardo tra quando applico un effetto e la sua effettiva implementazione e' importante, pensiamo al controllo di volume ad esempio)

per cui in questo caso l'uso della cpu per il decoding e' continuo a prescindere dall'uso del full file buffering.

altri player possono avere implementazioni diverse a seconda delle convinzioni del progettista. IMHO l'architettura di foobar e' ottimale perche' consente di caricare in ram tutto il brano anche quando e' molto grande (ovvero, non carica tutto l'album, ma solo il singolo brano in esecuzione) e poi con un po' di esperienza si puo' impostare di fino l'area in ms in modo da avere la migliore riproduzione. la contropartita e' che e' alquanto complicato azzeccare a orecchio tale setting..........

Come sempre la tua competenza è di livello superiore :) ti ringrazio moltissimo per la spiegazione limpida :) ora è più chiaro il tutto... Mi resta sempre il fatto peró che l'encoding lo fai solo la prima volta e se le librerie non fossero il massimo o al massimo della loro ottimizzazione alla fine si andrebbe sempre ad avere in decoding un file che non è stato codificato come dovrebbe la prima volta o comunque non in maniera ottimale come se fosse stato ottimizzato con delle librerie fatte a dovere... No?? Alla fine se vado a decodificare un brano codificato in maniera non ottimale la cpu fa sempre comunque più fatica o comunque non viene magari decodificato velocemente quanto lo stesso brano codificato con una libreria migliore...

Interessante anche la spiegazione sul funzionamento di foobar! Anche jplay dovrebbe essere circa simile come caricamente in ram del singolo brano se non sbaglio... poi come dici tu a sempre da filosofia a filosofia il funzionamento.
Per gli ms credevo che il minor numero andasse a influire più positivamente a livello di assenza di click e pop, invece non è così penso a causa della magari piccola instabilità del sistema che ci puó essere probabilmente... Adesso faccio gli esperimenti

phaeton ha scritto:dipende da come e' fatto il player.....

ad esempio foobar ha due aree di memoria distinte che usa in modo diverso.
la prima e' un file buffer, ovvero carica il file da disco in ram ma il file resta nel formato originale (flac, mp3, etc..). puoi dire a foobar di caricare l'intero file in ram prima di avviare l'esecuzione, in modo da non avere accessi al disco durante la riproduzione. questa area di file buffering e' definita in termini di spazio allocabile, ovvero MB di ram massimi utilizzabili.
la seconda area e' in realta' uno staging (o meglio una coda fifo) in cui foobar appoggia lo stream pcm decodato per applicarci eventuali elaborazioni (volume, filtri, etc..) e poi costruire il pacchetto da mandare al dac. questa area e' definita in termini di ms, perche' essendo una coda avrai anche una latenza in-out definita dalla lunghezza della stessa (cosa del tutto indifferente se parliamo di un player casalingo, ma se parliamo di un player usato in modo pro il ritardo tra quando applico un effetto e la sua effettiva implementazione e' importante, pensiamo al controllo di volume ad esempio)

per cui in questo caso l'uso della cpu per il decoding e' continuo a prescindere dall'uso del full file buffering.

altri player possono avere implementazioni diverse a seconda delle convinzioni del progettista. IMHO l'architettura di foobar e' ottimale perche' consente di caricare in ram tutto il brano anche quando e' molto grande (ovvero, non carica tutto l'album, ma solo il singolo brano in esecuzione) e poi con un po' di esperienza si puo' impostare di fino l'area in ms in modo da avere la migliore riproduzione. la contropartita e' che e' alquanto complicato azzeccare a orecchio tale setting..........

Grazie Phaeton per la spiegazione, come sempre esauriente, tecnica e perciò abbastanza chiara...oscura. scherzo , molto interessante.

Cortex, tu ed io abbiamo da studia' parecchio se vogliamo un buon voto in questo esame...

Bisogna fare i compiti a casa un pó di nerdismo googleiano non puó che fare bene se seguono anche test pratici

Cortex ha scritto:
...
se le librerie non fossero il massimo o al massimo della loro ottimizzazione alla fine si andrebbe sempre ad avere in decoding un file che non è stato codificato come dovrebbe la prima volta o comunque non in maniera ottimale come se fosse stato ottimizzato con delle librerie fatte a dovere... No??

cosa ci stai dicendo?
che dovrei rippare nuovamente tutti quei cd fatti pochi anni fa con una versione diversa di EAC???  

Cortex ha scritto:
...
Interessante anche la spiegazione sul funzionamento di foobar! Anche jplay dovrebbe essere circa simile come caricamente in ram del singolo brano se non sbaglio... poi come dici tu a sempre da filosofia a filosofia il funzionamento.
...

in bocca al lupo con jplay, soprattutto nella modalità più tosta (come si chiamava...hibernate?)-
dalle prove che avevo fatto era meglio con due pc (control+audio), ma via cavo, che in wifi  

Non con una nuova versione di EAC u.u con le librerie nuove ;) ma magari anche EAC aggiornato potrebbe fare la differenza ;D la mia fortuna è che di CD ne ho relativamente pochi per il momento eheheh
Poi we magari sono io che svalvolo... Prova a rippare con librerie diverse, dimmi se senti la differenza come la sento io :)


Con jplay mi interessava proprio quella modalità, sembra molto interessante... La prova e il soprattutto il download della versione di prova devo ancora farlo...
La modalità a 2 pc ho letto cosa faceva velocemente, ma non avendo 2 pc (o meglio li ho, ma non penso che un fisso si vada ad interfacciare con un portatile, anche se magari in ethernet cross ce la si fa, ma rimarrebbero 2 pc molto diversi, non so bene la cosa come sia) non posso provarla anche se sarebbe interessante
Vado a leggere bene va la

Cortex ha scritto:
...
non penso che un fisso si vada ad interfacciare con un portatile, anche se magari in ethernet cross ce la si fa
...

con l'incrociato si