VGMPlay for MSX

Par Grauw

Ascended (10767)

01-05-2016, 02:23

syn wrote:

Instead I started using Deflemask, a windowns/mac/linux tracker for many soundchips, which can export to VGM.

This was my short testsong using a YM2151, running in openMSX.

https://youtu.be/TaZsKZH8bVU

And no in the end I didn't make a psg remix tune.

Really nice, syn!

I was secretly thinking of maybe doing the same :).

Par syn

Prophet (2123)

01-05-2016, 17:24

Thanks. I think its a great tracker.

Yeah I was actually gonna ask you if you would support segapcm in opl4 in VGMPLAY, (i dunno how much work this is to write some converter) but i forgot about it.

Par Grauw

Ascended (10767)

01-05-2016, 17:43

I want to but haven’t implemented any non-MSX sound chip emulations yet.

Alternatively an external VGM conversion script could be written which translates the SegaPCM to OPL4.

Par syn

Prophet (2123)

01-05-2016, 17:44

Don't do it just because I asked I only wanted it for the remix contest.

I dont really see a future for ym2151 music creation because it is not really widely used on MSX.

(I mean I don't know if I will make more music for ym2151 because I cant use it in a msx game because that would probably be 1% of the msx users who can listen to it on a real msx)

Par Grauw

Ascended (10767)

01-05-2016, 17:44

How did you like the sound chip though?

Par Manuel

Ascended (19462)

01-05-2016, 21:51

After the story of flyguille's game music replayer, I wondered if it is a good approach for any kind of MSX music replayer. So, instead of making complex replayer code with a high level data format, just create a VGM like file (all register writes), add simple RLE compression to it and use that data in the replayer of the game.

Questions:
- does the compression do a good enough job to make the data small enough?
- is the replayer indeed simple and fast? (I can hardly imagine a simpler and faster replayer!)

Par Grauw

Ascended (10767)

01-05-2016, 22:37

If you convert the VGM to be frame-accurate it should be pretty small in many cases, strip out the sound chips you don’t need as well as handling for invalid data and you’re off to a good start.

Then as time permits and file sizes demand, as a next step you could create a derived format with the sound chip hardcoded to reduce the file size. I’d still record as VGM and use the VGM toolchain to trim, loop and reduce the file size before converting it to the final custom format.

Finally, if I’d really want to reduce the file size to a minimum, I’d add back-reference commands to eliminate repetitiveness (essentially a simple version of Lempel-Ziv), and possibly store channels in separate streams to improve compressibility. That’s quite a bit of extra work though. RLE won’t do much good, as there is very little run-length repetition.

Answers to questions:

1) Gzip does a good job for sure, but it’s fairly CPU-intensive to decompress and still needs to hold the entire decompressed data in memory. BitBuster is faster but still has the latter limitation. Adding a custom back-reference command to the VGM file format as I mentioned would probably be ideal.

2) Due to the generic nature of VGM the replayer is not always as simple and fast as could be; e.g. taking SCC as a particularly illustrative example, VGM stores the data in a rather awkward format unfortunately (specific for SCC; it’s fine for the other sound chips). Additionally, for every I/O to the SCC the VGM player switches slots because it does not know what command follows, even for sequences of waveform data it does this. If you would derive an SCC-specific player from VGMPlay, you could keep the SCC switched in permanently.

In summary, I think if you start with VGM and work from there, and keep your toolchain based on VGM, it’s definitely a good way to implement a replayer, it’s quick to get started, and the musician can use any tracker he wants even if it doesn’t have a replayer for MSX.

Par Manuel

Ascended (19462)

01-05-2016, 22:36

1) gzip doesn't help, I was talking about the in-memory size, ready for the replayer.
2) I didn't mean to actually use VGM. I meant to use a format which only stores register writes as a base, just like what flyguille did, who used an openMSX script to record these. So, use any tracker you like, and use any method you like to find the actual register writes and put that data in some file format.

Another thing: is flyguille the first to use such an approach? So, are all existing replayers (for all kinds of MSX trackers used around) based on more complex data?
So, how do existing replayers of trackers work? Do they use a different format for replaying than when composing? (That seems a good idea in most cases...)
What about those MML based replayers?

What are the advantages and disadvantages of all these approaches?

Par Grauw

Ascended (10767)

01-05-2016, 22:43

I think Huey mentioned the Trilo Tracker replayer uses a similar approach.

However specialised formats still have a benefit, not just in data size but they can also have it in terms of performance, e.g. in the case of an SCC instrument update it can just LDIR the 32 bytes in one go, whereas the VGM-like format needs to go “process command” “write byte to this address” “look up next command” x32. Of course there’s also nothing stopping a specialised format from storing register settings in a ready-to-out format, rather than going through e.g. a frequency table lookup.

The biggest benefit of VGM or a similar format is that it is generic and thus simple to record and play back anything.

Par Grauw

Ascended (10767)

01-05-2016, 22:49

Manuel wrote:

1) gzip doesn't help, I was talking about the in-memory size, ready for the replayer.

I would not be too optimistic about the in-memory size. It can quickly grow as you add complexity to the music. There are simple PSG VGMs whose data is really tiny, even uncompressed. But I think you can imagine that pitch bends and instrument macros and such can quickly balloon the file size.

Adding some back-reference command to avoid repeating will help a lot, but it’s not provided by VGM and such so you’d need to implement a simple compression dictionary builder yourself. Then again, if someone implements that kind of tooling once for VGM and VGMPlay, everyone will be able to make use of it from then on.