Newsgroup: it.comp.hardware.cd
Titolo: Masterizzatore

    Ho un computer con Celeron (Mendocino) 300A, scheda SCSI 2940, cd
Plextor SCSI 32x e masterizzatore Panasonic SCSI 7502b 4x / 8x in lettura.
Vorrei aggiungere un masterizzatore EIDE Burn Proof Yamaha CRW 3200, che ho
trovato a buon prezzo.
    Ho sentito dire che molti burn proof, sfruttando intensivamente questa
tecnologia, producono buchi di circa 20um che danno dei click nei CD audio,
mentre sembra che i masterizzatori Yamaha abbiano una precisione superiore
che causa buchi di appena 2um che non danno problemi.
    E' vero? Qualcuno sa qualcosa in proposito? Come vanno i Plextor e i
Teac?
    Solo un'altra domanda: e' pratico l'uso dei cd-rw per archiviare ed
aggiornare singoli file, ad es. di grafica? Danno problemi?
    Grazie per l'attenzione e scusatemi se sono stato un po' lungo.

che causa buchi di appena 2um che non danno problemi.
che unita' di misura e' um ???

 che unita' di misura e' um ???
Micrometri, è un po' difficile trovare il simbolino della.... mu!...
Sì, il primo Burn Proof era un po' una ciofecca, lasciava dei begli
spazi tra un pezzo e l'altro. Ma ora è stato migliorato e ci sono una
miriade di altri sistemi = ma con nomi diversi che fanno lo stesso.
Cmq la tradizione vuole che i cd audio vadano masterizzati a velocità
basse, quindi a meno che tu faccia delle porcate assurde mentre
masterizzi il Burn Proof o affini non dovrebbe entrare in azione.
 Dumah
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

    Grazie per l'attenzione e scusatemi se sono stato un po' lungo.
Figurati... :-)
    Ciao!!!
-- 
 gatto ---> 
www.infinito.it/utenti/gat_mont/
Rimuovi l'antispam!!!

che unita' di misura e' um ???
Micron. Millesimo di millimetro (o anche micrometro, se non
sbaglio...). Il carattere che sembra una u e che si pronuncia "mu..."
potrebbe non essere visto da tutti i set e quindi si è soliti usare la
semplice "u".


masterizzi il Burn Proof o affini non dovrebbe entrare in azione.
Esatto, ma ricordati che a volte si scrive meglio alle alte che alla
besse. Nei moderni masterizzatori, i 1x, 2x sono stati eliminati
proprio per quel problema!
Io consiglio di usare la velocità massima disponibile in CLV. P-CAV
non mi convince molto e neanche Z-CLV, la prima per il jitter e la
seconda per la compatibilità con i vecchi lettori. Poi sarò io che
sono eccessivamente previdente...


 me ne infischio.
