From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Galeon/1.3.14 Description of problem: When track #X is an audio track and #X+1 is a data track on the same disc, cdda2wav hangs before reaching 100% of the track #X : [anvil@gruyere ~]# cdda2wav -D /dev/cdrom1 -t 11+11 cdrom device (/dev/cdrom1) is not of type generic SCSI. Setting interface to cooked_ioctl. 126976 bytes buffer memory requested, 4 buffers, 8 sectors #Cdda2wav version 2.01a27_linux_2.4.21-14.elsmp_i686_i686, real time sched., soundcard, libparanoia support EnableCdda_cooked (CDIOCSETCDDA) is not available... AUDIOtrack pre-emphasis copy-permitted tracktype channels 1-11 yes no audio 2 AUDIOtrack pre-emphasis copy-permitted tracktype channels 12-12 yes no audio 2 Table of Contents: total tracks:12, (total time 54:43.03) 1.( 4:55.48), 2.( 3:53.51), 3.( 3:18.58), 4.( 3:18.51), 5.( 3:47.15), 6.( 4:09.36), 7.( 4:36.09), 8.( 3:20.29), 9.( 2:32.18), 10.( 3:03.59), 11.( 9:10.03), 12.( 8:37.01) Table of Contents: starting sectors 1.( 0), 2.( 22173), 3.( 39699), 4.( 54607), 5.( 69508), 6.( 86548), 7.( 105259), 8.( 125968), 9.( 140997), 10.( 152415), 11.( 166199), 12.( 207452), lead-out( 246228) CDINDEX discid: Moy4krFGpBT4rJUs_XDd3ju4aBo- CDDB discid: 0x9e0cd30c CD-Text: not detected CD-Extra: not detected samplefile size will be 97027100 bytes. recording 550.0399 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'... cdda2wav: Operation not permitted. cannot set posix realtime scheduling policy overlap:min/max/cur, jitter, percent_done: 0/ 0/ 1/ 0 86%cooked: Read cdda : Input/output error sector 202795 + 8, buffer F7000000 + 1f000 0/ 0/ 1/ 600 86% 0/ 0/ 1/ 600 86%^C^C EnableCdda_cooked (CDIOCSETCDDA) is not available... W Child exited with 2 zsh: exit 2 cdda2wav -D /dev/cdrom1 -t 11+11 [anvil@gruyere ~]# ll /dev/cdrom1 /dev/scd2 lrwxrwxrwx 1 root root 4 mai 15 17:46 /dev/cdrom1 -> scd2 brw-rw---- 1 anvil disk 11, 2 f�v 23 22:02 /dev/scd2 In this example, track #11 is audio, track #12 is data. I can reproduce this with all this sort of cd i have. Version-Release number of selected component (if applicable): cdda2wav(8:2.01-0.a27.4).i386 How reproducible: Always Steps to Reproduce: 1. Have a cdrom device 2. Put a cd with both audio and data tracks on it 3. start cdda2wav to extract last *audio* track (the one just before the data track) Additional info:
any improvement with the update releases?
I see a similar problem, but I am not convinced it is the fault of cdrtools. The problem I see is also with CDDA discs with data. In fact cdrtools seems to provide the best insight into why cdp and gnome-media don't like them. My favorite example is below. Tracks 1-13 are audio. Track 14 is data (a "copy-protecting" CD player for Windows, ha!). This is what I get in FC3t3, kernel-2.6.8-1.610, cdda2wav-2.01.1-4. Table of Contents: total tracks:14, (total time 73:58.00) 1.( 4:54.55), 2.( 5:22.25), 3.( 4:05.17), 4.( 4:52.60), 5.( 4:48.18), 6.(954414:07.21), 7.( 0:10.00), 8.( 0:10.00), 9.( 0:10.00), 10.( 0:10.00), 11.( 0:10.00), 12.( 0:10.00), 13.(60:48.05), 14.(11:09.70) Table of Contents: starting sectors 1.( 0), 2.( 22105), 3.( 46280), 4.( 64672), 5.( 86632), 6.( 108250), 7.( 4500), 8.( 5250), 9.( 6000), 10.( 6750), 11.( 7500), 12.( 8250), 13.( 9000), 14.( 282605), lead-out( 332850) Tracks 7-13 are messed up. Compare that to FC1, kernel-2.4.22-1.2199.nptl, cdda2wav-2.01-0.a19.2.FC1.1. Table of Contents: total tracks:14, (total time 73:58.00) 1.( 4:54.55), 2.( 5:22.25), 3.( 4:05.17), 4.( 4:52.60), 5.( 4:48.18), 6.( 5:34.72), 7.( 4:35.08), 8.( 3:52.20), 9.( 4:48.00), 10.( 4:16.22), 11.( 4:51.68), 12.( 5:48.22), 13.( 4:57.68), 14.(11:09.70) Table of Contents: starting sectors 1.( 0), 2.( 22105), 3.( 46280), 4.( 64672), 5.( 86632), 6.( 108250), 7.( 133372), 8.( 154005), 9.( 171425), 10.( 193025), 11.( 212247), 12.( 234140), 13.( 260262), 14.( 282605), lead-out( 332850) The FC1 box is different from the FC3 box, but when the FC3 box was an FC2 box, it worked fine. In fact, early versions of FC3t1 worked okay, too.
... or maybe I just never tried to play one of those discs until later in FC3 (but I don't think so).
Hmm.... Upon closer examination, track 13 in my example is supposed to be 2:25 in length, not 4:57. It looks like FC1 has a problem, too, just not as bad as FC3. FWIW, FC1's gnome-cd quits playing at 2:25, although the position slider is only about half-way to the end.
you could try to read with cdrdao, edit the cue file not to include the data track, and burn a new audio CD. Also interesting is what cdrdao finds for the audio track lengths.
The FC1 box has a Toshiba SD-M1711 DVD-ROM. The FC3 box has a Plextor PX-W4012S CD-R. cdrdao on FC1 really does not like the Toshiba. I've included the "console" TOC using both generic-mmc and toshiba drivers. They both spit out tons of errors. Neither produces a TOC file. The problem is just the cdrdao/Toshiba combination. The generic-mmc driver gets the right length for track 13, but doesn't see track 14. The toshiba driver gets the wrong length for track 13, but sees track 14. Remember that gnome-cd, cdp, xmms, etc., (anything that's not cdrdao) play the CD okay. cdrdao on FC3 is practically psychodelic, not matter what driver I use. No TOC file, there, either. All drivers produce the same output, though. gnome-cd, cdp, xmms, etc., refuse to go past track 6. Outputs are attached.
Created attachment 105419 [details] TOC for cdrdao on FC3 using generic-mmc
Created attachment 105420 [details] TOC for cdrdao on FC3 using generic-mmc
Created attachment 105421 [details] TOC for cdrdao on FC1 using toshiba
Created attachment 105422 [details] TOC for cdrdao on FC1 using generic-mmc
I have found what may be a similar problem in FC4 using cdda2wav. cdda2wav is used by xcdroast to get track information. On my system the device is reported to cdda2wav as /dev/cdrom. cdda2wav interprets this device as cooked_ioctl. The resulting track information reports every track as audio. This breaks multi-session recording in xcdroast. I have tried running cdda2wav with device as -D1,0,0 to get it to be seen as a scsi device, but apparently the cdrecorder is not interfaced through the scsi io system (it is not listed in /proc/scsi/scsi). Should cdda2wav report the correct track type using cooked_ioctl? Or should my cdrecorder be seen as a scsi device?
Re comment 11: I discovered that if I specify the device as ATA:1,0,0 (not /dev/cdrom or 1,0,0) I can avoid the cooked_ioctl interface and get the correct track type.
Moving this to the devel release instead of FC2, since FC2 is old news.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp