Bug 123281
Summary: | cdda2wav is unable to extract last audio tracks before data track | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dams <anvil> | ||||||||||
Component: | cdrtools | Assignee: | Harald Hoyer <harald> | ||||||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | rawhide | CC: | anvil, mattdm, triage | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | bzcl34nup | ||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2008-05-06 23:58:57 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Dams
2004-05-15 16:40:28 UTC
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 |