[PLUTO-help] Copiare CD audio, etc... LUNGA

[sabpll a libero.it]

Alle 09:53, lunedì 8 marzo 2004, Tom \ ha scritto:
> Innanzi tutto, credo che David chiedesse come mai il ripping è più lento
> in linux... Se la domanda era questa, la risposta è perchè, in genere,
> tuti i programmi sono in realtà dei front-end per cdparanoia, che è un
> bel tool a riga di comando. Se vuoi velocizzare la cosa, cdparanoia ha
> delle opzioni per fare meno controlli...
> [...]
> Qui vi chiedo una cosa io: siete sicuri? E se sì, perchè?? Scusatemi, io
> sono un fisico, e quindi vorrei capire il motivo delle cose...
> [...]
> Questa è una discussione che ho già avuto più volte con amici... Vi
> prego: se sapere di un motivo "erale" per cui i cd vanno masterizzati a
> velocità basse, me lo dite?
> Grazie...

In effetti i tool grafici sono soltanto front-end per
cdparanoia, mkisofs, cdrdao ed altri. Per questo motivo
preferisco fare parecchie cose, non solo maserizzare, da
riga di comando. Però anche i front-end permettono di
impostare moltissimi parametri, quindi non vedo il
problema.

Credo, però, di essere stato frainteso: il problema non è
la qualità del CD audio, ma non interrompere il flusso di
dati, perché altrimenti la masterizzazione fallisce e ci
ritroviamo con un bel sottobicchiere. 
Quindi, masterizzare a 48x è possibile ma devo fornire i
dati con una frequenza adeguata. Se li prendo da un HD va
bene, ma se li prendo da un lettore che li legge a 48x e
che per giunta spesso condivide lo stesso canale IDE...
Questo è il motivo *reale* per cui si deve masterizzare a
bassa velocità, ma non basta, bisogna anche leggere ad alta
velocità, possibilmente salvare un immagine su hard disk, e
tenere basso il carico del sistema.
Però i masterizzatori recenti hanno dei buffer di
scrittura enormi, spropositati, di diversi Mega, per cui
queste sono fisime, gli errori ed i CD rovinati sono
diventati rari. (ultime parole famose)

Altro paio di maniche è la qualità del risultato.
Penso che la presunta perdita di qualità sia più una
invenzione per vendere CD-R audio a prezzo maggiorato.
Però molte persone distinguono i CD masterizzati da quelli
originali, ma questo si basa su sensazioni personali, non
qualificabili e quantificabili. Non credo che ci sia
nessuna prova, misura di distorsione, del rumore od altro,
che non sia il confronto bit per bit dei due supporti,
capace di distinguere i due mezzi.

Però ho fondati motivi per credere che la copia di un CD
audio, anche prendendo tutte le precauzioni, non sia mai
perfetta.

Prima di tutto estrarre una traccia audio e salvarla in
fomato .wav non è equvalente a fare la copia bit per bit
della traccia; se non si sta attenti si inseriscono dei bit
zero come riempimento: questo si fà sentire sotto forma di
silenzi o click tra una traccia e l'altra.
Per questo motivo suggerivo di duplicare il CD in modalità
disk at once.  Ma quando si fa una compilation estrarre le
tracce è inevitabile: bisogna prendere provvedimenti.

Altro discorso sono le tracce dati; in questo caso le 
tracce sono identiche, errori di lettura/scrittura a parte.

Purtroppo, data la fisica del problema, gli errori di
lettura sono molto frequenti. I CD sembrano molto robusti
ed affidabili, ma è tutta apparenza. Il Red Book consente
fino a 250 errori al secondo dovuti al processo di 
produzione a cui si aggiungono gli errori in fase di lettura
dovuti a polvere, graffi, sporcizia, vibrazioni, deformazioni
del supporto,... Necissitano provvedimenti.

Per scrivere un byte viene usato un codice a correzione di
errore Reed-Salomon con CIRC, per cui si impiegano 32+1
simboli per memorizzarne 24
Ora sul CD vengono registrati pit e land, non zero ed uno.
Però uno corrisponde ad una transizione tra pit e land (o
viceversa), zero ad una mancata transizione; il risultato è
che non si possono avere due 1 consecutivi. Perciò si usano
ben quattordici (14) bit per codificare un ottetto (8 bit,
non un byte), e vengono aggiunti ulteriori 3 bit per 
separare gli ottetti.
E non è finita qui. Vengono aggiunti campi di sincronismo, 
spaziatori, controlli CRC. Alla fine per codificare 192 bit
di un segnale audio si usa un frame di 588 bit.

Ed ho tralasciato dettagli importanti. Comunque si pensa
che con questi accorgimenti non si riesca a correggere solo
un errore ogni 109 byte. 

Se si verifica un errore i lettori audio non tornano 
indietro e rileggo il dato ma lo correggono, se possono,
altrimenti lo ignorano, non vale la pena correggerlo.

Ma i lettori dati non possono fare così, e nemmeno possono
tollerare un errore su 109 byte. Aggiungono ridondanza con 
un altro livello di correzione degli errori.

Detto questo non penso che i lettori audio siano peggiori
dei lettori dati, hanno solo obbiettivi diversi.
Quello che è migliore (o solo più complicato) è soltanto il
metodo di correzione degli errori.

Ora le considerazioni finali.

I file .wav sono una sequenza di dati campionati che
corrispondono in modo molto complicato ai pit e land sul CD

Se c'è un errore irrecuperabile in un CD audio, ho solo più
rumore, ma forse il lettore è in grado di compensarlo con
un banalissimo filtro passa basso.
Se leggo lo stesso CD audio col computer ho più problemi,
e produco un file .wav con un errori.
Oppure il lettore può rifiutarsi di leggerlo.

Masterizzando un supporto di cativa qualtà ad alta velocità
produco più errori, ma non me ne accorgo perché vengono
corretti. Questo può essere irrilevante, ma può diminuire
la vita del CD.  I CD non sono eterni, si macchiano, si
graffiano, scoloriscono, si deformano,...
Questo si traduce con l'aumento del numero di errori che
ottengo  quando vengono letti, e se sono già pieni di 
errrori in origine...

-- 
Sabatino

PS Non è una questone di fisica, ma di trattamento delle
informazioni, cioè di informatica.
...

 
 
 
 
 
 
 
 
 
 
 
(X)   Non importa quanto lavori, non lavorerai mai abbastanza.

(Y)   Quello che non hai fatto è più importante di quello che hai fatto già.

(Z)   Niente è impossibile per chi non deve farlo.