Hi. I've tested your patch, and found some problems. (1) Cannot mount a data part. capricorn# cdcontrol info Starting track = 1, ending track = 12, TOC size = 106 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 6:18.00 0 28350 audio 2 6:20.00 6:03.10 28350 27235 audio 3 12:23.10 5:32.37 55585 24937 audio 4 17:55.47 3:35.65 80522 16190 audio 5 21:31.37 5:28.33 96712 24633 audio 6 26:59.70 3:58.15 121345 17865 audio 7 30:58.10 4:57.62 139210 22337 audio 8 35:55.72 4:58.55 161547 22405 audio 9 40:54.52 6:28.68 183952 29168 audio 10 47:23.45 5:01.50 213120 22625 audio 11 52:25.20 6:48.32 235745 30632 audio 12 61:45.52 8:10.74 277777 36824 data 170 69:56.51 - 314601 - - capricorn# mount_cd9660 /dev/acd0 /cdrom mount_cd9660: /dev/acd0: Invalid argument capricorn# (2) When I read the last audio track via /dev/acd0tXX, the output data has wrong length. capricorn# dd if=/dev/acd0t10 bs=2352 > /dev/null 22625+0 records in 22625+0 records out # correct length 53214000 bytes transferred in 19.750258 secs (2694345 bytes/sec) capricorn# dd if=/dev/acd0t11 bs=2352 > /dev/null dd: /dev/acd0t11: Input/output error 41883+0 records in 41883+0 records out # wrong length (!= 30632) 98508816 bytes transferred in 35.804241 secs (2751317 bytes/sec) capricorn# (3) When I play the last audio track with cdcontrol(1), the "next" command doesn't work (the drive stops playing). capricorn# cdcontrol play 11 capricorn# cdcontrol status Audio status = 17<playing>, current track = 11, current position = 0:13.68 No media catalog info available Left volume = 255, right volume = 255 capricorn# cdcontrol next acd0: FAILURE - PLAY_MSF ILLEGAL REQUEST asc=0x64 ascq=0x00 capricorn# cdcontrol status Audio status = 0<invalid>, current track = 11, current position = 0:26.57 Media catalog is inactive Left volume = 255, right volume = 255 capricorn# (These tests are done with Noriyuki Makihara's "Such a Lovely Place" (Sony Records, 1997).) By the way, I have an another patch that solves problems that you have pointed out and described above. http://homepage2.nifty.com/dumb_show/unix/work/ata.releng71.diff http://homepage2.nifty.com/dumb_show/unix/work/cdcontrol.releng71.diff I've tested the patch on FreeBSD 7.1-RELEASE and 8-current. This patch is not my original. The original patch was written by Chiharu Shibata for FreeBSD 4.4-RELEASE. http://www32.ocn.ne.jp/~chi/myprog/FreeBSD/atapi-cd.html One year later he rewrote the patch for FreeBSD 4.7-RELEASE. It also includes some quirks for old CD-ROM drives which are generally used with NEC PC-98 series. http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/74432 I rewrote the latter patch for FreeBSD 5.x, 6.x, and 7.x. At Thu, 09 Apr 2009 15:33:54 +0200, Jean-S?bastien P?dron wrote: > Hello, > > Enhanced CD (or Extra CA) is an Audio CD with an additionnal data track > at the end. Audio tracks belong to the first session while the data > track belongs to the second session. Therefore the last audio track ends > way before the data track start. > > The first consequence is that the duration of the last audio track isn't > reported correctly. Here is the output of cdcontrol(1) with such a CD[1]: > $ cdcontrol info > ... > 12 46:03.67 9:54.43 207142 44593 audio > 13 55:58.35 6:38.51 251735 29901 data > > The expected output is: > $ cdcontrol info > ... > 12 46:03.67 7:22.43 207142 33193 audio > 13 55:58.35 6:38.51 251735 29901 data > > A more "audible" consequence is that cdparanoia(1) copies 9'54" of data > instead of 7'22". The end of the ripped file is full of garbage. > > I made a patch (attached) that adds a new ioctl to query the start > address of the last session. This new ioctl is named > CDIOREADLASTSESSIONADDR. The patch also includes changes to cdcontrol(1). > > I added a new member at the end of struct acd_softc to store the last > session address. I don't know if this causes ABI breakage. > > Linux' corresponding ioctl is CDROMMULTISESSION. Beside this address, it > returns a flag named "xa_flag". Currently, I don't understand what it is > but it may be useful to add it to our ioctl too if someone knows its > purpose. > > Before I spend some time to teach cdparanoia(1) about this new ioctl, > I'd like some feedback on this patch, especially the name and the struct > ioc_read_last_session_addr. I would appreciate some test reports too! :) > > [1] This was tested with Avishai Cohen's last album, "Aurora". > > -- > Jean-Sébastien Pédron > http://www.dumbbell.fr/ (snip) --- WATANABE Kazuhiro (CQG00620_at_nifty.ne.jp)Received on Mon Apr 13 2009 - 13:56:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:46 UTC