Subproject: Find out everything that cdrecord -v -atip can find out

[scdbackup]

This ticket is a bit diffuse. Consider it as a stone pit from where to obtain tasks in case of personal boredom.

cdrecord -v -atip puts out a wealth of info about the drive and the inserted media. Various frontends use snippets of this output to make decisions. (See attachment for an example)

cdrskin -v -atip is much more sparse. That is in part because i do not really understand all output of cdrecord but mainly because libburn does not offer the needed information. (See attachment for an example)

I imagine the following info could be of use to frontends:

Revision : 'A201'

Device seems to be: Generic mmc2 DVD-R/DVD-RW.

Profile: CD-R

Profile: CD-RW (current)

Driver flags : MMC-3 SWABAUDIO BURNFREE

ATIP start of lead in: -11635 (97:26/65)

ATIP start of lead out: 359849 (79:59/74)

Manufacturer: CMC Magnetics Corporation

[scdbackup@…]

Output of cdrecord -v -atip

[scdbackup@…]

Output of cdrskin -v -atip

[scdbackup@…]

Sorry. Forgot to set the email address when submitting.

[lorenzo]

It appears that mmc_read_atip() could be a starting point for this. Unfortunately, at this time there is no API function to take advantage of this info and to expose it to an application that wishes to use it. Something like a burn_get_atip() would be nice. Another ticket or here?

[scdbackup]

No other ticket please.

One should check wether libburn.h offers an existing struct to which one could map the newly gained info. If there is none or if it seems hardly suitable, i would propose a new struct burn_info_atip (or so, the name should be well thought).

The eventual new API call should then fill that appropriate struct with all data available and the app may pick out what it deems interesting.

[lorenzo]

I found that this ticket could become a major task in the near future since cdrskin is now able to replace cdrecord for audio discs. I am one of the developers for a perl script called mp3roaster which takes ogg, mp3, wav and flac files and burns them to a CD. The trouble is that this particular front-end is unusable with cdrskin since it uses cdrecord's atip info to check the size of a CD before burning it. I would like to get mp3roaster working with cdrskin, but this ticket seems to be what holds that up for now. I will look into this in libburn/cdrskin and see if there is anything that can be used to get this info. It should be in the burn_drive struct somewhere, it's just buried somewhat and should be easy enough to dig up and expose to an app like cdrskin.

[scdbackup]

The task seems to be to dig it out of some MMC command reply.

libburn/mmc.c:

void mmc_read_atip(struct burn_drive *d)
{
        struct command c;
...
        c.dir = FROM_DRIVE;
        d->issue_command(d, &c);
        burn_print(1, "atip shit for you\n");
}

Unused and obviously not evaluating the reply which i suppose to be in c.

What output lines of cdrecord -atip are especially needed ?

[lorenzo]

I saw this function myself and had commented on its existance some time back. But it's very interesting that the function doesn't seem to do anything but issue a command. There is no indication of where the response is stored if in fact it's stored at all. The perl code that gets the time on the disc reads the entire atip info in a loop and picks out the lines:

ATIP start of lead in: -11635 (97:26/65) ATIP start of lead out: 359849 (79:59/74)

Actually, it picks out just the times on those lines and ignores the rest. It only uses what's in the parentheses and stores each part in a separate variable.

[scdbackup]

I inserted a test print in this function

void mmc_read_disc_info(struct burn_drive *d)
{
 ...
                d->start_lba = burn_msf_to_lba(data[17], data[18], data[19]);
                d->end_lba = burn_msf_to_lba(data[21], data[22], data[23]);

                fprintf(stderr, "libburn_experimental: start_lba = %d (%d %d %d) , end_lba = %d (%d %d %d)\n",
                        d->start_lba, data[17], data[18], data[19],
                        d->end_lba, data[21], data[22], data[23]);
...
}

which is called during burn_drive_grab().

The result with *blank* CD-RW is

