GNOME Bugzilla – Bug 463978
Lyrics reading embedded tags
Last modified: 2018-05-24 12:45:05 UTC
I'm using Debian Lenny. I have huge library with coverart and lyrics embedded into files (mp3 in my case), but hadn't noticed RB's ability to read both (only fetch them from internet using plugins, which hadn't had any options, configure button was dimmed). 1st is already requested as option for cover plugin (#345975), and this one will request second. Sorry, i'm not sure if lyrics getting is supported by underlaying libs and hadn't found similiar request, so i post this one.
Adding self to CC list. I would be particularly interested for mp3 files with "lyrics" with mixed character sets (e.g. language course podcasts with a transcript in both languages stored in the lyrics).
*** Bug 769180 has been marked as a duplicate of this bug. ***
One would have to use `db.entry_request_extra_metadata` to fetch the lyrics in the plugin (LyricGrabber), and create a new metadata signal handler that reads the lyrics from the file itself.
Created attachment 355042 [details] [review] display lyrics embedded in ogg/vorbis files The patch supports reading embedded lyrics from ogg/vorbis files using the LYRICS tag. MP3 support is missing because gst discoverer does not return those data.
Created attachment 355046 [details] [review] display lyrics embedded in ogg/vorbis files #2
Review of attachment 355046 [details] [review]: are you working on making gstreamer support the mp3 lyrics tags too? ::: plugins/lyrics/lyrics.py @@ +155,3 @@ + print("discovering %s" % location) + self.discoverer = GstPbutils.Discoverer(timeout=Gst.SECOND*1) + info = self.discoverer.discover_uri(location) This needs to call the discoverer asynchronously. Doing metadata extraction synchronously on the main thread will block everything else in the UI for as long as it takes, which could be seconds for files accessed via the network. @@ +174,3 @@ self.callback = callback + + text = self.lyric_from_tag() I don't think this is happening at the right point in the search process. It should happen after the lyrics cache is checked, and should respect the cache_only flag.
> are you working on making gstreamer support the mp3 lyrics tags too? No, my C is too rusty. > It should happen after the lyrics cache is checked For local files, using the cache only fills the harddisk with duplicate data. > and should respect the cache_only flag. I thought that cache_only is to disable network access to third-party sites. Extracting data from the file itself does not fall under that category.
(In reply to Christian Weiske from comment #7) > > are you working on making gstreamer support the mp3 lyrics tags too? > > No, my C is too rusty. > > > > It should happen after the lyrics cache is checked > > For local files, using the cache only fills the harddisk with duplicate data. We do the same for album art. It's an insignificant amount of space compared to the audio files the information is extracted from. I don't see a reason that this source of lyrics should behave any differently to the rest of them. > > and should respect the cache_only flag. > > I thought that cache_only is to disable network access to third-party sites. > Extracting data from the file itself does not fall under that category. I think the intention was to avoid potentially slow actions for some lookups, and I would consider metadata extraction to be potentially slow. It's not actually used for anything, but if we're going to keep it there we might as well make it work properly.
Created attachment 355205 [details] [review] Fetch lyrics from tags, async Patch updated. Tags are fetched async now.
Review of attachment 355205 [details] [review]: pushed as commit 1416e4c.
I don't think we can really consider this complete until it works with id3 tags, so I'm leaving the bug open.
Thanks for merging my patch.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/414.