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 109558 - [0.6.1] cdparanoia: wrong discid when cd has a data track
[0.6.1] cdparanoia: wrong discid when cd has a data track
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.6.0
Other Linux
: Normal normal
: 0.6.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-03-30 19:31 UTC by ian hummel
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch for 0.6 branch to emit warning (889 bytes, patch)
2003-04-11 12:01 UTC, Benjamin Otte (Company) 		none Details | Review

Description ian hummel 2003-03-30 19:31:24 UTC 
the cdparanoia plugin reports the wrong discid for cds which contain a data
track.  two particular examples are "Beastie Boys - Hello Nasty" and "G
Love and Special Sauce - Yeah It's That Easy."  The discid's are different
than that reported by, for example, cd-discid-0.8 or ExactAudioCopy v0.90b4.

Is it related to the fact that cdparanoia only reports the number of audio
tracks, neglecting the number of data tracks?
Comment 1 Benjamin Otte (Company) 2003-03-31 13:47:50 UTC 
Could somebody mark this as CLOSED / NOTGNOME or whatever is the 
appropriate solution for "this isn't supported in cdparanoia"?

Reasons for that:
Every track (audio and data) starts at an offset into the cd. This 
offset is measured in 75th of a second. The discid is computed by 
more or less checksumming these offsets (including the data tracks) 
in various different ways.
cdparanoia does store these offsets and there exists an API to query 
them. This is properly used by the plugin.

However:
When opening the device and reading those offset informations, 
cdparanoia might adjust the offsets of data tracks. Note: It does not 
always adjust them, but it might. And it will never adjust offsets of 
audio tracks. If it does adjust them, discid computation fails, 
because the offsets reported by cdparanoia are wrong. There is no way 
to xif this without modifying cdparanoia.

proposed solution:
I applied a patch that issues a g_warning upon g_object_get when the 
discid might be wrong. I'm not sure if we should remove the discid, 
since most of the times (no data tracks) the discid works correctly.
However we can not guarantee a correct discid.
I'm in favour of removing it.

Comments? wtay?
Comment 2 Benjamin Otte (Company) 2003-04-11 11:59:58 UTC 
Ading patch that g_warning's when the discid might be wrong.

Please mark as NOTGNOME when the patch is applied to 0.6
Comment 3 Benjamin Otte (Company) 2003-04-11 12:01:51 UTC 
Created attachment 15642 [details] [review]
patch for 0.6 branch to emit warning
Comment 4 Ronald Bultje 2003-04-12 09:29:31 UTC 
Even when it's not strictly a GStreamer bug, we might still want to
fix it upstream, right? Did anyone inform the cdparanoia people?

I don't think removing it completely is a good thing.
Comment 5 Ronald Bultje 2003-04-12 14:52:22 UTC 
Warning applied... Either way, this is not a Gst bug so it should be
fixed in cdparanoia instead...