libburn_experimental: start_lba = -11635 (97 26 65) , end_lba = 359849 (79 59 74)

while cdrecord reports with blank *and* non-blank CD-RW on -atip

  ATIP start of lead in:  -11635 (97:26/65)
  ATIP start of lead out: 359849 (79:59/74)

Regrettably the data reply for non-blank media shows no trace of above numbers within its first 32 bytes. So it stays a riddle how cdrecord gets the capacity for those.

[lorenzo]

Hm. This could be a good starting point. It's funny though that cdrecord is still able to get this info on non-blank media. But for a non-blanking front-end, this info is only needed if the disc is blank. Something to test maybe. In fact, with testing of mp3roaster and wodim mp3roaster tells me that audio files will fit on a non-blank CD and then proceedes to try to burn the disc without blanking it. I would get the same result using real cdrecord. Printing this info only on a blank disc may actually work better with mp3roaster since it would die before trying to process the audio files if the disc is not blank. Hm. A possible use case where we may not want full cdrecord emulation.

[scdbackup]

In mmc_read_toc() which is called for non-blank media there is another "lba" computation. But this does not use our magic numbers.

I will introduce an API function which returns drive.start_lba and drive.end_lba. The conversion function for Minute:Second:Frame format is already part of the API.

No lines "ATIP start of ..." from non-blank media will be a bug and not a feature for now. (One could introduce an --option to cdrskin which makes it a feature, though.)

[scdbackup]

Revision

On blank CD-RW :

$ cdrskin/cdrskin dev=0,1,0 -atip
cdrskin 0.2.3 : limited cdrecord compatibility wrapper for libburn
cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1'
cdrskin: scanning for devices ...
cdrskin: ... scanning for devices done
cdrskin: pseudo-atip on drive 0
scsidev: '0,1,0'
Device type    : Removable CD-ROM
Vendor_info    : 'HL-DT-ST'
Identifikation : 'DVDRAM GSA-4082B'
Driver flags   : BURNFREE
Supported modes: SAO RAW/R96R
cdrskin: status 1 burn_disc_blank "The drive holds a blank disc"
cdrskin: burn_drive_get_write_speed = 1764  (10.0x)
ATIP info from disk:
  Is erasable
  ATIP start of lead in:  -11635 (97:26/65)
  ATIP start of lead out: 359849 (79:59/74)
  1T speed low:  10 1T speed high: 10

On unused CD-R:

[...]
  ATIP start of lead in:  -11077 (97:34/23)
  ATIP start of lead out: 359848 (79:59/73)
  1T speed low:  24 1T speed high: 24

(The speed glitch is because i currently only get maximum speed from libburn and peeking into the data buffer of the originating mmc command did not yield any number that resembles cdrecord's "speed low".)

Interestingly a writable DVD+R does not yield start_lba and end_lba. It is evaluated as blank by some other mmc_call, but here in mmc_read_disc_info() one can distinguish it from a blank CD:

[...]
cdrskin: status 1 burn_disc_blank "The drive holds a blank disc"
cdrskin: burn_drive_get_write_speed = 5540  (31.5x)
ATIP info from disk:
  Is erasable
  1T speed low:  31 1T speed high: 31

[lorenzo]

All initial tests with mp3roaster pass so far. Mp3roaster still requires either a cdrecord link to cdrskin or a :%s/cdrecord/cdrskin/g in the script, but I can fix that since I am one of the developers of the project. I intend to make the burning app configurable so that it will be a config file change to make mp3roaster use cdrskin. This will make mp3roaster the first audio burning app to officially support the use of cdrskin if my tests continue to pass.

[scdbackup]

Makes me proud to become officially supported :))

[scdbackup]

The oldest available MMC draft

http://www.t10.org/ftp/t10/drafts/mmc/mmc-r10a.pdf

describes in table 77 a very interesting info set.

mmc.c: "MMC_GET_ATIP [] = { 0x43, 2, 4, ..." matches nicely tables 67 and 68. The byte "4" would be code "0100b" mentioned in table 68 and 77.

