Forums

Oh, I see now what you mean.
Actually I'm trying to keep everything (format and program) as simple as possible and even with that "sort of" LZ compression it's still very very simple. I'm anyway working on achieving a better compression through better code in my conversion/compression tool... I mean, complexity can be kept out...

I was already wondering how the compression works exactly. I have a decent understanding of LZ (I had to write my own ZLib variant because some console vendor did not allow 3rd party libs to be used), but I assume it's not the same, because you take repeated data from ROM, not from a runtime-dictionary in RAM?

I didn't even know I was doing something that could be somehow similar to LZ compression! LOL!
How it works, actually: for each 'substring' of length 35 to 4 (decreasing) starting from Nth byte, I seek in the previous bytes (starting from beginning of array) if there's a match.
How it should work instead: it should try somehow to maximize compression. I'm trying a different approach now which seems to shave some more... but it's still buggy :|

LZ covers mostly algorithms whereby you say "copy n bytes from location x". Normally x refers to somewhere in the decompressed data, but that's no good here because every byte is discarded as soon as it's "decompressed"; so instead it points into the compressed data. This can lead to tricksy things if you were to recurse. More specific algorithms, like Deflate as seen in zip/zlib, specify an actual implementation, generally with extras like Huffman coding of the data after compression.

Yeah, this is one of the things I was wondering about - I thought previously you would point only into a dictionary that has only bare psg data without any repeat-commands. Do you allow such recursion, having repeat-commands within repeat-blocks? It could work well with music...

No, I'm not compressing recursively. It would require some sort of decompress recursion stack, which is something I feel a little too complex.
Anyway making the compressor a bit smarter I could achieve to save another 260 bytes on my usual test file (I still didn't change any of the parameters like the substring max length)

I would really need few more VGMs to test... some suggestions?
I'd like one with could perform very bad on the compressor (some song that at least sounds very un-repetitive) and also one that appear to have long "pauses" (held notes ok, I mean long pauses in the data stream to the PSG chip...)
Since I know very few SMS games I have no idea, so here's why I rely on you :)

sverx wrote

I would really need few more VGMs to test... some suggestions?
I'd like one with could perform very bad on the compressor (some song that at least sounds very un-repetitive) and also one that appear to have long "pauses" (held notes ok, I mean long pauses in the data stream to the PSG chip...)
Since I know very few SMS games I have no idea, so here's why I rely on you :)

The title song of Ultima IV sounds quite unrepetitive to me but it doesn't seem like there are VGMs available for this game... I'll try to think of another unrepetitive song!
The title song of Asterix http://www.smspower.org/Music/Asterix-SMS has long held notes.
Hope this helps! :)

You'll get long pauses in the VGM data for music without vibrato or music envelopes, which basically means awful music. Try the handful of Colecovision soundtracks we have, Monopoly, or Alf.

As for stuff that's complex: try Ristar and Gunstar Heroes - although they use GG stereo so after stripping that out they might sound a bit unbalanced. Also Wiwi Jumbo from Space Harrier, which seems to be algorithmically generated and never repeats, the VGM is just a reasonable subset of it.

Calindro wrote

The title song of Asterix http://www.smspower.org/Music/Asterix-SMS has long held notes.

This has two "0x61 nn nn : Wait n samples" waits that aren't frame sync'd, has a GameGear stereo info (is it a GameGear game?) and, indeed, has quite all the spectrum of all the waits, from short to long and very very very long (at the end). Good catch, very useful! :D

Maxim wrote

Wiwi Jumbo from Space Harrier, which seems to be algorithmically generated and never repeats, the VGM is just a reasonable subset of it.

That's a real test-beast! Thousands of waits that aren't frame sync'd, the sort-of-LZ compression tool takes 7 minutes (!!!) and the effect is:

Info: input file size is 14070 bytes
Info: output file size is 11568 bytes

Unfortunately, because of those thousands of waits, the song becomes completely different... I think I have to round waits to the closest frame... let's see what I'll be able to do next days.
Thanks!

It looks like the Space Harrier VGM pack is not frame-accurate. There's a tool called "vgm_facc" which should do the conversion to frame-accurate timing for you. It lives here: http://vgm.mdscene.net/forum/viewtopic.php?t=207

However, when I tried it, it seems to struggle to find the correct timing offset. It might be better to re-dump the track for your testing.

In the Asterix track, the funny times are only at the start and end of the file, as is the GG stereo initialisation. These can be rounded and ignored respectively.

Following fellow forum users advices, I think I'll modify the file format allowing more code space for longer 'LZ' strings and less code space for *reserved* (which I think I'll actually use, at a later stage) and for long waits, which aren't so very common after all. So here's the planned new format - additional feedback is welcome again :)

PSG simplistic approach (log of writes to SN76489 port)

- No header
- %1cct xxxx = Latch/Data byte for SN76489 channel c, type t, data xxxx (4 bits)
- %01xx xxxx = Data byte for SN76489 latched channel and type, data xxxxxx (6 bits)
- %00xx xxxx = escape/control byte (values 0x00-0x3f), see table #1

Table #1

0x0000 0000 - end of data [value 0x00] (compulsory, at the end of file)