Scusate se mi intrometto puntando su un discorso prettamente qualitativo.
Sono sempre stato un gran sostenitore dei TEAC trovandomi benissimo con 
lettore (532s) e Master (58s) di questa casa.
Tra un po' dovrei acquistare un nuovo master (non perche' il 58s abbia 
dei problemi) e pensavo al nuovo TEAC 540 eide.
Il punto sul quale volevo soffermarmi riguarderebbe proprio il burn-proof 
e simili. A scanso di equivoci dico subito che preferirei avere un master 
con 4 mega di buffer (ma anche meno) senza burn-proof piuttosto che 
averne uno con burn proof.
Purtroppo tutti i master moderni hanno un qualche BP, dunque non 
c'e' scelta: la faccenda non mi preoccuperebbe troppo se il BP fosse 
disattivabile in qualche modo o se intervenisse SOLO quando necessario, 
ma purtroppo quest'ultima cosa non e' sempre vera (ne sto leggendo di 
tutti i colori).
Non cerco la velocita', non cerco la possibilita' di fare qualcos'altro 
durante la masterizzazione, non mi interessa la silenziosita', ecc., io 
vorrei solo che 'sto benedetto master facesse una cosa SOLA ma in maniera 
PERFETTA, cioe' che registrasse perfettamente-fedelmente (rispetto 
all'originale) byte per byte.
Io pensavo che questi discorsi dovessero ormai essere scontati vista la 
tecnologia d'oggi, ma porca pupattolona non sembra proprio esser cosi'.
Ho provato da amici alcuni master con BP (anzi, hanno masterizzato loro e 
poi mi hanno dato i cd) e la cosa irritante e' che facendo confronti 
binari serrati, o anche tramite crc32, non sono stati rari i casi nei 
quali sono state riscontrate differenze (rispetto agli originali), sia in 
masterizzazioni di audio che di dati. Non e' mai stata usata la max 
velocita' e sono stati usati supporti non proprio cessosi (Verbatim 
datalife plus, TDK Reflex Ultra e Sony).
Io non sarei esageratamente preoccupato perche' e' stata una verifica 
molto superficiale, infatti non ho la minima idea di che master abbiano 
usato (non lo sanno manco loro, sapete sono quegli assemblati belli e 
pronti dotati in apparenza di tutto ma con qualita' vomitevole; i miei 
amici sanno solo che i master supportavano il BP), dunque forse i master 
piu' accreditati non dovrebbero presentare certe sorprese.
Cmq, oltre a questo, ho letto varie cose in Rete e non tutte 
tranquillizzanti. Di italiano posso riportare qualcosa da una recensione 
sul TEAC CD-W524E di hardware upgrade:
------------------------------------------------------------------------ 
Qualche considerazione da fare: sono nate diverse lamentele per 
l'intervento del Burn-Proof (indichiamo con questo nome qualsiasi sistema 
che provveda alla salvaguardia dal buffer underrun error, per comodità), 
in situazioni di "non emergenza", poiché effettivamente avviene 
un'interruzione dei dati sulla superficie del disco, differente da quelle 
normalmente utilizzate nella scrittura. Sanyo garantisce la totale 
compatibilità di un supporto così registrato, cosa che effettivamente ci 
sembra logica.
Rimane comunque il dubbio di aver effettuato una registrazione del disco 
con interruzioni atipiche, che possono generare dubbi. Yamaha, nel 
proprio proprio dispositvo 20X in scrittura 2200E sfrutta la modalità P-
CAV, che non prevede introduzioni ed interventi di alcun sistema di 
protezione: è pur sempre l'unica voce fuori dal coro, in quanto 
praticamente tutte le case adottano ormai la tecnologia Z-CLV.
Alcune case in passato hanno preferito adottare velocità di estrazione 
relativamente basse, per salvaguardare la qualità delle tracce estratte. 
Le strategie adottate da Sony e HP su alcuni modelli, che imponevano la 
velocità di estrazione costante su tutto il disco (comunque bassa), hanno 
finito per scontentare il pubblico, attento evidentemente alla velocità 
pura.
------------------------------------------------------------------------
A parte considerazioni varie (tipo il fatto che non solo il summenzionato 
articolo menziona che il BP interviene anche quando non ce ne sarebbe la 
reale necessita'), mi sono soffermato anche dove l'articolo 
recita: "Sanyo garantisce la totale compatibilità di un supporto così 
registrato".
Io dico potrei anche dire OK, pero' dire "compatibile" non e' dire 
"perfezione byte su byte".
Inoltre, anche con i BP piu' moderni c'e' sempre un'interruzione, seppur 
"teoricamente" (forse) trascurabile:
Older versions of BURN-Proof had a gap size of either 40-45µm or 2-5µm 
between where the recording stopped and where it resumed. The new 
versions of BURN-Proof, featured on some of the 24x CD-RW drives, have 
decreased that gap to under 1µm.  This gap is so small that many people 
are calling it "0 gap."
Capito questo, vorrei proprio sapere se questo valore al di sotto di un 
micrometro possa ipoteticamente influenzare (basta anche una sola volta e 
anche se solo su un singolo byte) la scrittura corretta o meno del 
singolo byte.
Conoscete per caso dei luoghi in Rete (in inglese o tedesco vanno 
altrettanto bene) dove questa tematica venga affrontata in maniera 
piuttosto approfondita?
A questo punto la parola a voi (sempre se ne avete voglia) possessori di 
master con burn proof (o tecnologia simile), in particolar modo ai 
possessori di master TEAC moderni (come il tuo, gatto).
Sarebbero estremamenti graditi resoconti scaturiti da varie ed intense 
verifiche binarie (tipo con l'fc del dos) sia su dati che su audio, 
resoconti di qualche "tonnellata" di crc32  ^____^
Magari numerosi controlli crc tramite Monkey sui suoi file .ape 
masterizzati (verifica crc fatta direttamente sugli .ape masterizzati e 
fatta magari piu' di una volta), questa e' "tosta".
Ho finito, se un giorno avete del tempo libero e il vosto computer deve 
stare acceso per lavorare, mettetegli in coda un po' di questi controlli.
Grazie per le eventuali repliche-info.
Cia', mumble

 ha scritto nel messaggio
news:MPG.172b1d404...@News.CIS.DFN.DE...
[...]


 sono stati errori. Tutti scritti a 16x e con bp abilitato! E' sufficiente??
Prima di dire se sia o meno sufficiente, vorrei gentilmente sapere che 
modalita' hai usato per creare i file .ape, cosa hai usato per verificare 
i file .ape masterizzati e se queste verifiche le hai fatte piu' volte 
sui medesimi CD (anche sugli stessi CD che in precedenti verifiche non ti 
avevano segnalato alcun errore nei file .ape).
Cia', mumble

Estratto l'audio con EAC, compresso con MAC (compressione normale), i file
.ape verificati con MAC stesso. Per gli shn ci sono un paio di utility in
rete per la verifica degli md5. Come lettore cdrom uso Plextor Ultraplex 40x
o Toshiba dvd 16x.
Chiaramente i cd spediti in giro sono stati verificati solo due volte (da me
alla spedizione e dal destinatrio alla ricezione). Fino ad ora nessuno ha
mai trovato errori (speriamo bene :-) )
I cd che ho in casa li ho verificati una sola volta. Se vuoi posso fare un
controllino a campione (tutti sono un pò troppi!) Tutti i miei cd sono stati
masterizzati con bp abilitato, senza però farlo mai "scattare".
In generale non mi fiderei molto di cd scritti con bp in azione, vuol dire
che il sistema non è ottimizzato per la masterizzazione.
Saluti,
    Paolo


e simili....
mi spiace ma la momento non posso fare grossi test perchè quando ho
comprato il mio ultimo masterizzatore ho preso uno yamaha 2100s per 3
motivi :
1) SCSI (fondamentale)
2) Non ha burn proof o simili (non mi fido)
3) Proprio perchè senza BP ha 8Mb di Buffer.
Però la possima settimana dovrei avere sottomano un TEAC CD-W524EK (in
realtà l' ho già qui e sto aspettandoho il PC su cui installarlo),
quindi farò un po' di test anche perchè è un discorso che mi ha sempre
incuriosito.
Per ora pensavo di masterizzare direttamente CD audio forzando l' uso
del burn proof e testando il CRC delle copie con quello dell'
originale con EAC. Un' altra prova che farò sarà estrarre in wav la
traccia masterizzata con uso del BP e controllo di cosa succede all'
onda nel punto in cui è entrato in funzione usando un sound editor e,
se ci sono differenze, usando un editor esadecimale per vedere a cosa
corrispondono (saranno tutti "00" o altro? E se è altro cambia di
volta in volta o è sempre uguale?).
Potrei fare un confronto md5 con mokey o qualche altro test ti venga
in mente.
Per risparmiare tempo in verifiche, c'è qualcuno che ha il suddetto
masterizzatore e mi sa dire senza alcun margine di dubbio se è in
grado di scrivere/leggere lead-in e lead-out e qual'è il suo offset in
scrittura?
ciao,
Lucio
---------------------------------------
Cerchi una guida per EAC in italiano?
http://eac-italia.da.ru
http://eac-italia.cjb.net
Dove trovare EAC? :
http://www.exactaudiocopy.de/index.html
Dove trovare Musepack / MPC ?
http://www.uni-jena.de/~Epfk/mpp/
http://www.musepack.org
Dove trovare l'ultimo LAME? :
http://mitiok.cjb.net
---------------------------------------

 in mente.
Quello che non mi torna e' il controllo "verify" di Monkey. Su questo 
metto un pezzo di un mio post spedito all'altro NG:
---------------------------------------------------------------------
A proposito di questo, c'e' un qualcosa che non mi torna con il verify 
di Monkey's Audio.
Di rado mi capitano dei problemi con file .ape masterizzati su ottimi 
supporti e tramite ottimi master (Teac-Plextor) a velocita' non massime 
(2x o 4x): cioe', facendo il "verify" di Monkey DIRETTAMENTE sui file 
.ape masterizzati (creati con monkey versione 3.96-3.96beta2 e 3.96 
beta3, tutti con extra-high), di rado saltano fuori degli "invalid 
checksum" e questo mi fa incazzare come 'na bestia, anche perche' 
facendo controlli crc con altri programmi non salta fuori alcun problema 
e la riproduzione dei summenzionati .ape con il plugin monkey per Winamp 
(con DISABILITATA la voce "ignore bitstream error") non presenta problemi 
di alcun tipo e non si interrompe.
La cosa strana e' che questi "invalid checksum" capitano random, nemmeno 
nello stesso punto nel quale si erano manifestati in precedenza, e a 
volte non capitano proprio, cioe' uno stesso cd, con ad esempio 50 file 
.ape, che dopo un verify ha rivelato due file .ape con invalid checksum, 
in controlli successivi a tappeto puo' presentare ancora problemi, anche 
e perfino su ape del tutto diversi, oppure puo' benissimo non presentare 
alcun problema su alcun file ape.
Sto facendo vari controlli incrociati con CD masterizzati pieni di .ape 
fatti da alcuni amici con master yamaha, plextor, ecc., ma la solfa e' 
la stessa: a volte il verify di Monkey mi da' OK su tutto, altre volte 
controllando i medesimi CD puo' darmi OK come puo' segnalarmi un invalid 
checksum, cazzo sto sclerando.
Non dovrebbe c'entrare niente, ma questi comportamenti senza alcuna 
apparente logica sembra accadano maggiormente quando e' ATTIVATA in 
Monkey l'opzione "Stop processing after encountering an error", ma per 
l'appunto non dovrebbe c'entrare un'eva visto che tale opzione agisce 
"sul da farsi DOPO aver rivelato l'errore".
Ecco, chi avesste tempo/voglia potrebbe cimentarsi con queste prove-
verifiche senza cantar vittoria dopo averne fatte poche e non 
sistematiche, ma effettuate insistentemente nell'arco di giorni, sugli 
stessi CD gia' verificati piu' volte, ecc..
---------------------------------------------------------------------- 
Cia', mumble


Quasi certamente 1um è una distanza talmente piccola da essere irrilevante e
non interpretata come un errore. Inoltre i dati che vengono letti fanno
parte di un settore i cui ultimi byte contengono informazioni di controllo
in caso di errore circa l'integrità dei dati del blocco stesso.
[CUT]
Per i controlli quando avrò un pò di tempo mi ci metto.
ciao edo

 non interpretata come un errore.
Ho capito, ma vedi che qua siamo sempre nel "forse", "possibilmente", 
"quasi certamente", ecc.. Vorrei che in giro ci fosse una qualche 
documentazione tecnica che provasse senza minima ombra di dubbio che i 
miei timori sono infondati.
Cia', mumble

metto un pezzo di un mio post spedito all'altro NG: ...
Mi lascia un po' perplesso ... se non è un metodo affidabile al 100%
rischio solo di farmi venire il mal di testa per niente ... potrei
usare altri programmi per verificare md5, magari meno sensibili a
"cause esterne" durante il loro lavoro... per ora cmunque penso di
cominiciare con le prove che ti ho scritto, poi passerò ai test con
Monkey.


 "cause esterne" durante il loro lavoro...
Ma io ho gia' detto che con tutti gli altri programmi-librerie non c'e' 
alcun problema, il problema si presenta ("invalid checksum") con il 
verify di Monkey (e non e' del tutto detto che la colpa sia di 
quest'ultimo, Monkey in passato ha dimostrato di essere piuttosto 
sensibile in presenza di hardware non in "forma" al 100%, anche se il mio 
e' piuttosto stabile).
Cia', mumble

verify di Monkey ....
Dunque dunque, eccomi alla fine delle prove con un resoconto veloce.
Prima di tutto confermo che il burn proof puoi disabilitarlo senza
prolemi sia con Nero che con Feurio ma non con EAC (dove perň viene
attivato). C'č un' opzione apposita.
Secondo farlo entrare in fuzione non č cosě facile come sembrerebbe,
per lo meno nel mio caso dove mi sono visto costretto ad abbassare la
prioritŕ del processo di masterizzazione altrimenti il buffer rimane
sempre a livelli sufficienti (con Feurio l' ho impostato al minimo
possibile, mentre con Nero l'ho messo a 2Mb altrimenti diventava
troppo sensibile). Impostato cosě il sistema ho fatto un test senza BP
ed effettivamente il buffer underrun arriva che č un piacere.
Attivato il BP ho lanciato la demo nVidia con il camaleonte in
visualizzazione "a punti" che occupava piů del 100% della CPU, un
Athlon Xp 1800+ abbinato a GeForce 4(?)MX 440.
Alla fine ho masterizzato un CD misto con 340Mb di tracce .ape (sempre
la stessa) e 43 minuti di audio (anche qui sempre la stessa canzone
ripetuta). La masterizzazione č stata fatta a 16x (il supporto č un
bulk e per evitare di avere errori ho preferito evitare i 24x) ed č
durata 56 minuti, nei quali suppongo che il "Write Proof" (cosě si
chiama il sistema TEAC) sia entrato in funzione un po' di volte.
Purtroppo non so esattamente quando e come sia entrato in funzione
perchč, contrariamente a quanto mi apsettavo, alla fine non viene
fatto nessun resoconto in merito. Ho notato che quando la
masterizzazione si interrompe puň rimanere in stand by anche per 10
minuti in attesa di riempire nuovamente il buffer, cosě per evitare di
fare notte mi sono messo a trafficare per farlo entrare ed uscire piů
volte.
Alla fine di tutto 'sto casino ho controllato le tracce .wav con EAC e
gli .ape con Monkey. Risultato : tutto OK..... le tracce audio hanno
tutte lo stesso identico CRC e Monkey mi dice che tutti gli ape sono
OK (sto preparando una pagina con le immagini). All' ascolto le tracce
non presentano difetti udibili, insomma, sembrerebbe tutto perfetto!
La cosa mi sembra strana, ma evidentemente devo ricredermi sull'
efficacia del sistema adottato da TEAC (non posso dire nulla sulle
altre tecnologie).
Appena trovo un po' di tempo passerň tutto con "DAMN Hash Calculator"
in modo da avere anche SHA, HAVAL, RIPEMD-160, MD5 e CRC-32 ... e se
anche questi saranno tutti uguali come dovrebbero essere ... beh,
tanto di cappello al write proof & co.


Cia', mumble
Ciao, e non rinominare il subject nei reply! :-)


 Beh, gap=errore non è corretto.
Come no, se interrompi e poi riprendi non nell'esatto punto la 
comparazione puo' andare a puttane (ed e' quello che ho verificato con i 
CD che mi hanno passato), bisogna vedere quanto quel gap piccolo possa 
influire sullo stato dell'informazione binaria.
Cmq, a parte tutto questo mi avete gia' risposto, sembra che con l'ultima 
generazione di BP si possa stare abbastanza tranquilli.
Grazie a tutti.
Cia', mumble

