From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 12:17:53 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ABEF16A420; Tue, 14 Feb 2006 12:17:53 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C98743D4C; Tue, 14 Feb 2006 12:17:52 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id k1ECHWGJ029406; Tue, 14 Feb 2006 13:17:33 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43F1CA5C.9060303@deepcore.dk> Date: Tue, 14 Feb 2006 13:17:32 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5 (X11/20060130) MIME-Version: 1.0 To: Ariff Abdullah References: <20060213121101.47A5AA98F@m-kg282p.ocn.ne.jp> <43F07C73.6040502@deepcore.dk> <20060214010337.6e4e4a5a.ariff@FreeBSD.org> <200302240026.11989.soralx@cydem.org> <20060214192648.1e7a5277.ariff@FreeBSD.org> In-Reply-To: <20060214192648.1e7a5277.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: chi@bd.mbn.or.jp, freebsd-hackers@FreeBSD.ORG, nork@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/60163 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 12:17:53 -0000 Ariff Abdullah wrote: > On Mon, 24 Feb 2003 00:26:11 -0800 > soralx@cydem.org wrote: >>>> Hmm, could it be that the data track is always the last track ? >>> Yes. >> so that CD players would be able to play the disks? or does not >> matter? >> > Correct. Most hardware cd player are designed to play only the first > session on multisession disc, where in this case (CDEXTRA), the data > track will be ignored. Unlike mixed-mode cd, the data track (on > first track/session) usually result in silence playback. > > In case somebody might interested, I have a patch for (unfortunately) > RELENG_5 for atapicd multiblock access. Among other things, it > also fix multisession/dao writing of burncd(8). With this, you can > have conccurent access with varying blocksize on atapicd. > > http://people.freebsd.org/~ariff/misc/releng5_ata.diff > > It's a bit ugly. Somebody with deeper knowledge on ata/GEOM probably > will have better solution for this. Thats closer to a real solution. The problem is that for a CD EXTRA the offsets embedded in the iso is absolute to the start of media, if we address those directly as a track the offsets are off. This cannot coexist with CD containing multiple tracks with relative to the track start iso's on each track. We need a solution to this that does the right thing but its certainly not trivial, the above does contain some of the solution (from an eyeball review of the code), but more needs to be done.. I'll look into this when more important issues has been dealt with for the 6.1 release, possibly together with a burncd replacement I'm working on when time permits... -Søren