CDROM device and CDFS numberings

I’ve been experimenting to compare cdpranoia with ‘native’ ways to rip using the CD_ swis, etc. I’m trying to make sense of what seems like inconsistency in the device and CDFS numberings.

On my ARMiniX I have the internal optical drive. I’ve added an external drive connected via USB and set !Boot to have two CDROM drives.

If I use CD_Inquire the devices are listed as device 0 and device 2. Both return a handle of zero with this swi. Device 1 doesn’t exist. But the two CDFS icons show :1 and :0 and will work OK. This implies the ‘internal’ device numbers are 0 and 2 but the CDFS numbers are 0 and 1. This is confirmed by cdparanoia working if I use -d CDFS::0 or -d CDFS::2, and -d CDFS::0 fails.

This came to my attention when writing a simple control program to work out the time offsets into a file generated using cdparanoia to save a series of tracks into one wave file. Means I need two different values to specify the target drive. One for the CD_ swis, another for cdparanoia.

What seems to be happening is that both the internal (NOT USB) drive and the external (USB) drive are both given card = 0 lun = 0 by the system. And that device 1 seems to be ‘reserved’ for any second ‘internal’ drive. However the USB drive is being allocated ‘0’ for both drive and CDFS, leaving the internal drive with CDFS 1 and drive number 2! Should this be happening?

ARMiniX 5.21 (R-Comp)

Jim

Aha! Just found CDFS_ConvertDriveToDevice which helps in one direction! :-)

Still puzzled by the numberings, though. Only the device number changes, not the ‘card’ etc. Maybe this is because the CD_ swis were never really finished! ?

Jim

In what practical circumstances will the ‘card’, ‘lun’, and ‘handle’ of a CDROM drive have any value other than ‘0’?

I have an internal (non USB) drive and an external (USB) one. They have different drive numbers, but their card/lun/handle values are all zeros. This leaves me to conclude that at least so far as filing systems (cards) are concerned the value actually used is zero. So is it safe when scanning a machine to find drives to assume these are always zero? The problem here is that CDFS_ConvertDriveToDevice returns a drive value, but doesn’t return values for card/lun/handle, so if these aren’t always zero some added searching will be needed.

Jim

The LUN (Logical Unit Number) of a single device will always be 0. Non-zero values would only be applicable to things like autochangers – and I haven’t heard of one of those in years, though they used to exist.

Thanks, Dave. That means I can take for granted that lun will be ‘0’. I wasn’t clear what LUN meant.

For now I’ll assume that card will also always be ‘0’. My guess is that this may not be true if someone has/had a CD/DVD drive connected via a podule. But I have no way to check this now as my last RiscPCs went a year ago. They did use genuine SCSI and some SCSI Optical drives.

The problem I hit was that when using cdparanoia I was having to specify the drive in terms of the CDFS number, but the CD_ SWIs need the device number, etc. I’m aiming at producing either one test prog that can do either as the user chooses, or two apps that do the same rip process, but one using cdparanoia and the other the plain CD_ calls, perhaps with some overlap, alignment, and consistency re-rips. But have both apps user-driven by the same input for convenience.

Want to see what trade-off there may be between the level of checking and the rip speed. Alas, cdparanoia is pretty slow on my ARMiniX. Other programs like MM2 are much faster, but I don’t know what checking they do, and some CDRs can be ‘difficult’ to read faithfully. Getting the wrong samples quickly isn’t what I’m after. ;→

Doing this partly as a learning/investigation, partly because for classical music I often want two specific features. One being multi-track rips to a single wave file¹. The other being a printout out of the timings of the offsets into that file of the successive tracks. With the CD_ swis I can read the frame info on the tracks to generate the latter, whereas for cdparanoia I have to parse its time output report text which is a PITA. So I’m hoping I can do a native rip that works OK, and may be faster. :-)

Jim

¹ Ripping programs like MM2 often only let you rip to ‘one file per track’ which means I’d then have to stitch together the tracks. I can automate that, but it adds the problem of possible misalignements between individual track rips.

In the good old days, when periphery was connected via SCSI, we had the possibility to use up to 4 SCSI cards in one RISC OS computer. In SCSI world, this meant having SCSI IDs 0-31, but CDFS insisted on the “card” thing.

For LUNs, there were two usages in practice: CD changers, and the Panasonic “PhaseChange” drive, which was a CD-ROM combined with a random access MO-like device. The CD-ROM lived on LUN 1, IIRC.

