[emms-help] [PATCH] Add browsing by record label

The browser can now group artists by record label. --- lisp/emms-browser.el | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/lisp/emms-browser.el b/lisp/emms-browser.el index 8a86bd2..99e8120 100644 --- a/lisp/emms-browser.el +++ b/lisp/emms-browser.el @@

[emms-help] [PATCH] Improve browsing by artist and year

New function emms-browser-get-track-field-extended uses albumartist, originalyear and originaldate tags for grouping tracks in the browser. It can be assigned to emms-browser-get-track-field-function. --- lisp/emms-browser.el | 56 +--- 1 file

Re: [emms-help] [PATCH] New metadata extraction program

On 19/10/15 16:30, Rasmus wrote: --- a/AUTHORS +++ b/AUTHORS @@ -27,6 +27,7 @@ Ye Wenbin <wenbi...@gmail.com> Yoni (Johnathan) Rabkin <y...@gnu.org> mathias.dahl Rasmus Pank Roulund <em...@pank.eu> +Petteri Hintsanen<pette...

Re: [emms-help] 4.2 release tasks: emms-print-metadata install

On 25.10.2016 16:52, Rasmus wrote: Yoni Rabkin writes: OK, so there is a good reason to move to C++ with this, which would otherwise seem like overkill to me. Since we would want to test it a bit before packing it up into a release it can hopefully go out with the release

[emms-help] [PATCH] mpv player

/null +++ b/lisp/emms-player-mpv.el @@ -0,0 +1,120 @@ +;;; emms-player-mpv.el --- mpv support for EMMS + +;; Copyright (C) 2017 Free Software Foundation, Inc. + +;; Authors: Petteri Hintsanen <pette...@iki.fi> + +;; This file is part of EMMS. + +;; EMMS is free software; you can redist

Re: [emms-help] [PATCH] mpv player

On 16.09.2017 18:37, Yoni Rabkin wrote: Which version of mpv is currently being widely distributed? I know that previous versions (for instance the version I have) don't yet support the --input-ipc-server command. This also means that at the moment I can't test this patch. Unfortunately I have

Re: [emms-help] [PATCH] mpv player

Hello, Regarding old mpv versions: Ubuntu 14.04 has a fairly old version 0.3.4. It does not support --ipc-unix-socket, but it does have --input-file, which can be FIFO as well. I think that would be the best approach to control mpv from EMMS: besides being simple file I/O, it would probably work

Re: [emms-help] [PATCH] mpv player

Yoni Rabkin writes: > Since it's possible to install Guix with a newer version of mpv even on > older distros, I would recommend not supporting older versions unless > you have time to spare. Well the actual change is trivial, so if there is an easy way to use FIFO, I'd like

Re: [emms-help] [PATCH] mpv player

Hello all, Regarding the mpv patch, I don't think it makes sense to pursue it any further. Namely, there is already a quite solid implementation available at https://github.com/momomo5717/emms-player-simple-mpv It is also available from MELPA via package.el. I've been using it for some time

Re: [emms-help] [PATCH] mpv player

Yoni Rabkin writes: > mpv integration is currently happening, albeit not on this list (as per > the developers request). > > We'll see it in the git repo Real Soon Now (TM). Very good, thanks for your efforts. Petteri ___ Emms-help

Re: [emms-help] info-year and info-date

Pierre Neidhardt writes: > Do we actually need both fields? Looks like only info-date would be useful. I think we do, because there are probably massive amounts of old MP3s lying around which have only ancient ID3v1 tags with 4-digit YEAR tags. WMAs maybe as well. Some

Re: [emms-help] Multiple sound cards / volume change

Bob Newell writes: > When I got an Asus laptop I ran into trouble with volume changes from > the keyboard. To make a long story short it seems emms-volume-amixer.el > assumes the card for Master volume is 0. But it turned out to be 1 on > this laptop. At least, the

Re: [emms-help] Ditch-fork

Yoni Rabkin writes: > Nice, a bug that's actually a feature. I'll make sure that the > wikipedia portion works. Wikipedia seems to work okay. > I wonder if it would be better to launch an external browser or use > eww? emms-browser-lookup uses browse-url; I don't see any