[scdbackup]

Revision 302 :

Good news: cdrskin now gets real ATIP info.

Bad news: In MMC specs ATIP mutated to a twisted fake meanwhile. Speed info is now hidden in Orange Book and newer media make ATIP quite questionable.

Whatever: bug-or-feature is gone. cdrskin -atip reports lead-in and lead-out address now for blank and for non-blank media (even for closed CD-R).

Lorenzo: If you need a feature in that aspect, describe your wishes :)

[lorenzo]

Actually this is fine. I still have the feature I need, since cdrskin reports disc status. In mp3roaster I can just make it die without processing files and trying to burn based on the disc status. It would only work for cdrskin, but may still be worth doing if I can do it in such a way that it doesn't interfere if someone chooses to use cdrecord or wodim instead of cdrskin. Actually, trying to burn a non-blank audio disc is a shortcoming of mp3roaster which needs to be addressed no matter what burning app is used, although it may be difficult to fix using cdrecord/wodim. But this goes way beyond the scope of this ticket and possibly beyond the scope of libburn/cdrskin as well. For now we keep the lead in and lead out times in for all discs, since the information is supposed to be available whether the disc is blank or not. It's up to me and the other mp3roaster devs to fix our bug there. :)

[scdbackup]

For testing blank-or-not-blank with cdrecord i used to make a test on /dev/cdrom wether it would return some data. But that would only work with -data tracks and not with audio.

Astounding that cdrecord does not tell the blank status.

[scdbackup]

cdrecord does tell. One just has to ask:

On non-blank data CD-RW

$ cdrecord dev=0,0,0 -toc
[...]
first: 1 last 1
track:   1 lba:         0 (        0) 00:02:00 adr: 1 control: 4 mode: 1
track:lout lba:     64062 (   256248) 14:16:12 adr: 1 control: 4 mode: -1

On blank CD-RW

$ cdrecord dev=0,0,0 -toc
[...]
cdrecord: Input/output error. read toc: scsi sendcmd: no error
CDB:  43 00 00 00 00 00 00 00 04 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
Sense flags: Blk 0 (not valid) error refers to command part, bit ptr 0 (not valid) field ptr 0
cmd finished after 0.000s timeout 40s
cdrecord: Cannot read TOC header
cdrecord: Cannot read TOC/PMA

This could earn me the request to support -toc . eh ?

[scdbackup]

There is cdrskin option -toc now :)

It is kindof an extended -atip (like with cdrecord, too).

Audio looks like this:

ATIP info from disk:
  Is erasable
  ATIP start of lead in:  -11635 (97:26/65)
  ATIP start of lead out: 359849 (79:59/74)
  1T speed low:  4 1T speed high: 10
first: 1 last 4
track:   0 lba:         0 (        0) 00:02:00 adr: 1 control: 0 mode: 0
track:   1 lba:     55782 (   223128) 12:25:57 adr: 1 control: 0 mode: 0
track:   2 lba:     58464 (   233856) 13:01:39 adr: 1 control: 0 mode: 0
track:   3 lba:     61146 (   244584) 13:37:21 adr: 1 control: 0 mode: 0
track:lout lba:     78198 (   312792) 17:24:48 adr: 1 control: 0 mode: -1

( "mode:" is guessed via: (control&7)>=4 )

[scdbackup]

Four single-track sessions of data look like this

first: 1 last 4
track:   1 lba:         0 (        0) 00:02:00 adr: 1 control: 4 mode: 1
track:   2 lba:     75614 (   302456) 16:50:14 adr: 1 control: 4 mode: 1
track:   3 lba:    102249 (   408996) 22:45:24 adr: 1 control: 4 mode: 1
track:   4 lba:    128884 (   515536) 28:40:34 adr: 1 control: 4 mode: 1
track:lout lba:    148619 (   594476) 33:03:44 adr: 1 control: 4 mode: -1