Re: Playing or Ripping UDF CDs Under jessie

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i wrote:
> > They saw a CD and tried UDF. Cluelessly and in vain.

Jonathan Dowland wrote:
> They did that because of the fstab line which specified udf, and the
> presence of a data track on the CD.

The "problem CD" is pure audio. No indication on Table-Of-Content level
that there would be sectors readable by READ(10).
Whatever software tries to mount a filesystem there does not take
into account the sector format of the tracks.


> I've never seen the use of "iso9660,udf" in that column of fstab before.
> (would "auto" do the same thing?) You learn something new every day!

My Debian 8 fstab has such entries for sr0 and sr1, none for sr2 to sr4.
Like:
  /dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

I have disabled automounting on my system. What i cannot stop is udev
groping a newly inserted medium. Workaround is to wait until all drive
blinking stops before using the medium for mounting or burning.

I tried manual mounting as superuser with a commercial audio CD:

  # mount -t udf,iso9660 /dev/sr4 /mnt/iso
  mount: /dev/sr4 is write-protected, mounting read-only
  mount: /dev/sr4: can't read superblock

dmesg reports afterwards 

  [X.698578] sr 44:0:0:0: [sr4]  
  [X.698580] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
  [X.698581] sr 44:0:0:0: [sr4]  
  [X.698582] Sense Key : Illegal Request [current] 
  [X.698584] sr 44:0:0:0: [sr4]  
  [X.698586] Add. Sense: Illegal mode for this track
  [X.698587] sr 44:0:0:0: [sr4] CDB: 
  [X.698588] Read(10): 28 00 00 00 00 10 00 00 01 00
  [X.698591] end_request: I/O error, dev sr4, sector 64

This is a READ(10) attempt, which a system with a clue should not try
on tracks with CONTROL value 0.
I get a more standards compliant Sense Code from my ASUS BW-16D1HT burner
than Martin McCormick got from his SONY CRX140E, which seems to be quite
aged (CD only, IDE, reviews from year 2000, ...).

Linux has clue of CD media by its ioctl() family CDROM_*, but obviously
this does not fully shine through with filesystems, and probably even
less with userland automounters.

The mount attempts are not done with this first failure:
  ...
  [X.703472] UDF-fs: error (device sr4): udf_read_tagged: read failed, block=256, location=256
  ... many more failed READ(10) and messages about UDF ...
  [X.771416] UDF-fs: warning (device sr4): udf_fill_super: No partition found (1)
  ...
  [X.783391] isofs_fill_super: bread failed, dev=sr4, iso_blknum=16, block=16
  ...
  [X.807885] EXT4-fs (sr4): unable to read superblock
  ... 2 retries on same address ...
  [X.853593] FAT-fs (sr4): unable to read boot sector
  ... repeating the attempts for EXT4-fs and FAT-fs ...

So it does not look like mount would take the -t list as a restriction
for trying other filesystem formats.


deloptes wrote:
> > in any case no one can take the power of dd away :D

Jonathan Dowland wrote:
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.

Yep. dd uses POSIX functions like read(2), which in the end emit READ(10)
commands to the drive. But as said, this generic SCSI read command works
only with pure data storage devices or with data tracks on CD.
DVD and BD offer no non-data tracks. So CD are the only media i know,
which can offer non-data data.

Reading the subchannel info of CDs is normally only of interest for cloning
identical media or for circumventing weird read protection methods.
Their normal job is to tell an audio player roughly the current read
position, the Media Catalog Number, ISRC, CD-TEXT, ... For all drives it
provides the track's CONTROL value, which tells parts of the sector format.


Have a nice day :)

Thomas