From owner-freebsd-hackers Sat Feb 1 15:35:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA14283 for hackers-outgoing; Sat, 1 Feb 1997 15:35:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA14278 for ; Sat, 1 Feb 1997 15:35:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA06872; Sat, 1 Feb 1997 16:33:52 -0700 From: Terry Lambert Message-Id: <199702012333.QAA06872@phaeton.artisoft.com> Subject: Re: Mounting CD-ROM when data not on first track To: taob@risc.org (Brian Tao) Date: Sat, 1 Feb 1997 16:33:52 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Brian Tao" at Feb 1, 97 01:47:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On a whim, I bought the "Star Trek: First Contact" soundtrack > today on CD. It has a filesystem on track 14 of the disc with > Quicktime trailers of the movie. Trying to mount this on FreeBSD > 2.2-BETA gives me this error: > > cd0(ncr0:6:0): BLANK CHECK req sz: 16 (decimal) asc:64,0 Illegal mode for this track > cd0(ncr0:6:0): error code 0 > > I presume this is because mount_cd9660 only looks for data on > the first track of the CD? How would I mount the data track from such > a CD? This is the toc dump from cdcontrol: > > Starting track = 1, ending track = 14, TOC size = 122 bytes > track start duration block length type > ------------------------------------------------- > 1 0:02.00 4:21.27 0 19452 audio [ ... ] > 14 53:54.17 18:30.36 242417 83136 data > 170 72:22.53 - 325553 - - I believe this is a perfectly legal thing to do, actually. One wonders why the cd device starts at the raw track one instead of the first data track in any case... | a)Multisession Volume Recognition Sequence | The Volume Recognition Sequence shall begin at the 16th logical sector | of the first track of the last session on the disc. | | This volume recognition sequence supersedes all other volume recognition | sequences on the disc. The interpretation of the Volume Recognition | Sequence is otherwise unchanged. | | For example, consider a disc that contains 3 sessions, where session 1 | starts at 00:00:00, session 2 starts at 10:00:00, and session 3 starts | at 20:00:00. The Volume Recognition Sequence for this disc would start | at Minute:Second:Frame address 20:00:16. | | This technique is compatible with the CD-Bridge multisession technique. Have you determined whether the disc has a PVD or an SVD on it? The PVD is supposed to be overridden by an SVD, if present. This is consistent with the idea that the quicktime data is viewable from Windows95 or NT. Most likely, there exists Unicode extensions on the disk to enable use of "long names". The Microsoft specification for this type of disc is "Joliet". You can determine if this is the case by looking at the contents of the SVD: | Use a SVD with a UCS-2 (UNICODE) Escape Sequence. | The UCS-2 escape sequences used are: (25)(2F)(40), (25)(2F)(43), | or (25)(2F)(45). | The default setting of bit 0 of the SVD "Volume Flags Field" is ZERO. | The Unicode Wide characters shall be recorded in "Big Endian" | (Motorola) format. | Special Directory Identifiers are recorded as single byte names | containing (00) or (01). | SEPARATOR 1 and SEPARATOR 2 are encoded using an equivalent 16-bit | code point. | Sort ordering is unchanged, except that all justification pad bytes | are to be set to (00). There are additional rules for directory hierarchy recognition, depth greater than 8, and 128 character length limits. There are the standard "DOSsy" restrictions on file and directory name characters. Finally, it seems to me that the CDROM device should impose "slices" on its own, and it makes sense to me that 'd' is the whole disk and that 'c' is the first data area. This would have allowed the disk to be mountable as well, even if it is a Joliet disk using an extended volume recognition sequence (since such disks are required to be backward compatible in all cases, according to the Joliet "standard"). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.