General JavaScript VGM player discussion

Post by **vampirefrog** » 2018-05-22, 10:27:49

you can make a proxy script - just pass the vgmrips URL as a parameter and it fetches the vgz server side from vgmrips. Or, if you have a domain, I think I can add a http header to give you cross domain access, but I think the cleanest way for you , that doesn't depend on the vgmrips server, is to download the all_of_them.zip file, unpack it, and write a simple php script to extract vgm/vgz files from the zips. Plus this way you can have a listing.

niekniek · Post by **niekniek** » 2018-05-22, 16:56:56

Right, I'll give the download through script idea a shot. Are the m3u files available by some URL as well?

Are there any future plans to integrate the js player in the vgmrips.net site? Basically I started this emscripten thing because you said the MP3 files took too much space.

ctr · Post by **ctr** » 2018-05-22, 17:50:31

If you're concerned about MP3 file size, why not encode to Opus instead. Takes less space than MP3, less CPU usage and stuttering than JS, and supported on almost all modern browsers now (Only apple is still stubborn and refuse to support it). The JS player could still be used as a fallback though.

niekniek · Post by **niekniek** » 2018-05-22, 21:48:17

Why Opus instead of just playing the real thing? Won't take any extra diskspace...

Besides, it still stings a bit that a site that is all about vgm files doesn't use them for playback at home base.

Also, the javascript player works fine on all browsers afaik, including Safari... also on midrange mobile phones.

ctr · Post by **ctr** » 2018-05-22, 23:28:26

niekniek wrote:Why Opus instead of just playing the real thing? Won't take any extra diskspace...

Because of the reasons stated above, JS players use a lot of CPU and memory due to inefficient coding, tend to cause audio stuttering (especially when the user is doing something else in the background). You can also pretty much rule out using accurate FM chip emulators like NukedOPL or NukedOPN with JS, I can tell you that already.

Besides, the "real thing" is already used for playback. The files are rendered on-demand on the server by the real VGMPlay code, encoded and then cached.

niekniek wrote:Besides, it still stings a bit that a site that is all about vgm files doesn't use them for playback at home base.

The player on the site is intended for previewing VGM files. For optimal playback I think you should just download the files and play them on a native player instead, and that is what the site should be suggesting as well.

niekniek wrote:Also, the javascript player works fine on all browsers afaik, including Safari... also on midrange mobile phones.

I still suggested it could be used as a fallback or preference option. But I'd rather see it not be used by default, if the browser supports streaming.

Streaming files also have the advantage of instantaneous playback, as the file can start playback before it is finished downloading, for VGM files the entire file has to be downloaded, then decompressed to even start playback. Seeking is also a lot faster with streamed audio. Some VGMs can't even handle seeking at all (like all packs that use ADPCM/PCM streamed audio, we have quite a few of them on vgmrips).

niekniek · Post by **niekniek** » 2018-05-23, 0:07:30

Because of the reasons stated above, JS players use a lot of CPU and memory due to inefficient coding, tend to cause audio stuttering (especially when the user is doing something else in the background).

vgmplay-js is simply the c code converted to Javascript with Emscripten, so the quality of support for everything you mention is exactly the same as running a normal binary compiled from that code.

Obviously the Javascript conversion gives a performance hit, but I can tell you probably didn't try my thing, since it's using about 10% on my ancient i5 from 2009 and playing an MP3 file also takes about 10% CPU overhere, so imo you're not giving the Javascript engines from today the credit they deserve. I can't get it to stutter at all... seeking works very quickly as well. Not as quick as MP3 files I must say, but I believe that's because of the implementation I did with some horrible CCS and stuff. I believe my code can be optimised to be just as fast.

Besides, the "real thing" is already used for playback. The files are rendered on-demand on the server by the real VGMPlay code, encoded and then cached.

You get what I mean... If you put it like that you can simply download everything as MP3 files, since those are similar to VGM files in your words. When playing the MP3 files from vgmrips.net you're already downloading the data, might as well save it to local disk then. You don't need the VGM packs and you only need the default media player to play them, which probably is working very well.

As I said it's mainly the disk space thing...

For optimal playback I think you should just download the files and play them on a native player instead, and that is what the site should be suggesting as well.

One could say vgmplay-js IS a native player... it's just compiled to wasm code instead of x86/x86-64/arm/whatever binary code. The engine running the wasm code is simply compatible with all CPU platforms, similar to Java...

I have to agree with the instantaneous playback thing, but that's the only valid argument imo. You don't like Javascript/wasm a lot do you?

ctr · Post by **ctr** » 2018-05-23, 8:05:15

niekniek wrote:vgmplay-js is simply the c code converted to Javascript with Emscripten, so the quality of support for everything you mention is exactly the same as running a normal binary compiled from that code.

Except with 50x memory usage and 10x CPU usage...

playing an MP3 file also takes about 10% CPU overhere

On my old Pentium 4 playing an MP3 would be like 1-2% CPU usage...

If you put it like that you can simply download everything as MP3 files, since those are similar to VGM files in your words.

I did not say that, nor have I implied that. I said MP3 files are perfectly sufficient for playback in the browser, and for local playback you can go for the VGM files.

As I said it's mainly the disk space thing...

If Vampi really is that concerned about file size, probably time to stop piggybacking the work servers and actually use a real hosting service... But if you don't care about client performance, then everything I say simply doesn't matter.

One could say vgmplay-js IS a native player... it's just compiled to wasm code instead of x86/x86-64/arm/whatever binary code. The engine running the wasm code is simply compatible with all CPU platforms, similar to Java...

That's not native. Native code is what is processed directly on the CPU. Wasm is still just a bytecode that has to be recompiled or interpreted. But that is not what is causing the JS performance issues (unless you have literally megabytes of it, which is actually the case if you go to a "modern" website today). Those issues are mainly caused by the sandboxing and other security 'features' of JS.

