on-thy-fly okopirovani CD

[Martin Dvorak]

Dan Lukes wrote:
>     Vidis tam u 'burncd' nejake '-d' ?
> 
>     No, a kdyby sis ho tam nedopsal, tak by ti to fungovalo taky. DAO 
> mode potrebuje znat velikost vsech stop jeste pred zacatkem vypalovani, 
> aby mohl sestavit CUE sheet. Ale ty DAO k nicemu nepotrebujes, na kopie 
> datovych CD ti TAO bohate staci (i kdyz, tak jednoduse jak's to napsal 
> se to tyka jen non-multisession CD), takze staci vynechat to '-d' a bude 
> to fungovat.

Zkousel jsem to a simulace se ukoncila v poradku. Vypalovani naostro se 
ale zaseklo hned na zacatku (jediny output byl "adding type 0x08 file - 
size 0 KB 0 blocks") a musel jsem to po hodine killnout. Zrejme by se to 
s trochou namahy nakonec podarilo rozchodit, ale nemam ani tolik medii 
ani tolik casu.


>> BTW: Mezitim jsem rozchodil cdrdao - vyborne udelane, vsem vrele 
>> doporucuji. Pouze to chce scbus, pass a atapicam do kernelu, 
>> on-the-fly kopirovani to ma zabudovane (cdrdao copy --device 0,1,0 
>> --source-device 1,1,0 --on-the-fly --eject --buffers 128). Zatim 10 
>> CD, vsechny bezchybne, a to cte z oficialne nepodporovane mechaniky 
>> (driver se musel nastavit rucne).
> 
> 
>     No, jasne, ze to funguje, ale nenapsat tam u burncd to '-d' je preci 
> jen vyrazne jednodussi ... ;-)
> 
>     To nemluvim o tom, ze u burncd je mensi riziko underrunu.

Jak se to vezme. cdrdao zkopiruje v podstate libovolne datove i audio CD 
(vcetne CD se zamerne porusenymi sektory atd.), samo analyzuje vstupni 
disk, nacita subchannel informace atd. Proc ma cdrdao vyssi riziko 
underrunu nechapu, ale na burnproof jednotkach uz to je stejne jedno.
Jedine, co se mi zpocatku nezdalo, byla rychlost (okopirovani jednoho CD 
trvalo zhruba 25 min), ale stacilo nastavit na obou CD jednotkach 
ULTRADMA33 mod (misto puvodniho PIO4, ktere FreeBSD nastavuje 
defaultne). Jedno CD se ted on-the-fly okopiruje zhruba za 4 min, coz je 
max. rychlost vypalovacky, na ktere jsem to testoval.

-md-