#musicbrainz

they made a voice synthesizer based on Lia, then used that voice synth to sing one of Lia's songs.

could you imagine listening to a song where a voice synthesizer based on your own voice is covering you?

ianmcorvidae: what's that?

just submitted: daemon mode/MPD compatibility mode

last line of issue is a bit tongue-in-cheek ;)

kepstin-laptop: 2011-02 code drop, eh? Bit late for that, aren't you? ;)

ianmcorvidae: end of month ;

;)

2011 :P

...

gah.

you set the due date right, just not the title

mm, autogenerated bindings

I wonder if libmb4 is in AUR

nope

darn

exherbo has it, but only beta2, I should bump that package version

the AR schema design's gonna be interesting to do. I'm wondering if I should do a general extensible design like on the musicbrainz db, or if I should special case various types into full db relations.

I'd go fully general, myself

but then, I also want support for any new AR immediately

as it is, the db schema design is basically a simplified version of the real musicbrainz db schema

one potential worry is that there has been talk of n-ary ARs -- but I guess you can deal with that when it happens

the particular thing that was changed is that the various 'name', 'title', etc. fields are stored directly in the tables instead of being in their own x_name tables.

so it'll take very slightly more space, but that's okay because who's gonna have all million MB releases in their collection? :)

I figured that for the size of most people's music libraries, the duplication of names would be trivial; and it's no more information than any current db player would store

yeah

32M/home/cwalton/.local/share/rhythmbox/rhythmdb.xml

uncompressed xml ftw.

hah

throw it past gzip? naaaaaaah

32MB of XML isn't that bad, though

admittedly, I'm using a filesystem with transparent file compression

some of our WS queries are worse than that!

oh? btrfs or something else?

btrfs, yeah

I keep meaning to set that up

but I'm lazy sometimes :P

that's only 22409 files ^^ :)

heh, is that 32MB actual disk usage or what it would be on a normal-person FS?

that's the file size, not disk usage.

okay

I'm surprised rhythmbox can fit that much into 32MB of XML then, hah

the really fun thing is that most of my music is japanese, and it stores the characters as xml hexadecimal character entities like 雨

that's 8 bytes for one character.

huh

Y NO UNICODE, RHYTHMBOX!?

and filenames are url-encoded, for a 3× expansion on the number of bytes.

(or something like that)

That's Unicode, just escapedfor XML.

s/df/d f/

can't you use utf-8 directly, though?

that would be wildly more efficient

ianmcorvidae: yep.

You can.

(well, in this case it would anyway)

It stores MBIDs?

why yes it does.

anything sane stores MBIDs

I didn't think anything was sane, ianmcorvidae.

even *MPD* stores MBIDs and it's *stupidly* simplistic sometimes

It certainly doesn't make use of them.

mpdscribble does

(notably it doesn't store the replaygain parameters, those are read from the files at playtime)

Leftmost: rhythmbox scrobbles mbids.

but that's it.

yeah, that's usually all anything does with MBIDs

sadly :(

I want it to be more MBID aware.

(nudge nudge finish writing Riker :P)

Leftmost: there's a reason I'm writing riker ;)

I was all ready to say something snarky, and you go and ruin it.

Leftmost: if you have any awesome ideas for a musicbrainz-aware player, add them to https://github.com/kepstin/riker/issues

("Someone should write an MBID-aware player. Maybe name it riker."

+)

:P

kepstin-laptop, any mockups or sketches anywhere?

Leftmost: not yet. If you have some ideas for gui, post them on https://github.com/kepstin/riker/wiki/GUI-Mockups

I plan to make a few sketches tomorrow with some ideas.

Riker was just onscreen.

Perfect time to be looking at plans for it.

hmm. playbin2's gapless support is a bit iffy, and has been disabled off and on.

rhythmbox's gapless support has worked consistently and well for me since it was switched over to playbin2.

ianmcorvidae: hmm, that's an interesting idea; I might want to use http://zeitgeist-project.com/ to collect stats

bleh

Leftmost: which version of rhythmbox are you using?

not a terrible idea, the problem is I don't want to have to install zeitgeist :P

ianmcorvidae: maybe i'll make it an optional add-on, like scrobbling :)

2.95, kepstin.

as long as I can have logging without zeitgeist, I'm happy :)

Leftmost: hmm, I haven't ever had ~2.95 working properly - it would always hang after a couple of songs.

The only problem I have with rhythmbox right now is that it takes 20s or more to open. On an SSD.

zeitgeist is supposed to do neat things like be able to associate what music you're listening to with what you're currently doing.

Leftmost: I haven't had that issue - it opens more or less instantly, and is usable fairly soon after, but it takes a while before it's done rescanning the library

How many songs?

Anyhow, I will put in a strong vote for the use of gstreamer. It's also possible that gstreamer 1.0 will improve on playbin2's gapless support.

22409 on my laptop right now

more on my desktop; and my desktop is reading the files off an nfs share.

Odd.

you turned on the magical nfs asynchronous switch thing, though, yeah? (I think that was you)

ianmcorvidae: yeah :)

