Multi session capabilities like cdrecord -multi

[scdbackup@…]

This ticket is mainly a request to start getting a plan about how multi session is supposed to work and possibly to get a decent documentation snippet first.

I got neither experience with multi session nor much motivation to use it. Nevertheless, cdrskin would need -multi for completeness and competitiveness in comparison to cdrecord.

I understand that cdrecord -multi with a ISO-9660 file system needs cooperation by mkisofs. No idea what precautions would be required by other image formats like raw archives.

[scdbackup]

As of revision 368, cdrskin experimentally accepts option -multi . Following sessions in mode TAO (without blanking, of course) position themselves at CD areas where they can be read by the Linux CD-ROM driver with a little help of the user.

cdrskin/compile_cdrskin.sh -experimental
cdrskin/cdrskin ... -tao padsize=300k -multi /dvdbuffer/fertig.iso
cdrskin/cdrskin ... -tao padsize=300k /dvdbuffer/fertig.afio

The second session can be located by

cdrskin/cdrskin ... -toc

which replies something like

track:   2 lba:     75614 (   302456) 16:50:14 adr: 1 control: 4 mode: 1

With data tracks the "lba" address is the number of 2048 byte blocks. The afio archive can then be read by help of dd and this address:

dd bs=2048 skip=75614 | afio -t -

[scdbackup]

The libburn API function which implements cdrskin option -multi :

/* Sets the multi flag which eventually marks the emerging session as not being
   the last one and thus creating a BURN_DISC_APPENDABLE media.
     @param multi 1=media will be appendable, 0=media will be closed (default)
*/
void burn_write_opts_set_multi(struct burn_write_opts *opts, int multi);

[pygi]

This ticket also applies to libisofs. Once libburn has proper support, we should engrave it into libisofs as well.

[scdbackup]

There seems not to be much connection between cdrecord multi-session and mkisofs. The only interaction is to obtain the two -msinfo parameters for mkisofs option -C (i.e. lba of first track of last session, lba of the future session) and to append the output of mkisofs as first track of the next session.

I got no idea what mkisofs does with these two numbers and with the data read from the old ISO image (not via cdrecord but via the device driver triggered by option -M).

libburn is (hopefully) learning to produce the two numbers. The track lba can be determined from TOC. The future track lba is guessed for now according to cdrtools-2.01.01a13/README.multi . Obviously cdrecord does not read its -msinfo from TOC. (Drive makes different noises.)

[scdbackup]

About cdrskin -msinfo :

My both drives now are willing to hand out Next Writeable Addresses for an appendable CD. Not too much stderr stuff is emitted.

On libburn level:

The track lba can be read from the tradition libburn TOC structure. The Next Writeable Address can be obtained by a new API function

/* ts A61110 */
/** Read start lba and Next Writeable Address of a track from media.
    Usually a track lba is obtained from the result of burn_track_get_entry().
    This call retrieves an updated lba, eventual nwa, and can address the
    invisible track to come.
    The drive must be grabbed for this call. One may not issue this call
    during ongoing burn_disc_write() or burn_disc_erase().
    @param d The drive to query.
    @param o If not NULL: write parameters to be set on drive before query
    @param trackno 0=next track to come, >0 number of existing track
    @return 1=nwa is valid , 0=nwa is not valid , -1=error
*/
int burn_disc_track_lba_nwa(struct burn_drive *d, struct burn_write_opts *o,
                                int trackno, int *lba, int *nwa);

There still remains one large riddle:

How does cdrecord get the NWA without spinning up the drive ? (The drives spin up with cdrecord -toc but not with -msinfo)

I had some problem to calm down my NEC after performing MMC command 52h READ TRACK INFORMATION. Its LED stays bright although the drive is released and cdrskin ended. Spinning makes the usual noise but does not end after the usual 20 seconds. One can eject the drive without problems, though. A remedy was to read a few bytes after cdrskin has ended.

Meanwhile cdrskin does an extra release-grab cycle to get the drive into a noisy state which ends after a few seconds. An extra burn_disc_read_atip() did only help as long as the other drive was not busy ... very weird.

The noise is triggered by libburn's drive grabbing (which is so fat that it also includes reading TOC) but it is perpetuated by inquiring NWA via command 52h. ... until one shakes the drive sufficiently.

My other drive, the LG, insists in getting write parameters before it is willing to hand out a valid NWA. The setting of write parameters does not influence the problems with the NEC.

If no NWA is handed out by the drive, it is guessed from the leadout address by adding 11400 resp. 6900.

---

Given the high density of unexpected problems and workarounds this feature seems to need testing on as many drives as possible.

---

[scdbackup]

Revision 380

The multi-session features are now enabled in the normal build of cdrskin-0.2.5 but can only be used in write mode -tao.

[scdbackup]

I would be glad if somebody could provide me with a real multi-session usage example to be included in cdrskin/README.

[scdbackup]

(test wether only ticket 90 is broken or everything else, too)

[scdbackup]

My attempts to implement SAO writing to appendable disks failed for now.

MMC is not very informative about multi session aspects of command 5Dh SEND CUE SHEET. I am unsure about the demands regarding that cue sheet (which describes in advance the upcoming burn to the drive). MMC talks of "absolute disc location". That would be addresses beginning with the Next Writeable Address of the session, i guess. But a cue sheet computed with such an nwa offset is rejected by both of my drives. A cue sheet starting around address 0 is accepted by one of my two drives. None is willing to write data.

No wonder. cdrecord fails on both drives too. Same SCSI error conditions as i got with no nwa offset.

I don't see much chance of further progress without a drive that demonstrates its ability to burn SAO to an appendable disk via cdrecord and without any specs which relate SAO and appended sessions.

Please everybody test wether one of your drives has success with this sequence of cdrecord commands on a CD-RW:

cdrecord -v dev=... padsize=300k blank=fast -multi -data -sao imagefile
cdrecord -v dev=... padsize=300k -data -sao imagefile

Error messages from second cdrecord run are like

CDB:  2A 00 00 00 39 26 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 02 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
...
cdrecord: The current problem looks like a buffer underrun.
cdrecord: Try to use 'driveropts=burnfree'.
cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up.

(The first being quite informative, the latter being rather deceiving.)

If a suitable drive can be found i would prepare tests to try out my currently three theories about SAO on appendable disks:

- The CUE sheet is composed like for single session and the drive does the rest. cdrecord's behavior supports this theory somewhat.

- The CUE sheet is composed with disc locations beginning at the next writeable address. This is what i would read from MMC specs, but shows a different behavior with one of my drives than this drive does with cdrecord.

- The CUE sheet has to be composed from the CUE sheet of the previous sessions plus the CUE sheet records of the session to come. This would match the MMC specs too, but would be expensive to implement. I am not aware how to retrieve the previous CUE sheets resp. wether they can be reconstructed from TOC. (CUE sheets become TOC info. Question is wether the reverse mapping ins unique.)

For now, work on SAO to appendable disks is halted, i fear.

[pygi]

Libburn part implemented. Looking forward to libisofs implemenation.

[scdbackup]

The libburn part isn't complete yet. It is restricted to TAO. I would need a tester with a drive which can do follow-up sessions with cdrecord -sao.

[scdbackup]

Multi-session is spreading into libburn DVD recording. See ticket #13 , comments of today.

[vreixo]

Multisession is already working, please download last version.