Bug 135538

gnome-cd and sound-juicer use different data sources, just FYI.

If you revert to an older sound-juicer, does it work?

Okay, I tried looking up one of the albums directly (The Limp Bizket
one) on the freedb website and it showed up, but sound-juicer still
doesn't find it.

As for trying an older sj, sure point me to a source with an older
rpm, I don't have one in my stock.

sound-juicer uses Musicbrainz, not freedb.  Try using the musicbrainz website,
can you find them there?

Musicbrainz turns up this for the test album that SJ doesn't like
http://www.musicbrainz.org/showalbum.html?albumid=56305

sound-juicer 0.5.14 contains the same problem btw.

David Nielson,

Are you still able to reproduce this problem?

First off, this is a duplicate of bug 138342.  Secondly, as I remarked there, I
really don't think it's generating bad DiscIDs or anything.  It's simply a case
of the DiscID not existing in the MusicBrainz database.  Different pressings of
the same CD can be slightly different (depending on which sector they start
with), and thus generate new DiscID.  Luckily, with the new sound-juicer it's
very easy to select the "Submit Track Names" and go to MusicBrainz and add a new
DiscID to a listing which already exists.

This should be marked as a duplicate of 138342, and probably both of them should
be closed.

I submitted a disc id to musicbrainz (A Barry White CD) and it still couldn't
return the right information the next day (I haven't got the CD at the moment to
test, it's at home) even though it claimed it should have been available right
after submitting the information.

As a side note, it would be great if:

a. sound-juicer used the same cddb as the rest of Gnome.
b. if it doesn't, then it falls back to using the same cddb.

It's plain annoying that a CD that shows up fine in Rhythmbox, doens't show up
in sound-juicer, especially when you've initiated a rip of the CD using rhythmbox.

Rodd:

What version of sound-juicer?

As far as the side note goes, there was a bug in sound-juicer's fallback to
FreeDB if it couldn't find the CD in MusicBrainz.  It's been fixed, and
sound-juicer-2.14.1 will fallback correctly.  See GNOME bug 335071

http://bugzilla.gnome.org/show_bug.cgi?id=335071

Rodd:

I've tried plenty of CDs, and all of them worked IMMEDIATELY after submitting
the disc id to MusicBrainz, by doing "Re-Read Disc."  There was a problem in one
test version of sound-juicer that cached track information (and thus could cache
incorrect of missing information), and there was another bug that is fixed in
2.14.0 with clashing DiscIDs (basically, you could only select the first choice
of any CDs with matching IDs).

MusicBrainz definitely works in 2.14.0, but you'll have to wait for 2.14.1 for
the fallback to FreeDB if MusicBrainz doesn't have it to work.  The latter is
what Rhythmbox does, and explains the different behavior.

I have found that sound-juicer-2.14.0-1 fails to retrieve information for some
CDs using libmusicbrainz even though rhythmbox-0.9.3.1-3 successfully retrieves
a track listing for the same CD.

When I ran sound-juicer with the environment variable MUSICBRAINZ_DEBUG set (as
suggested in the sound-juicer README file) and with one of these CDs in the
drive, the request mq:GetCDInfo element contained only mq:depth and mm:cdindexid
elements.  The response to this request contained no information.

When I ran rhythmbox under the same conditions, the request element also
contained mm:firstTrack and mm:lastTrack elements, as well as an mm:toc element
listing the tracks on the CD and their lengths.  The response to this request
included the disc title, artist, and track listing.

The rhythmbox source tree contains several source files apparently copied from
sound-juicer in the metadata directory.  I suspect that
sj-metadata-musicbrainz.c has been changed in sound-juicer after this occurred,
but I did not find the version of sound-juicer these files were taken from in
the rhythmbox ChangeLog.  I do know that sound-juicer-2.10.1-1 (in FC4)
successfully retrieved a track listing for my test CD, and its MusicBrainz
request closely resembles the one sent by rhythmbox; I have not been able to
find RPMs for intermediate versions of sound-juicer.

Are you sure that the information is in MusicBrainz with the DiscID, not just in
FreeDB?  MusicBrainz doesn't use the FreeDB-style TOC and the other information.

Rhythmbox currently already proxies information from FreeDB if the information
is not in MusicBrainz.  Very old versions of sound-juicer used FreeDB, and
certain intermediate versions-- containing the code that rhythmbox now uses--
were able to proxy to FreeDB.  However, at some point the proxying to FreeDB
code was broken.  See the external GNOME Desktop bug which I linked at the
bottom.  (335071)  However, it's now fixed.

The 2.14.1 release of sound-juicer, which just entered updates-testing for FC5,
contains a fix which fixes proxy lookups to FreeDB.

Please test the sound-juicer-2.14.1-1.fc5 RPM in updates-testing to see if this
solves your problem.

"I have found that sound-juicer-2.14.0-1 fails to retrieve information for some
CDs using libmusicbrainz even though rhythmbox-0.9.3.1-3 successfully retrieves
a track listing for the same CD."

Yes.  Did you read my comment before yours?  rhythmbox falls back to FreeDB when
a CD is not in MusicBrainz; I know this for certain.  This was broken in
sound-juicer until the recent 2.14.1 release, and explains most if not all of
the different behavior.

Created attachment 127409 [details]
Rhythmbox MusicBrainz request/response

I am attaching a listing of a MusicBrainz request sent by rhythmbox-0.9.3.1-1
and the response sent by the server.  Note that this listing was produced by
setting the MUSICBRAINZ_DEBUG environment variable as suggested in the
sound-juicer README; this environment variable is detected and acted on by the
src/sj-metadata-musicbrainz.c file in sound-juicer also present in rhythmbox as
metadata/sj-metadata-musicbrainz.c, but not by libmusicbrainz.

I discovered the link to GNOME bug 335071 at the bottom of the Bugzilla page
after posting my initial comment, and I was able to compile an RPM to test the
sound-juicer patch provided attached to that bug tracker.  This patch does fix
the problem I have experienced with incorrectly handled MusicBrainz requests
sent by sound-juicer, and if it is included in sound-juicer-2.14.1, the next
version will solve my problem.	I did not read this GNOME bug initially because
the comment referring to it stated that the GNOME bug related to a FreeDB
fallback; upon reading the bug report and the patch provided, I discovered that
this was not the case and the bug was indeed related to my issue.

The sound-juicer-2.14.1-1.fc5.1 RPM in updates-testing does produce a correctly
formed MusicBrainz request and retrieve a track listing correctly from MusicBrainz.

Upon rereading the patched portion of sj-metadata-musicbrainz.c, I discovered a
comment that does state that the change was necessary to allow MusicBrainz to
use FreeDB as a fallback.  The previous comments on this bug report had given me
the impression that this fallback to FreeDB was supposed to be implemented by
sound-juicer itself rather than by the MusicBrainz server.

"The previous comments on this bug report had given me the impression that this
fallback to FreeDB was supposed to be implemented by sound-juicer itself rather
than by the MusicBrainz server."

Well, that's a matter of semantics, really.  Sound-juicer had to implement the
calls correctly (basically, send the information that MusicBrainz doesn't use
but FreeDB needs to identify the CD) in order for the fallback to work properly.
 I'm sorry if it was confusing.  Anyway, I really think that with
sound-juicer-2.14.1 this bug can be closed, along with the extremely similar bug
138342
 
I don't think David Nielsen is reading these bugs which were reported by his old
email address.  (He has a new one I've seen on fedora-devel-list.)

Changed summary to something more accurate.  Closing since it's fixed in the
sound-juicer-2.14.1-1.fc5.1 package in updates-testing.  (It also works in the
newer sound-juicer-2.14.2-1.fc5.1 package, since it was fixed upstream.)

*** Bug 138342 has been marked as a duplicate of this bug. ***