CD rip in WAV

[Antoniotrevi]

@pino si

[Luca44]

Il 16/12/2023 at 16:04, Jax ha scritto:

Buonasera,
sto cercando di rippare al meglio i miei CD,  usando XLD su mac, finora l'ho fatto settando in Flac, oggi ho deciso di  farlo sullo stesso cd in WAV una prima volta usando il campionamento originale (16-44.1) la successiva  in upsampling in 24-96 ( può arrivare anche a 32-96)
La differenza del WAV rispetto al Flac c'è, provato e riprovato, non sono sicuro  se valga la pena usare il 24-96 o se sia una perdita di spazio nell'HD. Qualcuno ha esperienza in tal senso?

Per curiositä : hai provato dopo aver rippato in Flac un album a ritrasformarlo in WAV e poi ad ascoltarlo dopo aver finito l'operazione ? Tecnicamente credo ci sia il modo di farlo (ma non chiedere a me come...) , in pratica se dopo la doppia conversione ti accorgessi che nulla cambia all'ascolto tra il primo WAV e il WAV finale , sapresti che il problema e` da qualche parte nel processo di scompattamento del FLAC del tuo sistema e non nel formato FLAC in se´. Da li potresti procedere a cercar di porvi rimedio o decidere altrimenti e dotarti di soli WAV se ritenessi le soluzioni troppo complesse/costose  

[TetsuSan]

1 ora fa, Luca44 ha scritto:

nulla cambia all'ascolto tra il primo WAV e il WAV finale ,

Fatto. Con Korg Audiogate. Tra il primo ed il secondo WAV non cambia nulla. CVD. Ma "il problema" non è un problema per me, l'ho sempre saputo. Preferisco risparmiare spazio, tempo di trasferimento ma soprattutto fruire dell'ampia possibilità di taggare i flac. Inoltre in alta risoluzione gli spazi occupati diventano rilevanti.

[Luca44]

@TetsuSan Ottimo !!

[stefano_mbp]

@Luca44 … eppure un alac trasformato al volo in wav usando MinimServer/MinimStreamer riprodotto con il SOtM sMS200 Neo suona meglio dell’alac riprodotto as-is

… lo stesso con flac

… sono sfumature, non notte/giorno, ma il suono risulta più pieno … 

 

[Mighty Quinn]

Il 16/12/2023 at 16:04, Jax ha scritto:

La differenza del WAV rispetto al Flac c'è,

Non c'è

Non ci può essere

Ovviamente 

[stefano_mbp]

41 minuti fa, FabioSabbatini ha scritto:

Non c'è

Non ci può essere

Ovviamente 

… eppure qualcuno si è preso la briga di analizzare il fenomeno … link

[Mighty Quinn]

@stefano_mbp sI vede che aveva tempo da perdere

Buon per lui 

[Necro]

41 minuti fa, stefano_mbp ha scritto:

… eppure qualcuno si è preso la briga di analizzare il fenomeno … link

2016. Non mi sembra che dica quale/i DAC sono stati usati e con quale protocollo di comunicazione (il link all'articolo completo è rotto). Inoltre non dice quale hardware è stato usato, mentre sul sw parla di JRiver e VLC. Ipotizza (e conferma con alcuni esperimenti "di ascolto") che i metadati siano la causa principale della diversità audio. Sulla base di queste premesse, l'unica cosa plausibile è che siano stati testati casi di comunicazione sincrona col DAC dove il processo di analisi dei metadati e di decompressione può avere introdotto jitter che ha causato la diversità dei risultati di ascolto (sembra che parli specificatamente di alterazioni in termini di posizionamento dello stage e non altro). Oggi come oggi, dopo quasi 8 anni, in uno stream asincrono, con i DAC moderni, l'influenza della sorgente e delle sue fluttuazioni nella trasmissione dello stream sono pressochè azzerate (a patto di una corretta implementazione di reclocking da parte del DAC). Tale esperimento, sulla base delle ipotesi di cui sopra, dovrebbe avere risultati molto diversi oggi come oggi.

[stefano_mbp]

1 minuto fa, Necro ha scritto:

dovrebbe

… ipotesi … e la tesi dove sta ?

[Necro]

1 minuto fa, stefano_mbp ha scritto:

… ipotesi … e la tesi dove sta ?

non c'è, dovrebbero ripetere loro l'esperimento nelle condizioni "aggiornate". Ma loro stessi, nel 2016, NON hanno saputo dare una spiegazione alla cosa. Hanno riportato solo dei risultati di ascolto di cui non è chiaro quale è stato il campione.

[stefano_mbp]

11 minuti fa, FabioSabbatini ha scritto:

vede che aveva tempo da perdere

Buon per lui 

Non mi aspettavo una reazione come quella di uno che non sa che dire ma reagisce nella consueta maniera “dogmatica” … non è da te suvvia!

[stefano_mbp]

2 minuti fa, Necro ha scritto:

non c'è

Appunto … se vuoi confutare devi portare argomenti

[Necro]

2 minuti fa, stefano_mbp ha scritto:

… ipotesi … e la tesi dove sta ?

non c'è, dovrebbero ripetere loro l'esperimento nelle condizioni "aggiornate". Ma loro stessi, nel 2016, NON hanno saputo dare una spiegazione alla cosa. La sto dando io una ipotesi del perchè, nel 2016, hanno riscontrato quanto riportato. Così come sto dando una ipotesi del perchè oggi non accadrebbe. Loro hanno riportato solo dei risultati di ascolto di cui non è chiaro quale è stato il campione anche se, ovviamente, hanno dichiarato la metodologia in cieco (almeno quello).

[pino]

Riguardo ai Flac si legge che è un formato Lossless non compresso, ma si legge anche che è compresso.

Come al solito, senza basi,attingendo notizie in rete ci si confonde ancor di più.

Chi fa un po di chiarezza ?

Grazie

[Necro]

Adesso, stefano_mbp ha scritto:

Appunto … se vuoi confutare devi portare argomenti

Gli argomenti sono quelli di cui sopra. Gli argomenti di chi ha scritto il documento sono di carattere statistico: sono diversi perchè all'ascolto sono diversi (ripeto, non mi sembra si dica nel riassunto di quale campione stiamo parlando). Su queste basi vale tutto: tu senti le differenze, io no, gli argomenti sono tutti qui. Sarebbe bello se ripetessero l'esperimento oggi, nelle condizioni che ho indicato.

[Necro]

14 minuti fa, pino ha scritto:

Riguardo ai Flac si legge che è un formato Losless non compresso, ma si legge anche che è compresso.

Come al solito, senza basi,attingendo notizie in rete ci si confonde ancor di più.

Chi fa un po di chiarezza ?

Grazie

E' un formato lossless e su questo non c'è niente altro da dire. Tale formato può avere 8 livelli di compressione sempre maggiore. Ovviamente, più aumenta il livello di compressione, più aumenteranno le risorse di calcolo richieste per effettuare la decompressione. In linea di massima il formato FLAC nasce con metodologie di compressione atte ad ottimizzare al massimo la decompressione, tanto da garantire performance di real-time proprio a livello di progettazione del formato. Detto questo, ritorniamo al punto principale: attribuire una "differenza" ai due formati può essere fatto solo ipotizzando una differenza nello streaming dati generato. L'unica cosa che può alterare ciò sono le tempistiche di decompressione/metadati di cui parla anche l'articolo che possono, a livello teorico, introdurre jitter. L'introduzione del jitter, però, avrebbe senso di essere (anche se da dimostrare a quali livelli di udibilità) se parlassimo di comunicazione sincrona col DAC. In DAC moderni, in USB asincrono, oggi come oggi, torno a ripetere, questa "problematica" è di fatto superata e NON può sussistere in nessuna forma. Se avete una comunicazione sincrona (tipo coax) le cose sono tecnicamente diverse e possiamo anche parlarne, ma non dipende dal contenuto del formato in sè per sè (che è il medesimo nei due casi).

[Antoniotrevi]

@pino è compresso senza perdite dati , il wav non è compresso ed

è senza perdita dati.