0x0000 0001 - loop begin marker [value 0x01] (optional, songs with no loop won't have this)

0x0000 0nnn - RESERVED for future expansions [values 0x02-0x07]
* PLANNED: GameGear stereo - the following byte sets the stereo configuration
* PLANNED: event callback - the following byte will be passed to the callback function
* PLANNED: longer waits (8-255) - the following byte gives the additional frames
* PLANNED: compression for longer substrings (52-255) - followed by a byte that gives the
length and a word that gives the offset

0x0000 1xxx &
0x0001 xxxx &
0x0010 xxxx &
0x0011 0xxx - COMPRESSION: repeat block of len 4-51 [values 0x08-0x37]
This is followed by a word which is the offset (from begin of data) of the repeating block

0x0011 1nnn - end of frame, wait nnn additional frames (0-7) [values 0x38-0x3f]

Said that, I'm planning to work on SFX integration. In my plans, SFXs are files very much like those used for background music but they should use channel 2 and/or 3 (noise) only.
In the easier approach I can think the program fires the SFX giving the data address and a mask that indicates if the SFX will use channel 2 or 3 or both. Then I guess I will have to silence the background music going on on the channel(s) allocated to the SFX, play the SFX while the music goes on and re-activate the background music when the SFX is over. But to correctly reactivate the music I guess I have to log all the changes the music would send to the PSG on SFX allocated channels, right? My biggest doubt is how to log these changes easily and effectively.
Again, any help on this is much appreciated!

Yes, store the last recent bytes that would have been written to channel 2 and 3 (that's just 3 or 2 bytes per channel).
Edit: I think this is a little tricky here because data comes in just as bare bytes, with no info on whether it's volume or frequency. You'll have to detect what it is and store it accordingly.

Care has to be taken of the noise channel. - The noise sequence has to be restarted always when the music resumes.

Edit 2: Maybe it's worth to split this forum thread into two, with the second one about music only.

Yes, it's really tricky... that's the reason I'm asking for some hints!

about topic splitting... well, I can't do that myself, but I suggest to separate from this post of mine (Fri Jan 31) onward...

edit: I edited the previous post, I forgot the "callback" planned feature :)

This topic has covered a lot of subjects but it's not easy to split it up much of the time as we'd need to also split individual posts, which we can't do :(

if it's possible to split from a given post onward (as it was on phpBB 2.x)... I already suggested the starting post in my previous post ;)

(it seems the PSG "logging" it's working, now I'm working to stop sending the PSG data for chn 2-3 when marked 'busy'...)

Hmm, phpBB2? Who would still be using that? :)

I've done a bunch of splitting up by subject; sverx is now the proud starter of more than one topic.

Personally, I think phpBB2 is still the best choice when it comes to something easy to customise, since you can do pretty much whatever you want with it.

Maxim wrote

Hmm, phpBB2? Who would still be using that? :)
I've done a bunch of splitting up by subject; sverx is now the proud starter of more than one topic.

Thanks! :D (and anyway I said "as it was on phpBB 2.x"... I'm no longer hacking on it, but back then I did a lot of customization...)

now let's stop derailing this topic or we will need a new split :p

Ok, I've got the first beta working! :)
It's still a quite basic approach, but it plays a background music (in loop) and pressing the button 1 it fires a soundeffect (a simple one I did myself in few minutes using Mod2PSG2) on channels 2-3, keeping the music active on channels 0-1 and then reactivating the other two channels when the SFX ends or gets canceled (releasing the button 1).
Since I don't want to spread that very early beta, fellow forum users who took part in this topic who might want to give it a try, please PM me for a download link (it's a 16KB ROM with more than 60% unused...)

Well, it works fine so far.

Remember if you have sound effects playing on channel 2 but not on the noise channel, the music can't use the channel 2 frequency feature of the noise channel.

If you want to go more far with sound effects, you could implement looping ones.

Thanks! I know of that correlation between channel 2 and 3 when noise channel is set to use the tone of channel 2, and that's something I still have to address.
Looping SFX support is planned to be in since first 'official' release :)

Ok, I think I'm at a good point.
- the file format for both music and SFX is done, at least the minimum needed
- there's a converter from VGM to PSG ("my" format) with a switch to filter only channel 2 and/or 3, for SFX.
- there's a compressor, which is very very slow (approx. one minute per KB of original data on my PC) but it seems to do its work well, and it's even not compulsory to compress data, after all.
- the library supports music on any channel, and SFXs on channel 2 and/or 3 (the music on these channels will disappear when SFX is playing and it will seamless resume when SFX is complete or canceled)
- the library uses 34 bytes of RAM and in the worst condition I could try it required some 9% of CPU horsepower
- SFX can be looping or normal (one-shot)
- it seems to be working (LOL!)

I'd like to upload the whole of it somewhere, for you all to check/comment/use/enhance... any hints? Some online repository (if it's not googlecode, better...)?

GitHub GitHub GitHub! :)

Kroc wrote

GitHub GitHub GitHub! :)

OK OK OK! :D

Since I don't know how these things works, I will start with a test called "PSGplay" even if I actually don't like this name so much. (Does PSGlib sound too pretentious? mmm...)

GitHub seems pretty awesome, it's just a shame you have to use Git :) Also note that you are implicitly using a liberal open-source licence if you use free hosting there, be aware of the consequences (others may use your code commercially, for evil, etc).

for evil? :)
I've seen they've got some licensing you can choose... I think GPL would be fine...

It's here.
By the way, how do I set the current version number? :| How do I set the license? I couldn't find it anywhere :| (sorry for being so newbie...)

