Hqplayer

bibo01 ha scritto:...Quella software può essere sviluppata in due maniere principali: tramite compilazione o tramite tweaks.
La prima permette al player di interagire con l'OS in maniera particolare, pur rimanendo bit perfect - vedi XXHighEnd, JPlay, MQN...
La seconda corrisponde in buona parte allo snellimento dei servizi inutili - vedi AO, Fidelizer, CAD script...

Ciao, non sono sicuro di aver capito bene a cosa ti riferisci, per mia esperienza e per sommi capi le cose stanno così (non solo per l'audio):

1. alcune cose riesci a farle 'semplicemente' operando sui parametri di configurazione - più o meno esposti chiaramente - dello specifico S.O. e probabilmente ti riferisci a questo quando parli di "snellimento dei servizi inutili" e "tweaks".

2. In altri casi - mi risulta solo in linux, ma potrei sbaglire - operi più in profondità ed a volte si rende necessario il build per abilitare/disabilitare funzionalità diverse da quelle previste in origine, in pratica è quello che fanno i 'gestori' delle diverse distro.

3. In casi più estremi, si può arrivare alla modifica del codice sorgente e quindi si deve effettivamente ricompilare, in pratica è un opzione solo per Linux e ove le politiche di distribuzione (licensing) lo consentano.

Questa ultima pratica, tranne che per scopi ludici o educativi, ritengo però sia certamente fuori portata per "persone normali" non solo e non tanto per competenze e capacità, ma perchè il 'ciclo di vita' di una componente software di base come quelle di cui stiamo parlando richiede uno sforzo di gestione che certamente trascende le possibilità di un hobbista e - temo - ormai anche quelle di una piccola organizzazione.

E' un aspetto spesso sottovalutato, ma fondamentale, prima causa di abbandono e morte prematura di tantissimi progetti molto promettenti.

4. Fare il 'porting' da una piattaforma hw ad un'altra comporta la necessità di ricompilare, ma credo tu non ti riferisca a questo caso.

Non conosco nel dettaglio tutte le soluzioni che riporti, ma non mi risulta che installando Jplay (windows) tu debba ricompilare alcunchè.

Forse ho capito male io.

Marco

marcoc1712 ha scritto:

Ciao, non sono sicuro di aver capito bene a cosa ti riferisci, per mia esperienza e per sommi capi le cose stanno così (non solo per l'audio):

1. alcune cose riesci a farle 'semplicemente' operando sui parametri di configurazione - più o meno esposti chiaramente - dello specifico S.O. e probabilmente ti riferisci a questo quando parli di "snellimento dei servizi inutili" e "tweaks".

2. In altri casi - mi risulta solo in linux, ma potrei sbaglire - operi più in profondità ed a volte si rende necessario il build per abilitare/disabilitare funzionalità diverse da quelle previste in origine, in pratica è quello che fanno i 'gestori' delle diverse distro.

3. In casi più estremi, si può arrivare alla modifica del codice sorgente e quindi si deve effettivamente ricompilare, in pratica è un opzione solo per Linux e ove le politiche di distribuzione (licensing) lo consentano.

Questa ultima pratica, tranne che per scopi ludici o educativi, ritengo però sia certamente fuori portata per "persone normali" non solo e non tanto per competenze e capacità, ma perchè il 'ciclo di vita' di una componente software di base come quelle di cui stiamo parlando richiede uno sforzo di gestione che certamente trascende le possibilità di un hobbista e - temo - ormai anche quelle di una piccola organizzazione.

E' un aspetto spesso sottovalutato, ma fondamentale, prima causa di abbandono e morte prematura di tantissimi progetti molto promettenti.

4. Fare il 'porting' da una piattaforma hw ad un'altra comporta la necessità di ricompilare, ma credo tu non ti riferisca a questo caso.

Non conosco nel dettaglio tutte le soluzioni che riporti, ma non mi risulta che installando Jplay (windows) tu debba ricompilare alcunchè.

Forse ho capito male io.

Marco

La compilazione a cui mi riferisco sopra non è relativa a nuove versioni dell'OS (quindi non a Linux), bensì del player stesso che inserisce al proprio interno dei "tricks" particolari. Ad esempio, lavorare su porzioni di RAM congiunta, non frammentata.

RockOnlyRare ha scritto:

Ho letto la presentazione che hai fatto su cMP2 che risale al "lontano" 2011, tre anni e passa sono un eternità su un campo relativamente nuovo.
Adesso secondo te quale la soluzione (ambito windows) più addidabile , io ho hqplayer + cubox,  e che accorgimenti conviene usare per ottenere il meglio (es alimentatore esterno per il cubox etc etc)....
Grazie

Sei già a buon punto, soprattutto se ti trovi bene con HQPlayer. Dipende molto dalle tue possibilità di configurazione della rete, dalle tue abitudini ed esigenze. Puoi mettere PC+router+HD/NAS in un'altra stanza, lavorare in remote verso il PC (anche in wi-fi), mettere un piccolo ali lineare per il cubox, isolare la presa del cubox da quella del DAC.

PS: iniziai ad usare cMP2 nel 2008 :)

RockOnlyRare ha scritto:

Che accorgimenti consigli per ottenere il miglior "compromesso" , perchè alla fine si cerca sempre di trovare la soluzione migliore limitamente ai nostri mezzi...

Senza andare su cose estreme e costose alimentazioni lineari, a parte spostare PC+router+HD/NAS in un'altra stanza (come spiegato sopra), proverei le CAD script che sono delle semplici ottimizzazioni del SO.

bibo01 ha scritto:
La compilazione a cui mi riferisco sopra non è relativa a nuove versioni dell'OS (quindi non a Linux), bensì del player stesso che inserisce al proprio interno dei "tricks" particolari. Ad esempio, lavorare su porzioni di RAM congiunta, non frammentata.

Ah, mi pareva strano. Continua a sfuggirmi in che senso è la compilazione e non il codice 'in se' (quindi il lavoro del programmatore) a permettere questo. Ti riferisci a qualche particolare parametro uilizzato in fase di link? In che modo è un'opzione disponibile per prodotti commerciali come JPlay?

Grazie.

marcoc1712 ha scritto:

Ah, mi pareva strano. Continua a sfuggirmi in che senso è la compilazione e non il codice 'in se' (quindi il lavoro del programmatore) a permettere questo. Ti riferisci a qualche particolare parametro uilizzato in fase di link?  In che modo è un'opzione disponibile per prodotti commerciali come JPlay?

Grazie.

A volte sono presenti dei parametri particolari, come in XXHighEnd, a volte sono nel codice del programma stesso, come in JPlay. Ovviamente quasi mai il programmatore dice esattamente cosa fa.

Riguardo l'isolamento tra PC e DAC, questo prodotto di prossima uscita sarà a mio avviso abbastanza interessante: Uptone Audio Regen

Per un discorso generale sull'isolamento il terzo post di John Swenson, progettista di TI, è utile da leggere.

bibo01 ha scritto:
Sei già a buon punto, soprattutto se ti trovi bene con HQPlayer. Dipende molto dalle tue possibilità di configurazione della rete, dalle tue abitudini ed esigenze. Puoi mettere PC+router+HD/NAS in un'altra stanza, lavorare in remote verso il PC (anche in wi-fi), mettere un piccolo ali lineare per il cubox, isolare la presa del cubox da quella del DAC.

PS: iniziai ad usare cMP2 nel 2008 :)