Re: [emms-help] Ditch-fork

Yoni Rabkin writes: > I'm leaving this up for discussion for the next week, and if there > isn't a really good reason raised I'm removing > `emms-browser-lookup-pitchfork'. Pitchfork lookup does not currently work at all, so functionality-wise this decision wouldn't make

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt writes: > mediainfo returns "Drive" as Album/Performer, which is correct. This is > missing from emms-print-metadata. Then there is something different within tags, I guess. What does ogginfo show? Petteri ___

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt writes: > That does not work for me. > > (emms-track-get track 'info-albumartistsort) > > is always nil. So it only ever uses 'info-artist. Something I > missed? Perhaps you don't have that symbol in your track database (emms-cache-db;

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt writes: > I use an up-to-date Gentoo with emms 4.1, taglib 1.11.1. You should get emms 4.2 or newer. Version 4.1 uses the old emms-print-metadata, which is implemented using TagLib's C interface. New emms-print-metadata is written in C++ and has more

Re: [emms-help] Album artist grouping in emms-browser

On 17.05.2018 19:27, Pierre Neidhardt wrote: A correct implementation would collate by 'info-albumartistsort (or 'info-artistsort) and display 'info-albumartist. I'm not sure to understand what you mean with this. Can you give a concrete example? It means that artists are collated (sorted)

Re: [emms-help] Album artist grouping in emms-browser

On 24.10.2017 01:48, Pierre Neidhardt wrote: I haven't looked into this properly, sorry about that, so I'll just drop a quick question: is it possible to group by album-artist in the browser view? I use this (defun ph-emms-browser-get-track-field (track type) "Return TYPE from TRACK. This

Re: [emms-help] Album artist grouping in emms-browser

Petteri Hintsanen <pette...@iki.fi> writes: > I usually do something like (setq emms-cache (make-hash-table)) to > clear the cache. Sorry, the correct var is emms-cache-db Petteri ___ Emms-help mailing list Emms-help@gnu.org https://l

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt writes: > I noticed that setting emms-browser-get-track-field-function as > suggested in this thread will fail to work on tracks that were already > cached. Your cache probably contains records from the older version of emms-print-metadata. These records do

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt writes: >> Caching in general is not particularly smart at the moment. Also the >> metadata extraction could be orders of magnitude faster by batching; now >> there is one exec per track. > > Any specific example where this slowdown shows? Nothing

Re: [emms-help] tag editor and mp3

Yoni Rabkin writes: > Pierre Neidhardt writes: > >> What about joining forces with taglib, create a fullfledged `taglib-tool` >> and merge emms-print-metadata in it? > > That sounds excellent, but it isn't something that I can do at the > moment. > > Are

Re: [emms-help] tag editor and mp3

Pierre Neidhardt writes: > I've asked upstream what they think. If it's a no-go, then we do as you > said, an Emms-specific tool. Otherwise we bring together the effort of > a much bigger community ;) OK, sounds good. Petteri

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt <ambre...@gmail.com> writes: > Petteri Hintsanen <pette...@iki.fi> writes: > >> Caching in general is not particularly smart at the moment. Also the >> metadata extraction could be orders of magnitude faster by batching; now >> there is one e

Re: [emms-help] Album artist grouping in emms-browser

Pierre Neidhardt writes: > Changing this design would imply a lot of refactoring... For little > benefit I believe. I believe your analysis is correct. It would be stupid to break an otherwise simple design (which is intrinsically good) and working implementation. Thanks,

Re: [emms-help] tag editor and mp3

On 19.03.2018 12:09, Yoni Rabkin wrote: As above, I wouldn't go for more than an interface to a robust solution that people can install. I would go for this as well. I don't think that EMMS should aim to be "the" tagging facility that most people would use for tagging stuff. There are

Re: looking forward to Emms 6.0

Yoni Rabkin writes: > * Find a suitable replacement for emms-print-metadata as a way to access > taglib. A current candidate is installing pytaglib. I have been playing with a bit orthogonal solution to this, namely writing a native elisp implementation to extract tags from Ogg Vorbis files

emms-info-native

