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 661141 - Albums spread across multiple CD's are badly ripped and tagged
Albums spread across multiple CD's are badly ripped and tagged
Status: RESOLVED DUPLICATE of bug 652972
Product: sound-juicer
Classification: Applications
Component: general
Other Linux
: Normal major
: ---
Assigned To: Sound Juicer Maintainers
Sound Juicer Maintainers
Depends on:
Reported: 2011-10-06 23:49 UTC by Luis Menina
Modified: 2011-10-07 08:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

Screenshot of s-j with CD2 out of 2 inserted (134.16 KB, image/png)
2011-10-06 23:49 UTC, Luis Menina

Description Luis Menina 2011-10-06 23:49:02 UTC
Created attachment 198493 [details]
Screenshot of s-j with CD2 out of 2 inserted

I have a few albums that are composed by 2 CDs. On both albums, I saw the same behavior: when the first CD is inserted, the full set of tracks is displayed (CD1 + CD2), and pre-selected. Then, clicking on the "extract" button will rip and tag correctly all the tracks of CD1, but it will then continue ripping the tracks of CD2 from CD1. For example, s-j will tell it's ripping track 12..22 while CD1 has only 15 tracks. All the "invented" tracks are in fact one real track of the CD, which is ripped again and again, and wrongly tagged with CD2 song names.

Likewise, if I insert CD2, all the tracks from CD1 & 2 are shown, and pre-selected. The problem is that the tracks from CD1 are not ignored. This means that if I rip track 1, it contains track 1 from CD2 (which is track 12 of the album), but will get all its tags from track 1 from CD1 ! 

So no track from CD2 will ever match its tags...

Expected behavior would be to have all tracks displayed, but tracks not on the inserted CD be grayed out and impossible to select for ripping.
Comment 1 Christophe Fergeau 2011-10-07 08:13:07 UTC

*** This bug has been marked as a duplicate of bug 652972 ***