glyr - a musicmetadata searchengine utility and library written in C

SahibBommelig · 2011-09-02 14:59:04

Hello,

libglyr is a library to serve all metadata a normal musicplayer usually needs (like covers, songtexts, fanart and stuff see the README for more)
There's of course a commandline version of it called glyrc:
Example:

glyrc lyrics --artist "Excrementory Grindfuckers" --title "Das Kuh"

There's a plethora of options and features, you should look them up in the README (see below).

What can it be used for?

Musicplayers/managers.
Desktopwidgets that show the current song's cover (etc.)
Embed metadata in your musicfiles.
Whatever needs music metadata, that is not served by musicbrainz.

Why?

Because every player implements this, often with strange results.
Often many providers break and don't get fixed.
They're somewhat built-in and not usable from the outside.
Many scripts for this were pretty limited.

Why In C?

Many musicplayers are written in it.
I like it and learned a lot :-)
Don't panic! There are bindings to other languages:
- my Python-Wrapper plyr.
- meh's Ruby-Wrapper ruby-glyr.

Links:

Github Page (with README and wiki)
PKGBUILD for glyr (git version)
Bugreports / Requests or to sahib@online.de

Applications that use it:

GMPC
Pragha
Freya (My little Fun-MPD Client, discontinued though) .
lyvi, a nice ncurses lyrics (and more!) viewer.

Dependencies: glib-2.0, libcurl and sqlite3

Obligatory Screenshots:

Commandline utility (glyrc):

GMPC with glyr in action (old):

Edit: Updated.

Last edited by SahibBommelig (2012-08-06 17:34:00)

mentat · 2011-09-12 09:38:57

Great
Happy of this official release.
My player is a very basic mp3 tags reader (plaiter) ...
So now thx glyrc I'll use it to fecth cover & advance informations and notify them on my windows manager.

Edit: typo

Last edited by mentat (2011-09-12 09:39:47)

SahibBommelig · 2011-09-18 14:25:41

mentat wrote:

Great
Happy of this official release.
My player is a very basic mp3 tags reader (plaiter) ...
So now thx glyrc I'll use it to fecth cover & advance informations and notify them on my windows manager.

My pleasure, mentat.

Though..No other answers yet?

Well, some news:

libglyr features caching now. (Just pass --cache <some_dir> to glyrc to enable it - example below)
By the next release libglyr will be an internal plugin of gmpc - and replace all other Metadata plugins. You can try it in gmpc-git.
The gmpc-glyros-git package will therefore be outdated when gmpc 11.11 comes out.
Nicer ruby bindings are on the way.

A quick ruby-script to fetch the currently playing song from MPD and load a cover for it, that's shown via notify-send:

#!/usr/bin/ruby
# Fetches periodically the currently running song from mpd,
# Downloads the corresponding cover, and saves it in /tmp/cover.png
# Requires ruby 1.9 for creating the dir.

DB_DIR = "#{ENV['XDG_CONFIG_HOME']}/cover"
TMP_COVER_FILE = "/tmp/cover.png"

begin
  require 'rubygems'
  require 'librmpd'
  require 'thread'
rescue LoadError => e
  puts "Unable to load librmpd: #{e}"
  puts "Is it installed?"
  puts "gem install librmpd"
end

#===============#

unless Dir.exists? DB_DIR
  begin
    Dir.mkdir(DB_DIR)
  rescue SystemCallError => e
    puts "Cannot create Coverdir at #{DB_DIR}: #{e}"
    exit(-1)
  end  
end

#===============#

class SongListener
  def initialize
    @mpd = MPD.new
    @mpd.register_callback self.method('song_cb'), MPD::CURRENT_SONG_CALLBACK 
  end
#------------------
  def start
    puts "Hit enter or CTRL-D to exit.\n\n"
    @mpd.connect true
    thread = Thread.new { gets }
    thread.join
  end
#------------------
  def stop
    @mpd.disconnect 
  end
#------------------
  def song_cb(song)
    unless song.nil? then
     system %(glyrc cover --artist "#{song.artist}" --album "#{song.album}" --write /tmp/cover.png --cache #{DB_DIR})
     system %(notify-send -t 3000 "<b><font size=9>#{song.title}  </font></b><br>#{song.artist}<br>from #{song.album} <br><img src=\"#{TMP_COVER_FILE}\" width=\"150\" alt=\"cover\"/>")
    end
  end
end

#===============#

client = SongListener.new
client.start
client.stop

Note: You need a notifcation daemon that understands html markups, you also may want to change the notify-send to your liking..

Last edited by SahibBommelig (2011-09-18 15:05:31)

avx · 2012-04-27 10:29:57

Grad gefunden, danke

Little problem, though, when I request a tracklist, it's always only returning the first song. F.e.

glyrc tracklist -a "queen" -b "a night at the opera"

gives only one result, calling it with '-n 99' gives either a) a number of single files, all containing one title or b) if used with '-w file.txt', a single file, only having one entry consisting of the last title on the album.

Have I missed something or am I supposed to write a function to cat them together? (Edit, glyr-0.9.5)

Last edited by avx (2012-04-27 10:30:31)