generazione di BP si possa stare abbastanza tranquilli.
Sì, quello che fa paura è altro. CD sporchi, lettori fetenti ecc...


Athlon Xp 1800+ abbinato a GeForce 4(?)MX 440.
Io non userei un programma "hard" per interrompere il transfer rate.
Di solito i programmi di masterizzazione hanno la precedenza nelle
risorse. Da me il buffer non si schioda neanche con un programma di
burn-in. Fai una copia al volo e decelera il cd-rom!


vacanza :-)
Beato te :)
Buon viaggio!


burn-in.
E' vero, infatti ho anche modificato le priorità dei processi
abbassando quella del sofware che stavo usando in quel momento per
masterizzare (comunque è tutto spiegato nel resto del post).Sul fatto
che il BP sia entrato in funzione sono abbastanza sicuro perchè la
masterizzazione fatta a 16x è durata 56 minuti (un CD da 80 pieno
fatto in DAO). Ad un certo punto mi è anche comparsa una scritta nella
finestra di NERO che mi diceva che il masterizzatore era in pausa (non
mi ricordo esattamente cosa diceva, purtroppo è comparsa una volta
sola durante tutti i test, ne sai qualcosa?). Comunque l 'indicatore
del buffer è sceso a zero parecchie volte e lì rimaneva finchè non
intervenivo manualmente a rimettere la masterizzazione con priorità
normale.
Alla fine di tutto 'sto ambaradan comunque posso dire di essere
rimasto decisamente ben impressionato sia dall' affidabilità del Write
Proof della TEAC che da quella dei software di masterizzazione che
senza intervenire su cache e processi sono veramente difficili da
mettere in crisi.
ciao,


generazione di BP si possa stare abbastanza tranquilli.
Assolutamente! Non mi sarei mai aspettato che fosse così affidabile.
Ho ricreato una situazione che potreppe essere considerata come tipica
per il BP, ossia sovraccarico di lavoro (dimenticavo, per metterlo
ancora più in crisi ho anche provato a sfogliare il CD mentre veniva
masterizzato usando sia explorer che altri programmi ma non ha sortito
nessun risultato perchè mi sa che durante la masterizzazione non è
comunque possibile accedere alla periferica, ossia io potevo
"entrarci" ma non vedevo nulla) e non è andato assolutamente in crisi,
anzi, ho dovuto anche abbassare la priorità del processo altrimenti
non entrava proprio.
Il prossimo masterizzatore so già cosa sarà :)
