From owner-freebsd-scsi Mon Jul 2 7:25:57 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id 10D9E37B40B for ; Mon, 2 Jul 2001 07:25:49 -0700 (PDT) (envelope-from mckay@thehub.com.au) Received: from dungeon.home (ppp125.dyn249.pacific.net.au [203.143.249.125]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id AAA00126; Tue, 3 Jul 2001 00:25:46 +1000 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.3/8.11.1) with ESMTP id f62EPxX12646; Tue, 3 Jul 2001 00:25:59 +1000 (EST) (envelope-from mckay) Message-Id: <200107021425.f62EPxX12646@dungeon.home> To: schilling@fokus.gmd.de Cc: ken@kdm.org, freebsd-scsi@freebsd.org, mckay@thehub.com.au Subject: Re: Problems reading burned CDs References: <200107021341.PAA16435@burner.fokus.gmd.de> In-Reply-To: <200107021341.PAA16435@burner.fokus.gmd.de> from schilling@fokus.gmd.de at "Mon, 02 Jul 2001 15:41:40 +0200" Date: Tue, 03 Jul 2001 00:25:59 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Monday, 2nd July 2001, schilling@fokus.gmd.de wrote: >The more features cdrecord gives you the more sense is in having a unique >interface. I still have hopes that a unified CD burner driver interface can be built. There are many ways to burn a CD (unfortunately!) but we only need a few by default. For example, I believe it is safe nowadays to write everything as multisession (left open). That could be the default. Also, now we know that TAO causes certain problems, we can pad by default. And so on. Maybe raw writing becomes the default too. It's too complicated the way it is. >The latest cdrecord e.g. introduces RAW writing which is thew only way >of doing DAO on Philips drives. Note that Philips OEM drives are dominating >the drive market now. Can this be automatically detected? Then the best write mode can be used without the user being involved. >>> There is no difference between a burned and a pressed CD. >>> There _is_ a difference between a TAO and a DAO CD. >So you could say that in general you cannot distinguish a CD with bad sectors >from one written on TAO. This kills all my ideas for making this "just work". But I might experiment with heuristics to lower timeouts for the last 2 sectors and absorb errors on them. Don't worry Jörg, I won't commit anything without consensus! >>FreeBSD won't read past the specified end of media (as reported by the read >>capacity command), and shouldn't have any trouble reading files on the CD, >>since any file won't encompass the last two blocks on a TAO CD. > >So did you tests with a TAO ISO-9660 CD where the last file's last block is in the >first fraction of a FS buffer block and the rest would take the run-out sectors? What's the simplest way (using cdrecord) to write such a disk? I'll test it on my gear. I am not in the habit of intentionally making difficult to read CDs. That happens only by accident. :-) So I could use a hint. By the way, Jörg, do you have expert knowledge of CDROM filesystems, as well as CD burners? I have a multisession Joliet CDROM that is completely unreadable on FreeBSD (mount reports cd9660: /dev/acd0c: Invalid argument). It has one more track than it has sessions. The extra track is between the others, and is 63 seconds long. It reads perfectly on Win98. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message