edit: ok I set the license. I choose a BSD so that homebrew using the library won't be forced to release source code too (which was compulsory with GPL, if I understool correctly).

Feel free to comment on this too!

It looks good, well commented, example program is simple enough. I had much less problems with GIT than with CVS/SVN in the past, so I'm glad you chose it.

Thanks! Let me know if you find any bug or something that doesn't seem perfect :)

This is a great piece of work. With Sonic 1 level editor, music is an area totally outside of my experience, so I won't be able to provide a built in music editor for Sonic 1's music format. Now if I could replace the music engine with VGM playback then conceivably users could import any song they wanted into the game! This would be a huge boon! I'll look at this project in the future to check viability. Anything you can do to make the format as compact as possible and reliable (well tested with many VGMs) would be great.

It would be informative to export the entire Sonic soundtrack to this format and see how much space it took. If nothing else, paging is likely to be different to the original, as the engine and data won't all fit in a single bank.

The format (I called that 'PSG' because I lack a better name) is quite compact compared to uncompressed VGM, not very compact if you compare with gzipped VGM, unfortunately. And I can't say this is surely suitable for your needs, actually.
A PSG is about 1/3 of the corresponding VGM, but this varies too...
The compression is very simple but not so effective, so if there are suggestions to make it much more effective I could surely apply them :)

edit: Maxim, you mean this? I can try with those if you like.

edit(2): I tried with those, there were no warnings at all in the conversion and the results are:
uncompressed VGMs = 164 KB - biggest file 40KB
uncompressed PSGs = 87,6 KB - biggest file 22KB
compressed PSGs = 48 KB - biggest file 11KB

Kroc can confirm but I suspect Sonic's music engine and data (including SFX) come to just under 16KB. Switching format seems like it costs about x3 space.

Does your engine play nicely with paging? How about within a track?

Paging???
I wonder that it works, given all the bugs that I found yesterday and today!!! :D
(seriously, now: no, the engine does no paging at all. I'm not planning to add that ATM but I can't exclude to do that later eventually...)

The driver runs from $C000 to $C715 (1'813 bytes) and the music / sfx data fills from $C7D0 to $FFB1 (14'305 bytes), so the driver/tables/music/sfx fill 1 bank with a few bytes to spare.

The thing is that I'm porting Sonic 1 to 512K ROM so instead of one bank, it'll have two -- approx. 30KB of space for music, instead of 14. No internal paging in the driver would need be added as the game can set page 1 & 2 before calling the music driver.

If the format can be improved to compact to 2x size then it would be feasible at least for implementation in Sonic 1.

Paging is difficult... The easiest solution for now would be to use two slots for a max. size of 32KB. Have the music player in slot 0, data in slot 1 and 2. Having the code handle paging on the fly is nasty and slow, you'd have to check/update paging for every byte from the stream. Maybe someone can come up with clever tricks of how to do it.

There's something I miss... if the largest file is 11 KB and you anyway play one background music only a time, why would be paging needed for the engine in this case? Or you've got ROM constraints too?

Kroc wrote

If the format can be improved to compact to 2x size then it would be feasible at least for implementation in Sonic 1.

I would love that... so far the best I can do is before your eyes. But I'm not an expert on compression, so if you've got suggestions I can try experimenting different methods...

Kroc wrote

I won't be able to provide a built in music editor for Sonic 1's music format.

Maybe I can look into that, if you give me a green light, and I can send you the vbp and stuff for a possible integration within your master editor. The format seems to be simple enough, so I might be able to do something nice. No promises, though.

A tracker for a commercial game engine (and a pretty good one at that) is just what we need around here :) It'll be much more restrictive than a VGM derived format, of course.

Regarding paging, it's pretty quick to check on each byte (just check for $c000), alternatively there's an upper limit on the number of bytes per frame, so you could split on chunks and only check once per frame, or even have an end of page signal in the music data. Or just don't support data over bank boundaries, you don't need to.

What you will need to do is play music from one bank and SFX from another at the same time. That's why I think the player needs to be bank aware.

Yes. Changing the data a little can make it more efficient. There's not much data in one frame, so it's not too slow anyway. There are different ways to check for the boundary efficiently, I'm not sure which one is the best here. If it's done only once per frame it won't matter much.

Luckily SFX are going to fit into a single bank easily, paging is mostly relevant to music only.

There's two issues with paging: track data crossing a page boundary, which is avoidable, and playing data from two banks at once, which is somewhat avoidable if you can page two banks at once. I'd rather pass the page number and offset to the player and have it select the banks itself, but it can also be blind to paging provided you can squeeze the playback code in the first 16KB. All these restrictions make the traditional single bank music engine with data much more convenient for programmers...

Maxim wrote

A tracker for a commercial game engine (and a pretty good one at that) is just what we need around here :) It'll be much more restrictive than a VGM derived format, of course.

The music doesn't have to be done with a tracker style program. Sonic's format, I think it's quite good, does not seem to be derived from a tracker.

True, but if I make the editor it will look like a tracker anyway, since I love trackers :U

And I'd probably make it import XM files, too.

Not sure if I'll take this task, though. I have some problems with my computers so this isn't the best time for me to do things.

Yesterday evening I spent a good hour searching on the internet for alternative solutions for compressing my PSG files, but I didn't find anything suitable. The matter is that every library/algorithm I found do requires (on the decompression side) either some RAM (more than a couple bytes I mean) or to access some bytes already decompressed before, both of which I can't afford, since everything that is decompressed is sent to PSG chip at once.

