Multi-session CDROM access... How?

[Mike McCarty]

Edward Dekkers wrote:
>>> If you fixated after the first session, you don't have multiple 
>>> sessions but multiple writes.  This is another issue.
>>
>>
>>
>> Hmm. Then what exactly is "Multi-session Mode"?
>>
>> Mike
> 
> 
> OK, let me try to explain.

Thank you for your kind reply.

> A CD-R has a table of contents. When you write files to it, it not only 
> writes the files, but the table of contents as well. It is this table of 
> contents that the reading device sees when you for example get a list of 
> files on the CD.

Yes, I am aware of this.

> In multi-session mode, what basically happens in the burning software 
> (if done properly), is that it reads this table of contents first before 
> doing anything else. You can tell the burning app to add, update and 
> even delete files. What you must understand is that a CD-R is not 
> erasable ever.

Yes, I am aware of this. I have always thought of it as being like a
regular PROM, one can program more bits to 0, but one can't turn
a bit back on. Now, I don't know which way bits are when the CDROM
is fresh from the factory, but I figured that once a bit is programmed
(to 1 or 0, whichever is "programmed") it can't go back.

And I figured that "deleting" from the disc meant adding a new mark
indicating "deleted". In this case, you seem to be saying that the
entire TOC gets marked as deleted. Then there must be something like a
linked list of TOCs. When a TOC gets deleted, then the deleted flag gets 
set in the TOC, a new pointer gets added, and a new TOC is written.

> Basically when you tell the burning app to add a file, it 
> writes that file plus a new table of contents including all the files 
> previously PLUS the new file. If you tell it to update a file, it will 
> write the new file completely, and in this case, when it finishes the 
> session and writes a modified table of contents, it points the file name 
> to the new position on the disk. The original file is ALSO there, but 
> because a disk only has one table of contents, which says the file 

I suppose you mean only one ACTIVE table of contents. Since bits can't
be "unprogrammed" on a CDROM, the old TOC must still be there.

> exists at point B now, not point A, the original file is essentially not 
> accessible so it looks like it's been updated. Same when you tell the 
> burning app to delete a file. It doesn't write ANYTHING file-wise, but 
> simply writes out a modified table of contents which does not have a 
> pointer for the erased file.
> 
> You sort of get what I mean? Multi-session basically keeps a disk 
> flexible by moving a table of contents.

You are using the word "moving" rather loosely, but I believe we are
on track.

> Only one table of contents is active (the latest one) at one time.

Ah, yes.

> Multiple Writes is basically the same EXCEPT that the burning app writes 
> a completely new table of contents every session WITHOUT ANY DETAILS 
> FROM THE PREVIOUS TABLE OF CONTENTS.

Ok. So then there is, from the perspective of the disc format, no
difference. The only difference is how much of the previously active
TOC gets merged with the new TOC. In one mode, everything from the
previous TOC which is not either (1) deleted or (2) updated gets
merged into the new TOC w/o change. In another mode, the entire
TOC gets ignored. In either case, only the latest (the ACTIVE, if
you will) TOC gets used by default. To use other TOCs one must
specify on the mount command which TOC to consider to be the ACTIVE
one.

> So, if you have session 1 with files A, B and C, then write a new 
> session with a file D WITHOUT the burning software knowing about the 
> previous session's table of contents (this usually happens through user 
> error), ONLY file D will be visible.

Hmm. The program I used (xcdroast) has an option to write in
multi-session mode, which I selected.

Actually, there are two options which may be selected or deselected.

The first, "write as multi-session" says, in the expanded
information "Write the CD in such a way, that it is possible to
append further data (in a new session) at a later time. Please note
that for the first session you need 22MB extra space on the CD-R/RW
and all additional sessions take 13MB each."

The other, "do not fixate after write" is explained as
"This prevents the CD-Writer from fixating (closing) the CD after
writing. You can use this to create an audio CD in several
steps. Just be sure to fixate after the last track. (Or use the
'Fixate CD-R/RW only' button.) Note: this does only work in
Track-At-Once-Mode."

I did not select the "do not fixate after write" when I created the
CD. IOW, I supposedly "fixated" each of the sessions. When I tried to
select "do not fixate after write", I got a pop-up warning me that
this might create an unusable CDROM, so I didn't try that.

> This is where the session mounting thingy you do becomes necessary. It 
> simply uses a different table of contents to the current active one. On 
> a properly burned multi-session disk this should really not be necessary.

Well, things are basically as I understood them. What I don't understand
is why xcdroast created the disc in the manner it did, not merging
the TOCs, and what different option selections I need to make in order
that this not happen again.

Other than trying each of the four combinations of those two options,
what should I do in order to understand what is going on? I have read
the web site, but this level of detail is not covered.

Perhaps I need to send an e-mail to the author. I just thought that
someone here might be well-acquainted with xcdroast.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!