SahibBommelig · 2012-04-27 11:44:01

avx wrote:

Have I missed something or am I supposed to write a function to cat them together? (Edit, glyr-0.9.5)

No, at the moment the interface (glyrc) is not capable of doing this itself. But I will add a --as-one option that simply concatenates all requested (text-)items.

(Alternatively you could of course use the library directly: example)

avx · 2012-04-27 13:23:32

I'll try that, thanks.

In the meantime, I found '-n 99 -w stdout >> file' to be working, too.

Do you have an idea, how to best name a download image, regarding it's extension? I.e. with '-F "jpeg;png"' (to hopefully get the best result), I don't know beforehand, what the result will be, thus I'm currently running `file` against it and rename appropriately. Since glyr already knows from curl, what the extension on the server is, that could be used by just adding the extension to the requested filename?!

SahibBommelig · 2012-04-28 14:16:37

Added --as-one option to glyrc.

avx wrote:

Do you have an idea, how to best name a download image, regarding it's extension? I.e. with '-F "jpeg;png"' (to hopefully get the best result), I don't know beforehand, what the result will be, thus I'm currently running `file` against it and rename appropriately. Since glyr already knows from curl, what the extension on the server is, that could be used by just adding the extension to the requested filename?!

Indeed the lib knows what format the image has, and glyrc saves the images with the according extension.
You might be interested in --callback, which allows you to do something like this:

# Only echos the path were the file was saved. <path> gets expanded
$ glyrc cover -a akrea -b lebenslinie -v0 --callback 'echo <path>'
./akrea_lebenslinie_cover_0.jpeg

You could subsitute 'echo' with your own script then.

If that's not what you were searching for: Please elaborate a bit, Im not sure if I understood you correctly.

Btw.: -F "jpeg;png" is not really useful, I never saw it returning a .gif, but some servers return a wrong MIME type called 'jpg' which would be left out here.

avx · 2012-04-28 20:22:08

Added --as-one option to glyrc.

Thanks.

but some servers return a wrong MIME type called 'jpg' which would be left out here.

I see, I thought this would be checked locally, when already downloaded.

As for my example, let's say I'd pass '-w somename', than since glyr/curl downloads the image, it already knows the extension of the file on the server, so glyr could just expand the variable storing '-w' by the extension. Given that I run a script over my whole collection, this could greatly decrease the overhead of calling `file` and/inside another script.

SahibBommelig · 2012-04-29 16:50:03

I think the best solution would be to introduce something like this:

glyrc (...) --write "somefile.#{format}"