Dear list, I just pushed a new branch ‘info-native’ into emms repo. It implements a new info method ‘emms-info-native’ for Vorbis, Opus and FLAC files. This method is "native" in the sense that it implemented in plain Emacs Lisp and hence does not require any external programs or libraries. The

Re: emms-info-native

Yoni Rabkin writes: > Since the diff between the main and info-native branches is only > emms-info-native (and version numbers), can you please merge the work > you have done so far in info-native into the main branch? Sure, but should we update the manual first? I can do that. > We can keep

Re: tag editing

Grant Shoshin Shangreaux writes: > Another option might be to hook into the emms-info-native code and add > tag writing capabilities as well. I wouldn’t recommend going this way, at least not yet. Some rationale: 1. There are already plenty of solid free implementations for writing

Re: emms-info-native

Yoni Rabkin writes: > I'm always glad when someone gives the manual some attention (few > developers want to write documentation). But I wouldn't worry about > updating the manual until there is an ELPA release with that code. Ok, fair enough. I will update the manual later then.

Re: [PATCH] Add: tracktag interface and support for Opus

Grant Shoshin Shangreaux writes: > Another oddity I see is that EMMS info has info-year in most places, but > info-date appears in a few other. is there an actual distinction for > some metadata? Yes, there are actually four different info-symbols related to release dates: 1. info-year: this

Re: [PATCH] Add: tracktag interface and support for Opus

Grant Shoshin Shangreaux writes: > By the way, I used some real metadata from tracks I have, but afaik that > is not copyrighted data. If we'd prefer to keep it out of the code base, > I can replace it. If I add any audio files in for testing, I will ensure > they are properly free. As far as I

Re: Set default expand level?

Keno Goertz writes: > I have tried using emms-browser-mode-hook, but > > #+BEGIN_SRC emacs-lisp > (add-hook 'emms-browser-mode-hook 'emms-browser-expand-to-level-2) > #+END_SRC > > just makes Emacs freeze up when calling emms-smart-browse. It looks like emms-browser-find-top-level function

Re: New emms-info-native

Yoni Rabkin writes: > I got this error on the very first file I tried: > (error "id3v2 tag/header/frame size [0 68 75 12] is invalid") > > exiftool reports that the id3 size is a wopping: > ID3 Size: 1123734 That’s correct, you can find that out also by evaling

Re: New emms-info-native

Petteri Hintsanen writes: > It gives 1123724; that does include the tag header which is always 10 > bytes. Should have been "that does *not* include the tag header...", sorry. Petteri

Re: New emms-info-native