If you can avoid memory allocation as much as possible, you will reduce CPU usage (that was probably the reason why the original JS player was so slow, and why yours is faster)

Post by **ValleyBell** » 2018-05-23, 11:00:46

I'm interested in how well (or badly) NukedOPN2 performs in JavaScript.
niekniek: Could you try to post the current Git version of VGMPlay to JS and make a test with the NukedOPN2 YM2612 core? (You need to set EmuCore = 2 for the YM2612.)

NukedOPN2 is the most demanding sound core we have, so it's an excellent performance test.

Post by **vampirefrog** » 2018-05-23, 13:38:48

My plan is to let the user choose between mp3 and vgm emulation playback. I guess the question is which will be the default. Perhaps we can have some heuristic to detect if the browser is capable of vgm emulation, then mp3. We used to have ogg as well but they do add up.

I am currently swamped with job work and I think perhaps end of june is when I'll have some time to attempt to implement the js player into the site.

The work servers we're "piggybacking" on is a proper server. To move the site to a "real" server would not be an upgrade unless we'd be using a VPS, which costs money. Perhaps if we start a vgmrips patreon we might afford one. Currently it takes up 100GB space, and I estimate it will grow to 200GB. Some quick searching reveals prices between $30 and $40 per month for US hosting, and for Romania hosting I've seen prices between 50 and 60 EUR per month. I am not sure whether to host it in the US, because of our uncertain legality. I am not even sure about other european countries. Perhaps we can use some sort of caching system, I recall there was a service that Amazon offered, where they cache your files and serve them through their global network through some DNS tricks that they do. That way it would be fast for everyone. It remains to be seen. Either way, it costs money which we don't currently have.

I don't understand why words are allowed to escape ctr's mouth sometimes.

It would be nice to find a developer to make a vgmrips player for android and ios. It should be possible to use the plain vgmplay code for both situations. We can then link to the apps on the front page.

m3u files are not available right now. I think you can scrape the web page instead, for a list of files.

niekniek · Post by **niekniek** » 2018-05-23, 14:39:27

Why would a browser that's not too old not be capable of vgm emulation? It works fine on everything I tested it on, if someone finds an issue please let me know. I understand you hesitate, as I would with anything new, but I hope in time you can still delete your MP3 files. If something doesn't work properly it's almost certain that it's in my webaudio/javascript/html/css stuff so it can probably be fixed, since the wasm vgmplay binary should behave 100% the same as any binary version since it's based on the same source and I think Emscripten is a stable product with full compatability.

About performance, Chrome on my Imac seems to use the same amount of CPU when playing an mp3 file as when playing a vgm file. If the tools to check that can be trusted. It should be tested when the browser is showing an empty tab and not the one with the progress bar since that uses cpu as well.

https://github.com/niekvlessert/vgmplay-js contains the latest version, I can try the NukedOPN2 thing. Any game in particular I should test? I can put it online with that game...
https://niekvlessert.github.io/vgmplay-js/ to use it. Or vlessert.nl/vgmplay-js/.

And vgmplay is included in my player, ViGaMuP, for Android! Which now has lazy-loading image search for downloading from vgmrips. Any feedback on that is very welcome too.

niekniek · Post by **niekniek** » 2018-05-23, 14:45:05

By the way, I have not put any time in the -O parameters, and Emscripten supports asm.js and real wasm, that could further improve performance...

Post by **vampirefrog** » 2018-05-23, 16:38:25

niekniek wrote:ViGaMuP

Perhaps I can expose some API calls and you can add vgmrips-specific functionality in your app, like latest/top rated packs, search, login, rate, save to favorites. Though ideally this would be a separate app that only plays vgm files from vgmrips.

ctr · Post by **ctr** » 2018-05-23, 17:24:15

vampirefrog wrote:The work servers we're "piggybacking" on is a proper server.
I don't understand why words are allowed to escape ctr's mouth sometimes.

Well, I said "real hosting service". Work hosting doesn't seem reliable to me in the long run of things. They could shut it down as soon as they need space for another customer, after all. Unless you already pay your workplace for hosting space, that alone would probably be enough for me to call it "real hosting" and not piggybacking. if you already do that then I apologize... Also allow me to remind you about our still current lack of SSL support. In a few weeks, browsers will put a nice red banner on our site saying it's insecure and potentially malicious.

Regarding hosting sites, I know joshw.info gets away with hosting terabytes of VGM, so as long as we stay somewhat under the radar we should be fine I think. (Though playback on the site could complicate things for us on that regard)

vampirefrog wrote:It would be nice to find a developer to make a vgmrips player for android and ios. It should be possible to use the plain vgmplay code for both situations. We can then link to the apps on the front page.

I would prefer an open source application. For iOS there's Modizer.

niekniek · Post by **niekniek** » 2018-05-23, 22:35:56

Well, the code of my player is currently not in good enough shape to open source it... I would be willing to help on a real vgmrips player for Android though, I can use the experience I gained from ViGaMuP. However there have to be more developers then me and some serious testers as well before I can be persuaded to get that in the works. Also some rough requirements overview would be nice.

The ability to download vgz files can be used in that native player as well. For example use the webview to offer the normal site experience in the app, but when it comes to playing the files, download the vgz file once, then cache it, and play it locally using the engine.

ctr · Post by **ctr** » 2018-05-23, 23:43:19

niekniek wrote:I can try the NukedOPN2 thing. Any game in particular I should test? I can put it online with that game...

Literally any game from project2612 would work, but if you want a stress test then Segasonic the Hedgehog could be a good test case. Two YM3438 chips and they're all used.