So format gets expanded, and you do not need 'file' anymore. Other vars would be possible too (like #{num})

Would this be an acceptable solution for your usecase?

Last edited by SahibBommelig (2012-04-29 16:54:57)

avx · 2012-04-30 20:15:18

Yep, that'll be fine, thank you.

SahibBommelig · 2012-04-30 22:15:37

Done. One may do now something like this:

glyrc (...) --write "/tmp/:artist:_:album:_:type:.:format:"

resulting in:

/tmp/AC|DC_Highway to Hell_cover.jpeg

(AC/DC was escaped to AC|DC, not sure if there's a nicer way)

This also works for --callback, where you can access the --write argument via :path:

avx · 2012-05-09 03:05:07

Nice, works perfectly (for me) now, thanks.

Now if I'd only find the same thing for movies/tvshows, I'd be a happy camper.

SahibBommelig · 2012-08-04 22:33:20

Some update:

I've released libglyr 1.0.0, which means that the API is completely stable now. Also some broken providers were fixed, and quite a few were added.

Also, there are two very nice bindings to other languages:

my Python-Wrapper plyr.
meh's Ruby-Wrapper ruby-glyr.

Also two "new" applications that use it:

Freya (My little Fun-MPD Client, discontinued though) .
lyvi, a nice ncurses lyrics (and more!) viewer.

Last edited by SahibBommelig (2012-08-06 10:30:18)

aspidites · 2012-08-05 23:44:35

Should note that cmus-lyrics is now pyvi (Which I think was posted a few days back).

emto · 2013-12-12 02:03:36

Great work Sahib, I enjoy a lot glyrc writing my own bash script with eyeD3, gxmessage, sqlite3 and feh.

I found something really weird, don't know if it's a provider (artist photo) issue or glyrc.

The artist photo is different with the same artist name and same provider.

1.- [user@Arch]$ glyrc artistphoto --write "/tmp/" --artist="mecano"

output:
WRITE to '/tmp/mecano___artistphoto_1.jpeg'
FROM: <http://api.discogs.com/image/A-148781-1327062352.jpeg>

2.- [user@Arch]$ glyrc artistphoto --write "/tmp/" --artist="mecano" --cache /home/user/DATA/

output:
WRITE to '/tmp/mecano___artistphoto_1.jpeg'
FROM: <http://api.discogs.com/image/A-369477-1275843244.jpeg>

Database didn't exist when I executed them, it created one, like must to be the first time running with --cache

You can see the provider it's the same but with different results, the only difference it's the --cache parameter
It's not a random output, always the same.

Sorry my bad english

Thank you

emto · 2013-12-12 11:55:13

A lil more info:

runnig WireShark and glyrc with --cache parameter I see that there are two calls to the same provider. I t begin to download http://api.discogs.com/image/A-148781-1327062352.jpeg and suddenly another call is made and it begun to download the another one, leaving the first apart.

SahibBommelig · 2013-12-12 12:32:13

Hello emto,

that's in some way expected behaviour not a bug, although it's pretty weird.
The only difference between two runs: is the following:

λ glyrc artistphoto --write "/tmp/" --artist="mecano" -v 4
...
#[00/01] Checking image-types: [.] (-0 item(s) less)
...
FROM: <http://api.discogs.com/image/A-148781-1327062352.jpeg>
λ glyrc artistphoto --write "/tmp/" --artist="mecano" -v 4 --cache /tmp
...
#[00/01] Checking image-types: [..] (-0 item(s) less)
...
FROM: <http://api.discogs.com/image/A-369477-1275843244.jpeg>

libglyr will search for more items when a cache is used,
since it expects that it may have cached the item already (in which case it will deliver another item)
and since glyr is dumb it won't start re-searching currently. It will do this even if the cache is empty yet.
So, in the second run two items are checked (i.e. checking the http header, if it's a valid image, you see this in wireshark probably),
but only the first of those two is downloaded - which is the one that ends "...44.jpeg".

Before I provide any solutions, is this something that just bugged you, or do you need this behaviour for e.g. scripting purpose?

emto · 2013-12-12 12:45:24

thank you for the reply.

ok , that is. I always test with empty directory, with no metadata.db inside, so no cache is present.

I was "snooping" with wireshark and this is what I found, like you express in your comment:

Both case, with and without --cache parameter, the provider anwser is the same in:
Javascript Object Notation :application/json
Object
Member Key: "results"
Array -----------------> (this one is the same for both)

Only the glyrc with --cache parameter ask for two headers:

HEAD /image/A-369477-1275843244.jpeg HTTP/1.1\r\n
and
HEAD /image/A-148781-1327062352.jpeg HTTP/1.1\r\n

then it choose the first, ok.

I don't know why without --cache it choose the another one

Thank you for your reply and glyrc.

Greetings

emto · 2013-12-12 12:50:55

sorry, I didnt answer to your questio: Before I provide any solutions, is this something that just bugged you, or do you need this behaviour for e.g. scripting purpose?

Really, I only wanted to share this, no problem with my script.
Anywhere there a few artist with the same name and sooner or later we must to decide manually which one to download and to insert in the sqlite database, deleting the register we don't want.

Thank you

SahibBommelig · 2013-12-12 14:08:27

elmo wrote:

I don't know why without --cache it choose the another one

In the first run it only consideres the ...352.jpeg one (because it it's the first of http://api.discogs.com/database/search? … t&q=mecano).
In the second run the first two urls in this json response are considered and with the current implementation the last found one will be taken (there's no exact reason for this, one could change this...).

Well, thanks for your sharp eyes, even if this wasn't a serious problem :-)

Arch Linux

#1 2011-09-02 14:59:04

glyr - a musicmetadata searchengine utility and library written in C

#2 2011-09-12 09:38:57

Re: glyr - a musicmetadata searchengine utility and library written in C

#3 2011-09-18 14:25:41

Re: glyr - a musicmetadata searchengine utility and library written in C

#4 2012-04-27 10:29:57

Re: glyr - a musicmetadata searchengine utility and library written in C

#5 2012-04-27 11:44:01

Re: glyr - a musicmetadata searchengine utility and library written in C

#6 2012-04-27 13:23:32

Re: glyr - a musicmetadata searchengine utility and library written in C

#7 2012-04-28 14:16:37

Re: glyr - a musicmetadata searchengine utility and library written in C

#8 2012-04-28 20:22:08

Re: glyr - a musicmetadata searchengine utility and library written in C

#9 2012-04-29 16:50:03

Re: glyr - a musicmetadata searchengine utility and library written in C

#10 2012-04-30 20:15:18

Re: glyr - a musicmetadata searchengine utility and library written in C

#11 2012-04-30 22:15:37

Re: glyr - a musicmetadata searchengine utility and library written in C

#12 2012-05-09 03:05:07

Re: glyr - a musicmetadata searchengine utility and library written in C

#13 2012-08-04 22:33:20

Re: glyr - a musicmetadata searchengine utility and library written in C

#14 2012-08-05 23:44:35

Re: glyr - a musicmetadata searchengine utility and library written in C

#15 2013-12-12 02:03:36

Re: glyr - a musicmetadata searchengine utility and library written in C

#16 2013-12-12 11:55:13

Re: glyr - a musicmetadata searchengine utility and library written in C

#17 2013-12-12 12:32:13

Re: glyr - a musicmetadata searchengine utility and library written in C

#18 2013-12-12 12:45:24

Re: glyr - a musicmetadata searchengine utility and library written in C

#19 2013-12-12 12:50:55

Re: glyr - a musicmetadata searchengine utility and library written in C

#20 2013-12-12 14:08:27

Re: glyr - a musicmetadata searchengine utility and library written in C

Board footer