After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168994 - cdparanoia plugin problem with CDs whose first track doesn't start at 00:00
cdparanoia plugin problem with CDs whose first track doesn't start at 00:00
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other All
: Normal blocker
: 0.8.8
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-03-02 16:29 UTC by James Henstridge
Modified: 2005-03-05 18:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
patch (608 bytes, patch)
2005-03-03 13:50 UTC, Ronald Bultje
none Details | Review

Description James Henstridge 2005-03-02 16:29:53 UTC
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@xiph.org> and Xiphophorus

Report bugs to paranoia@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.
Comment 1 James Henstridge 2005-03-03 13:36:16 UTC
Changing severity/milestone at Ronald's request.
Comment 2 Ronald Bultje 2005-03-03 13:50:07 UTC
Created attachment 38203 [details] [review]
patch

This reverts part of an earlier patch, which breaks interface stability. I did
it to get rid of the lead-in in Totem, but that's apparently a bad idea for
other apps... With this, gnome-cd works fine again. Should go into 0.8.8.
Comment 3 James Henstridge 2005-03-03 14:41:49 UTC
This patch seems to fix the problem in gnome-cd and sound-juicer.
Comment 4 Thomas Vander Stichele 2005-03-05 18:00:05 UTC
commited