Re: [dev] music db editor

From: Szilágyi Szilveszter <szilveszter_AT_gmx.co.uk>
Date: Sat, 12 Oct 2013 10:27:43 +0200

Hello,

as for question 4,
I use Cmus and I am quite happy with it.
Based on ncurses like Midnight Commander.
It has 5 different views (Album/Artist, Library, Playlist, Play Queue, Browser).
No tag editor, no database operations.
You can also control it by cmus-remote command.
Here is my .conkyrc displaying current track.

${if_running cmus}\
  ${exec cmus-remote -Q|grep "file"|awk '{$1="";print}'|sed -r "s/.*\/([^/]*\/[^/]*)/\1/"|xargs -0 -I {} expr substr "{}" 1 44|head -n1}...\
  ${exec cmus-remote -Q|grep "title"|awk '{$1=$2="";print}'|sed 's/^ *//'|xargs -0 -I {} expr substr "{}" 1 16|head -n1}...\
$endif\

Regards,
Szilveszter


On Sat, Oct 12, 2013 at 06:16:57PM +1100, Daniel Bryan wrote:
>The reason all the existing solutions are so sucky is that they try to
>solve too many problems. I think that if you deconstruct what you want
>this program to do, the concept falls apart a little.
>
>I'm not sure how "suckless" it is in terms of the code - for all I know
>it's a maintainers' nightmare - but it seems like MPD already does
>a lot of what you want.
>
>Furthermore, it has a simple client-server architecture; MPD just binds
>to a socket and clients talk to it with a simple control protocol.
>Security can be handled at the network level. Anyone can write a client;
>I use mpc, a nice unix-Y utility, but there are clients written in GTK
>and QT and for Android and iOS etc. (they all suck compared to a CLI
>interface obviously). Some of the web interfaces aren't too bad.
>
>This is my entire mpd.conf:
>
> music_directory "/var/lib/mpd/music"
> db_file "/var/lib/mpd/mpd.db"
> log_file "/var/log/mpd/mpd.log"
> log_level "verbose"
> pid_file "/var/run/mpd/mpd.pid"
> state_file "/var/lib/mpd/mpdstate"
> user "mpd"
>
> audio_output {
> type "alsa"
> name "My Sound Card"
> }
>
>
>> 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.
>
>This is precisely what MPD does.
>
>> 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.
>
>Searching:
>
> mpc search artist Fela
>
>Sorting and filtering:
>
> mpc search artist Fela | sort -r | grep 'Expensive Shit'
>
>> 7) Editing. Undecided.
>
>Specialised tools do this better.
>
>I'm confused by the perceived need for a "music manager" at
>all. There are fantastic scripts out there for munging idv3 tags and all
>that; combined with find and xargs you can do anything. For playback and
>browsing your library, MPD does a great job.
>
>I don't know what "management" there is to be done beyond that.. is this
>program designed to solve the fact that you didn't organise your music
>files into artist and album in the first place?
>
>It sounds like this could be a bit of a monolithic beast.
>
>I did once start (and abandon) a tool that did a small part of this: it
>would examine the tags in my music folder and identify:
>
>* files that weren't organised correctly into folders by artist and
> album
>* files that seemed to be missing key tags like track number, artist,
> album
>
>It would print the filename, the artist and the album, tab-delimited, so
>it was easy to then script moving the offending files into the right
>place with cut, xargs, awk, etc.
>
>Daniel
>
>
>On 2013-10-11, Evan Buswell wrote:
>> 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 - 10:27:43 CEST