If you want to experiment with all that “extract audo from a CD” stuff, you could do a lot worse than to have a look at one of my early “frameworks” for Audio CD extraction:
http://www.huber-net.de/readaudio.zip

It is in plain old BBC BASIC, complete without GUI frontend and proper error handling, and (therefore?) extremely simple to understand. It has code to directly use many known command sets via SCSI (and therefore USB), and also CDFS CD_ReadAudio. Make sure to read the !Help file before trying to use it.

Thanks, Steffen! I’ll have a look. :-)

At present I’m experimenting with trying to make ‘overlapping’ reads using the CD_ swis to check the alignment and consistency of the ripped sections of data. Aim being something that does some checking but might be faster than cdparanoia and ‘native’ rather than a port.

Jim

Is there any written documentation on the various areas Steffan’s code deals with? As on some other occasions I’m trying to make sense of how things work by looking at his BASIC code when I’ve not used BASIC for years. So I’m trying to chase down how each PROC, etc, relates and why specific values get poked into specific swis for specific reasons.

At present I’m trying to understand two issues:

1) How the MMC speed settings are made, and how to direct these to a specific device. I’ve noticed that the CDFS => device numbers mapping seems to be the same as the SCSI device numbers, but don’t know if this is always the case.

2) If there are any advantages to using one route rather than another. e.g. I’m currently using the CD_ swis for ripping, but is there an advantage in using one of the other sets like the SCSI_ ones? Or am I not understanding that? [I’m only interested in ripping audio CD/CDR/CDRW. Not in data discs.]

I’ve got a simple cdparanoia/CD_ comparison app working, but at present they both seem to be the same (low) speed for both my drives (about x4). Hence I’m wondering about winding up the speed to see how they compare at other speeds.

Jim

1) How the MMC speed settings are made,

IIRC setting MMC speed has never worked.

IIRC setting MMC speed has never worked.

My memory – as ever – is unreliable. But Steffan did let me have an MMC speed setting program some years ago for my Iyonix and I think that did work. However I guess this is a hit-and-miss affair depending on the hardware.

FWIW I’ve managed to tweak my test programs. CDparanoia rips at about x3 and my own lighter process at about x8. Much the same speeds for the internal and external drives I’m using. If I can maintain x8 and get good results I won’t be concerned about trying to change the speed in practice. Fingers crossed! :-)

The only ‘check’ I’m doing with my light rip is regarding alignment. i.e. I rip in chunks 5 sec + 1 frame in length. Then take the next rip starting 5 sec later. Then check that the +1 frame in the ‘earlier’ rip has the same values as in the first frame of the later one. Save the 5sec chunks in sequence and print a warning if the values in the overlapped frame don’t match.

Currently chasing minor bugs, but the resulting wave files are generally identical when I rip a decent quality ‘commercial’ disc. And no sign of any alignment errors. However the real test will be CDRs up to more than 10 years old! I expect cdparanoia to struggle with those and to see errors from my method.

Jim

@Jim and @Chris: as far as I am aware, none of the generic CDFS drivers support setting the read speed via *CDSpeed for MMC compatible drives. However, my tools certainly work for MMC drives.

@Jim, there is written documentation for my code: the SCSI2 standard, the various MMC standards and the Acorn SCSI documentation. It is not really difficult to understand, but a bit time consuming to put it all together.

If the CD_ SWIs are working for you, I would stay with them, because the API is easier to use. But if you want to have full control over the device, the SCSI_Op is the only way.

Jim: My memory may well be even less reliable than yours. Hopefully someone can be authoritative in a response. Steffan?

If the CD_ SWIs are working for you, I would stay with them, because the API is easier to use. But if you want to have full control over the device, the SCSI_Op is the only way.

Understood. At present I’m happy enough with the CD_ swis as x8 is fast enough for me. Chances are, a higher speed would just make read errors more likely anyway! :-) However if/when convenient, I’d welcome some pointers sometime to where the MMC + relevant SCSI documentation may be. If only because one of my reasons for trying to write programs in this area is to help me understand what I’d need to add to the ROSS documentation I’m still building and hope to publish in fuller form when I can.

FWIW I may still have my old Acorn SCSI manuals somewhere if they might help me. Plus the PRMs. Alas, they weren’t much help for the CD_ SWIs! :-/