Leftmost: a cold start of rhythmbox on my laptop is usable in about 5 seconds, fully rescanned in 10-15.

(my laptop has a seagate momentus xt hybrid ssd-hdd)

presumably that first 5 seconds is spent loading and parsing the 32mb xml file for the library ;)

I've had some issues with rhythmbox. It's honestly not terribly well written. I still think gstreamer is the way to go, though. :P

I'm still using rhythmbox 0.13 because of that playback crashing/hanging issue I hit in 2.95 :/

the limited code I have for riker right now just reads tags from a file with gstreamer, does a musicbrainz xml ws query, and inserts data into a database.

reading tags with gstreamer is actually kind of interesting to do, and doesn't take that much code

just hook the file up to a decodebin, and bring it to PAUSED, and it'll emit tag events for all the gstreamer-supported tags.

and gstreamer supports quite a lot of tags :)

haha

I've consumed a goodly amount of gstreamer kool-aid.

I purged it from my system due to rhythmbox kinda sucking

and switched to mpd.

rhythmbox is a piss-poor example of a gstreamer-based interface.

part of the reason I want to use gstreamer is that it's easy to throw in audio filters and stuff with no real extra app code

like the bs2b filter for headphone listening or replaygain.

It does a lot of stuff outside of gstreamer and doesn't do it too well.

and rhythmbox's gstreamer code mostly predates a lot of modern conveniences, and isn't that great either

I have no doubt :P I haven't touched anything gstreamer-related since 2007

but I can load massive libraries in it, it has fast search, it scrobbles, and does replaygain.

and even then it was only rhythmbox (and exaile, if that uses gstreamer -- not sure)

gstreamer has also come a very long way in the past few years.

I'm really looking forwards to gstreamer 1.0, they have some pretty cool stuff planned.

yeah

mostly in support of non-linear video editing, but lots of enhancements all around.

When I first started dogfooding GNOME, totem was barely usable for most of my day-to-day. Now it works almost perfectly for me.

mostly I'm just very suspicious of anything that's tied to GNOME or KDE, in part because they usually expect me to install the rest of their software if I try to install one little thing

it's a pity they haven't enabled 10bit h264 decoding yet :)

e.g. the list of dependencies for tracker is stupidly huge

that's the /only/ thing I miss in totem.

a lot of tracker's deps really are optional, though

heh, I dunno

ianmcorvidae, I think there's that habit, but I think it's hardly necessary.

it was essentially unusable even with just the 80 dependencies arch made me install :P

most of tracker's dependencies are really just file decoders and file-reading libraries for the various formats it can index

which you have to admit is better than reimplementing all that themselves...

certainly

tracker is pretty intense dependency-wise. A lot of GNOME apps are less so.

the non-optional tracker dependencies are libpng, glib, sqlite, libxml2, libgee, and pango.

and that's /it/, really.