Senza andare su cose estreme e costose alimentazioni lineari, a parte spostare PC+router+HD/NAS in un'altra stanza (come spiegato sopra), proverei le CAD script che sono delle semplici ottimizzazioni del SO.

Grazie e complimenti, io nel 2008 avevo solo mp3 (riservandomi di prendere il supporto fisico per i lavori che ne valevano la pena) e non avrei mai pensato alla liquida come sorgente "principe" per l'hi-fi

In merito agli accorgimenti, alcuni li ho già fatti, come Nas in un'altra stanza, DAC e cubox sono su due linee diverse, il router in realtà è in un'altra stanza ma c'è un hub di rete a cui sono collegati tutti gli apparecchi in sala, per cui penso che "non conti"... Però l'hub usa una presa di corrente diversa sia da quella del pc che dell'impianto (quindi DAC, che sono tutti collegati ad una "ciabatta" Einstein The octopus che dovrebbe garantire un buon isolamento dal resto dell'impianto.

Il dubbio potrebbe essere se conviene collegare al "The octopus" al limite anche l'alimentatore del cubox (che penso prenderò tra poco). (PC e hub no perchè li uso anche con lo stereo spento).

Per cui il solo limite, per poter pilotare il player, è che ho la necessità di avere il pc nella stanza dove si trova l'impianto.
Dispongo anche del wi-fi, ma non è indicato per la trasmissione dei dati, troppo lenta rispetto alla gigabyte via cavo.

Qualche ulteriore "dritta" ?

bibo01 ha scritto:
A volte sono presenti dei parametri particolari, come in XXHighEnd, a volte sono nel codice del programma stesso, come in JPlay. Ovviamente quasi mai il programmatore dice esattamente cosa fa.

Ok, tutto quanto è nel codice... è nel codice, se è open source lo vedi, puoi interpretarlo e decidere di modificarlo (...in teoria...) se è proprietario no.

XXHighEnd, ha dei parametri che puoi settare in fase di link e lo puoi fare tu (come utente) a partire dal codice assembler/oggetto? Strana pratica.

marcoc1712 ha scritto:

Ok, tutto quanto è nel codice... è nel codice, se è open source lo vedi, puoi interpretarlo e decidere di modificarlo (...in teoria...) se è proprietario no.

XXHighEnd, ha dei parametri che puoi settare in fase di link e lo puoi fare tu (come utente) a partire dal codice assembler/oggetto? Strana pratica.

Non mi sono spiegato bene...
Ovviamente tutti i programmi commerciale hanno le loro caratteristiche nascoste nel codice.
JPlay non ti dà la possibilità di ritoccare alcuni parametri. Avviene tutto under the hood.
XXHighEnd ha dei parametri impostabili dall'utente che variano l'effetto sonoro a valle pur rimanendo bit perfect.

bibo01 ha scritto:
Non mi sono spiegato bene...
Ovviamente tutti i programmi commerciale hanno le loro caratteristiche nascoste nel codice.
JPlay non ti dà la possibilità di ritoccare alcuni parametri. Avviene tutto under the hood.
XXHighEnd ha dei parametri impostabili dall'utente che variano l'effetto sonoro a valle pur rimanendo bit perfect.

Ah, adesso mi torna:

XXHighEnd - come altri - mette a disposizione dei parametri (o entry point) per modificare il proprio comportamento run time (nel mio primo post li ho classificati al punto 1), mentre JPlay no.

In nessun caso ci sono opzioni di 'tweaking' per l'utente in fase di 'compilazione' ero stato tratto in inganno dalla tua distinzione iniziale.

In fin dei conti si tratta di tecniche: la prima consente all'utente maggiore libertà, la seconda è 'chiusa' ed accessibile solo allo sviluppatore, che per i prodotti commerciali equivale al proprietario.

Dal punto di vista degli effetti però cambia poco o nulla, ammeso che la funzionalità sia implementata correttamente in entrambi i casi.

bibo01 ha scritto:Riguardo l'isolamento tra PC e DAC, questo prodotto di prossima uscita sarà a mio avviso abbastanza interessante: Uptone Audio Regen

Per un discorso generale sull'isolamento il terzo post di John Swenson, progettista di TI, è utile da leggere.

Curioso, sto leggendo proprio adesso su altri forum alcune considerazioni di John Swenson, che oltre ad essere un progettista per TI è anche un free lance che progetta e realizza DAC per molti marchi hi End ed io ho conosciuto (nel senso che ci siamo scambiati qualche messaggio via forum - disclaimer - ) nel corso del progetto per la realizzazione di un sostituto per lo SqueezeBox 'certificato' dalla community. Lui stava progettando il DAC come doughter board della wandboard, selezionata come hw.

Purtroppo il progetto in se è naufragato per problemi legali, credo però che John stia proseguendo con l'HW, anche se non sono molto informato (non comprerò una wanboard, comunque).

Credo che abbia il grande merito di aver dato un supporto 'razionale' (ed a suo avviso anche misurabile) alla possibile influenza dell'hw, s.o. e sw. sul lavoro del dac anche in presenza di stream rigorosamente bit perfect.

Non è l'unico, certamente riprende il lavoro di altri (è normale) ma il suo più grande pregio è l'understatement che sempre usa, che fa sembrare naturali ed ovvie teorie altrimenti molto dibattute (per usare un eufemismo).

Lo seguo con attenzione e se ne fossi capace proverei a realizzare un DAC su sue specifiche, ma con le mani...

Se ti ricordi della mia ricerca 'dall'altra parte' è stata in buona misura stimolata - per analogia - proprio da alcune sue considerazioni.

mi guarderò Uptone Audio Regen.

Ciao

marcoc1712 ha scritto:


Curioso, sto leggendo proprio adesso su altri forum alcune considerazioni di John Swenson, che oltre ad essere un progettista per TI è anche un free lance che progetta e realizza DAC per molti marchi hi End ed io ho conosciuto (nel senso che ci siamo scambiati qualche messaggio via forum - disclaimer - ) nel corso del progetto per la realizzazione di un sostituto per lo SqueezeBox 'certificato' dalla community. Lui stava progettando il DAC come doughter board della wandboard, selezionata come hw.

Purtroppo il progetto in se è naufragato per problemi legali, credo però che John stia proseguendo con l'HW, anche se non sono molto informato (non comprerò una wanboard, comunque).

Credo che abbia il grande merito di aver dato un supporto 'razionale' (ed a suo avviso anche misurabile) alla possibile influenza dell'hw, s.o. e sw. sul lavoro del dac anche in presenza di stream rigorosamente bit perfect.

Non è l'unico, certamente riprende il lavoro di altri (è normale) ma il suo più grande pregio è l'understatement che sempre usa, che fa sembrare naturali ed ovvie teorie altrimenti molto dibattute (per usare un eufemismo).

Lo seguo con attenzione e se ne fossi capace proverei a realizzare un DAC su sue specifiche, ma con le mani...

