Ce qui est dommage, c'est que l'option -pad de cdrecord ajoute 15 blocs, plut�t que le nombre n�cessaire pour correspondre � la taille retourn�e par Linux. Mais l'auteur de cdrecord n'a sans doute pas une opinion mitig�e de Linux pour rien... Cette valeur de 177041 retourn�e par Linux est �trange.
Je me compl�te. Ca n'est pas facile car on trouve plein d'infos de plein de monde qui ne savent pas forc�ment tr�s bien de quoi ils parlent. Comme moi. :-)
La taille retourn�e par Linux vient de la TOC du CD. On peut aussi la lire avec 'cdrecord dev=0,0,0 -toc'. Le fait que les 1-2 (exceptionnellement plus) derniers secteurs puissent �tre illisibles est normal. On parle de run-out sectors, cela vient du temps que le laser s'�teigne ai-je lu.
D'apr�s <http://memebeam.org/toys/WritingCdromsRight> il est possible d'�viter ce probl�me en utilisant un gravage disk-at-once au lieu du track-at-once par d�faut :
NB, j'ai pas essay� ceci ! mkisofs -no-pad -r -J -o test.iso files/ # this results in test.iso which is 202752 bytes, and 202752/2048 = 99 sectors cdrecord -v dev=0,0,0 -dao tsize=99s driveropts=burnfree test.iso # verify result: cmp /dev/cdrom test.iso # copy result: cat /dev/cdrom > copy.iso
La qualit� de cette page est douteuse, mais pour le DAO, �a �tend ce qu'�crit l'auteur de cdrecord (qqn de fiable je suppose :-) dans son README.copy. Autre confirmation pour le DAO <http://www.isodisc.com/pages/cdtechspec2.html>
Marc Mongenet
_______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