I thought that maybe if I would be able to compress shorter substrings too (actually the shortest is 4 bytes) and making the compressed code take less space (now it's taking 3 bytes) these could be useful for achieving better compression ratios, but I'm racking my brain to imagine how to achieve that. Any idea?

If you can split the data by channel you will save two bits on every command - but packing the bits will complicate the code. However, even without that, I suspect you'd get much better compression because within a channel there will be much more repetition. The cost will be the need for timing info in all four streams, so it's not a guaranteed win.

Something like this: two control bits, to specify volume, frequency, timing or control commands, followed by as many bits as necessary. Thus volume commands take 6 bits, frequency 12, timing could use a variable number of bits to optimise for the most common lengths. You can then do bitwise lookback for LZ runs. Commands would be used for the LZ references, loop jumps, and whatever else is needed, again being dial with the bits.

You might choose to pull the raw data out into a separate blob from the main data stream, and thus turn the entire playback steam into references to this "dictionary". This might make the references shorter, especially if you applied some Huffman coding to them so common ones were encoded in fewer bits. Or even put the whole dictionary inside the Huffman tree.

Next stream of thought idea: maybe Huffman coding would be a big win on its own, as the number of values used is pretty small (few games use the 10 bit frequency range very uniformly).

Maybe encoding volume and frequency changes as the delta values would increase the compressibility, particularly with Huffman again.

Regarding general compression, it is tricky because few algorithms are designed for low memory use and no read access to the uncompressed stream. Some of the graphics compression algorithms on the Matter System might be useful, as they tend to avoid reading back the uncompressed data, but I don't think any of the ones I know of will help here - they're either basic RLE or much more oriented to the data format.

Thanks for the good hints, unfortunately I was already thinking at most of them and I'm not so sure they'll perform well enough to eclipse the actual system (since I believe it would be not a good idea to over-complicate everything for shaving off some more 60 bytes from a 2KB file, right?).
The biggest concern I have is about manipulating bits (instead of whole bytes) on the SMS... from what I've seen the Z80 is very costly/slow at shifting bits so I guess a realtime Huffman-like decoding could be overkilling... or am I just wrong?

Martin wrote

Maxim wrote

A tracker for a commercial game engine (and a pretty good one at that) is just what we need around here :) It'll be much more restrictive than a VGM derived format, of course.

The music doesn't have to be done with a tracker style program. Sonic's format, I think it's quite good, does not seem to be derived from a tracker.

I could do the UI, perhaps even the whole thing if i either wrote a PSG emulator in VB6 (insanely hard) or used an external program like VGMPlay to do the conversion to audio for playback within VB6 (easy).

Sonic's format is straightforward, documented and capable, but music editing is last in my priority list. I have an assembler to make, a disassembly to piece together and a level editor to complete. A public build is at least a year away, if not two!

The assembler is going well for an initial start, despite being VB6 it currently tokenises 460K of code into 104'000 words in 0.1s. I don't think speed will be an issue, but it will be a slog to get to the fully assembled ROM stage.

sverx wrote

... from what I've seen the Z80 is very costly/slow at shifting bits so I guess a realtime Huffman-like decoding could be overkilling... or am I just wrong?

It certainly is slow, as you can only shift one place at a time and many of the shift opcodes are slower than 4 cycles. However, if you were traversing a Huffman tree you only want one at a time anyway, don't you? (It's a few years since I implemented such a thing.) Using add a, a you get optimal performance (for the Z80) of four cycles. Bitwise unpacking data is much more troublesome.

The hard part is that these aren't incremental changes to try, they're pretty big chunks of work just to see what happens. I wrote a Huffman encoder for graphics data and it worked out much worse than RLE, for example, even before attempting to write a decoder.