On Wed, Feb 10, 2021 at 08:02:49PM -0500, Yoni Rabkin wrote: > I will admit ignorance to what an "id3v2 unsynchronisation scheme" is. "Unsychronization scheme" is a compatibility feature for older software that does not understand id3 tags and looks for MP3 synchronization frames (certain

Re: Default info methods

g it eg. after emms-cache-sync. -- Petteri >From 3aaf60567ebefc5aee111e72ee869b16a4c0a713 Mon Sep 17 00:00:00 2001 From: Petteri Hintsanen Date: Thu, 11 Mar 2021 20:53:11 +0200 Subject: [PATCH] Make it possible to force-update Emms cache Add a prefix argument to emms-cache-sync that will unco

Re: tag editing

Grant Shoshin Shangreaux writes: > i also still need to do the verification of tag updates after it > happens. i'm working on writing up some ert tests to make it a bit > easier to ensure, my plan was to generate some test audio files for the > tag editor to operate on. i'm not sure if its

Re: info-native merged to master

"Fran Burstall (Gmail)" writes: >> same info. Can you please send a sample of some offending file so I can >> investigate? > Here! Thanks. The file has a TSO2 frame with the "wrong" value, as expected, but it also has a user-defined text frame TXXX with ALBUMARTISTSORT key and "Various

Re: info-native merged to master

"Fran Burstall (Gmail)" writes: >> We could do the same by decoding TXXXs in emms-info-native. It could be >> a defcustom in case some users prefer strictly "standard" tags. > That is probably the way to go though my reading of the spec is that TSO2 > is not strictly standard either! That's

Re: info-native merged to master

"Fran Burstall (Gmail)" writes: > I get a lot of mismatches emms-info-native vs emms-info-taglib around two > tags: > > 1. albumartistsort: > > 2. genre: emms-native-info yields things like "(16)" while > emms-print-meta-data gives things like "Reggae". > > I think all this happened at commit

Default info methods

Hi all, While working on Chapter 13 "Track Information" of Emms manual, I realized that Emms actually populates emms-info-functions on startup via emms-all. I think this is the right thing to do, as it provides functional metadata support out of the box. But the way emms-all does this could be

Re: Default info methods

I pushed the manual draft into info-native branch. Please let me know if you find it difficult to follow, or other flaws, typos, etc. Thanks, Petteri

Re: Default info methods

Yoni Rabkin writes: > "Fran Burstall (Gmail)" writes: > >> The manual should also explain how to recompute info when a new info method >> is introduced (thus 'emms-cache-rest' followed by >> 'emms-add-directory-tree'). This came up recently on Emacs StackExchange... > > That is a good idea.

Re: info-native merged to master

"Fran Burstall (Gmail)" writes: >> I think taglib is going wrong here. > > Maybe so, but in all the cases in my tests, it gives the "right" answer. > In the example I gave , it was part of a compilation with albumartist > "Various Artists" and I would expect albumartistsort to at least >

Re: New emms-info-native

"Fran Burstall (Gmail)" writes: > Yes: both emms-print-metadata and exiftool work fine. Here is what > exiftool says: [...] > Band: The Weeknd [...] > Album : House of Balloons > Track : 3/9 At least these should

info-native merged to master

Hello all, emms-info-native seems to work well enough so I merged it into the master branch. Thanks to everyone who helped in testing and debugging. Of course, if you still run into bugs, please report them. I'll update the manual soon-ish. Petteri

Re: info-native merged to master

"Fran Burstall (Gmail)" writes: > I get a lot of mismatches emms-info-native vs emms-info-taglib around two > tags: [...] > It is interesting that exiftool gives the same answer as emms-info-native > here so maybe this is a controversial tag? "Album artist sort" is taken from "TSO2" frame,

Re: New emms-info-native

Yoni Rabkin writes: > However, the same file now shows: > (error "id3v2 unsynchronisation scheme is not supported") I just pushed a new version to emms.git/info-native. Please try if it gives any better results. Thanks, Petteri

Re: New emms-info-native

Yoni Rabkin writes: > Can you please merge this so that people living with the main branch of > the git repo can give it a go? Merged and pushed. Thanks, Petteri

Re: New emms-info-native

Hi, Thanks, this is very useful information. > 1. emms-info-taglib trims trailing white space in strings but > emms-info-native does not. Is this problematic? It is easy to add trimming if needed. Maybe even a defcustom. > 2. emms-info-native puts dates in the year or original-year field

Re: New emms-info-native

I just pushed a new revision without emms-info-native--max-peek-size checks. It still does a couple of other checks, but you shouldn’t see excessive size errors anymore. > My personal take is that trimming the whitespace is a good idea, if only > because other info sources do it. I added

Re: New emms-info-native

(apologies it you get this message twice, my mailer is complaining for some reason) Yoni Rabkin writes: > Petteri, what do you think of the dynamic-scaling idea? It could help but I think it’s not the best way to go forward. I am afraid it is the design itself that is failing here. Namely,

Re: New emms-info-native

Yoni Rabkin writes: > When I try it on a wider selection of tracks I get a framing mismatch > early on. Attached are the first 10k of that file. The attached file does not seem to have id3v2 tag at all. Maybe it has an id3v1 tag? That would be located at the end of the file. Petteri

Re: emms-info-native

Grant Shoshin Shangreaux writes: > i cant tell if this is user error or something with the info-native > function, but i just noticed that the tracks i already had loaded in the > cache db are now "doubled". if i enter one from the smart browser, it > ends up putting two entries in the playlist.

Re: tag editing

Grant Shoshin Shangreaux writes: >>> 1. add a shim for TagLib to write to files (beyond me at the moment) >> >> this one is probably easy to do. The current Taglib shim >> (emms-print-metadata) can be extended to support tag updates as well. >> I can help with that if needed. > > That would be

Re: New emms-info-native

Hi all, I just pushed a new version into the branch with improved error handling. Now emms-info-native--decode-id3v2 returns nil in case of serious problems (missing or garbled input) *or* if there was no usable metadata in otherwise valid input file. Even though distinction between valid

Re: New emms-info-native

"Fran Burstall (Gmail)" writes: > I tried last night's test on the new info-native branch version and got > zero errors in 14051 files in 371 secs. This is twice as fast as last > night but nowhere near the 250 tracks a second that Yoni is seeing! If you have lots of Ogg or FLAC files in your

Re: bug: infinite loop if albumartist is empty string

Grant Shoshin Shangreaux writes: > sometimes i'd get a type error, but then emacs would go into a state > were my cpu was pegging at 100% and fans turned on high. i could C-g to > break out of it. here's the stack trace when quitting: > > Debugger entered--Lisp error: (quit) >

Re: emms-info-native

Grant Shoshin Shangreaux via writes: > fwiw i just tried importing my Music directory with emms-info-native as > my only info function. it reported ~4200 tracks to go and it took > several minutes to finish. unfortnately i didn't time it. i'll include [...] > but, so far so good, the flac, ogg,

Re: New emms-info-native

"Fran Burstall (Gmail)" writes: > 1. Just one file returns nil: it has a gigantic (4.8MB) id3v2.3 tag which I > can send if you want. Probably I should just accept defeat on this > one! Does emms-print-metadata, exiftool, id3info, tinytag, eyeD3, or some other tool give sensible values for it?

Re: New emms-info-native

Yoni Rabkin writes: > (Without actually checking) my guess is that it is the fact that: > >(cdr '("composer")) => nil > > ...and so `string-trim-right' errors on getting nil as an input. > > So perhaps the call to `string-trim-right' can look like: > > (string-trim-right (or (cdr field)

Re: emms-info-native and track duration

Petteri Hintsanen writes: > Right, completely forgot this requirement. I will revert the commit. > > We can easily replace any infringing files with our own, synthetic test > files. I pushed a new set of commit into the branch. There should be no infringing files anymore. I al

Re: Emms and old Emacsen

Yoni Rabkin writes: > My understanding of shorthands was that they were added as a way for > emacs to incorporate some strangely named libraries (s.el), and not as a > way to name libraries strangely. Shorthands is a way of renaming poorly > named libraries in order to make them behave in the

Re: emms-info-native and track duration

Yoni Rabkin writes: > I haven't tested the code yet, but I intend to. Thanks, please let me know if you have any issues or remarks. > As far as naming goes we'll need to make a decision. Currently the > format is emms-info-TOOLNAME, and not emms-info-FORMAT. Therefore, files > such as

Re: emms-info-native and track duration

Yoni Rabkin writes: > Haven't tested yet because I get a: > > emms-info-native-vorbis.el:85:36: Error: Wrong number of > arguments: (3 . 3), 4 > make: *** [Makefile:71: emms-info-native-vorbis.elc] Error 1 > > ...when I try to compile the code on Emacs 28.2. Thanks, this was something I

Re: emms-info-native and track duration

Yoni Rabkin writes: > Please go ahead and merge into main. All else being equal, I'll wait for > one month and release 17. Fair enough, merged and pushed. Thanks, Petteri

Re: emms-info-native and track duration

Yoni Rabkin writes: > Since it all seems to work well enough, perhaps it is time to merge it > into the main branch? > > If you do, I'll postpone Emms 17 for a month or so to allow some more > testing and then release it as part of 17. I just pushed the "last" set of commits to the branch, so

Re: emms-info-native and track duration

Yoni Rabkin writes: > Works for me on both 29.1 and 28.2. > > I only got one error on one machine, and with one MP3 track. But on > closer inspection of that track it really doesn't start with "ID3". Thanks for testing. Did you get sensible playing times? That's the main new feature, after

Re: emms-info-native and track duration

Yoni Rabkin writes: > After feeding the new code all of the track I could muster, the only > outliers are in a single album of ogg files which all return a 0 playing > time on all versions of info-native, new and old. Nothing immediately > stands out to me about the files in this album in terms

Re: emms-info-native and track duration

Yoni Rabkin writes: > Perhaps it would be good to update the other pieces of metadata when the > comment is too long so that the user still gets the benefit of playing > time, title and etc. This is doable. Now the code is short-circuiting in the sense that whenever there is an error

Re: emms-info-native and track duration

Hello, I pushed a few more commits into info-native branch. This time, the primary change is the use of new bindat-type macro, which was introduced in Emacs version 28.1. There is also compatibility code for older Emacsen, so Emacs 28 or later is not required. The branch has been tested with

Re: emms-info-native and track duration

Yoni Rabkin writes: > Petteri Hintsanen writes: > >> On Mon, Dec 05, 2022 at 01:14:07PM -0500, Yoni Rabkin wrote: >> >>> Do you have any input or insight regarding implementation of track >>> duration for emms-info-native? >> >> Do you mean pop

[PATCH] emms-seek and emms-seek-to

either. What do you think, does this make sense? thanks, Petteri >From cf1222e8c106272109a681fd51dea45f5e3a1fca Mon Sep 17 00:00:00 2001 From: Petteri Hintsanen Date: Fri, 2 Sep 2022 16:48:59 +0300 Subject: [PATCH] dev --- emms.el | 53 + 1 file changed, 41 insertion

Re: [PATCH] emms-seek and emms-seek-to

Yoni Rabkin writes: > Yes, I think that this is a good idea. I've applied it to the git repo > so that others can try it out and provide feedback ahead of the next > release. I just pushed a couple of commits into master. They fix docstrings and the manual. Please review and adjust as you see

Re: emms-seek-* function does not match docstring or manual

"Fran Burstall (Gmail)" writes: > Wrong type argument: stringp, 20.0 > > The reason is that TIMESTAMP is fed to emms-timespec-to-secs which expects > a string. Correct, this is a bug. I will try to fix it soon. Thanks, Petteri

Re: emms-seek-* function does not match docstring or manual

Petteri Hintsanen writes: > "Fran Burstall (Gmail)" writes: > >> Wrong type argument: stringp, 20.0 >> >> The reason is that TIMESTAMP is fed to emms-timespec-to-secs which expects >> a string. > > Correct, this is a bug. I will try to fix it

Re: emms-info-native not setting info-playing-time

"Fran Burstall (Gmail)" writes: > I am sure that this was working when we were testing emms-info-native but > it ain't now Do you remember for what exactly did it work? I dared to venture into Emms git history, and I'd say the only possibility for emms-info-native to return playing time was

Re: Any appetite for patches for EMMS support for SNES SPC files?

On 27.7.2023 18.30, Yoni Rabkin wrote: As for the rest, can you please split it out to a separate file such as "emms-info-native-spc" or "emms-info-native-id666" or similar? That will scale better as we add more native info methods. To simplify things, I am planning to split emms-info-native

Re: Tag-Editor cuts album title / deletes other tags

Titus Müller writes: > It feels strange to send you these minor problems while being very > happy with EMMS. Quite the contrary. These are serious problems (data loss) and ought to be fixed as soon as possible. Thank you for reporting them. In the meantime, I hope you do have backups of your

Re: emms-info-functions tested, and more data to the tag editor topic

Titus Müller writes: > Now, what I found out, is: Setting emms-info-functions just to > '(emms-info-native) works fine, also '(emms-info-mp3info > emms-info-native) works. But if I change the order of the two and use > '(emms-info-native emms-info-mp3info), it produces the problematic > data:

Re: Contributing?

Erica writes: > Some Metadata is still missing. I do at least have album artist data > working. Not with Metaflac or native info though. Metaflac cli shows a nice > data record. But not within emms. emms-info-metaflac does not extract album artist. The info methods are not feature-par with

Re: Contributing?

Petteri Hintsanen writes: > It is a copy-paste error, thanks for spotting this. I'll push a fix > soon. Except that Yoni had fixed it already, thanks! Petteri

Re: MusicBrainz integration (and by extension other music search APIs)

Yoni Rabkin writes: > What are your thoughts on this? I don't have anything concrete to suggest to Emacs interface at this time. But it may be good to check MusicBrainz Picard if you haven't done that already. Namely, you don't necessarily need to implement a database browsing mechanism at