Messages

Make sure you have gstreamer plugin packages installed, e.g. try running this in terminal:

Code Select Expand

sudo apt-get install gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-bad gstreamer0.10-plugins-ugly

I am seeing this error from running it in terminal

Code Select Expand

vmtouch: FATAL: mlock: /media/sda5/Music/mp3new/Classic Rock/Lou Reed/Lou Reed - Take a Walk on the Wild Side.mp3 (Cannot allocate memory)

This is likely because you have a low memory lock limit set - see here for the explanation. I think the solution will be to edit /etc/security/limits.conf (as root) and set the "memlock" value to something larger (or -1 to remove the limit).

Made this for my own use, perhaps somebody else will also find it useful:

Precache plugin loads the next song (or its beginning) into VM cache in order to aid gapless playback.

Requires vmtouch.

With mpv (and possibly gstreamer, not entirely sure about that) gapless mode works by keeping the audio buffer (which is provided by the sound driver - PulseAudio, ALSA, etc) open between the time when mpv finishes playing one file and starts playing the next. If mpv can open and start reading the next file in the few milliseconds it takes for the sound driver to process the remaining contents of the buffer, you get a gapless transition. If your music library is on a disk that is slow or busy, opening the file might take too long and you get a gap between songs. Precache eliminates disk latency from the equation by ensuring that the next file is loaded into virtual memory (i.e. RAM) before it is time to open it.

I have the exact same second error on 64-bit Arch system. How did you manually rebuild the perl-glib-object-introspection on your config? Thanks.

I think simply reinstalling the perl-glib-object-introspection package from AUR should do the trick.

It just so happens that gmusicbrowser stores the equalizer settings for the Gstreamer backend in a format that is exactly the same as Mplayer's. That makes it very easy to have the Gstreamer equalizer apply to Mplayer as well. Just insert this line in gmusicbrowser_mplayer.pm, at line 77:

Code Select Expand

push @cmd_and_args, '-af','equalizer='.$::Options{gst_equalizer} if $::Options{gst_use_equalizer};

Of course, this is only a workaround and has its limitations: you can't adjust the equalizer in realtime during playback, and in fact the equalizer controls will only be adjustable when you have the Gstreamer backend selected. But after you've adjusted the settings to your liking, you can just switch to Mplayer backend, keep the "Use equalizer" checkbox ticked and the equalizer will work.

OK, I was mistaken - the volume command does not work from gmusicbrowser - I assume it is cancelled out by the gmb's own volume settings. However, the channel command does work (I also use "-af equalizer" regularly). Your screenshot looks good - try entering "-af channels=1:0:0:0" instead of "-af volume=-25" and it should take effect on the next song.

Both of these commands ("-af channels=1:0:0:0" and "-af volume=-12") work for me in gmusicbrowser. Maybe you forgot to set mplayer as your output in the Audio tab? The mplayer options would have no effect if you were still playing through gstreamer.

My music library is located on an external HDD which spins down after some idle time. If the HDD is woken up by gmusicbrowser (starting playback or scrolling around the playlist which involves loading cover art), the program becomes completely unresponsive for the several seconds it takes for the HDD to spin up again. Would it be possible to somehow put file loading in the background so that gmb would remain interactive while waiting for the disc to spin up?

HQPlayer is closed source and does not appear to have a command-line interface, which makes external management pretty much impossible, as far as I can tell - it would be up to the developers of HQPlayer to implement such feature.

What player do you have in mind? GMB supports playback through mplayer. Not sure about DRC, but it can upsample.

File > Preferences or right-click on the tray icon > Settings both work for me with the Audacious layout.

Thanks for the response, I'll be looking forward to the updates.

Speaking of mplayer improvements, another small addition would be equalizer support - mplayer has equalizer as one of its audio filters, and it quite nearly matches up with the frequency bands already presented in the equalizer GUI for gstreamer. From the manual page:

equalizer=[g1:g2:g3:...:g10]

10 octave band graphic equalizer, implemented using 10 IIR band pass filters. This means that it works regardless of what type of audio is being played back. The center frequencies for the 10 bands are:
No. frequency
0 31.25 Hz
1 62.50 Hz
2 125.00 Hz
3 250.00 Hz
4 500.00 Hz
5 1.00 kHz
6 2.00 kHz
7 4.00 kHz
8 8.00 kHz
9 16.00 kHz

If the sample rate of the sound being played is lower than the center frequency for a frequency band, then that band will be disabled. A known bug with this filter is that the characteristics for the uppermost band are not completely symmetric if the sample rate is close to the center frequency of that band. This problem can be worked around by upsampling the sound using the resample filter before it reaches this filter.

<g1>:<g2>:<g3>:...:<g10>

floating point numbers representing the gain in dB for each frequency band (-12-12)

EXAMPLE:

mplayer -af equalizer=11:11:10:5:0:-12:0:5:12:12 media.avi

Would amplify the sound in the upper and lower frequency region while canceling it almost completely around 1kHz.

With an idle slave, it would be enabled by passing (for example)

Code Select Expand

af_add equalizer=0:0:0:0:0:0:0:0:0:0 and changes to the configuration applied with

Code Select Expand

af_cmdline equalizer 11:11:10:5:0:-12:0:5:12:12 (note the lack of "=" sign there). The changes are even applied immediately during playback, which is nice.

No, this is unrelated. Try copying the input.conf file from /etc/mplayer to ~/.mplayer:

Code Select Expand

cp /etc/mplayer/input.conf ~/.mplayer/input.conf

I've recently started experimenting with mplayer audio backend for gmusicbrowser as it offers greatly reduced CPU usage compared to gstreamer (mplayer2 uses 0-2 % CPU where gstreamer got 10-20). The biggest annoyance in this switch is the loss of gapless playback. As I understand it, gmusicbrowser currently starts a new mplayer process for each song, killing and restarting it at every track transition, which is responsible for most of the gap. The reason for this was explained in an earlier thread:

This is because last time I tried with mplayer in slave mode, I couldn't get a signal (output) telling me that the track was finished. By using one process per track, the process ends when the track ends.

But I've found that mplayer does send an EOF signal at a higher verbosity setting. Launching mplayer with

Code Select Expand

mplayer -msglevel all=1:statusline=5:global=6 ("global=6" is the important part) generates "EOF code: 1" when it reaches end of file. The codes apparently mean different things, although I couldn't find any documentation on them, so simply listening for lines starting with "EOF code:" should be sufficient.

Assuming gmusicbrowser can detect that, a single mplayer process should be started with "-idle" flag, and files fed to it by issuing:

Code Select Expand

loadfile "/path/to/file.mp3"

Better yet, in order to take advantage of mplayer2's "--gapless-audio" option, gmusicbrowser should also inform it of the next item in the playlist (probably when the current one starts playing) by also sending

Code Select Expand

loadfile "/path/to/next_file.mp3" 1 where "1" is the "append" option as explained here.

Granted, even the --gapless-audio option is still experimental and imperfect (there's a short clicking noise at track transition on my system), but in any case this should be a vast improvement over the current kill-restart cycle. So the question is: did you just overlook the EOF code output, or is there something else preventing such implementation?