Author	Message
sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 14, 2014 11:03 am
	Oh, I see now what you mean. Actually I'm trying to keep everything (format and program) as simple as possible and even with that "sort of" LZ compression it's still very very simple. I'm anyway working on achieving a better compression through better code in my conversion/compression tool... I mean, complexity can be kept out...

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Fri Feb 14, 2014 11:26 am
Martin Joined: 04 Nov 2004 Posts: 273	I was already wondering how the compression works exactly. I have a decent understanding of LZ (I had to write my own ZLib variant because some console vendor did not allow 3rd party libs to be used), but I assume it's not the same, because you take repeated data from ROM, not from a runtime-dictionary in RAM?

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 14, 2014 12:49 pm
	I didn't even know I was doing something that could be somehow similar to LZ compression! LOL! How it works, actually: for each 'substring' of length 35 to 4 (decreasing) starting from Nth byte, I seek in the previous bytes (starting from beginning of array) if there's a match. How it should work instead: it should try somehow to maximize compression. I'm trying a different approach now which seems to shave some more... but it's still buggy :\|

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Feb 14, 2014 1:50 pm
	LZ covers mostly algorithms whereby you say "copy n bytes from location x". Normally x refers to somewhere in the decompressed data, but that's no good here because every byte is discarded as soon as it's "decompressed"; so instead it points into the compressed data. This can lead to tricksy things if you were to recurse. More specific algorithms, like Deflate as seen in zip/zlib, specify an actual implementation, generally with extras like Huffman coding of the data after compression.

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Fri Feb 14, 2014 2:05 pm
Martin Joined: 04 Nov 2004 Posts: 273	Yeah, this is one of the things I was wondering about - I thought previously you would point only into a dictionary that has only bare psg data without any repeat-commands. Do you allow such recursion, having repeat-commands within repeat-blocks? It could work well with music...

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 14, 2014 2:14 pm
	No, I'm not compressing recursively. It would require some sort of decompress recursion stack, which is something I feel a little too complex. Anyway making the compressor a bit smarter I could achieve to save another 260 bytes on my usual test file (I still didn't change any of the parameters like the substring max length)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 14, 2014 2:45 pm
	I would really need few more VGMs to test... some suggestions? I'd like one with could perform very bad on the compressor (some song that at least sounds very un-repetitive) and also one that appear to have long "pauses" (held notes ok, I mean long pauses in the data stream to the PSG chip...) Since I know very few SMS games I have no idea, so here's why I rely on you :)

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Fri Feb 14, 2014 3:05 pm
Calindro Joined: 14 Apr 2013 Posts: 624	sverx wrote I would really need few more VGMs to test... some suggestions? I'd like one with could perform very bad on the compressor (some song that at least sounds very un-repetitive) and also one that appear to have long "pauses" (held notes ok, I mean long pauses in the data stream to the PSG chip...) Since I know very few SMS games I have no idea, so here's why I rely on you :) The title song of Ultima IV sounds quite unrepetitive to me but it doesn't seem like there are VGMs available for this game... I'll try to think of another unrepetitive song! The title song of Asterix http://www.smspower.org/Music/Asterix-SMS has long held notes. Hope this helps! :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Feb 14, 2014 3:48 pm
	You'll get long pauses in the VGM data for music without vibrato or music envelopes, which basically means awful music. Try the handful of Colecovision soundtracks we have, Monopoly, or Alf. As for stuff that's complex: try Ristar and Gunstar Heroes - although they use GG stereo so after stripping that out they might sound a bit unbalanced. Also Wiwi Jumbo from Space Harrier, which seems to be algorithmically generated and never repeats, the VGM is just a reasonable subset of it.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 14, 2014 4:18 pm
	Calindro wrote The title song of Asterix http://www.smspower.org/Music/Asterix-SMS has long held notes. This has two "0x61 nn nn : Wait n samples" waits that aren't frame sync'd, has a GameGear stereo info (is it a GameGear game?) and, indeed, has quite all the spectrum of all the waits, from short to long and very very very long (at the end). Good catch, very useful! :D Maxim wrote Wiwi Jumbo from Space Harrier, which seems to be algorithmically generated and never repeats, the VGM is just a reasonable subset of it. That's a real test-beast! Thousands of waits that aren't frame sync'd, the sort-of-LZ compression tool takes 7 minutes (!!!) and the effect is: Info: input file size is 14070 bytes Info: output file size is 11568 bytes Unfortunately, because of those thousands of waits, the song becomes completely different... I think I have to round waits to the closest frame... let's see what I'll be able to do next days. Thanks!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Fri Feb 14, 2014 6:53 pm
	It looks like the Space Harrier VGM pack is not frame-accurate. There's a tool called "vgm_facc" which should do the conversion to frame-accurate timing for you. It lives here: http://vgm.mdscene.net/forum/viewtopic.php?t=207 However, when I tried it, it seems to struggle to find the correct timing offset. It might be better to re-dump the track for your testing. In the Asterix track, the funny times are only at the start and end of the file, as is the GG stereo initialisation. These can be rounded and ignored respectively.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Mon Feb 17, 2014 9:36 am Last edited by sverx on Mon Feb 17, 2014 3:17 pm; edited 1 time in total
	Following fellow forum users advices, I think I'll modify the file format allowing more code space for longer 'LZ' strings and less code space for reserved (which I think I'll actually use, at a later stage) and for long waits, which aren't so very common after all. So here's the planned new format - additional feedback is welcome again :) PSG simplistic approach (log of writes to SN76489 port) - No header - %1cct xxxx = Latch/Data byte for SN76489 channel c, type t, data xxxx (4 bits) - %01xx xxxx = Data byte for SN76489 latched channel and type, data xxxxxx (6 bits) - %00xx xxxx = escape/control byte (values 0x00-0x3f), see table #1 Table #1 0x0000 0000 - end of data [value 0x00] (compulsory, at the end of file) 0x0000 0001 - loop begin marker [value 0x01] (optional, songs with no loop won't have this) 0x0000 0nnn - RESERVED for future expansions [values 0x02-0x07] * PLANNED: GameGear stereo - the following byte sets the stereo configuration * PLANNED: event callback - the following byte will be passed to the callback function * PLANNED: longer waits (8-255) - the following byte gives the additional frames * PLANNED: compression for longer substrings (52-255) - followed by a byte that gives the length and a word that gives the offset 0x0000 1xxx & 0x0001 xxxx & 0x0010 xxxx & 0x0011 0xxx - COMPRESSION: repeat block of len 4-51 [values 0x08-0x37] This is followed by a word which is the offset (from begin of data) of the repeating block 0x0011 1nnn - end of frame, wait nnn additional frames (0-7) [values 0x38-0x3f] Said that, I'm planning to work on SFX integration. In my plans, SFXs are files very much like those used for background music but they should use channel 2 and/or 3 (noise) only. In the easier approach I can think the program fires the SFX giving the data address and a mask that indicates if the SFX will use channel 2 or 3 or both. Then I guess I will have to silence the background music going on on the channel(s) allocated to the SFX, play the SFX while the music goes on and re-activate the background music when the SFX is over. But to correctly reactivate the music I guess I have to log all the changes the music would send to the PSG on SFX allocated channels, right? My biggest doubt is how to log these changes easily and effectively. Again, any help on this is much appreciated!

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Mon Feb 17, 2014 10:27 am
Martin Joined: 04 Nov 2004 Posts: 273	Yes, store the last recent bytes that would have been written to channel 2 and 3 (that's just 3 or 2 bytes per channel). Edit: I think this is a little tricky here because data comes in just as bare bytes, with no info on whether it's volume or frequency. You'll have to detect what it is and store it accordingly. Care has to be taken of the noise channel. - The noise sequence has to be restarted always when the music resumes. Edit 2: Maybe it's worth to split this forum thread into two, with the second one about music only.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Mon Feb 17, 2014 2:00 pm
	Yes, it's really tricky... that's the reason I'm asking for some hints! about topic splitting... well, I can't do that myself, but I suggest to separate from this post of mine (Fri Jan 31) onward... edit: I edited the previous post, I forgot the "callback" planned feature :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Mon Feb 17, 2014 4:01 pm
	This topic has covered a lot of subjects but it's not easy to split it up much of the time as we'd need to also split individual posts, which we can't do :(

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Mon Feb 17, 2014 4:34 pm
	if it's possible to split from a given post onward (as it was on phpBB 2.x)... I already suggested the starting post in my previous post ;) (it seems the PSG "logging" it's working, now I'm working to stop sending the PSG data for chn 2-3 when marked 'busy'...)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Mon Feb 17, 2014 7:22 pm
	Hmm, phpBB2? Who would still be using that? :) I've done a bunch of splitting up by subject; sverx is now the proud starter of more than one topic.

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Tue Feb 18, 2014 12:29 am
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Personally, I think phpBB2 is still the best choice when it comes to something easy to customise, since you can do pretty much whatever you want with it.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Feb 18, 2014 8:47 am
	Maxim wrote Hmm, phpBB2? Who would still be using that? :) I've done a bunch of splitting up by subject; sverx is now the proud starter of more than one topic. Thanks! :D (and anyway I said "as it was on phpBB 2.x"... I'm no longer hacking on it, but back then I did a lot of customization...) now let's stop derailing this topic or we will need a new split :p

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Feb 18, 2014 3:37 pm
	Ok, I've got the first beta working! :) It's still a quite basic approach, but it plays a background music (in loop) and pressing the button 1 it fires a soundeffect (a simple one I did myself in few minutes using Mod2PSG2) on channels 2-3, keeping the music active on channels 0-1 and then reactivating the other two channels when the SFX ends or gets canceled (releasing the button 1). Since I don't want to spread that very early beta, fellow forum users who took part in this topic who might want to give it a try, please PM me for a download link (it's a 16KB ROM with more than 60% unused...)

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Wed Feb 19, 2014 6:08 pm
Martin Joined: 04 Nov 2004 Posts: 273	Well, it works fine so far. Remember if you have sound effects playing on channel 2 but not on the noise channel, the music can't use the channel 2 frequency feature of the noise channel. If you want to go more far with sound effects, you could implement looping ones.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Feb 19, 2014 6:25 pm
	Thanks! I know of that correlation between channel 2 and 3 when noise channel is set to use the tone of channel 2, and that's something I still have to address. Looping SFX support is planned to be in since first 'official' release :)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Feb 20, 2014 1:29 pm
	Ok, I think I'm at a good point. - the file format for both music and SFX is done, at least the minimum needed - there's a converter from VGM to PSG ("my" format) with a switch to filter only channel 2 and/or 3, for SFX. - there's a compressor, which is very very slow (approx. one minute per KB of original data on my PC) but it seems to do its work well, and it's even not compulsory to compress data, after all. - the library supports music on any channel, and SFXs on channel 2 and/or 3 (the music on these channels will disappear when SFX is playing and it will seamless resume when SFX is complete or canceled) - the library uses 34 bytes of RAM and in the worst condition I could try it required some 9% of CPU horsepower - SFX can be looping or normal (one-shot) - it seems to be working (LOL!) I'd like to upload the whole of it somewhere, for you all to check/comment/use/enhance... any hints? Some online repository (if it's not googlecode, better...)?

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Thu Feb 20, 2014 3:27 pm
Kroc Joined: 08 Dec 2013 Posts: 200	GitHub GitHub GitHub! :)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Feb 20, 2014 3:39 pm
	Kroc wrote GitHub GitHub GitHub! :) OK OK OK! :D Since I don't know how these things works, I will start with a test called "PSGplay" even if I actually don't like this name so much. (Does PSGlib sound too pretentious? mmm...)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Thu Feb 20, 2014 6:59 pm
	GitHub seems pretty awesome, it's just a shame you have to use Git :) Also note that you are implicitly using a liberal open-source licence if you use free hosting there, be aware of the consequences (others may use your code commercially, for evil, etc).

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 21, 2014 8:37 am
	for evil? :) I've seen they've got some licensing you can choose... I think GPL would be fine...

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Feb 21, 2014 9:36 am Last edited by sverx on Mon Mar 03, 2014 3:44 pm; edited 1 time in total
	It's here. By the way, how do I set the current version number? :\| How do I set the license? I couldn't find it anywhere :\| (sorry for being so newbie...) edit: ok I set the license. I choose a BSD so that homebrew using the library won't be forced to release source code too (which was compulsory with GPL, if I understool correctly). Feel free to comment on this too!

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Fri Feb 21, 2014 11:53 pm
Martin Joined: 04 Nov 2004 Posts: 273	It looks good, well commented, example program is simple enough. I had much less problems with GIT than with CVS/SVN in the past, so I'm glad you chose it.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Sat Feb 22, 2014 2:29 pm
	Thanks! Let me know if you find any bug or something that doesn't seem perfect :)

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Mon Feb 24, 2014 7:04 pm
Kroc Joined: 08 Dec 2013 Posts: 200	This is a great piece of work. With Sonic 1 level editor, music is an area totally outside of my experience, so I won't be able to provide a built in music editor for Sonic 1's music format. Now if I could replace the music engine with VGM playback then conceivably users could import any song they wanted into the game! This would be a huge boon! I'll look at this project in the future to check viability. Anything you can do to make the format as compact as possible and reliable (well tested with many VGMs) would be great.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 25, 2014 6:11 am
	It would be informative to export the entire Sonic soundtrack to this format and see how much space it took. If nothing else, paging is likely to be different to the original, as the engine and data won't all fit in a single bank.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Feb 25, 2014 9:28 am
	The format (I called that 'PSG' because I lack a better name) is quite compact compared to uncompressed VGM, not very compact if you compare with gzipped VGM, unfortunately. And I can't say this is surely suitable for your needs, actually. A PSG is about 1/3 of the corresponding VGM, but this varies too... The compression is very simple but not so effective, so if there are suggestions to make it much more effective I could surely apply them :) edit: Maxim, you mean this? I can try with those if you like. edit(2): I tried with those, there were no warnings at all in the conversion and the results are: uncompressed VGMs = 164 KB - biggest file 40KB uncompressed PSGs = 87,6 KB - biggest file 22KB compressed PSGs = 48 KB - biggest file 11KB

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 25, 2014 12:44 pm
	Kroc can confirm but I suspect Sonic's music engine and data (including SFX) come to just under 16KB. Switching format seems like it costs about x3 space. Does your engine play nicely with paging? How about within a track?

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Feb 25, 2014 1:14 pm
	Paging??? I wonder that it works, given all the bugs that I found yesterday and today!!! :D (seriously, now: no, the engine does no paging at all. I'm not planning to add that ATM but I can't exclude to do that later eventually...)

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Tue Feb 25, 2014 3:05 pm
Kroc Joined: 08 Dec 2013 Posts: 200	The driver runs from $C000 to $C715 (1'813 bytes) and the music / sfx data fills from $C7D0 to $FFB1 (14'305 bytes), so the driver/tables/music/sfx fill 1 bank with a few bytes to spare. The thing is that I'm porting Sonic 1 to 512K ROM so instead of one bank, it'll have two -- approx. 30KB of space for music, instead of 14. No internal paging in the driver would need be added as the game can set page 1 & 2 before calling the music driver. If the format can be improved to compact to 2x size then it would be feasible at least for implementation in Sonic 1.

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Tue Feb 25, 2014 3:09 pm
Martin Joined: 04 Nov 2004 Posts: 273	Paging is difficult... The easiest solution for now would be to use two slots for a max. size of 32KB. Have the music player in slot 0, data in slot 1 and 2. Having the code handle paging on the fly is nasty and slow, you'd have to check/update paging for every byte from the stream. Maybe someone can come up with clever tricks of how to do it.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Feb 25, 2014 3:32 pm
	There's something I miss... if the largest file is 11 KB and you anyway play one background music only a time, why would be paging needed for the engine in this case? Or you've got ROM constraints too?

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Feb 25, 2014 3:41 pm
	Kroc wrote If the format can be improved to compact to 2x size then it would be feasible at least for implementation in Sonic 1. I would love that... so far the best I can do is before your eyes. But I'm not an expert on compression, so if you've got suggestions I can try experimenting different methods...

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Tue Feb 25, 2014 4:14 pm
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Kroc wrote I won't be able to provide a built in music editor for Sonic 1's music format. Maybe I can look into that, if you give me a green light, and I can send you the vbp and stuff for a possible integration within your master editor. The format seems to be simple enough, so I might be able to do something nice. No promises, though.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 25, 2014 4:25 pm Last edited by Maxim on Tue Feb 25, 2014 5:29 pm; edited 1 time in total
	A tracker for a commercial game engine (and a pretty good one at that) is just what we need around here :) It'll be much more restrictive than a VGM derived format, of course. Regarding paging, it's pretty quick to check on each byte (just check for $c000), alternatively there's an upper limit on the number of bytes per frame, so you could split on chunks and only check once per frame, or even have an end of page signal in the music data. Or just don't support data over bank boundaries, you don't need to. What you will need to do is play music from one bank and SFX from another at the same time. That's why I think the player needs to be bank aware.

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Tue Feb 25, 2014 5:25 pm
Martin Joined: 04 Nov 2004 Posts: 273	Yes. Changing the data a little can make it more efficient. There's not much data in one frame, so it's not too slow anyway. There are different ways to check for the boundary efficiently, I'm not sure which one is the best here. If it's done only once per frame it won't matter much. Luckily SFX are going to fit into a single bank easily, paging is mostly relevant to music only.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 25, 2014 5:32 pm
	There's two issues with paging: track data crossing a page boundary, which is avoidable, and playing data from two banks at once, which is somewhat avoidable if you can page two banks at once. I'd rather pass the page number and offset to the player and have it select the banks itself, but it can also be blind to paging provided you can squeeze the playback code in the first 16KB. All these restrictions make the traditional single bank music engine with data much more convenient for programmers...

