Stable: 2.5.2
Development: 2.6-alpha3
MOC (music on console) is a console audio player for LINUX/UNIX designed to be powerful and easy to use.
You just need to select a file from some directory using the menu similar to Midnight Commander, and MOC will start playing all files in this directory beginning from the chosen file. There is no need to create playlists as in other players.
If you want to combine some files from one or more directories in one playlist, you can do this. The playlist will be remembered between runs or you can save it as an m3u file to load it whenever you want.
Need the console where MOC is running for more important things? Need to close the X terminal emulator? You don't have to stop playing - just press q and the interface will be detached leaving the server running. You can attach it later, or you can attach one interface in the console, and another in the X terminal emulator, no need to switch just to play another file.
MOC plays smoothly, regardless of system or I/O load because it uses the output buffer in a separate thread. The transition between files is gapless, because the next file to be played is precached while the current file is playing.
Supported file formats are: MP3, Ogg Vorbis, FLAC, Musepack (mpc), Speex, Opus, WAVE, those supported by FFmpeg/LibAV (e.g., WMA, RealAudio, AAC, MP4), AIFF, AU, SVX, Sphere Nist WAV, IRCAM SF, Creative VOC, SID, wavpack, MIDI and modplug.
Other features:
This file is only a brief description of MOC, for more information is available on the home page (http://moc.daper.net/documentation).
You can also find a discussion forum on the MOC home page.
To build MOC from the distribution tarball you will need:
If you are building from the SVN repository you will also need:
You should choose which of the following audio formats you wish to play and provide the libraries needed to support them:
For interfacing to the sound sub-system, you will need libraries for one or more of the following:
For network streams:
For resampling (playing files with sample rate not supported by your hardware):
For librcc (fixes encoding in broken mp3 tags):
Note that for Debian-based distributions, you will also require any '-dev' suffixed versions of the packages above if building from source.
The versions given above are minimum versions and later versions should also work. However, MOC may not yet have caught up with the very latest changes to library interfaces and these may cause problems if they break backwards compatibility.
MOC is developed and tested on GNU/Linux. Sometimes test runs are made on other operating systems, and it is known to compile and probably work on:
There is no intention to support MOC on MS-Windows (so please don't ask).
Generic installation instruction is included in the INSTALL file.
In short, if you are building from an SVN checkout of MOC (but not if you
are building from a downloaded tarball) then you will first need to run:
autoreconf -if
and then proceed as shown below for a tarball. (If you are using the
tarball but have applied additional patches then you may also need to run
autoreconf.)
To build MOC from a downloaded tarball just type:
./configure
make
And as root:
make install
Under FreeBSD and NetBSD (and possibly other systems) it is necessary to run the configure script this way:
./configure LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include
Note that MOC and some of its supporting packages make use of GNU extensions to the C89 and C99 language standards. Therefore, do not set the '-std' option in CFLAGS to a non-GNU value; if you do, configure will fail unexpectedly.
In addition to the standard configure options documented in the INSTALL file, there are some MOC-specific options:
--enable-cache=[yes|no]
Specifying 'no' will disable the tags cache support. If your
intent is to remove the Berkeley DB dependancy (rather than
simply removing the on-disk cache) then you should also either
build MOC without RCC support or use a librcc built with BDB
disabled.
--enable-debug=[yes|no|gdb]
Using 'gdb' will cause MOC to be built with options tailored to
use with GDB. (Note that after release 2.5 this option will be
split into separate debugging and logging options.)
--with-oss=[yes|no|DIR]
Where DIR is the location of the OSS include directory (and
defaults to '/usr/lib/oss').
--with-vorbis=[yes|no|tremor]
Using 'tremor' will cause MOC to build against the integer-only
implementation of the Vorbis library (libvorbisidec).
You can install MOC into its own source directory tree and run it from there so you do not have to install it permanently on your system. If you're just wanting to try it out or test some patches, then this is something you may wish to do:
./configure --prefix="$PWD" --without-timidity
make
make install
bin/mocp -M .moc
Run program with the 'mocp' command. The usage is simple; if you need help, press 'h' and/or read mocp manpage. There is no complicated command line or cryptic commands. Using MOC is as easy as using basic functions of Midnight Commander.
You can use a configuration file placed in ~/.moc/config, but it's not required. See config.example provided with MOC.
Yes, there are themes, because people wanted them. :)
Themes can change all colors and only colors. An example theme file with a exhaustive description is included (themes/example_theme) and is the default MOC appearance.
Theme files should be placed in ~/.moc/themes/ or $(datadir)/moc/themes/ (e.g., /usr/local/share/moc/themes) directory, and can be selected with the Theme configuration options or the -T command line option (see the manpage and the example configuration file).
Feel free to share the themes you have created.
You can redefine standard keys. See the instructions in the keymap.example file.
Not every release is extensively tested on every system, so the particular configuration of software, libraries, versions and hardware on your system might expose a problem.
If you find any problems then you should search the MOC Forum for a solution; your problem may not be unique. If you do find an existing topic which matches your problem but does not offer a solution, or the solution offered does not work for you and the topic appears still active, then please add your experience to it; it may be that additional information you can provide will
contain the clue needed to resolve the problem.
If you don't find an answer there and you installed MOC from your Linux distribution's repository then you should report it via your distribution's usual reporting channels in the first instance. If the problem is ultimately identified as actually being in MOC itself, it should then be reported to the MOC Maintainer (preferably by the distribution's MOC package maintainer).
If you built MOC from source yourself or you get no resolution from your distribution then start a new topic on the MOC Forum for your problem or contact the MOC Maintainer.
Before reporting a problem, you should first read this Forum post:
Linkname: How to Report Bugs Effectively
URL: http://moc.daper.net/node/1035
and the essay it references:
Linkname: How to Report Bugs Effectively
URL: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
There are two things you must do if at all possible:
If you do not do those two things (and don't offer a good explanation as to why you didn't) your problem report is likely to be ignored until such time as you do.
Want to modify MOC? You're welcome to do so, and patch contributions are also welcome.
MOC is written in C, so you must at least know this language to make simple changes. It is multi-threaded program, but there are places where you don't need to worry about that (the interface is only a single thread process). It uses autoconf, automake and libtool chain to generate configuration/compilation stuff, so you must know how to use it, for example, if you need to link to an
additional library.
The documentation for some parts of the internal API for creating decoder plugins (file format support) and sound output drivers can be generated using Doxygen (http://www.doxygen.org/). Just run the doxygen command from the MOC source directory.
Before you change anything it is a good idea to check for the latest development version (check out from the Subversion repository is the best). Your changes might conflict with changes already made to the source or your feature might be
already implemented. See also the TODO file as it is updated regularly and contains quite detailed information on future plans.
If you need help, just contact MOC's Maintainer via e-mail. And if you are planning anything non-trivial it's a good idea to discuss your intentions with the MOC Maintainer once you've clarified your ideas but before spending too much time implementing them; it will be more productive if your work fits with MOC's future direction.
* Original author is Damian Pietras
* Current maintainer is John Fitzgerald
* For comments and questions see the official forum:
http://moc.daper.net/forum
* Need to report a bug? You can reach the maintainer(s) at:
mocmaint@daper.net