Re: [dev] music db editor
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 t
Re: [dev] music db editor
mpd is actually about 50% orthogonal to what I want to do. It
maintains a database in order to play files. I'm pretty OK with the
actual players out there. The primary purpose here is not playing
music but managing and editing the metadata associated with music
files; I just threw in the call-an-external-player feature since, if
you already have a means to select a bunch of files based on tags (for
inspection/editing), this might literally be about three lines of code
extra. Although code is not the only consideration, so perhaps that
doesn't belong.
I kind of wondered whether I'd get this response. And of course no
worries if people prefer to go with existing tools. But I do think
there's a real need, at least for me. Maybe another way of thinking
about it is what I'm building would be to tools like id3v2 as an
interactive text editor is to sed. Sed is not replaceable by vi, and
in many ways is "better" and more flexible. But you wouldn't want sed
to be the only way to edit your file. Same for a music database.
Sometimes it's convenient to use things like for file in `find -name
*.mp3`; do if id3v2 -l $file|grep -q 'TPE1.*something'; then id3v2 -a
'something else' $file; fi; done. And indeed, wrapped in some scripts
that hid the boilerplate for the 90% cases, that's what I did for
years. But many typical tasks just don't map very well to this
paradigm, e.g. look through the entire music database and make sure
you don't have anything tagged incorrectly. What's incorrect? Hard to
say; you only really know it when you see it. It's that "seeing it"
that's made difficult by most command line tools. You can create
heuristics, but these only go so far. That being said, I'm not married
to having this functionality follow the "music manager" paradigm; in
fact I'd like to move away from that as much as possible, while still
keeping visualization/interactive editing. One possible less
monolithic way would be to have three programs; one which sucked tags
into a tabular database; one which tagged files based on the database;
and one which provided a sort of visual editing of a tabular database.
Potentially the last could even be a regular text editor (although
that wouldn't solve the issue of album art). But I get fidgety when I
think about nontrivial databases being replicated, edited, and then
overwritten. Potentially, one bug and boom, the whole thing's gone.
-Evan
On Sat, Oct 12, 2013 at 12:16 AM, 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?
Re: [dev] music db editor
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 l
Re: [dev] music db editor
On 12 October 2013 08:16, Daniel Bryan wrote: > > 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. Still got that script lying around? Rob
Re: [dev] music db editor
On 10/12/13 at 11:35am, Rob wrote: > On 12 October 2013 08:16, Daniel Bryan wrote: > > > > 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. > > Still got that script lying around? > About this, one of the few gtk programs I cannot do without is easytag. In particular, its ability to find and download metadata from cddb based on the files to be tagged. Does anyone here use another program for this purpose? Manolo
Re: [dev] music db editor
* Manolo Martínez [2013-10-12 07:19]: > on the files to be tagged. Does anyone here use another program for this > purpose? http://musicbrainz.org/doc/MusicBrainz_Picard Cheers Jochen
Re: [dev] music db editor
> > on the files to be tagged. Does anyone here use another program for this > > purpose? > > http://musicbrainz.org/doc/MusicBrainz_Picard > Thanks, I'll give it a try.
Re: [dev] music db editor
I started on a project a while ago that may be a helpful starting
point. It is a daemon written in C that watches a directory with
inotify ("~/Music" by default), tracks metadata about music files in a
sqlite3 database, and responds to HTTP queries about artists and
authors with JSON. It fits my needs perfectly well; I use it every
day to listen to music, although there are certainly aspects that
could be improved. I'm open to suggestions and criticisms. It
currently has 4 deps: taglib, sqlite3, libevent2, and glib. It looks
like the only thing I'm using glib for is URI escaping (this was
written before I was trying to suckless), it could easily be removed.
https://github.com/bpowers/cnote
usage:
$ curl localhost:1969/artists # list all artists, returns array of strings
[
"A Tribe Called Quest",
...
]
$ curl localhost:1969/albums/Soul%20Limbo # info about tracks in an album:
[
{
"album": "Soul Limbo",
"artist": "Booker T. & The M.G.'S",
"path":
"amazonmp3/Booker_T__&_The_M_G_'S/Soul_Limbo/B000UBJSDO_(disc_1)_01_-_Be_Young,_Be_Foolish,_Be_Happy.mp3",
"title": "Be Young, Be Foolish, Be Happy",
"track": "1"
},
...
]
On Sat, Oct 12, 2013 at 7:34 AM, Manolo Martínez
wrote:
>> > on the files to be tagged. Does anyone here use another program for this
>> > purpose?
>>
>> http://musicbrainz.org/doc/MusicBrainz_Picard
>>
>
> Thanks, I'll give it a try.
>
Re: [dev] music db editor
Thanks; that looks like a great starting point. One way of doing this
would be to define/borrow a simple key/value db protocol, build/borrow
a server that would speak this db protocol, but with the back end
being your music library. Then the front end could just be a
completely generic visual db editor. I think I might try and go with
that.
-Evan
On Sat, Oct 12, 2013 at 12:20 PM, Bobby Powers wrote:
> I started on a project a while ago that may be a helpful starting
> point. It is a daemon written in C that watches a directory with
> inotify ("~/Music" by default), tracks metadata about music files in a
> sqlite3 database, and responds to HTTP queries about artists and
> authors with JSON. It fits my needs perfectly well; I use it every
> day to listen to music, although there are certainly aspects that
> could be improved. I'm open to suggestions and criticisms. It
> currently has 4 deps: taglib, sqlite3, libevent2, and glib. It looks
> like the only thing I'm using glib for is URI escaping (this was
> written before I was trying to suckless), it could easily be removed.
>
> https://github.com/bpowers/cnote
>
> usage:
> $ curl localhost:1969/artists # list all artists, returns array of strings
> [
> "A Tribe Called Quest",
> ...
> ]
> $ curl localhost:1969/albums/Soul%20Limbo # info about tracks in an album:
> [
> {
> "album": "Soul Limbo",
> "artist": "Booker T. & The M.G.'S",
> "path":
> "amazonmp3/Booker_T__&_The_M_G_'S/Soul_Limbo/B000UBJSDO_(disc_1)_01_-_Be_Young,_Be_Foolish,_Be_Happy.mp3",
> "title": "Be Young, Be Foolish, Be Happy",
> "track": "1"
> },
> ...
> ]
>
> On Sat, Oct 12, 2013 at 7:34 AM, Manolo Martínez
> wrote:
>>> > on the files to be tagged. Does anyone here use another program for this
>>> > purpose?
>>>
>>> http://musicbrainz.org/doc/MusicBrainz_Picard
>>>
>>
>> Thanks, I'll give it a try.
>>
>
