Newsgroup: it.hobby.hi-fi
Titolo: ma siamo sicuri che ...

... il ripping dei cd su hd non funzioni meglio con copia iso di
clonecd e montaggio di unità virtuale con virtual clone drive?
e poi rimane il romanticismo di scegliere il disco...
ciao

 ciao
s�, forse, ma dobbiamo imparare a liberarci dagli orpelli materiali, no?

 confronta i dati letti (bit per bit) con una banca dati pubblica.
Beh se cosi fosse (confronto bit a bit) potrebbe scaricare il file Wav 
direttamente dalla banca dati pubblica :-)
Forse comparerà l'hash del file wav....
 

...mah rimango dubbioso
non ho un approccio esasperatamente tecnico ma per la creazione di una
iso con clonecd al minimo della velocità (4x) si impiegano circa 15
minuti, con eac molto molto meno segno che il disco è letto più
velocemente. ovviamente la teoria vuole che più è lenta la lettura più
è accurata.
ciao

> s , forse, ma dobbiamo imparare a liberarci dagli orpelli materiali, no?
ma infatti non si tocca materia alcuna salvo il mouse per montare
virtualmente ....

 minuti, con eac molto molto meno segno che 
segno che hai impostato i controlli di EAC a livello molto basso.
Piu' l'estrazione e' accurata piu' tempo impiega (al piu' mi sembra circa
1:1, ma chi lo usa potra' essere piu' preciso).
Piergiorgio
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


sì, scusa, lo davo per scontato.
l'hash è univoco rispetto al contenuto del file wav di ogni singolo brano, quindi il confronto bit a bit non è diretto ma l'identità tra l'hash ricavato dal ripp e l'hash in banca dati testimonia l'esattezza del ripp.



sì, scusa, lo davo per scontato.


 Piergiorgio
se il cd è in buone condizioni e il sistema di lettura (meccanica+ottica) funziona correttamente non c'è motivo per insistere nel voler rallentare o rileggere molte volte le tracce; il confronto tra gli hash delle tracce e quelli in banca dati è sufficiente a garantire che la lettura sia avvenuta correttamente.
può convenire invece rallentare la lettura o leggere più volte qualora gli hash del cd non siano presenti in banca dati e in qual caso sarebbe anche gradito che chi effettua il ripp inviasse in banca dai i suoi hash per favorire i successivi ripp.


il ripp in singoli brani compressi lossless flac ha però il grande vantaggio di poter utilizzare i tag per la classificazione di ogni singolo brano/cd. i tag sono poi leggibili da qualunque media server a tutto vantaggio della navigazione nella mediateca.
se il ripp viene eseguito con un po' di furbizia e si generano (e conservano) anche i file *.log e *.cue, ci si ritrova anche con un ottimo backup della cd-teca perchè i cd possono essere integralmente ricreati.  generando anche gli *.m3u e file "folder.jpg" per ogni cd si semplifica poi ulteriormente la navigazione nella mediateca.



Quale teoria? Se usi l'ultimo e più performante camion in F1 non
arrivi di certo primo, lo stesso se usi una ferrari alla Parigi Dakar.
Al contrario la teoria ti dice che una meccanica da pc è ottimizzata
per la massima velocità, per decodificare in un dato modo. In
un'estrazione raw, a.e., eviti qualsiasi ecc e ti affidi ad un sistema
statistico nella lettura e rilettura di una traccia o in quella audio
ti affidi a quelli del red book e altri etc. Insomma devi settare la
"scala" più adeguata e non è detto che sia la più lenta.
mm

Piergiorgio
Non direi: con un lettore cdr decente, senza cache, con C2 si viaggia,
in secure mode, tra il 10 e 20 con un cd in normali condizioni. Certo
se vai in "paranoid" i tempi si allungano notevolmente, ma se
statisticamente con accurip il dato torna non c'è motivo per insistere
- oltretutto è sconsigliato dallo stesso autore. Se il lettore ti va
sotto il 10 e sopratutto ti si abbassa la percentuale nel log il tuo
cd è in pessime condizioni e non ha senso usare "paranoid" non faresti
che stressare la mecanica inutilmente, EAC non farebbe altro che
riportarti "errore" - al contrario, da secure passi a burst e gli dici
di fregarsene degli errori, poi speri he non siano udibili altrimenti
si spera che la prossima volta ti ripassi la 3 o 4ta di copertina con
le istruzioni sul supporto :-)
mm



mi sembra perfettamente chiaro!!( tag, m3u, .log,che mi@Kie sono?)


sorry, vediamo se riesco a spiegarmi.
cue = file che descrive come le tracce compongono l'intero cd.
se disponi del file cue descrittivo e di tutti i file wav o flac relativi alle singole tracce, EAC o Nero (ad esempio) possono ricostruire l'intero cd.
tag = singolo dato (es. titolo, autore, data, genere, ecc...) incapsulato nel file (flac).
m3u = file con playlist (se poi mi chiedi cos'è una playlist... :-)).
può essere utile per garantire con alcuni player l'esecuzione dei brani di un cd con l'esatta sequenza (es. Windows media Player o Windows Media Classic)
log = ehm... davvero non sai cos'è un file di log? ehm...
può essere utile per testimoniare, o anche solo ricordare, a distanza di tempo la correttezza o meno del ripp.
folder.jpg = beh... questo è un normale file grafico.
di norma i player come foobar2000 utilizzano file con questo nome (o similari) per rappresentare con una copertina il contenuto di una cartella contenente file audio (o video).
se crei una cartella per ogni cd e ci metti l'immagine della copertina chiamandola folder.jpg...
ciao

 incapsulato nel file (flac).
dimenticavo... i tag trovano la loro utilità nel fatto che quasi tutti i media server sono in grado di leggerli, indicizzarli e quindi fornire elenchi ordinati in base ai loro valori (es: mostrami l'elenco dei cd per ordine di autore o di anno, ecc...) o meglio di utilizzarli con filtri di ricerca (es: dammi tutte le interpretazioni dei Notturni di Chopin uscite nel 2000).