libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Read Sub-channel changes


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Read Sub-channel changes
Date: Tue, 31 May 2016 21:03:09 +0200

Hi,

the command READ SUB-CHANNEL seems to be quite a lottery.

2 out of 5 inspected CDs show glitches with MCN and ISRC.
The result is about the same on three DVD/BD drives. (I do not
have any real CD drive any more.)

All 5 CDs show undamaged CD-TEXT. It is a riddle why the MCN and
ISRC data are more prone to read problems than the CD-TEXT stuff.

Well, there were no valgrind error messages. The failures were caused
by unwilling drive replies, not by wrong processing in libcdio.

--------------------------------------------------------------------
Proposals:
--------------------------------------------------------------------

- cdio_get_mcn() should finally lead to mmc_get_mcn().

  Currently it gets redirected to ioctl(CDROM_GET_MCN) in Linux driver.
  Is mmc supported on all platforms ?
  Can ((CdIo_t *) p_cdio)->op.get_mcn be skipped in favor of calling
  mmc_get_mcn() directly ?
  Or is it necessary to hop from each driver onto mmc_get_mcn() ?
  (How to get the (CdIo_t *) parameter, then ?)

- cd-info should report Sense Codes of unexpectedly failed SCSI commands.

  I provoked some "illegal request" by wrong track number in order to
  verify that really no Sense Code gets emitted by failed READ SUB-CHANNEL
  with correct track numbers.
  But there was no error indication to see with cd-info.
  I had to put a printf() into run_mmc_cmd_linux() in order to see it.

  The printf() shows 5,24,00 with wrong track number. No Sense Code is
  replied with correct track numbers even if the returned TCVAL bit is 0.

- Leon should have a look at
    
http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=0f9fe770268bc74e571c999e67b74d4968d0e835
  and judge whether
    +  if (i_cdtext > CDTEXT_LEN_BINARY_MAX + 2)
  and following lines are really correct. It seems inconsistent and it
  has the "2" with a different sign than in the replaced code snippet.

--------------------------------------------------------------------

Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]