[dev] music db editor

From: Evan Buswell <ebuswell_AT_gmail.com>
Date: Fri, 11 Oct 2013 23:38:15 -0700

Hi all,

New to this list, but a great admirer of some of the elegance I've
seen coming out of the suckless community. Apologies for a very long
first post, but it's because I'm trying to help a lot? We'll go with
that. Also, double apologies if this ought to go elsewhere. It seemed
like a proposal that would fit in well with the current set of
suckless programs and others on this list might be interested in it.

In what began as a sort of rage against the immense suckiness of
rhythmbox, banshee, clementine, itunes, etc. etc., I've been thinking
about writing a music db management program that would do just that.
Existing software is so awful and agglomerative that almost anything
would be better, so all the more reason for caution at the beginning.
I know plenty of people probably just happily/unhappily use fs
organization + mplayer. Awesome if that works for you. It used to, but
the niceness of not having to use crap was finally outweighed by the
awkwardness of this method and its distance from hardware players.
Here's what I'm thinking so far:

1) There is no actual "music database" that's updated. There is just a
cache db which automatically indexes the metadata embedded in music
files. The tags on the file are always authoritative.

2) There is one configurable location with music files. If a user
needs them in more than one place, they can use symlinks. By default
this is just ~/Music.

3) The music folder is watched. The cache is updated/invalidated
automatically when a file is altered or a new file/folder is added
anywhere. This should be easy/lightweight enough with inotify,
although other more portable suggestions are welcome so long as they
don't involve something hideous that pulls in all of gnome. On startup
the whole shebang will have to be reindexed, but careful use of stored
mtimes, background reindexing, plus a fallback start-with-clear-cache
flag should keep this from getting too out of hand.

4) Support for meta-tags, like "artist" that are present everywhere
but differ in id3v1, the several id3v2s, flac, etc. Access to any tag
directly by name when that is needed.

5) Sorting. Searching. This could potentially be done through straight
sql (and use of sqlite), but then I don't like sql much, so...yeah. I
suppose this will likely just have
key--regex--sortkey/prevsortkey/prevprevsortkey/etc. It would be nice
to be completely general, but that would involve the creation of a
sql-like language that isn't awkward for 98% of actual queries.

6) Display. Needs to be graphical bc of embedded pictures. But should
be only one view: a simple table with configurable columns
corresponding to tags/metatags. Album art is a column in the table
just like everything else. If someone wants some itunes-like album
picture list view (and don't get me wrong, I kinda like that), there
should be a separate chooser program that gives that view and nothing
else.

7) Editing. Undecided. Could be simple double click on a field makes
it editable. Better might be an interactive sed-like regex, but this
has the potential to totally wreck massive numbers of files very
quickly. Any way about it I can't completely depend on analogy to
sed/ed/vi/whatever, as there's images to consider. Anything more
automagically complicated than opening a file chooser for images is
immediately barred as something to be implemented in a separate
program, if at all.

8) Playback. No playback. But can launch a specified command with a
group of files based on a search/sort.

9) Organize files. No file organization, but I'll likely build a
separate commandline program that arranges the filesystem based on
tag. Actually, this is the only part that I've started.

10) Sync. Should be able to manually sync with libgpod or libmtp
supported devices. As in: search, sync results with device x.
Automatic sync of a complex search should be supported through shell
scripts. Not decided, but atm I feel like taking files *from* these
devices is separate enough to jettison.

Questions:

1) Most of these types of programs are now media rather than music
management programs. Does anybody actually want this? I'm all for more
generality if it can be done with minimal added complexity and in a
way which actually results in more simplicity, rather than just
idiotic agglomeration. But I suspect this is just agglomeration.
Nobody tags movies, AFAIK.

2) Toolkit? Is swk ready for a project like this? Is gtk2 too sucky? I
love C. A lot. But it may not be the best for quick, simple GUI
development (yet!). Fallback is either tcl/tk, or Python+tkinter.
Actually in all likelihood I'll use Python+tkinter, but I want to
explore other options first.

3) Suggestions on being more simple? Can this be usefully partitioned
into more than one app? Can I usefully not do some of this? I'm open
to just having a few command line tag/copy/etc programs, too, but
somehow the task of music management would need to be made as fast as
using something like Clementine is, on the rare occasions that it
actually works and does what you want instead of simplifying in all
the wrong places and then crashing. Really, my preferred way of doing
this would have been to just write a FUSE filesystem and call it a
day. Filesystems and databases have always seemed redundant to me. The
trouble is that actually quite a few tags have "/" embedded in them,
so this is not really workable atm. Why shells/filesystems/tools
didn't long ago provide for full binary filename support with escape
sequences is beyond me.

4) Suggestions on programs which already do all or a portion of this?
Possible reusable crossovers to other projects? It strikes me that 90%
of this could be implemented as a completely generic interactive
key--value database editor. But I'm not sure the glue and special
cases for the other 10% (cache vs. db, plus the extra variable of a
file corresponding to a data set) is worth it.

Caveats:

Just (!) that I'm in a PhD program and should be doing that instead of
thinking about this. And probably randomly will. For months at a time.
But it's possible that with a good, simple starting design and
judicious use of existing libraries this could be a pretty quick
development process. Especially with help. Any way about it, if enough
people are interested I'm fine taking more of a background role,
anything from co-maintainer to mindless (but shiftless) slave. I just
want to never use Rhythmbox/clementine/banshee/etc. ever again.

For whoever made it this far, thank you!
-Evan
Received on Sat Oct 12 2013 - 08:38:15 CEST

This archive was generated by hypermail 2.3.0 : Sat Oct 12 2013 - 08:48:07 CEST