This here is the Kiloman Music Encoder, or KM-Encoder for short. I made it to store the music for a Mega Man clone project that's been on the backburner for a while.
Multi-channel examples
Two covers by me, two originals by @Gruber and @BoneVolt respectively.
As many 2-channel Mega Man covers as I could fit
Originally 8 seperate carts worth of music, all in one!
The only limit for storing music now is the character (and cart size) limit! Even SFX filters are stored properly!
It uses the full range of ord() and chr() to store the data in base-256. (A pointer from @merwok helped me bump that up from base-240!)
The Tools
How to use: https://docs.google.com/document/d/1A1dydhxVaCSEObqKKoZIaOsFkMbZXg4FakKssZkFpEQ/edit?usp=sharing
Have fun!
OLD VERSION:
Guess this makes two of us using music compression systems to store Mega Man tracks ;). In my case I found that plain base-256 strings compressed just about as well (in terms of compressed bytes) as a complex RLE variant I made. You seem to possibly be using some additional compression methods in your code, did you notice better byte compression than raw strings?
@JadeLombax Nah I'm not compressing it any further than base-256 characters, honestly don't know if there's a way to compact the strings further without blowing up the token count.
Speaking of, I have a new version ready that I'll post soon which is nearly twice as effcient token-wise.
Yeah, I came up with a system that could encode changes in volume, note, and instrument type, but it didn't really beat the built-in compression by any significant margin and took more tokens.
As for token savings, I found that you can poke big chunks of data to memory using P8scii codes right in the string, so I'm just using a simple setup like this:
musicptrns={
""
}
musicsfx={
""
}
function decode(track)
?"⁶!3100"..musicptrns[track]
?"⁶!3244"..musicsfx[track]
end
|
@JadeLombax I... wow I'm surprised that ?"⁶!3200"..sfxdata[val] works. That's another 7 tokens saved. Doing one big poke to 0x3100 is only best used if every song is 4 channels though, otherwise there'll have to be a lot of empty space in the encoded patterns string.
Well, I'm currently using 3-channel tracks and trying to limit each one to 16 or fewer patterns, so with about 10 tracks total that's around 640 extra blank bytes in the strings. It's something, but I figure the compression should largely take care of it, and this saves tokens, but for your project it might work better to not have that blank pattern data.
[Please log in to post a comment]