Martin Joined: 04 Nov 2004 Posts: 273	Posted: Tue Feb 25, 2014 7:53 pm
Martin Joined: 04 Nov 2004 Posts: 273	Maxim wrote A tracker for a commercial game engine (and a pretty good one at that) is just what we need around here :) It'll be much more restrictive than a VGM derived format, of course. The music doesn't have to be done with a tracker style program. Sonic's format, I think it's quite good, does not seem to be derived from a tracker.

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Wed Feb 26, 2014 12:11 am
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	True, but if I make the editor it will look like a tracker anyway, since I love trackers :U And I'd probably make it import XM files, too. Not sure if I'll take this task, though. I have some problems with my computers so this isn't the best time for me to do things.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Feb 26, 2014 10:10 am
	Yesterday evening I spent a good hour searching on the internet for alternative solutions for compressing my PSG files, but I didn't find anything suitable. The matter is that every library/algorithm I found do requires (on the decompression side) either some RAM (more than a couple bytes I mean) or to access some bytes already decompressed before, both of which I can't afford, since everything that is decompressed is sent to PSG chip at once. I thought that maybe if I would be able to compress shorter substrings too (actually the shortest is 4 bytes) and making the compressed code take less space (now it's taking 3 bytes) these could be useful for achieving better compression ratios, but I'm racking my brain to imagine how to achieve that. Any idea?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Feb 26, 2014 10:53 am
	If you can split the data by channel you will save two bits on every command - but packing the bits will complicate the code. However, even without that, I suspect you'd get much better compression because within a channel there will be much more repetition. The cost will be the need for timing info in all four streams, so it's not a guaranteed win. Something like this: two control bits, to specify volume, frequency, timing or control commands, followed by as many bits as necessary. Thus volume commands take 6 bits, frequency 12, timing could use a variable number of bits to optimise for the most common lengths. You can then do bitwise lookback for LZ runs. Commands would be used for the LZ references, loop jumps, and whatever else is needed, again being dial with the bits. You might choose to pull the raw data out into a separate blob from the main data stream, and thus turn the entire playback steam into references to this "dictionary". This might make the references shorter, especially if you applied some Huffman coding to them so common ones were encoded in fewer bits. Or even put the whole dictionary inside the Huffman tree. Next stream of thought idea: maybe Huffman coding would be a big win on its own, as the number of values used is pretty small (few games use the 10 bit frequency range very uniformly). Maybe encoding volume and frequency changes as the delta values would increase the compressibility, particularly with Huffman again. Regarding general compression, it is tricky because few algorithms are designed for low memory use and no read access to the uncompressed stream. Some of the graphics compression algorithms on the Matter System might be useful, as they tend to avoid reading back the uncompressed data, but I don't think any of the ones I know of will help here - they're either basic RLE or much more oriented to the data format.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Feb 26, 2014 11:14 am
	Thanks for the good hints, unfortunately I was already thinking at most of them and I'm not so sure they'll perform well enough to eclipse the actual system (since I believe it would be not a good idea to over-complicate everything for shaving off some more 60 bytes from a 2KB file, right?). The biggest concern I have is about manipulating bits (instead of whole bytes) on the SMS... from what I've seen the Z80 is very costly/slow at shifting bits so I guess a realtime Huffman-like decoding could be overkilling... or am I just wrong?

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Wed Feb 26, 2014 12:57 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Martin wrote Maxim wrote A tracker for a commercial game engine (and a pretty good one at that) is just what we need around here :) It'll be much more restrictive than a VGM derived format, of course. The music doesn't have to be done with a tracker style program. Sonic's format, I think it's quite good, does not seem to be derived from a tracker. I could do the UI, perhaps even the whole thing if i either wrote a PSG emulator in VB6 (insanely hard) or used an external program like VGMPlay to do the conversion to audio for playback within VB6 (easy). Sonic's format is straightforward, documented and capable, but music editing is last in my priority list. I have an assembler to make, a disassembly to piece together and a level editor to complete. A public build is at least a year away, if not two! The assembler is going well for an initial start, despite being VB6 it currently tokenises 460K of code into 104'000 words in 0.1s. I don't think speed will be an issue, but it will be a slog to get to the fully assembled ROM stage.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Feb 26, 2014 1:12 pm
	sverx wrote ... from what I've seen the Z80 is very costly/slow at shifting bits so I guess a realtime Huffman-like decoding could be overkilling... or am I just wrong? It certainly is slow, as you can only shift one place at a time and many of the shift opcodes are slower than 4 cycles. However, if you were traversing a Huffman tree you only want one at a time anyway, don't you? (It's a few years since I implemented such a thing.) Using add a, a you get optimal performance (for the Z80) of four cycles. Bitwise unpacking data is much more troublesome. The hard part is that these aren't incremental changes to try, they're pretty big chunks of work just to see what happens. I wrote a Huffman encoder for graphics data and it worked out much worse than RLE, for example, even before attempting to write a decoder.

Forums

View topic - PSGlib 'official' topic [was: "Music engines"]