search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
26.73k stars 2.84k forks source link

Support game-music-emu #91

Closed Nikoli closed 10 years ago

Nikoli commented 11 years ago

vlc and mpd use game-music-emu for playing various format, it would be nice to support them in mpv.

https://code.google.com/p/game-music-emu/

elevengu commented 11 years ago

I don't know if this is going to be considered or how difficult it would be to do, but I fully support this idea (same with fluidsynth). I think the philosophy of mpv is to get rid of the broken stuff people don't use anymore but to support stuff like this that would actually get a lot of use.

When it comes to other game music formats, aosdk (http://rbelmont.mameworld.info/?page_id=221) would be nice, but licensing issues would surely prevent that. (EDIT: And obviously, M1 would never happen.) For Amiga games and other demoscene modules (mod, s3m, xm, it, etc.), vlc and mpd use modplug (http://modplug-xmms.sourceforge.net/). So gme and libmodplug would seem to make sense.

ghost commented 11 years ago

Note that ffmpeg already supports libmodplug. You have to enable it explicitly at ffmpeg compilation, like most external ffmpeg dependencies.

qyot27 commented 11 years ago

I've never been able to get FFmpeg to see libmodplug, despite explicitly giving it the paths to the headers and lib. Keeps complaining that it can't find its own function. I even tried shifting the detection for it over to pkg-config, and it still couldn't find it.

The only reason I'm mentioning this here is because libmodplug is actually the last* remaining piece in the [extremely thorough] cross-compiling guide I've been working on that covers virtually every external dependency that FFmpeg and mpv call in.

*technically not true, but close enough (I have to try enabling openal with mpv again, nor did I do anything with the FireWire support libraries or non-free bits, although the non-free stuff will probably be a future addendum) it's also not a guarantee that everything works (cddb, for instance), but the point was to get the stuff built and linked in.

ghost commented 11 years ago

libmodplug is also said to be unmaintained etc.

elevengu commented 11 years ago

Note that ffmpeg already supports libmodplug.

Blech, I already knew that but forgot! In fact, I've already used it before with ffmpeg, with not particularly great results if I remember correctly. Probably why I forgot. I just do everything in OpenMPT anyway.

I've never been able to get FFmpeg to see libmodplug, despite explicitly giving it the paths to the headers and lib.

sherpya (http://oss.netfarm.it/mplayer-win32.php) has ffmpeg and mplayer Windows builds with libmodplug, so maybe you could ask him how he did it.

Your guide sounds awesome, good luck!

libmodplug is also said to be unmaintained etc.

All those formats are quite mature, so it's maybe not as worrying as it should be (last update August 2011). I just noticed the changelog references timidity, so maybe midi files are already supported this way, who knows. Probably not anything anyone would ever want to use, as I seem to remember modplug not doing too great with midi, or ffmpeg not doing too great with midi, or something like that a couple years ago. I ended up using Qsynth (based on fluidsynth).

I guess this stuff all depends on ffmpeg anyway. http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks is a page that might be outdated but mentions some of these. That page did remind me of vgmstream (http://hcs64.com/vgmstream.html), which is appropriate to mention in this thread.

qyot27 commented 11 years ago

Yeah, it would seem the fix for modplug detection is fairly simple, https://github.com/sherpya/FFmpeg/commit/3d9f912ee12931f7d89d4994ca8e1e839e951591

It may not be the method the guide ends up using, but it seems to point to the same general thing I was starting to suspect. When I moved x264 detection to pkg-config it required having FFmpeg load in stdint.h first.

ghost commented 11 years ago

I added libxmp support to a branch: https://github.com/mpv-player/mpv/commit/libxmp (This was 4 months ago. I updated the branch just now, though, so it requires newest libxmp.)

ghost commented 11 years ago

Not much, just two things:

  1. It would be better if it were in ffmpeg
  2. They're still changing their API... what I did just 4 months ago was already broken by an API change,
elevengu commented 11 years ago

But XMP (eXtended Module Player) is actively maintained and supports a great bunch of module formats without the use of partial emulation

Looks cool! Seems like a much better long-term solution than modplug, which is infamous for its inaccuracies (but good enough for laymen).

I didn't even know mplayer2?|mpv could even support formats that ffmpeg|libav didn't. Opens up possibilities like, oh, the title of this thread!

ghost commented 11 years ago

I didn't even know mplayer2?|mpv could even support formats that ffmpeg|libav didn't.

That has always been part of MPlayer's architecture. But things have been moved to or replaced with functionality provided by ffmpeg, and mpv takes this even further.

ghost commented 11 years ago

So, please decide: which of these libraries do you want? Going by the API, gme could be supported. fluidsynth looks kind of bad, but maybe it could be supported too. For libxmp there's already a working branch.

I definitely don't want to add 3 wrappers just for some obscure file formats.

Nikoli commented 11 years ago

For me most useful would be fluidsynth support. About gme and libxmp: just support what seems better for you.

ghost commented 11 years ago

I added libgme support to ffmpeg. Note that ffmpeg has libmodplug support too. (Both must be explicitly enabled at ffmpeg compilation.)

libxmp support could be added too after they change the API. (If ffmpeg want it at all.)

ghost commented 10 years ago

Since there's no more interest in this, I'm closing it.

Feel free to reopen if you have a request.

ThomS8312 commented 9 years ago

Is there a way to configure libmodplug as well as change soundfonts? What I'm hearing by default leaves a lot to be desired...it sounds like a music box with a harsh sound.

ghost commented 9 years ago

I'm not sure what you even mean.

ThomS8312 commented 9 years ago

I thought libmodplug was a software synthesizer (had never heard of it before) and was an alternative to fluidsynth/timidity. What is "libmodplug" and how do I get it to work properly? I already have ffmpeg installed with it enabled.

ghost commented 9 years ago

What is "libmodplug" and how do I get it to work properly?

I don't know either, just that it's obviously a library. If you know a better library, tell me.

mia-0 commented 9 years ago

Modplug isn’t a synth. It just plays a few tracker music file formats which use prerecorded samples.

ThomS8312 commented 9 years ago
Modplug isn’t a synth. It just plays a few tracker music file formats which use prerecorded samples.

Are the "prerecorded samples" sound banks that are included in the library itself?

mia-0 commented 9 years ago

Are the "prerecorded samples" sound banks that are included in the library itself?

No, they’re part of each file.

ThomS8312 commented 9 years ago

Seeking seems to be broken with .mid (MIDI) and .xm (FastTracker 2) files. The player sometimes exits or playback loops to the beginning while seeking in certain scenarios. Some .mid and .xm files won't play at all (the player itself won't even load), while other players can without issue.

I think mpv would benefit the most with FluidSynth support for MIDI playback. It's a popular choice in other linux audio players and an interest in it was expressed previously.

Based on what I've heard from libmodplug, it's not suitable for MIDI. Almost anything would be better. Maybe something's wrong with the playback? There's no percussion and it sounds like only one instrument is playing overall, and that instrument is more like a piercing "beep" that plays at different tones.

ThomS8312 commented 9 years ago

In fact, including Timidity++ support too would give greater MIDI support to mpv. FluidSynth or Timidity++ are usually the two choices for software synths (MIDI playback) in audio programs. If only one is supported, users of the unsupported synth are out of luck.

ThomS8312 commented 9 years ago

After looking into this further, I've concluded that Timidity++ is the best choice for MIDI playback. There's no need to support more than one synth.

I think the focus of a software synth for mpv should be playing .mid files. I've tested playback with a few .mid files I have and Timidity++ played them even better than Fluidsynth did (using the FluidR3_GM soundfont). Fluidsynth wouldn't play one particular .mid file I had, and complained that the file "wasn't a Sound Font file" and "couldn't load" it. Fluidsynth also plays .mid files with an overly emphasized chorus while recessing the other instruments. Timidity++ played the .mid files without these issues.

Timidity++ prints out the metadata of a currently playing .mid file in the terminal too. That's useful because ffprobe doesn't seem to retrieve that kind of information from .mid files. Another benefit of Timidity++ is that it loads faster than Fluidsynth. Timidity++ loads right away, but Fluidsynth takes a moment or two before it begins playing.

I also briefly looked into Wildmidi. It's not as mature as Timidity++ is, so it wouldn't be a viable alternative.

ghost commented 9 years ago

Frankly, I can't seem to find a Timidity++ lib or API. Where did they hide it?

Timidity++ prints out the metadata of a currently playing .mid file in the terminal too. That's useful because ffprobe doesn't seem to retrieve that kind of information from .mid files.

A proper library should never print anything to the terminal, unless explicitly asked to. Anyway, I'm not sure if ffprobe or mpv can dump the information you want, because they use a generic API designed for video media files.

ThomS8312 commented 9 years ago
Frankly, I can't seem to find a Timidity++ lib or API. Where did they hide it?

I'm not sure about Timidity++'s code, but I read somewhere it isn't a library.

A certain approach needs to be taken with MIDI playback because it's an entire context in and of itself. Mpv would need to accomadate that context for complete support.

What I used to test both Fluidsynth and Timidity++ were the timidity and fluidsynth command line programs. Both synths are MIDI players and have their own configuration files. timidity prints the metadata of the currently playing file in the terminal.

Proper MIDI support must include a means to configure the synth (options, changing sound banks). I visualize the support for Timidity++ to be similar to how youtube-dl is supported, meaning options from a separate program can be passed through mpv. timidity would be the backend for MIDI playback and its configuration file would be acknowledged as well.

I find there are some alternative midi players: https://github.com/Mindwerks/wildmidi

Wildmidi doesn't support SF2 (so the FluidR3_GM2-2.sf2 sound bank is not an option), and Timidity++ has more support than both Wildmidi and Fluidsynth for standard .mid files.

ghost commented 9 years ago

I'm not sure about Timidity++'s code, but I read somewhere it isn't a library.

Then it's not useable by ffmpeg or mpv. You still could probably make timidity output raw audio and pipe that to mpv, though.

ThomS8312 commented 9 years ago

Actually, Timidity++ can be run as a daemon, providing ALSA with MIDI support. That's probably the point of connection you're looking for. Other programs are able to utilize Timidity++ in this way.

ghost commented 9 years ago

Can you point me at a program that uses timidity in such a way?

ThomS8312 commented 9 years ago

aplaymidi is a program that does.

mia-0 commented 9 years ago

On Monday 08 June 2015 13:12:33 V. Lang wrote:

Can you point me at a program that uses timidity in such a way? There’s SDL_mixer… which contains a stripped-down copy of timidity itself.

Edit: Oh, actually that’s using it differently, but maybe that code could just be turned into a library.

ThomS8312 commented 9 years ago

aplaymidi is a simple program that is part of the ALSA project. Test MIDI playback with command aplaymidi FILE.mid -p 128:0, assuming you have the Timidity++ deamon running beforehand with the default client/port (command timidity -iA).

Another one is Rosegarden. It's a music composer/editor program and is fully featured compared to aplaymidi.

psi29a commented 7 years ago

Not sure if this ship has sailed, but wildmidi is in the process of adding support for soundfonts. It also supports more file formats than just MID and playback of MID is done so with less CPU usage than either fluidsynth and timidity.

ghost commented 7 years ago

API seems reasonable, so if anyone wants to implement this.

shmerl commented 6 years ago

Proper MIDI support must include a means to configure the synth (options, changing sound banks).

Fluidsynth allows external control through QSynth for example.

clort81 commented 1 year ago

I am adding here the note that as of 2023-03-03, mpv does playback via gme via ffmpeg, if that is built-in.
This can be achieved by adding --enable-libgme to a file called ffmpeg_options in the root directory of the mpv-build tree on this repository.
https://github.com/mpv-player/mpv-build And then running rebuild script.

As an aside, I would like to know how to achieve stereo separation on playback (libgme supports this) when playing .nsf and other chiptunes with mpv. Stereo seperation of voices makes old chiptunes much more tolerable to the ear.