[gstreamer-bugs] [Bug 168994] New: cdparanoia plugin problem with CDs whose first track doesn't start at 00:00

bugzilla-daemon at bugzilla.gnome.org bugzilla-daemon at bugzilla.gnome.org
Wed Mar 2 08:29:53 PST 2005


Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=168994
 GStreamer | gst-plugins | Ver: HEAD CVS

           Summary: cdparanoia plugin problem with CDs whose first track
                    doesn't start at 00:00
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: james at jamesh.id.au
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


Please describe the problem:
At first I thought this was a bug in sound-juicer, but it is also apparent in
gnome-cd.  If it isn't a gstreamer bug, then both of those programs are doing
the same thing wrong :)

On certain CDs, seeking to the beginning of a track leaves you in the middle of
the one before hand.  The only unusual thing about the CD I can think of is that
there is some audio before the first track.  This shouldn't be related to any
copy protection schemes (the CD I tried is from 1999).

Steps to reproduce:
1. insert an affected CD
2. rip it with sound-juicer
3. listen to the resulting media files


Actual results:
each audio track should end up in its own file

Expected results:
tracks are split over file boundaries, with the start of tracks in the middle of
files.

Does this happen every time?
Yes, for affected CDs.

Other information:
If I seek to a track with gnome-cd, it ends up in the middle of a track just
like sound-juicer.

If I tell the command line cdparanoia tool to rip a particular track, it seems
to pick the right range of time.

Here is the toc for an affected CD:

$ cdparanoia --query
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty at xiph.org> and Xiphophorus

Report bugs to paranoia at xiph.org
http://www.xiph.org/paranoia/



Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    14246 [03:09.71]    12735 [02:49.60]    no   no  2
  2.    21232 [04:43.07]    26981 [05:59.56]    no   no  2
  3.    19402 [04:18.52]    48213 [10:42.63]    no   no  2
  4.     9662 [02:08.62]    67615 [15:01.40]    no   no  2
  5.    16236 [03:36.36]    77277 [17:10.27]    no   no  2
  6.    23275 [05:10.25]    93513 [20:46.63]    no   no  2
  7.    20107 [04:28.07]   116788 [25:57.13]    no   no  2
  8.    30807 [06:50.57]   136895 [30:25.20]    no   no  2
  9.     7613 [01:41.38]   167702 [37:16.02]    no   no  2
 10.    22800 [05:04.00]   175315 [38:57.40]    no   no  2
 11.    20318 [04:30.68]   198115 [44:01.40]    no   no  2
 12.    17352 [03:51.27]   218433 [48:32.33]    no   no  2
 13.    31275 [06:57.00]   235785 [52:23.60]    no   no  2
TOTAL  254325 [56:31.00]    (audio only)

Note the begin time for track 1.  My guess is that some piece of code is making
an assumption that track 1 begins at offset 0, but that is only a guess.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.




More information about the Gstreamer-bugs mailing list