Review: Exaile Media Player (Linux.com)

[Posted January 8, 2007 by corbet]

Linux.com reviews the Exaile music player application. "Exaile is similar to Amarok, but it's based on GTK+ (the GIMP Toolkit), the same GUI toolkit GNOME uses, and thus it loads almost instantly on GNOME and integrates nicely with it. The first impression the program makes is that it's a clone of Amarok, at least from an interface point of view; if you're an Amarok user, you'll feel right at home."

File date order

Posted Jan 9, 2007 2:13 UTC (Tue) by ncm (guest, #165) [Link] (21 responses)

(It would be extra work to match Amarok's C or C++ code bugs in Python.)

Exaile seems very nice, but not so useful to me since it appears to lack XMMS's ability to sort a playlist by file date, which (in my rips) matches album order. My NEXBlack gadget has the same problem. How do other people deal with this?

Playlists and track ordering

Posted Jan 9, 2007 3:57 UTC (Tue) by Ross (guest, #4065) [Link]

I used to set the title format in XMMS to include the track number, padding with zeros to two digits, and then sort by title. If you want to sort albums the year of release would probably do the trick. But the sorting got kind of slow, and had to be repeated every time I ripped a disc, so I wrote a script to create playlists. I agree it seems like something that music players should be able to handle.

File date order

Posted Jan 9, 2007 3:58 UTC (Tue) by sjj (guest, #2020) [Link] (12 responses)

I name them like this:
music/Spoon/Gimme Fiction/Spoon_Gimme_Fiction_4_My_Mathematical_Mind.mp3 and sort alphabetically.

... only to find out that I should do 01, 02 for track numbers etc because my car mp3 player and my phone won't sort that right. Then I fix that and notice that the car player only uses 8 chars to sort.

So now I just use random play ;-)

File date order

Posted Jan 9, 2007 5:04 UTC (Tue) by drag (guest, #31333) [Link] (11 responses)

What I like to do personally is use MPD for playback and use one of it's front ends to control it.

The downside is that the clients I use are able to pull the ID3 tags off of my *.flac files (which most of them are) It can pull the tags off of the Ogg files fine though. This is how I keep things orginized.

But Amarok can see the id3 tags well. So what I do is have ~/var/mpd/playlists hold the playlists aviable for it and then I use Amarok to help me generate and make playlist that I then drag and drop into that directory.

Works like a charm.

I know it's a bit odd, but I find the sound quality with mpd is better then what I get from something like rhythmbox or Amarok for some reason.

File date order

Posted Jan 9, 2007 7:54 UTC (Tue) by ncm (guest, #165) [Link] (10 responses)

Hmm, did you mean client(s?) you use are *not* able to pull ID3 tags from your FLAC files? I wonder if it/they can handle Ogg/FLAC files...

File date order

Posted Jan 9, 2007 8:54 UTC (Tue) by drag (guest, #31333) [Link] (9 responses)

Yes either clients or the server (I don't know which is responsable) are not able to pull id3 tags off of flac files. They work fine for ogg files.

File date order

Posted Jan 9, 2007 10:33 UTC (Tue) by nix (subscriber, #2304) [Link] (8 responses)

FLAC files don't have ID3 tags, nor do Ogg files; they have Vorbis comments. (Sorry, pedantic, I know...)

Further, the same code that reads comments out of Ogg Vorbis files should be able to read them from Ogg FLAC files (but possibly not from FLAC files not in an Ogg container). If your FLACs aren't Ogg-encapsulated, try encapsulating them and see if that works. (Of course, it's possible that MPD isn't even *trying* to read Vorbis comments if the file is a FLAC file, in which case this won't help at all...)

File date order

Posted Jan 9, 2007 13:30 UTC (Tue) by drag (guest, #31333) [Link] (7 responses)

""FLAC files don't have ID3 tags, nor do Ogg files; they have Vorbis comments. (Sorry, pedantic, I know...)""

Fine with me. This could explain alot.

I went back and looked at the some of the files more closely... As it turns out it is reading the metadata from some of the flac files and not others. The only files that weren't getting picked up were flac files (and I have a mixture of Ogg Vorbis and Flac) so I assumed incorrectly that flac was the problem.

but now it seems that the problem is the program that I ripped them with. (I beleive grip, but I don't remember as I used a number of tools over the years)

When I run the 'file' command on the flac files that aren't having their metadata read by mpd are coming up as:
filename.flac: MP3 file with ID3 version 2.3.0 tag

A proper flac file shows up as:
filename.flac: FLAC audio bitstream data, 16 bit, stereo, 44.1 kHz, 9766680 samples

Now the data itself is definately flac. Flac123 plays them fine (although the tags aren't showing up). They show up in other programs as flac files, but I guess the container is what mp3 uses.

Or something like that.

This kinda pisses me off. Now I have to figure out a script to reencode them to proper flac files while converting the metadata to the proper format. At least now I have a slightly better idea of what is going on.

On a side note:
Does anybody have a favorite ripping program that uses cdparanoia or at least implements a similar level of error detection and correction?

Program choices

Posted Jan 9, 2007 15:38 UTC (Tue) by tajyrink (subscriber, #2750) [Link]

I'm using SoundJuicer for random needs, and used grip when I converted my whole CD collection. Anyway, back then I had limited disk space and decided Ogg Vorbis quality 7 should be enough for everybody... and grip handled ogg vorbis files' comments just fine, _even though_ I think I had to add manually track number parameter. Don't know if the default grip settings are nowadays better.

I found out the lack of track numbers after ripping ca. 60 CDs with grip, so I did a small script to get the track number out of the file name (Artist - Album/NN-Title.ogg) and add it with vorbiscomment:

#!/bin/sh

bdir=/tmp

cd $bdir

for directory in ${bdir}/* ; do
cd "${directory}"
for file in *.ogg ; do
tracknr=`echo "${file}" | cut -b 1-2`
echo T: ${tracknr}, file: ${file}
vorbiscomment -a -t TRACKNUMBER=${tracknr} "${file}"
done
done

Looking at FLAC parameters, you have to spend some time to utilize the -T tag a lot when using grip, because flac doesn't have different options for different tags like oggenc does, but it should be possible. I seemingly haven't done that, instead ripping all my FLACs with Sound Juicer. SJ is otherwise nice but if I recall correctly it doesn't set year tag.

File date order

Posted Jan 9, 2007 16:17 UTC (Tue) by nix (subscriber, #2304) [Link] (5 responses)

It looks more like you have straight MP3 files with .flac extensions to me :) nothing can read MPEG files with FLAC encapsulated inside as far as I know (I doubt anyone's ever written code to do any such odd thing). (Why flac123 can handle them is a mystery.)

You may find the `metaflac' tool useful for inspecting and editing Vorbis comments. (Note that unlike ID3 they are completely freeform: you can even have multiple comments with the same name...)

File date order

Posted Jan 9, 2007 18:37 UTC (Tue) by Lockjaw (guest, #4611) [Link] (4 responses)

After a recent update on my Debian Etch machine, the grip -> cdparanoia -> flac chain started producing files that the "file" command detects as mp3's. oggenc (flac for home system, ogg vorbis for ipod) would claim they weren't the right format for encoding. They appear to be valid, but unusually crafted flac files. Careful searching will show patches to file's "magic" so that these are properly detected as flacs.

Running flac by hand on the wav files left over from grip and then using metaflac to copy the tags from the "mp3" flacs produced a usable product. Next time I have a big pile of cd's to rip I'll try and track down the exact problem - I caught the flac command spawned by grip to create the flacs, and when I type it in on the command line it does just fine - and I only have the one version of flac installed on my machine. I suspect something is going on with the character encoding used by grip.

metaflac --export-tags-to=- detects_as_mp3.flac | metaflac --import-tags-from=- hand_crafted.flac

will do the tag copy for you.

File date order

Posted Jan 10, 2007 1:11 UTC (Wed) by piman (guest, #8957) [Link] (3 responses)

This is all way simpler than you're making it. :) The FLAC files just have ID3 data prepended to them. That makes them corrupted files, but many FLAC decoders can still read them, because many broken encoders write them, because many FLAC decoders read them, etc.

File date order

Posted Jan 10, 2007 17:59 UTC (Wed) by Lockjaw (guest, #4611) [Link] (2 responses)

Yep - the "broken" flacs worked on my Sonos system (and maybe one of xmms and xine, although I don't remember exactly), but I couldn't convert them to ogg vorbis with oggenc.

Still, you must admit some there's strange voodoo going on with grip creating them broken, and everything working just fine when I cut and paste the "flac" command I catch from grip using "ps" during the encoding. If it's really ID3 prepended that's the problem, then grip must be using a different library for the encoding even though it's executing the same flac command. Hmmm...

In any case, I can't have broken files, so they have to be fixed somehow. I'm rather addicted to the grip workflow after doing 600 discs with it, so next time I need to do a bunch I'll have to at least automate the repair with a script (or go back to the version of grip that worked when I did the 600...).

BTW - while I'm on the subject of being over-the-top with getting correct rips, let me put in a plug for using secure-cdparanoia.py. It's a python script that runs cdparanoia repeatedly on each disc, checking to make sure they read the same each time (or at least letting you know if they don't); I was surprised by how many don't. Also, plextor drives are worth the extra money. There's no better way to be convinced of this than ripping 600 discs a second time because of too many audible pops in the first set.

File date order

Posted Jan 11, 2007 4:32 UTC (Thu) by piman (guest, #8957) [Link] (1 responses)

In the Grip Config/ID3 panel there is a checkbox "Only tag files ending in .mp3". Turn this on and the problem should go away. It encodes to FLAC using the command line and then does the tagging itself.

File date order

Posted Jan 11, 2007 17:18 UTC (Thu) by Lockjaw (guest, #4611) [Link]

Thanks - makes perfect sense. The grip upgrade caused problems with my .grip config, and it must have gotten switched somewhere along the line. I'm sure I went too fast reconstructing it and thought "of course I want the tags", not thinking of the difference between tags and comments.

File date order

Posted Jan 9, 2007 5:42 UTC (Tue) by omez (guest, #6904) [Link]

I configure my ripper program to prepend the track number to the filename and the song name in the metadata. Padding with an appropriate number of leading zeros is required to ensure correct sorting. Books on CD require additional numbering to enforce the desired ordering.

Some players will circumvent even this strategy by stripping the leading numbers before sorting.

File date order

Posted Jan 9, 2007 8:18 UTC (Tue) by pheldens (guest, #19366) [Link] (5 responses)

In addition to proper tagging with easytag, this works nice for medium size collections, and lets the filesystem sort:

artist - year - albumname/01 - artist - songname.extension

http://easytag.sourceforge.net/

File date order

Posted Jan 9, 2007 11:08 UTC (Tue) by svena (guest, #20177) [Link] (3 responses)

Easytag might not be a good choice. At least the Rhythmbox devs discourage it's use.

File date order

Posted Jan 9, 2007 12:50 UTC (Tue) by k8to (guest, #15413) [Link] (2 responses)

This just says that easytag still uses id3v2.3.

Considering that id3v2.4 does not gracefuly degrade, I don't see much reason to use id3v2.4 _ever_, especially since there are no convenient command line tools for scripting manipulation of your files from metadata which will be able to understand your id3v2.4-tagged files. Not to mention there is a large body of mp3 playing software which does not understand id3v2.4.

I use exfalso for all my flac and vorbis tagging needs, but I have to fall back to really clunky programs for mp3s for compatability. This is really an indictment of the clowns who "manage" the id3 format through all its many binary incompatable changes which never seem to get around to improving it to not need them in the future. One of the many reasons I avoid mp3 when possible.

File date order

Posted Jan 10, 2007 1:32 UTC (Wed) by piman (guest, #8957) [Link] (1 responses)

Well, by that logic, since id3v2.3 doesn't gracefully degrade and id3v2.2 doesn't gracefully degrade, we should just not use ID3 beyond ID3v1.1. While in theory I agree with that :), I'd rather see pervasive ID3v2.4 support everywhere -- in general it's a much saner standard, and it supports UTF-8.

It's not that hard to write code that can read ID3v2.3 and ID3v2.4, especially to the extent EasyTag cares about (not much).

'mid3v2', included with Mutagen (which is required by Ex Falso), is a command-line-compatible clone of the 'id3v2' tool that id3lib has. I'm not sure it's "convenient" since 'id3v2' is not a great interface, but I suspect that's what you're referring to.

File date order

Posted Jan 12, 2007 3:48 UTC (Fri) by k8to (guest, #15413) [Link]

Yes, all the backwards incompatabilities of id3 are a big joke, but all the software on my system is capable of handling id3v2.3 (which is a really large amount), and only 2 programs handle id3v2.4.

Thus, the value of id3v2.4, due to network effects, is really low.

easytag

Posted Jan 9, 2007 19:47 UTC (Tue) by johnkarp (guest, #39285) [Link]

I gave up on easytag long ago after it kept on mangling accented and
non-latin tags. I always submitted bug reports, and they got fixed, but
the overall state never seemed to improve. And I still run into FLAC files
in my collection that won't play because easytag put ID3 tags instead of
vorbis tags on them.

Nowdays I just use the tagger built into Amarok. Being less automated, its
a bit more tedious to use, but at least I never have to manually fix the
tags afterwards.