IIRC your MMC speed prog worked when I tried it some years ago, but I have no idea how it works! 8-]

Also, MusicMan2 seems to rip at a higher speed, so I guess it does use something like MMC/SCSI. But for obvious reasons I can’t look at the source code of that.

Once I’ve finished with them I’ll put my test/demo ripper up so others can have a look if interested. Just want to tweak a few details so it is easier to use, then write a !Help file for it.

Jim

OK, FWIW I’ve now put up a test version of the simple programs I wrote to compare different rip methods. CDParanoia versus my plain ripframes. Its at

http://www.audiomisc.co.uk/software/ClassicRip.zip

Here the two give the same results for commercial discs, but ripframes runs at about x7 whereas cdparanoia runs at about x3. Its aimed at making ripping multitrack works into a single file easier. So it also generates timing files for such rips.

Jim

Apologies! The version of ClassicRip I put up yesterday had a bug. I’ve now replaced it with a bugfixed version.

Jim

Currently puzzled that I can’t get my ClassicRip program to work on my Iyonix. Not yet examined it in detail, but it looks like the CDFS call to get the device number from the CDFS number returns a strange result (values like 24 or 25) so the rest of the program can’t interrogate the drive to find the disc details.

Jim

it looks like the CDFS call to get the device number from the CDFS number returns a strange result (values like 24 or 25)

I believe that’s correct behaviour. The number returned by CDFS_ConvertDriveToDevice is actually composed as follows:

• Bits 0-2 = SCSI device
• Bits 3-4 = SCSI card
• Bits 5-7 = SCSI LUN
• Bits 8-15 = drive type (my memory is a bit hazy but I think this basically indicates which driver is being used, or for very old drives the make/model of the drive)

Looking at your ClassicRip sources, it looks like you need to update your CDFS_ConvertDriveToDevice calls to extract the card & LUN from the returned ID. Then your code should work.

Long ramble about SCSI device IDs below:

One thing you have to realise with the Iyonix is that (as far as the OS is concerned) the drives aren’t connected via SCSI. This causes problems because the CD SWIs internally use SCSI device IDs to identify drives. So even though the drive isn’t accessible via the SCSI SWIs, the ATAPI module needs to make sure it has a SCSI ID assigned to it in order to allow it to register the drive with the CD modules.

Unfortunately, due to the way that USB devices can come and go at runtime, there’s no easy way for the ATAPI module to get itself a fake SCSI ID. In old OS versions (about 2 years ago), CDFS used to search for drives starting from SCSI card 0. This meant that on startup the ATAPI module would “claim” SCSI devices 0 and 1 on SCSI card 0. But as the drives aren’t connected via SCSI, the SCSI module wasn’t made aware of that claim. So it would think that card 0 is still free for use, and if you were to connect a USB CD drive it would most likely be given device 0 card 0 as well. That would then block that device from registering with the CD drivers because both the ATAPI drive and the USB drive would be sharing the same ID.

To solve this problem I changed the search order that CDFS uses when it looks for drives on startup. So now it will start from card 3 and work down to card 0. This means ATAPI (and anything else which uses fake SCSI IDs, e.g. CDFaker) will generally assign themselves IDs belonging to SCSI card 3. Which means cards 0-2 will be left free for legitimate SCSI devices.

One area for improvement in the future would be to rewrite the ATAPI module so that it does expose the CD drives as SCSI devices. This is possible because ATAPI is quite literally “SCSI-over-ATA”, the same as how most USB mass storage devices (USB sticks, hard discs, CD drives, etc.) all use “SCSI-over-USB”. If we were to do that then that would both eliminate one of the sources of potential SCSI device ID conflicts, and would allow us to easily support other ATAPI devices such as IDE Zip drives (which with any luck will “just work”, assuming the SCSI/USB versions are already supported by the OS).

The number returned by CDFS_ConvertDriveToDevice is actually composed as follows:
• Bits 0-2 = SCSI device
• Bits 3-4 = SCSI card
• Bits 5-7 = SCSI LUN
• Bits 8-15 = drive type (my memory is a bit hazy but I think this basically indicates which driver is being used, or for very old drives the make/model of the drive)

Ah! So if I take the returned value and extract the card/lun values and use them, it should work? I’ll experiment.

I asked a while ago about card/lun values. At the time the impression I got was that in practice these were always zero. So I wrote the program on that basis.

