GNOME Bugzilla – Bug 353181
Parses all titles from FreeDB /
Last modified: 2014-03-24 16:38:04 UTC
Forwarded from: https://launchpad.net/distros/ubuntu/+source/sound-juicer/+bug/57941 Binary package hint: sound-juicer When I put a various artists cd with " / " in the track titles in, sound-juicer incorrectly parses the data from musicbrainz.org as if it were from freedb. The submit metadata link is http://musicbrainz.org/bare/cdlookup.html?id=fGWBpfD_H_uCCYeRrIjHAy2Xv1Q-&tracks=14&toc=1+14+219750+150+20035+36055+49192+62785+79180+90180+104735+119955+140205+147685+171460+206485+212060 and the cd in musicbrainz is http://musicbrainz.org/release/4d87c8d0-6f5e-442c-923c-c82a709f49b4.html For example, track 1 is "Inverness Gathering / The Drunken Piper / 79th's Farewell to Gibraltar / Earl of Mansfield" by "Edinburgh City Police Pipe Band" but sound-juicer shows it as "The Drunken Piper / 79th's Farewell to Gibraltar / Earl of Mansfield" by "Inverness Gathering" I forgot to mention that I'm using sound-juicer 2.15.5.1-0ubuntu1. I'm attaching the toc and an empty data file for the cd that causes the problem. http://librarian.launchpad.net/4027155/cd.toc http://librarian.launchpad.net/4027156/data.wav.bz2
I'm using Ubuntu 6.06.1 with SJ 2.14.4. This also happens for soundtracks, etc. For CDs with various artists and where there are multiple songs in the same track, the MusicBrainz site recommends formatting like this: http://wiki.musicbrainz.org/TracksWithMultipleArtists > If a track has two songs, Song A by Artist A and Song B by Artist B, it is > highly recommended to make Artist A the TrackArtist and > Song A / Artist B - Song B the TrackTitle. This way, no bogus Artists are > created. Artist A / Artist B as TrackArtist would imply both artists > collaborated in some way; for these tracks, that is not the case. As discussed in this bug, when a slash appears in the track title Sound Juicer does the wrong thing with it. Consider the "Pulp Fiction" soundtrack, here: http://musicbrainz.org/release/10913f37-3770-41fc-bad7-739cf48ca8cb.html Note tracks 1, 8, 9, and 12 have slashes in the title. When SJ extracts the CD and creates an ogg file or whatever it uses the text AFTER the slash as the track title and the text BEFORE the slash as the artist; this is very wrong: the text before the slash is the title of the first song on the track and the text after the slash is the artist and title of the next song on the track, etc. So for example when SJ rips Pulp Fiction, the title for track 8 is "08 - The Centurions - Bullwinkle Part II.ogg" and the artist is "Zed's Dead, Baby". Obviously a slash is not a valid character in a filename so I'm not sure exactly how to translate these... but what happens now is incorrect as it causes the track title to show up in the artists column.
Damn and blast. OK, I'll have to see if there is a way to identify albums as being from FreeDB when doing the /-magic.
I guess I don't really understand how SJ works with the downloads and what the issue is with FreeDB data, but you can get an XML-formatted version of the album information from MusicBrainz right? For example here's one for the Pulp Fiction album: http://musicbrainz.org/ws/1/release/10913f37-3770-41fc-bad7-739cf48ca8cb?type=xml&inc=artist+counts+release-events+discs+tracks This should be pretty straightforward to parse without requiring any tricky heuristics... ?
The problem is that I need to find a way of determining if the data is from MusicBrainz directly so the / are intentional, or are proxied by MusicBrainz from FreeDB, so / is used to split the artist and title.
Ah. I didn't realize MusicBrainz proxied FreeDB automatically. That's kind of a pain to be sure!! There's nothing in the XML that tells you whether it's direct from MusicBrainz or proxied from somewhere else? Or maybe an option you can add to the URL to disable that feature? I don't know of an album that's proxied, offhand, to check with. If not that definitely deserves some kind of request to the MusicBrainz folks, especially if the format of the proxied material is not rendered compatible. Good luck Ross!
from #musicbrainz (http://chatlogs.musicbrainz.org/2006/2006-09/2006-09-30.html#T14-25-13-554334): 14:25:13 <luks> dseomn: there is a status in the RDF response. <mq:status>OK</mq:status> means it's from MB, <mq:status>Fuzzy</mq:status> means it's from freedb 14:26:01 <luks> or they could simply eleminate the problem by using the new web service, which doesn't use freedb as all
http://chatlogs.musicbrainz.org/2006/2006-09/2006-09-30.html#T14-40-12-930921 14:40:12 <luks> sorry, i was wrong. freedb lookups will return <mq:status>OK</mq:status> as well 14:43:12 <luks> but they still can tell if it's from freedb by checking the release ID 14:46:13 <dseomn> luks: what's the difference between what release id's would be returned? 14:46:47 <luks> http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2004-June/000832.html - there is an example of a RDF with freedb data 14:48:29 <luks> so if release id = "freedb:genid1", it's from freedb 14:48:45 <dseomn> ah, thanks 14:49:12 <dseomn> you mean the line '<rdf:li rdf:resource="freedb:genid1"/>' right? 14:49:18 <luks> yes 14:49:21 <luks> hm, I thought SJ saves MB IDs to the tags 14:49:28 <dseomn> it does 14:49:47 <dseomn> are you thinking that it might save that to tags? 14:49:49 <luks> even these bogus freedb ones? 14:50:13 <dseomn> I don't have and freedb and not mb cds to test with 14:50:32 <dseomn> *any maybe sj should parse the IDs first and do something like: if (id begins with "freedb:") { parse data with freedb magic, ignoring id tags else { parse data without freedb magic, including id tags }
ROCK. Thanks for that.
Has any progress been made?
Created attachment 77109 [details] [review] patch to not do slash parsing if the id doesn't start with "freedb:" instead of testing for a VA release This works for me, but it doesn't fix the possible problem that fake "freedb:" ids might be written to tags.
Committed, thanks.