Re: [Muine] [Patch] Better album defining

I just don't get it, what's so bad about supporting not-so-well-tagged music library. I'm not suffering this problem - I have a VERY well tagged music library, but some don't.

If we want Muine to be a "Just Work" kind of program to must people, we should do things that will make life easier. Of course, those things shouldn't hurt the beauty of Muine in any way. But, I don't think that Iain's patch is any harm to Muine. If you'll do a quick overview of the idea, you'll see that it has much more good than bad. The good side is that (1) lots of people that will start their Muine for the first time will not think 'WTF is wrong with this program, why do I have so many of the same album?!", (2) people who download songs from p2p programs could enjoy Muine much more, and (3) people who just like their music library organized in some strange way, could still use Muine. Now, let's look at the bad sides. Well,... sorry, I really can't think of any, besides for the stupid-old-quote - "Muine is for people who have their music library well-tagged." - WHO CARES?!

That's about it. I think Iain's patch is wonderful and should get into the official source of Muine, but maybe that's just me.

Sorry for my English, I'm not a native English spiain wrote:eaker as you can see...


Two possibly fairly typical use cases that Muine seems to have problems

Case #1

I have a pretty poorly tagged mp3 collection. As an example I have
tracks by KOOP, Koop and koop, from albums called "Waltz for Koop.",
"waltz for koop" and "Waltz For Koop". Its pretty clear that these are
all the same album - "Waltz For Koop" by Koop. Muine however gives me 3

Attached is a patch that makes a canonical name from album strings by
converting the name to lower case, and removing all punctuation. This
canonical name is then used as the album key.

Case #2

I really don't care about how things are laid out on the filesystem. As
a consequence of this, I have one huge mp3 directory ~/Media/Music. It
contains 500 mp3s. Then I also have another directory in it called
~/Media/Music/Unsorted. It contains about the same number of mp3s but
they've got dumb names, because they've just been copied from my friends
iTunes collection. And then when I rip a CD using Sound-Juicer, it
extracts the tracks to ~/Media/Music/album-title/

Scattered about these directories are various tracks from the same
album, I could have Music/radiohead-lurgee.mp3 and
Music/Unsorted/radiohead-you.mp3. Both of these are from the same album
- "Pablo Honey" by Radiohead. Muine however creates two separate albums
because the pathname is different, the album keys are Music/Pablo Honey
and Music/Unsorted/Pablo Honey.

Another problem with using pathname + album name is the case where two
artists have 2 different albums with the same title, and I have the
tracks in the same directory.

The patch also fixes this case by using artists, album name, and
performers as the album key, instead of pathname, album name. The only
thing I've thought of is should it use performer as these might be
different between songs?

I guess the real question in all this is "How well do we want Muine to
handle poorly organised and poorly tagged files?". I know it would be
nice to insist that people organise their files in a heirarchal
Genre/Artist/Album directory structure and have all their files
correctly tagged, but I think its really silly to believe that that
would happen for most people.

Any comments (either of my patch or the question)?


Index: Song.cs
RCS file: /cvs/gnome/muine/src/Song.cs,v
retrieving revision 1.40
diff -u -p -r1.40 Song.cs
--- Song.cs	27 Apr 2004 17:25:41 -0000	1.40
+++ Song.cs	23 May 2004 18:45:09 -0000
@@ -161,7 +161,7 @@ public class Song
			string dirname = Path.GetDirectoryName (filename);

-			return dirname + ":" + album;
+			return StringUtils.JoinHumanReadable (artists) + ":" + album + " " + StringUtils.JoinHumanReadable (performers);

Index: SongDatabase.cs
RCS file: /cvs/gnome/muine/src/SongDatabase.cs,v
retrieving revision 1.37
diff -u -p -r1.37 SongDatabase.cs
--- SongDatabase.cs	8 May 2004 12:24:45 -0000	1.37
+++ SongDatabase.cs	23 May 2004 18:45:09 -0000
@@ -229,7 +229,7 @@ public class SongDatabase if (song.Album.Length == 0)

-		string key = song.AlbumKey;
+		string key = StringUtils.MakeCanonical (song.AlbumKey);

		bool changed = false;

Index: StringUtils.cs
RCS file: /cvs/gnome/muine/src/StringUtils.cs,v
retrieving revision 1.12
diff -u -p -r1.12 StringUtils.cs
--- StringUtils.cs	26 Feb 2004 10:46:10 -0000	1.12
+++ StringUtils.cs	23 May 2004 18:45:09 -0000
@@ -19,6 +19,7 @@

using System;
using System.Runtime.InteropServices;
+using System.Text;

using GLibSharp;

@@ -70,6 +71,25 @@ public class StringUtils
		return ret;

+	public static string MakeCanonical (string str)
+	{
+		string lower;
+		StringBuilder ret = new StringBuilder ();
+ if (str == null) + return null;
+		lower = str.ToLower ();
+		/* Remove anything that isn't a letter or a number.
+		   FIXME: Should we even use numbers in this? */
+		foreach (char c in lower)
+			if (Char.IsLetterOrDigit (c) || Char.IsWhiteSpace (c))
+				ret.Append (c);
+		return ret.ToString ();
+	}
	[DllImport ("libc")]
	private static extern int strlen (string str);


muine-list mailing list
muine-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]