NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/alt/cdrom/5281

Internet Message Format | 1992-12-22 | 4.0 KB

Path: sparky!uunet!mcsun!Germany.EU.net!tools!jk
From: [e-mail] (Juergen Keil)
Newsgroups: alt.cd-rom
Subject: Re: multi-session Photo CDs (was Re: Reading CD-I)
Date: 21 Dec 92 21:19:57
Organization: TooLs GmbH, Bonn, Germany
Lines: 69
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
NNTP-Posting-Host: leo.tools.de
In-reply-to: [e-mail]'s message of Mon, 21 Dec 1992 10:49:04 GMT

In article <[e-mail]> [e-mail]
(Adrie Koolen) writes:

> In article <[e-mail]> [e-mail] (Juergen Keil) writes:
> >But things get really interesting with a real 2 session Photo-CD I've
> >got: Here you have an updated ISO 9660 filesystem starting on track 3
> >pointing to pictures in track 2 and track 4 (overwriting the ISO 9660
> >filesystem in track 1 which (obviously) has only pointers to the
> >pictures from the first session).
>
> How are the blocks numbered? Normally, in an ISO9660 fs, the first block
> is block 150 in the track. If files are stored in previous track, one
       ^^^
This block has the address 0min 2sec frame#0; normally it is the first
user accessible block on a CD (e.g. all SCSI cd-rom drive I know address
this block with a logical block address of 0).  This block is logical
sector# 0 in an ISO9660 fs.

> should use negative numbers, or what? Or do they use absolute block
> numbers, in stead of track relative numbers?

Absolute block numbers.  If you have a session starting at min M, sec S,
frame# F (which is the ISO9660 block# x = (M*60+S)*75+F - 150, assuming
2KByte ISO9660 logical sector size), you have ISO9660 volume descriptor
blocks starting at block# x+16.

> >I'm surpised that I havn't seen someone complaining that he still can
> >only access the first session of a multi-session Photo-CD on his brand
> >new multi-session drive, because the OSs ISO 9660 filesystem code is
> >unaware of the updated directory structure of the disc!
>
> I suspect that the multi-session MSCDEX low-level device driver recognizes
> a multi-session CD and presents only the last fs to MSCDEX.

Perhaps the ISO9660 filesystem code (MSCDEX?) should ask the device driver
for a 'last session offset' and use this offset for reading the volume
descriptor from the cd.  The Toshiba XM-3301BC drives have a vendor unique
command READ DISC INFORMATION which returns a 'last session offset'. For the
multisession disc I mentionen in my previous posting the drive returns

    Vendor   : TOSHIBA
    Product  : CD-ROM XM-3301TA
    Revision : 2162
    first track : 1
    last track : 4
    track  1 starts at  0 min,  2 sec, frame#  0
            adr = 1, control = 4, data track, digital copy prohibited
    track  2 starts at  0 min,  9 sec, frame# 65
            adr = 1, control = 4, data track, digital copy prohibited
    track  3 starts at  3 min, 16 sec, frame# 35
            adr = 1, control = 4, data track, digital copy prohibited
    track  4 starts at  3 min, 22 sec, frame# 37
            adr = 1, control = 4, data track, digital copy prohibited
    lead out track at  3 min, 49 sec, frame#  8
    CD-ROM/XA disc
    last session at min 03, sec 22, frame# 53

Unfortunatelly the 'last session' information that the drive returns is
rather useless, since it simply points 16 sectors into the last track (track
4) which only contains the pictures recorded in the second session!  (The
last (photo recording) session starts with track 3 and I would expect a
'last session' information like 3 min, 16 sec, frame# 41, which would be a
useful pointer to the last session; this is either a bug in the Toshiba's
firmware or the photo goofed things up).  My multisession ISO9660 file
system code ended up with reading the disc's table of contents and scaning
each data track at beginning_of_track+16 if there is a ISO9660 volume
descriptor present on that track to find out the latest ISO9660 fs.
--
Juergen Keil          [e-mail] ...!{uunet,mcsun}!unido!tools!jk