My Iyonix does have two optical drives. One DVD the other CD. At present one works with cdparanoia but the other refuses. (Crashes.) I think both drives used to work with cdparanoia, and that this may have changed because I updated the Iyonix’s OS just before I switched to mainly using an ARMiniX. So I don’t think I used the drives at all after the Iyonix OS upgrade.

Ideally, I’d use the CD drive for ripping audio CDRs as past experience shows it is more reliable with degraded discs. I was wanting to compare this with ARMiniX when I fell into the problem I reported.

Thanks,

Jim

BTW If the OS code is updated/improved for ATAPI, etc, maybe it could also include some clearer MMC support? I can’t make head or tail of the logic of the SCSI Op calls for that! 8-]

Yes! Pleased to confirm that reading the card and lun as described lets the program find the drive! :-) I’ll put up a fixed version tomorrow.

This has also reminded me of a quirk of the CD ROM drive (Sony CD-RW). It pretends it doesn’t exist unless there is a data CD in the drive when the Iyonix is powered up. However it’s been like that since I fitted it some years ago. So I’ve reverted to leaving an unwanted CD in the drive as a ‘placeholder’. (Ancient Maplin catalogue CD.)

Thanks again,

Jim

I’ve now made a new version (0.60) of my !ClassicRip and its ripframes utility available. As before, downloadable from

http://www.audiomisc.co.uk/software/ClassicRip.zip

It should now work OK on machines like the Iyonix where the card and LUN numbers are non-zero. In addition to adding the detection and use of these values I found I also had to add a WimpSlot setting for running ripframes on an Iyonix, although this isn’t needed on my ARMiniX.

Also a few minor tweaks. e.g. I’ve now given the application and icon.

One interesting result of comparing it here Iyonix vs ARMiniX is that the ripframes ripping is much faster on my Iyonix’s Sony CD-RW drive than on the DVD drive in my ARMiniX or using an external USB DVD drive with my ARMiniX. So old drives do have their advantages it seems! :-)

Jim

Are you seeing non-zero LUNs?

I found I also had to add a WimpSlot setting for running ripframes on an Iyonix, although this isn’t needed on my ARMiniX.

The point probably is that the default setting of wimpslot on the ARMiniX is much higher than on the Iyonix. If a wimpslot is not set explicitly when a binary is run, the default setting will be used, and this is often too small.

ripping is much faster on my Iyonix’s Sony CD-RW drive than on the DVD drive in my ARMiniX or using an external USB DVD drive with my ARMiniX.

This may be nothing to do with the drives, but more to do with the relative speeds of the IDE bus on the Iyonix and the usb interface on the newer hardware.

ATAPI IDE on the IYONIX is very slow, UDMA only got implemented for harddrives, so it is PIO Mode 0 for CD-like devices. This is much slower than what USB is capable of.

The point probably is that the default setting of wimpslot on the ARMiniX is much higher than on the Iyonix.

On both machines the ‘next’ value on the Tasks display says 640k by default. I’d assumed this was also the default value for a WimpSlot unless specifically altered. Is this not the case?

I’ve noticed when running other programs I’ve written that on my ARMiniX they seem happy to run with large amounts of memory assigned just by ‘C’ assignments like ‘double fred[bignumber]’ at the start. But I then started wondering if my own memory was misleading me and that TaskObey/Obey allowed this without having to adjust the assigned slot. Now I assume I’m not understanding some difference between my ARMiniX and my Iyonix.

FWIW The Iyonix is running ROOL RO5.18 and my ARMiniX the R-comp RO5.21 (7 Mar 2014).

Are you seeing non-zero LUNs?

No. But I only have two cases to check:

1) ARMminiX. Both card and LUN always ‘0’. Although one drive is internal and the other an external USB drive. They seem to behave pretty much the same in use. Only the drive numbers differ.

2)My Iyonix. There the card is ‘3’ and the LUN is ‘0’. Two drives internally connected. One a Sony CD-RW the other a DVD drive.

FWIW I just checked a while ago and my ripframes (now altered to handle non-zero card/lun) rips at about x18 speed on the Iyonix if I use the Sony CD-RW drive. Whereas it rips at about x8 using either drive on my ARMiniX. My guess is that this is somehow a reflection of the drive being designed for CDRs not DVDs, but I have no idea if this guess is correct.

Jim