Bonjour,
j'ai un problème de réglage de vitesse avec mon graveur dvd interne, qui d'après k3b est un lite-on sohw 812s (je peux pas ouvrir ma machine pour vérifier pour cause de garantie). Suivant le type de dvd-r que j'insère, les vitesses de gravure possibles varient. Le problème, c'est qu'elles sont trop élevées ! (ça change des gens qui se plaignent des gravures trop lentes, non ?)
Jusqu'ici, les dvd-r que j'avais devaient être gravés à 2770 kbps minimum, mais là je viens d'en acheter 200 qui sont au minimum à 5540 kbps. Hélas, ma pauvre machine ne suit pas, et sur 11 dvd gravés un seul est arrivé à terme. Le tracé de sa piste montre des irrégularités manifestes. Pendant la gravure, la LED du graveur n'arrêtait pas de clignoter du rouge à l'orange, ce que j'ai interprété comme un problème de buffer. Le dvd rescapé ne passe pas sur ma platine de salon.
Suis-je le seul dans ce cas ? Je n'ai rien trouvé sur google. Est-ce normal d'avoir ces vitesses minimales, surtout aussi élevées, et de plus différentes d'un type de dvd à un autre ? Est-ce normal que ma machine ne tiennent pas le choc (c'est une entrée de gamme vieille de 6 mois, mais j'ai l'impression que le disque dur est très lent) ? Je suis sous Debian Sarge avec un kernel 2.4.26.
Y a-t-il un moyen de graver les dvd sans utiliser growisofs ? Sinon, je suis assez pessimiste. En effet, j'ai modifié le code de la fonction set_speed_B6h pour qu'il m'affiche toutes les vélocités disponibles au moment de graver: pour mes anciens dvd, 2770 et 5540, pour les nouveaux 5540,8310 et 11080.
Voilà, si vous avez des idées, *ou des pointeurs sur d'autres forums peut-être plus appropriés*, n'hésitez pas.
Merci d'avance.
# Quel programme
Posté par Fabimaru (site web personnel) . Évalué à 2.
J'ai un problème similaire. Au mieux je peux écrire à 3.7x des DVDRW Verbatim 4x avec growisofs. Si j'ai mldonkey (qui transmet à 70ko/s max) qui tourne, le ralentissement est encore plus fort. Normalement avec un bon buffer logiciel ça devrait régler le problème. Apparemment growisofs ne gère pas de buffer logiciel car l'auteur estime que cela ne pose pas de problème car les graveurs peuvent reprendre la gravure. J'ai regardé la vitesse de lecture d'un disque ainsi produit, il y a de gros ralentissement à certains endroit du disque.
Je n'ai jamais eu de problème avec cdrecord (pour les CD) par le passé. Ma machine est un Athlon 1.4Ghz avec un disque lisant à 20Mo/s maximum.
On peut utiliser cdrecord avec un patch DVD (de base dans la Mandrake) parait-il. Je n'ai pas pu testé car pour le moment car je voudrais graver à tous les coups en 4x sur mes DVD.RW (pour tester) et apparemment cdrecord-dvd n'accepte pas les disques réinscriptibles.
Je suis en train de faire des tests avec le programme "pipebuf2" pour voir si ça règle le problème, mais je n'ai pas fini.
[^] # Re: Quel programme
Posté par remyremy . Évalué à 1.
mkisofs -r -J movies/ | pipebuf2 -b 32 -i 1 | growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc=/dev/fd/0
Le buffer de pipebuf2 était toujours plein, mais la LED clignotait toujours aussi vite. Idem avec -b 64. Après j'ai essayé de faire mkisofs à l'avance.
cat movies.iso | pipebuf2 -b 32 -i 1 | growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc
et
growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc=movies.iso
Même résultat. Après je me suis plongé dans le code de growisofs. J'ai commencé à rajouter un buffer. Au bout d'un moment, j'ai eu l'idée d'une expérience: j'ai remplacé la boucle d'écriture principale
while ((n=read (infd,the_buffer+off,DVD_BLOCK-off)) > 0)
par
while (1)
ce qui fait que le programme ne lit jamais de données en entrée, et grave le même bloc de 32k encore et encore. Cela m'a permis de tester si c'était la lecture de l'iso par le pipe qui ralentissait le reste.
Hélas, le résultat était toujours aussi mauvais. Ce n'est donc pas un problème de buffer. La seule possibilité que je vois encore pour s'en sortir avec growisofs consisterait à tenter d'optimiser la fonction qui se charge de l'écriture (pwrite64_method). Celle-ci ne travaille qu'avec des blocs de 32k. Est-ce un choix de l'auteur ou une contrainte technique ? Dans le premier cas, il y a peut-être moyen d'augmenter cette taille, en espérant que cela améliore les performances. A creuser, mais sans trop d'espoir...
Pour ce qui est du patch dvd, il est aussi présent dans Debian, sous la forme d'un cdrtools patché, modifié et repackagé sous le nom de dvdrtools. La commande s'appelle dvdrecord ici au lieu de cdrecord-dvd.
Je n'arrive pas du tout à la faire marcher chez moi. Même un -scanbus échoue et retourne:
dvdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open SCSI driver.
Reste encore à teste cdrecord-prodvd.
[^] # Re: Quel programme
Posté par Fabimaru (site web personnel) . Évalué à 1.
J'imagine que si fonction "poor_mans_pwrite64" ne prend que des blocks de 32k, c'est parce que c'est une contrainte matérielle (je n'y connais rien).
Comment as-tu fait tes tests ? J'ai utilisé un DVD+RW Verbatim neuf, mais je me demande si les performances ne se dégradent pas avec le nombre d'écriture (j'ai dû faire une trentaine de tests).
[^] # Re: Quel programme
Posté par remyremy . Évalué à 1.
J'ai réussi a utiliser dvdrecord -scanbus (il suffisait de rajouter -dev=ATAPI ou quelque chose à cet effet). La gravure avec dvdrecord n'a pas marché, toujours le même problème de vitesse. Je n'ai pas essayé cdrecord-prodvd.
J'ai regardé en diagonale la spécification MM5, la dernière version des commandes SCSI pour le multimedia. Apparemment, la taille d'un bloc d'écriture pour les DVD est de 2k. 32k correspond à la taille d'un bloc ECC (Error-Correcting quelqueChose ?). Je n'ai rien trouvé qui impose d'avoir des blocs par groupe de 16 (32/2) lors d'une commande WRITE.
Ce commentaire est un peu prématuré, vu qu'il y a encore un paquet de choses que je ne comprends ou ne sais pas dans MM5 et growisofs. C'est juste pour signaler que j'ai pas lâché l'affaire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.