Se ti ricordi della mia ricerca 'dall'altra parte' è stata in buona misura stimolata - per analogia - proprio da alcune sue considerazioni.

mi guarderò Uptone Audio Regen.

Ciao

Complimenti

RockOnlyRare ha scritto:

Complimenti

De che...


Piccolo OT a cui non dare seguito qui:

Se vuoi farti un'idea di come era difficile nel 2009 far passare l'idea che a parità di DAC il transport o altro potessero generare differenze, dai un'occhiata a questo post, che ho ritrovato dato che ho visto qualcun'altro tirare in ballo ADM nella disputa JPLAY/JRIVER.

[URL="http://forums.slimdevices.com/showthread.php?71321-Sound-quality-between-wav-and-flac/page13"]http://forums.slimdevices.com/showthread.php?71321-Sound-quality-between-wav-and-flac/page13[/URL]

Qui eravamo Io, John e pochi altri a sostenere di sentire - ERESIA - differenze tra flac e wav, ipotizzando che potessero dipendere da 'carichi' del player, dato che è evidente che all'ingresso del dac sono identici in termini di bit.

Secondo me è stata una discussione interessante e produttiva, al di là dei toni, mi spiace solo che le vicissitudini in casa Logitech ed altro abbiano interrotto la discussione proprio sul più bello.

Per fortuna oggi è (spesso) più semplice affrontare questi temi con mente più aperta ed in alcuni casi si trovano pure soluzioni!

Ciao e buon Natale.

marcoc1712 ha scritto:

De che...


Piccolo OT a cui non dare seguito qui:

Se vuoi farti un'idea di come era difficile nel 2009 far passare l'idea che a parità di DAC il transport o altro potessero generare differenze, dai un'occhiata a questo post, che ho ritrovato dato che ho visto qualcun'altro tirare in ballo ADM nella disputa JPLAY/JRIVER.

http://forums.slimdevices.com/showthread.php?71321-Sound-quality-between-wav-and-flac/page13

Qui eravamo Io, John e pochi altri a sostenere di sentire - ERESIA - differenze tra flac e wav, ipotizzando che potessero dipendere da 'carichi' del player, dato che è evidente che all'ingresso del dac sono identici in termini di bit.

Secondo me è stata una discussione interessante e produttiva, al di là dei toni,  mi spiace solo che le vicissitudini in casa Logitech ed altro abbiano interrotto la discussione proprio sul più bello.

Per fortuna oggi è (spesso) più semplice affrontare questi temi con mente più aperta ed in alcuni casi si trovano pure soluzioni!

Ciao e buon Natale.

Non ho tempo per leggere tutta la discussione, ma secondo te i problemi erano legati allo "scompattamento" del FLAC rispetto al wav che è in formato non compresso ? C'e di buono che oggi l'hardware si è evoluto in modo pazzesco, il collo di bottiglia sono casomai le reti e la velocità di lettura (in certe situazioni).

RockOnlyRare ha scritto:
Non ho tempo per leggere tutta la discussione, ma secondo te i problemi erano legati allo "scompattamento" del FLAC rispetto al wav che è in formato non compresso ? C'e di buono che oggi l'hardware si è evoluto in modo pazzesco, il collo di bottiglia sono casomai le reti e la velocità di lettura (in certe situazioni).

Ricostruire la storia completa prenderebbe molto tempo, di fatto nel tempo altre persone hanno continuato a segnalare tali differenze mentre qualche 'modifica' al firmware ed al motore di conversione sul server è stata apportata, il che a mio avviso è segno che qualcosa da sistemare potenzialmente c'era.

Quello che mi lascia perplesso è che sia 6 anni fa che oggi vengono utilizzate misure con ADM per 'demolire' la possibilità che differenze ci siano, mentre per me rimane chiaro che ADM non dimostra alcunchè, tranne che gli stream sono effettivamente bit perfect, dato che in condizioni 'reali' registra defferenze anche riproducendo files identici.

