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
