Last session size limiting range of readable sectors

Hi :wink:

I’m writing a windows application in C# which needs to be multisession-aware.

I’ve done some reading-around to attempt to get up-to-speed, as I’m a relative newcomer to the world of CDROM standards; ECMA-[119, 6, 35, 130, 168], MMC-3, Joliet spec. - admittedly a fair amount of it was skimmed but I feel I have a fair understanding.

I’m currently stalled on something which is central to the application and should be simple; reading sectors [both raw and user-data only] from a multisession CD which is verifiably readable [according to IsoBuster 1.5].

Prior to the reads, I’ve used the Win32 IOCTL_CDROM_READ_TOC_EX with CDROM_READ_TOC_EX_FORMAT_FULL_TOC to return, amongst other things; a list of sessions, the tracks that each session consists of, the start of each track and each session’s lead-out.

These details have been checked against IsoBuster to ensure I’ve read them correctly and indeed I’ve read and displayed various sectors (mainly 16 & 17) and compared them with ISO Buster’s ‘view sector’ dialog as a sanity-check.

I have a CD that has six sessions, the last of which (closed) has 18220 sectors (upto start of lead-out).

If I attempt to read sectors from the cd in the range 0-18219 (which should fall within the first session, whose lead-out begins at LBA 61687), all is well, but any higher and the read attempt fails, despite using various methods to attempt a read (Win32’s ReadFile from the CDROM device handle, SPTI of MMC’s ‘READ CD’ and ‘READ CD MSF’). The same effect is noticeable with different multisession cds [dependent on the size of the final session in each case] yet is absent on single session cds.

Clearly there’s a gap in my understanding. Anyone know what’s happening?


PS. Am I correct in assuming that a M:S:F address always translates to an LBA using the formula:
(M * 60 + S) * 75 + F - 150 - even across session boundaries ?

I’m confused - don’t quite understand about your LBA range.

You mentioned reading 0-18219, is that LBA range for 1st session or last session?

Also, you mentioned 18220 sectors, is that for just last session?

As I understand it, LBAs start at the beginning of the first track of the first session and extend to the end of the lead-out of the last session (but I may be mistaken which could certainly start to explain the confusion).

Assuming I’m not mistaken then ‘yes, within the first track’ and ‘yes, the 18220 sectors is just for the last session, as the first session size is 61687 excluding lead-out’; as the range is smaller than the range of LBAs comprising the first track and starts in the same place.

What I was attempting to show is that although I’m reading from outside the sixth session, the size of the sixth session seems to be being used to limit the allowable range of LBAs that may be used when reading.

Further update: Prior to the previous post I’d written a small C++ console app which only contained code to open a device handle, loop to accept a sector number, read the sector and dump it to the console window. I’m much more familiar with C++ so wanted to ensure that I hadn’t made some mistake in C#, to which I’m a newcomer. I also wanted to reduce the chance of the problem I’m describing being caused by some side-effect in other parts of the code.

Unfortunately the console app only verified what I’d been experiencing in the C#.

Disturbingly though, without making any changes to the C++, the reads have now started succeeding intermittently (at first sparsely, now frequently almost always succeeds). Somehow, this is worse as I’ve no idea why it wasn’t working before BUT happily now that I’m able to read the PVD and SVD from the first track of each session I’m more sure that I understand how it all fits together.

Thanks for your promt reply. Do you have any vague ideas about what might cause such a phenomenon?

I at first thought it was related to my inappropriate use of IOCTL_CDROM_GET_LAST_SESSION which barely has documentation but testing showed that inclusion/exlusion of this call makes no difference to the addresses i’m getting from IOCTL_CDROM_READ_TOC_EX.

This may not be in your case, but, in my experience of multisession CDs, it depends on the reader. Some readers does exactly the same behaviour that you are describing. On others this problem never happen.

I suggest you try another reader and confirm that it is the reader at work.

Also, it may be another program interferring with your reads. Do you have any tray CDRW software running, e.g. clonecd tray, directcd, etc.

I did as you suggested yet the same behaviour was exhibited in my CDRW and DVDROM.

I’m starting to think the intermittent problem is caused by the disk as I’ve created a new multisession disk and so far have had no problems.

Most strange though.

thx for your suggestions ;o)