Re: [dev][announce] slm - music curation
Hi all, On Tue, Dec 3, 2013 at 4:13 PM, Alexander S. wrote: > The consensus solution: > 1) hardlinks, > 2) delete them when inode link count drops to one. If you use hard links, don't delete the hard links, and also monitor the "farm," then categorization and organization become the same problem. Edit the id3 tag and the file is automatically moved. Drop new files into an incoming folder, and then remove them after you check that they've been put in the right place. But lose no information if the incoming files were tagged incorrectly. I'm still thinking about other things, but I like this a lot. One reason that one may want to preserve the symlink option, as an option, is that someone may have their music on an external drive. Seems pretty common. Apologies for my late-to-the-party catch-up reply, -Evan
Re: [dev] Some thoughts about XML
I'm really not saying something very profound here, so I'm a bit confused by the sarcastic response. For certain things it's pointless and inefficient to parse something and then deparse it later. It's not like you're gonna put UTF-8 parsing into cat. On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Czarkoff wrote: > Evan Buswell said: >> I can care that this is UTF-8 when I need to, and not care otherwise. > > I would love to see the code that detects whether you care or not. > > -- > Dmitrij D. Czarkoff >
Re: [dev] Some thoughts about XML
It's still UTF-8 in practice. It's just IMO not the job of parsers of this sort to start enforcing or translating the character set of strings. All the parser has to look for is \" " and \\. I can care that this is UTF-8 when I need to, and not care otherwise. I didn't start replacing commas with null bytes or ridiculous crap like that. On Sat, Oct 19, 2013 at 3:28 PM, Thorsten Glaser wrote: > Evan Buswell dixit: > >>playing with that adds symbolic references and uses binary instead of >>utf-8 strings); RST is better for structured text---though I'm not > > Oh yeah, let’s all do binary now instead of passing around plaintext! > > Wait. No! > > Pointing out Unix/Plan 9 way works just fine, > //mirabilos > -- > Beware of ritual lest you forget the meaning behind it. > yeah but it means if you really care about something, don't > ritualise it, or you will lose it. don't fetishise it, don't > obsess. or you'll forget why you love it in the first place. >
Re: [dev] Some thoughts about XML
I loathe XML, but I think the OPs bigger point was: hey look, here is
a way that we can try and create a space between the suck of the web
and our code. So we support browsers through XSLT, and do something
slightly more sane with XML. I think that's a pretty valid suggestion.
IMO, this doesn't go far enough as XML is really not good for
anything. JSON is better for data (or a variant "KSON" I've been
playing with that adds symbolic references and uses binary instead of
utf-8 strings); RST is better for structured text---though I'm not
sure I really like any of the structured text formats.
But OTOH, I do like the idea of separating the translation-to-html bit
from the generate-sensible-output bit. XSLT may have done this poorly,
but it's on the right track (and what else works better for this, Awk?
Perl? m4?). I mean, I take the point that we can't really make the web
stack all that much better, but at least we can containerize suck?
Yes?
On Sat, Oct 19, 2013 at 11:54 AM, Evan Buswell wrote:
> I loathe XML, but I think the OPs bigger point was: hey look, here is a way
> that we can try and create a space between the suck of the web and our code.
> So we support browsers through XSLT, and do something slightly more sane
> with XML. I think that's a pretty valid suggestion.
>
> IMO, this doesn't go far enough as XML is really not a good for anything.
> JSON is better for data (or a variant "KSON" I've been playing with that
> adds symbolic references and binary instead of utf-8 strings); RST is better
> for structured text---though I'm not sure I really like any of the
> structured text formats.
>
> But OTOH, I do like the idea of separating the translation-to-html bit from
> the rest of it. I mean, I take the point that we can't really make the web
> stack all that much better, but at least we can containerize suck? Yes?
>
> On Oct 19, 2013 9:04 AM, "Dmitrij D. Czarkoff" wrote:
>>
>> Szymon Olewniczak said:
>> >> s/HTML/XML+XSLT/g is quite a revolution.
>> > But it's something whitch I can use in my application straight away
>> > without forcing user to change their web browsers.
>>
>> You aren't really about replacing HTML with XML+XSLT; you are about
>> *generating* HTML with XML+XSLT, are you?
>>
>> > It's about whole "modern web" stack and ways we can make it better,
>> > without a huge revolution.
>>
>> We can't.
>>
>> 1. We have nothing to do with its development.
>> 2. It only gets worse over time.
>> 3. It is {,mis,ab}used on such scale that it can't be sanitized.
>>
>> You can't have a sane tool for doing everything.
>>
>> --
>> Dmitrij D. Czarkoff
>>
>
Re: [dev] music db editor
Since people seem interested in the filesystem-is-metadata approach,
here's a pretty ancient perl script that I used for about 5 years to
do that (wrote this before Python was even a thing). Files are assumed
to be organized as artist - album/track.title.mp3. In order to better
replicate the filesystem structure on portable media players, this
tags album as "artist - album" so you can get rid of all the lists on
the interface except album view. I used this with a 1-line script,
"mvmp3s" for quickly moving files to the right place, which was just
something like:
for file in *.mp3; do mv "$file" "$(echo $file|sed "$@"|titlecase)"; done
Not hard to just type that yourself, but slightly faster and easier this way.
Like I said, I've finally decided for various reasons to take the
opposite approach. So I built a script to organize files based on
tags. Attached that, too, just in case. It basically uses the iTunes
format.
Honestly, I feel like the filesystem solution *should* be better for
me, but isn't, just because of the inability of too many
filesystems/shells/tools to handle the full unicode charset in
filenames (including very common characters like '/', ':', '?'), which
consequently makes it impractical to implement tag2fn and fn2tag as
proper complements. Basically the choice came down to putting awkward
if readable substitutions into my mp3 files ('[/:]' -> ' - '; '?' ->
'_'), and breaking compatibility with the rest of the world, hence
never integrating mp3s into the library without a lot of overly
unmechanical careful renaming, or to stop being such an iconoclast. Of
course, I still want to do things at least right-ish (that suck less),
so here I am.
On Wed, Oct 16, 2013 at 3:01 PM, Bobby Powers wrote:
> On Tue, Oct 15, 2013 at 11:10 AM, Martti Kühne wrote:
>> 3.: I don't have any need to collect metadata about my music I run off mpd,
>> and
>> if I had the need, I could build symlink trees from my already sane directory
>> structure:
>>
>> music/A/Artist/Album/trackname.flac
>>
>> That way I could add whatever metadata I could think of on any point in the
>> tree - and in actual filesystem metadata, since, that's where metadata goes,
>> right? As an example, I could list albums by different artists in a "weird"
>> directory and link all the weird music there, residents, die antwoord, etc.
>
> yes, yes, this seems like the way to do it. I like this much better
> than the sqlite I had been using, thanks for the encouragement.
>
>> I myself have a lot of unknown artist id3v2 tags and broken encodings in that
>> data, but I don't much need to give one, since I know where to find my
>> stuff...
>>
>> Also, where's the code? I'd be interested to try stuff out, especially 3
>> figure
>> SLOC projects as it's tradition in this part of the net...
>
> I'm going to work on this later this week, I'll post something with
> hopefully minimal suck then.
>
> yours,
> Bobby
>
tagmp3s
Description: Binary data
slurpmusic
Description: Binary data
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.
>>
>
Re: [dev] music db editor
sed 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 complete
[dev] music db editor
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 occasi