Il fatto che sincronizzando i due clock (cosa impossibile in fase di riproduzione e comunque non messa in evidenza nell'attuale disputa vs. JPlay) tali differenze si riducano enormemente rende solo chiaro che tali differenze hanno dominio nella gestione del clock, quindi si tratta di jitter... Ma c'era realmente bisogno di dimostrarlo?

Marco.

marcoc1712 ha scritto:

Ricostruire la storia completa prenderebbe molto tempo, di fatto nel tempo altre persone hanno continuato a segnalare tali differenze mentre qualche 'modifica' al firmware ed al motore di conversione sul server è stata apportata, il che a mio avviso è segno che qualcosa da sistemare potenzialmente c'era.

Quello che mi lascia perplesso è che sia 6 anni fa che oggi vengono utilizzate misure con ADM per 'demolire' la possibilità che differenze ci siano, mentre per me rimane chiaro che ADM non dimostra alcunchè, tranne che gli stream sono effettivamente bit perfect, dato che in condizioni 'reali' registra defferenze anche riproducendo files identici.

Il fatto che sincronizzando i due clock (cosa impossibile in fase di riproduzione e comunque non messa in evidenza nell'attuale disputa vs. JPlay) tali differenze si riducano enormemente rende solo chiaro che tali differenze hanno dominio nella gestione del clock, quindi si tratta di jitter... Ma c'era realmente bisogno di dimostrarlo?

Marco.

Grazie per le spiegazioni . Se ho capito bene, in teoria è possibile che causa jitter un flac possa "suonare" in modo leggermente differente dal wav ?
Eppure il flac è lo standard attuale usato da gran parte dei siti che vendono files in hires, ed in pratica dalla stragrande maggioranza degli utenti che usano il lossless.

Si possono trovare analogie sulla diatriba per cui si senta meglio un cd originale o il file lossless (wav o flac) estratto dallo stesso al 100% di qualità, per cui il cd risentrebbe del controllo degli errori mentre il file estratto potrebbe non essere identico al 100%....
Tu su questo aspetto che posizione hai ?

No e per favore non riapriamo la polemica sui formati audio.

Quello che io ho sperimentato è che il contenuto in BIT all'ingresso del dac non varia per le versioni WAV o FLAC dello stesso brano musicale, sia che la conversione venga fatta sul server che sul player, quindi si tratta certamente di un formato lossless bit perfect. A qualcuno basta questo per chiudere la partita, ad altri no.

Io non sono in grado di determinare perchè, ma sul mio impianto di allora sentivo differenze e come me, anche altri, molto più qualificate di me (es. John S.).

Dato che se lo stream è uguale per contenuto di bit, l'unica differenza può originarsi nel dominio temporale, prendendo il nome di jitter. Si ipotizzava si trattasse dell'effetto del diverso carico di CPU o di fattori analoghi, quali la rete, che mediante modulazione del PS interferissero con il lavoro del clock interno e/o di quello del dac collegato, originando jitter, che non è lontano da quanto è sostenuto oggi per molti altri fattori. Credo che questa prima 'intuizione' abbia contribuito a formulare la teoria del jitter generato da software che John ha poi compiutamente formulato in seguito.

Nello specifico di SB, ci fu un successivo rilascio di software che risolse (in parte) il problema, non so intervenendo su quali fattori, ma credo proprio ci fosse un 'bug' del sistema in se, se non ricordo male legato ad un eccessivo guadagno e quindi a saturazione.

Flac è uno standard di fatto per il rilascio di file in alta definizione e tranne che per Apple (e non è un distinguo piccolo, visto che comunque 'domina' almeno l'80% del mercato, mentre almeno un altro 18% è in MP3 da altri siti).

Il motivo va probabilmente cercato in alcune sue caratteristiche vincenti, tra le quali:

1. sicuramente lossless.
2. open source
3. efficiente
4. supporta bene i TAG ed anche i .cue files


Io, per i ben noti motivi di minimizzare il carico, NON faccio eseguire la decodifica al rendererer (NAA).

Stabilire se un CD è stato rippato correttamente è banale se possiedi il CD, molto facile anche se non ce l'hai. I primi CD player (1984-5) avevano un led rosso che segnalava gli errori, è stato tolto perchè le persone si lamentavano di quanto spesso si accendesse...

Se hai fatto il rip di un numero significativo di CD, sai che succede che alcuni siano 'ostici' ed impieghino più tempo ad essere rippati accuratamente da EAC, proprio perchè non fa intervenire la correzione di errore ma prova a leggere più volte fino a che non ottiene un numero statisticamente sicuro di letture uguali, altri proprio non riesce a ripparli senza errori...

Detto questo, che sembrerebbe giocare a favore dei files, non sono sicuro di non preferire il suono del mio 'vecchio' TEAC VRDS-10 + Audio Research DAC 1-20 per qualche aspetto minore, ma qui temo entrino in gioco fattori anche emozionali. Se mettiamo in campo altri aspetti e potenzialità, non c'è partita.

p.s.

In realtà, se ho voglia di 'complicarmi la vita' vado direttamente di vinile, il CD è ancora li e collegato, ma suona realmente MOLTO raramente.

p.p.s.

La tua domanda mi ha fatto riflettere su come mai si discute tanto animatamente della potenziale differenza tra trasporti 'liquidi' mentre è accettata la differenza tra meccaniche CD, oltre al fatto che uno dei punti di forza del VRDS-10 era l'isolamento dalle vibrazioni, che invece è la cenerentola nei transport attuali, spesso leggeri e rigidi oltre misura.

Quello delle vibrazioni è un tralo che mi rode da un po.

Ciao.

Ad essere sincero, ho smesso di farmi tante domande: se qualcosa suona meglio per le mie orecchie non mi interessano i motivi. Spendo gia' troppo tempo dietro a bit, cazzi e mazzi durante la giornata
Per le mie orecchie, lo stesso oggetto (il SOtM SMS 100) usato come SB renderer, DLNA renderer e HQPlayer NAA renderer non suona allo stesso modo. Qualche post piu' su ho scritto che persino usato senza filtri, dithering etc etc HQPlayer suona meglio, di poco, della configurazione con DLNA, Jriver a fare da server e SOtM a fare da renderer.
Usato con SB suona in maniera pure diversa, ma potrebbe dipendee dalla configurazione, non sono esperto e mi interessava poco indagare.
Non ci dovrebbero essere differenze, il file lossless e' sempre decodoficato sul server, eppure non suonano uguali. Di piu nin zo e non voglio sapere

realmassy ha scritto:Ad essere sincero, ho smesso di farmi tante domande... Di piu nin zo e non voglio sapere

Io non ci riesco e non solo in campo audio.

Ciao e bune feste.

marcoc1712 ha scritto:No e per favore non riapriamo la polemica sui formati audio.

Quello che io ho sperimentato è che il contenuto in BIT all'ingresso del dac non varia per le versioni WAV o FLAC dello stesso brano musicale, sia che la conversione venga fatta sul server che sul player, quindi si tratta certamente di un formato lossless bit perfect. A qualcuno basta questo per chiudere la partita, ad altri no.

Io non sono in grado di determinare perchè, ma sul mio impianto di allora sentivo differenze e come me, anche altri, molto più qualificate di me (es. John S.).

Dato che se lo stream è uguale per contenuto di bit, l'unica differenza può originarsi nel dominio temporale,  prendendo il nome di jitter. Si ipotizzava si trattasse dell'effetto del diverso carico di CPU o di fattori analoghi, quali la rete,  che mediante modulazione del PS interferissero con il lavoro del clock interno e/o di quello del dac collegato, originando jitter, che non è lontano da quanto è sostenuto oggi per molti altri fattori. Credo che questa prima 'intuizione' abbia contribuito a formulare la teoria del jitter generato da software che John ha poi compiutamente formulato in seguito.

Nello specifico di SB, ci fu un successivo rilascio di software che risolse (in parte) il problema, non so intervenendo su quali fattori, ma credo proprio ci fosse un 'bug' del sistema in se, se non ricordo male legato ad un eccessivo guadagno e quindi a saturazione.

Flac è uno standard di fatto per il rilascio di file in alta definizione e tranne che per Apple (e non è un distinguo piccolo, visto che comunque 'domina' almeno l'80% del mercato, mentre almeno un altro 18% è in MP3 da altri siti).

Il motivo va probabilmente cercato in alcune sue caratteristiche vincenti, tra le quali:

1. sicuramente lossless.
2. open source
3. efficiente
4. supporta bene i TAG ed anche i .cue files


Io, per i ben noti motivi di  minimizzare il carico, NON faccio eseguire la decodifica al rendererer (NAA).

Stabilire se un CD è stato rippato correttamente è banale se possiedi il CD, molto facile anche se non ce l'hai. I primi CD player (1984-5) avevano un led rosso che segnalava gli errori, è stato tolto perchè le persone si lamentavano di quanto spesso si accendesse...

Se hai fatto il rip di un numero significativo di CD, sai che succede che alcuni siano 'ostici' ed impieghino più tempo ad essere rippati accuratamente da EAC, proprio perchè non fa intervenire la correzione di errore ma prova a leggere più volte fino a che non ottiene un numero statisticamente sicuro di letture uguali, altri proprio non riesce a ripparli senza errori...

Detto questo, che sembrerebbe giocare a favore dei files, non sono sicuro di non preferire il suono del mio 'vecchio' TEAC VRDS-10 + Audio Research DAC 1-20 per qualche aspetto minore, ma qui temo entrino in gioco fattori anche emozionali. Se mettiamo in campo altri aspetti e potenzialità, non c'è partita.

p.s.

In realtà, se ho voglia di 'complicarmi la vita' vado direttamente di vinile, il CD è ancora li e collegato, ma suona realmente MOLTO raramente.

p.p.s.

La tua domanda mi ha fatto riflettere su come mai si discute tanto animatamente della potenziale differenza tra trasporti 'liquidi' mentre è accettata la differenza tra meccaniche CD, oltre al fatto che uno dei punti di forza del VRDS-10 era l'isolamento dalle vibrazioni, che invece è la cenerentola nei transport attuali, spesso leggeri e rigidi oltre misura.

Quello delle vibrazioni è un tralo che mi rode da un po.

Ciao.

Ancora una volta grazie mille per le esaurienti risposte e la pazienza che hai....

Ho cercato con il tempo, essendo appassionato di vinili da lunghissima data e quindi poi anche di cd, di mantenere dal punto di vista qualitativo, il più possibile equilibrate le tre fonti musicali, intendendo come terza ovviamente il formato liquido.
Forse il punto di forza del mio impianto è proprio nella meccanica CD "La Diva", prodotto molto recente e particolarmente curato e performante anche grazie ad una connessione proproetaria con il DAC (La Voce S2, pure lui Acoustic Quality)
Ecco perchè non sono interessato più di tanto trasformare la mia collezione di cd in FLAC (senza contare che essendo circa 1500 ci vorrebbero mesi se non anni....) , per cui mi limito a farli sono con gli ultimi acquisti (se ne vale la pena) e quelli che reputo i migliori per poterli "portare in giro" in un hd o che mi richiedono gli amici.
Infine come sappiamo bene, un sacco di album di rock ( o loroo rimasterizzazionI) non sono certo il massimo dal punto di vista audiofilo, per cui cd, flac vinile, hires, sempre male si sentono perchè il problema è alla radice...

Da vari ascolti e confronti sul mio impianto, devo dire che per me è davvero una bella lotta stabilire cosa suoni meglio.... la differenza è così sfumata che non mi spinge a convertire i cd.

realmassy ha scritto:Ad essere sincero, ho smesso di farmi tante domande: se qualcosa suona meglio per le mie orecchie non mi interessano i motivi. Spendo gia' troppo tempo dietro a bit, cazzi e mazzi durante la giornata
Per le mie orecchie, lo stesso oggetto (il SOtM SMS 100) usato come SB renderer, DLNA renderer e HQPlayer NAA renderer non suona allo stesso modo. Qualche post piu' su ho scritto che persino usato senza filtri, dithering etc etc HQPlayer suona meglio, di poco, della configurazione con DLNA, Jriver a fare da server e SOtM a fare da renderer.
Usato con SB suona in maniera pure diversa, ma potrebbe dipendee dalla configurazione, non sono esperto e mi interessava poco indagare.
Non ci dovrebbero essere differenze, il file lossless e' sempre decodoficato sul server, eppure non suonano uguali. Di piu nin zo e non voglio sapere

Beh diciamo che lo scopo finale è ascoltare quello che suona in modo più soddisfacente, poi è chiaro che se riesci a scoprirne la causa, è sempre meglio ed in questo il Gazebo è molto bello !!

Quando ero dentro il mondo hi-fi (ho anche collaborato con un negozio per un paio di anni), fine anni 70, me ne intendevo infinitamente più di adesso, per passione, interesse ed anche portafoglio, è assurdo pensare che a 25 anni avevo una disponibilità economica che oggi a 60 neppure me la posso immaginare !!!!!

RockOnlyRare ha scritto:C'e di buono che oggi l'hardware si è evoluto in modo pazzesco, il collo di bottiglia sono casomai le reti e la velocità di lettura (in certe situazioni).

Solo parzialmente daccordo. In configurazioni com HQP il server prende forse beneficio dal poter usare hw più potente, certamente come NAA/Renderer stiamo utilizzando generalmente hw meno potente per scelta. In architetture SB, un Duet non è molto diverso da un Cubox nemmeno come consumo energetico.

Credo invece che - proprio grazie alle richieste di mercato alimentate dal consumo domestico di materiale multimediale (di cui noi rappresentiamo la nicchia nella nicchia 'stereo') - le tecnologie di rete siano molto maturate e soprattutto diventate di utilizzo generale.

Nel 2009 Esisteva già Ethernet 1Gb, ma era praticamente riservata ai datacenter, Wifi era 'b' 11 Mbit/s, oggi è 'ac': 500 Mbit/s, Powerline era praticamente sconosciuta e comunque disponibile solo a 14 Mbit/s, oggi con HomePlug AV si arriva a 500 Mbit/s.

Discorso analogo per lo storage ed interfacce di accesso ai dati:  USB2 vs USB3, Firewire - Thunderbolt, sata - sata3, il costo per gb è una frazione i quello del 2009, in particolare per SSD, quindi si può ottenere maggiore capacità a maggiore velocità a costi molto minori.

Cosa comporta tutto ciò per noi? Beh, se nel 2009  nel mettere in piedi un'architettura distribuita uno doveva preoccuparsi dei limiti imposti dalla rete e per librerie di significative dimensioni i costi di storage erano alti, il che consigliava di utilizzare formati compressi (seppur lossless) sia in trasmissione che in storage, oggi non è più così e può solo migliorare.

marcoc1712 ha scritto:

Solo parzialmente daccordo. In configurazioni com HQP il server prende forse beneficio dal poter usare hw più potente, certamente come NAA/Renderer stiamo utilizzando generalmente hw meno potente per scelta. In architetture SB, un Duet non è molto diverso da un Cubox nemmeno come consumo energetico.

Credo invece che - proprio grazie alle richieste di mercato alimentate dal consumo domestico di materiale multimediale (di cui noi rappresentiamo la nicchia nella nicchia 'stereo') - le tecnologie di rete siano molto maturate e soprattutto diventate di utilizzo generale.

Nel 2009 Esisteva già Ethernet 1Gb, ma era praticamente riservata ai datacenter, Wifi era 'b' 11 Mbit/s, oggi è 'ac': 500 Mbit/s, Powerline era praticamente sconosciuta e comunque disponibile solo a 14 Mbit/s, oggi con HomePlug AV si arriva a 500 Mbit/s.

Discorso analogo per lo storage ed interfacce di accesso ai dati:  USB2 vs USB3, Firewire - Thunderbolt, sata - sata3, il costo per gb è una frazione i quello del 2009, in particolare per SSD, quindi si può ottenere maggiore capacità a maggiore velocità a costi molto minori.

Cosa comporta tutto ciò per noi? Beh, se nel 2009  nel mettere in piedi un'architettura distribuita uno doveva preoccuparsi dei limiti imposti dalla rete e per librerie di significative dimensioni i costi di storage erano alti, il che consigliava di utilizzare formati compressi (seppur lossless) sia in trasmissione che in storage, oggi non è più così e può solo migliorare.

Ovvio che l'evoluzione vada in quel senso, ma non tutti dispongono della gigabyte, ad es il mio dell con meno di un anno di vita incredibilmente non ne dispone, ho dovuto mettere una scheda di rete usb 3 esterna !!!

RockOnlyRare ha scritto:
Beh diciamo che lo scopo finale è ascoltare quello che suona in modo più soddisfacente, poi è chiaro che se riesci a scoprirne la causa, è sempre meglio ed in questo il Gazebo è molto bello !!

...scoprirne la causa... è un po forte, mi accontento di avere l'opportunitità di formarmi un'opinione grazie alle esperienze di chi è più competente ed alle piccole prove che riesco a mettere in campo.

Come ho già avuto modo di scrivere, rispetto e forse a volte invidio chi come Massimiliano è in pace con il suo impianto e si gode la musica.

Ben aldilà della sua posizione, ci sono tanti musicisti (ed anche il mio Maestro, non che io abbia mai imparato realmente, ma lui è un Maestro davvero) che ascoltano con poco più di un gramofono e sono contentissimi, discernono le caratteristiche degli strumenti e le capacità degli esecutori ben al di là di quello che riesco a fare io con il mio impianto.

Il commento più bello che ho ricevuto da uno di loro è stato, ascoltanto un brano del Don Giovanni: "bello, riesco a seguire il dialogo senza andare a memoria". Nessun commento su profondità della scena, dinamica, ecc.

All'estremo opposto ci sono persone 'innamorate' della tecnologia, che freneticamente provano e cambiano apparecchi e tweaks, molti sono tecnici competenti che spesso antepongono le misure all'ascolto, a volte non particolarmente competenti in materia musicale.

Ho ovviamente tratteggiato figure 'ideali' e limite, nell'universo tra i due opposti, si apre una 'nube' di audiofili / tecnologi molto variabile per competenze tecniche e musicali, ognuno di noi si pone in un qualche punto in questa nube e si gode impianto e musica in modo completamente diverso.

C'è chi ignora gli aspetti tecnologici ed ascolta contento, chi ignora gli aspetti 'musicali' ed ascolta contento, chi ignora entrambi ed ascolta comunque contento.

Ma c'è anche chi è diplomato al conservatorio ed ha una doppia laurea in ingegneria elettronica ed acustica, come chi è semplicemente spinto da curiosità verso gli aspetti tecnologici e/o musicali e cerca la sua strada per migliorarsi in entrambi i campi.

Mamma ha lesinato il talento, ma con la curiosità non si è risparmiata!

Grazie mamma.

RockOnlyRare ha scritto:
Ovvio che l'evoluzione vada in quel senso, ma non tutti dispongono della gigabyte, ad es il mio dell con meno di un anno di vita incredibilmente non ne dispone, ho dovuto mettere una scheda di rete usb 3 esterna !!!

Occhio a non usare lo stesso bus USB sul quale c'è il DAC!

Ciao.

marcoc1712 ha scritto:

Occhio a non usare lo stesso bus USB sul quale c'è il DAC!

Ciao.

nessun pericolo il DAC si collega via USB (con un cavo che separa segnale da alimentazione) al NAA cubox, mentre il pc usa appunto la scheda di rete per comunicare con il cubox.
I files sono su NAS di rete oppure su un hd usb 3.0 su uno slot diverso da quello di rete.
Anche le prese di alimentazione del DAC sono separate da quelle di pc e di cubox.