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 663456 - sound-juicer - many problems with multi-disc collections, misinterprets musicbrainz data, rips tracks not on CD in tray, creates duplicates of CD1 content tagged as CD2 content
sound-juicer - many problems with multi-disc collections, misinterprets music...
Status: RESOLVED DUPLICATE of bug 652972
Product: sound-juicer
Classification: Applications
Component: ripping
2.32.x
Other Linux
: Normal critical
: ---
Assigned To: Sound Juicer Maintainers
Sound Juicer Maintainers
Depends on:
Blocks: 567433 579093
 
 
Reported: 2011-11-05 15:20 UTC by James Broadhead
Modified: 2011-11-05 21:35 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
see 21 tracks on CD, sound-juicer displays + rips 42. (244.11 KB, image/png)
2011-11-05 15:20 UTC, James Broadhead 		Details
02 - overwrite - sj attempts to overwrite good files with bad (280.77 KB, image/png)
2011-11-05 15:21 UTC, James Broadhead 		Details
03 - After. Duplicate / Mistagged content created. (197.25 KB, image/png)
2011-11-05 15:31 UTC, James Broadhead 		Details

Description James Broadhead 2011-11-05 15:20:25 UTC 
Created attachment 200756 [details]
see 21 tracks on CD, sound-juicer displays + rips 42. 

Summary: sound-juicer creates many files which are mis-tagged and mis-named. It overwrites good content with bad. It fails to interpret good musicbrainz info correctly. 

Severity: Marked Critical - this bug destroys good data and replaces it with bad. (eg. I rip CD1, get files for CD1 and CD2. Then I rip CD2, good CD1 files get overwritten with bad, CD2 files created. Result: Files named/tagged as CD1 contain CD2 contents, CD2 contents good.)

Reproduction: 
Compilation foo has 2 CDs

In Musicbrainz: 
CD1 - 01 - alpha   - 65mins
CD1 - 02 - bravo   - 5 mins
CD2 - 01 - charlie - 3 mins
CD2 - 02 - delta   - 67 mins

If I put CD1 in the tray, and start sound-juicer, it will pull the Musicbrainz record for the disc. However, instead of parsing out only the tracks for the disc contents hash, sound-juicer acts as though the disc in the tray contains all of the tracks in the compilation. 

So sound-juicer displays:
"foo" - 140mins (Obviously wrong) 
01 - alpha
02 - bravo 
03 - charlie
04 - delta

When ripping sound-juicer outputs files for each track, even those not on the disc in the tray (perhaps iterating over the CD twice, then mis-tagging the repeated contents of CD1 as though it were CD2). 

The musicbrainz records in these cases are correct, and correctly associate tracks and discs. This problem is definitely in sound-juicer's interpretation of the mbz data. 

Examples: Any of the "Now [0-9][0-9]!" CDs, "To Dad from Motown" (which I have just added to MBZ to confirm this bug report).

http://musicbrainz.org/release/e4f43bc1-07d2-4967-b084-f6ec5be870bb
http://musicbrainz.org/release/e4f43bc1-07d2-4967-b084-f6ec5be870bb/discids

Expected Behaviour: 
* sound-juicer should only show / rip the contents of the CD in the tray, not attempt to rip the other CDs while they are still in the case(!)
sound-juicer should never display more tracks than exists on the CD in the tray, regardless of data acquired from MBZ. 
* sound-juicer should error-out if it is requested to rip track N+1 or above for a CD with N tracks 
* It should have better support for tagging / filenames of multiple disc collections in general
* sound-juicer is inadequately tested pre-release. That something was wrong was evident to me with the first 2-cd set that I ripped.  

Screenshots: 
Taken with "To Dad from Motown Disc 2" in the drive. All views are updated/refreshed.
01-before - see 21 tracks on CD, sound-juicer displays + rips 42. 
02-overwrite - sound-juicer attempts to overwrite CD1 ripped content
03-after  - sound-juicer has created tracks 01-21 of this collection in error, has mis-tagged them as CD1's contents.
Comment 1 James Broadhead 2011-11-05 15:21:44 UTC 
Created attachment 200757 [details]
02 - overwrite - sj attempts to overwrite good files with bad
Comment 2 James Broadhead 2011-11-05 15:31:15 UTC 
Created attachment 200758 [details]
03 - After. Duplicate / Mistagged content created.
Comment 3 Christophe Fergeau 2011-11-05 20:00:29 UTC 
(In reply to comment #0)
> * sound-juicer is inadequately tested pre-release. That something was wrong was
> evident to me with the first 2-cd set that I ripped.  

Prerelease testing isn't so easy when things change behind your back... In this case, it broke overnight after unexpected server-side changes from musicbrainz.
Comment 4 Christophe Fergeau 2011-11-05 20:01:45 UTC 

*** This bug has been marked as a duplicate of bug 652972 ***
Comment 5 James Broadhead 2011-11-05 20:34:55 UTC 
(In reply to comment #3)
> (In reply to comment #0)
> > * sound-juicer is inadequately tested pre-release. That something was wrong was
> > evident to me with the first 2-cd set that I ripped.  
> 
> Prerelease testing isn't so easy when things change behind your back... In this
> case, it broke overnight after unexpected server-side changes from musicbrainz.

Fair enough, perhaps they serve an API version number or similar? It would be nice if this could be avoided in the future. I'll add a comment to that effect in the primary bug report.
Comment 6 Christophe Fergeau 2011-11-05 21:35:59 UTC 
Hmm maybe I was a bit too hasty in closing this bug, it's generally much easier to track bugs when there is only one issue tracked per bug, I'm not sure all the remaining items are really relevant to the port to the new musicbrainz API.