Bug 123281 - cdda2wav is unable to extract last audio tracks before data track
cdda2wav is unable to extract last audio tracks before data track
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: cdrtools (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-15 12:40 EDT by Dams
Modified: 2008-05-06 19:58 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 19:58:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
TOC for cdrdao on FC3 using generic-mmc (2.55 KB, text/plain)
2004-10-18 23:32 EDT, Allen Kistler
no flags Details
TOC for cdrdao on FC3 using generic-mmc (945 bytes, text/plain)
2004-10-18 23:36 EDT, Allen Kistler
no flags Details
TOC for cdrdao on FC1 using toshiba (1006 bytes, text/plain)
2004-10-18 23:37 EDT, Allen Kistler
no flags Details
TOC for cdrdao on FC1 using generic-mmc (945 bytes, text/plain)
2004-10-18 23:37 EDT, Allen Kistler
no flags Details

  None (edit)
Description Dams 2004-05-15 12:40:28 EDT
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:
Comment 1 Harald Hoyer 2004-10-13 08:30:08 EDT
any improvement with the update releases?
Comment 2 Allen Kistler 2004-10-16 17:20:10 EDT
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.
Comment 3 Allen Kistler 2004-10-16 17:24:52 EDT
... or maybe I just never tried to play one of those discs until later
in FC3 (but I don't think so).
Comment 4 Allen Kistler 2004-10-16 18:02:26 EDT
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.
Comment 5 Harald Hoyer 2004-10-18 10:34:12 EDT
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.
Comment 6 Allen Kistler 2004-10-18 23:30:24 EDT
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.
Comment 7 Allen Kistler 2004-10-18 23:32:25 EDT
Created attachment 105419 [details]
TOC for cdrdao on FC3 using generic-mmc
Comment 8 Allen Kistler 2004-10-18 23:36:14 EDT
Created attachment 105420 [details]
TOC for cdrdao on FC3 using generic-mmc
Comment 9 Allen Kistler 2004-10-18 23:37:04 EDT
Created attachment 105421 [details]
TOC for cdrdao on FC1 using toshiba
Comment 10 Allen Kistler 2004-10-18 23:37:56 EDT
Created attachment 105422 [details]
TOC for cdrdao on FC1 using generic-mmc
Comment 11 Mark 2006-03-06 11:51:56 EST
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?
Comment 12 Mark 2006-03-07 08:49:58 EST
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.
Comment 13 Matthew Miller 2006-06-29 23:30:31 EDT
Moving this to the devel release instead of FC2, since FC2 is old news.
Comment 14 Bug Zapper 2008-04-03 11:34:37 EDT
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.
Comment 15 Bug Zapper 2008-05-06 19:58:55 EDT
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

Note You need to log in before you can comment on or make changes to this bug.