Forums

Not sure who mantain the VGM format now, so I just post it here.

There are special tags to wait 735 or 882 samples, which is very helpful. There is support for many chips from different systems, including ones that were used in arcades, so generally it is possible to have update rate other than 50 or 60 hz. For this case, it would be nice to have a tag to wait custom number of samples.

I imagine it this way:

- a tag to set up number of samples per wait. You just specify a number after this, like 735 or 882 or anything, this setting is remembered
- a tag to wait the number of samples that was set by previous tag

So you can use the first tag once at the beginning of the song, and then use second tag the same way as 0x62 or 0x63 used now.

How about additional fields in the header that lets you override the length of 0x62 and/or 0x63? Or do you still need them to have their original meaning for your purposes?

For my purposes it would be enough to have a header field that defines number of samples in 0x62/0x63, indeed.

This is a great idea. Having a special wait command for the most used values can save several bytes throughout all the song.

Currently I'm mantaining the VGM format.

I actually like the idea of overriding the length of 0x62/0x63 commands. (although, IMO, 'a few bytes' don't make the file a lot smaller when it already has 200 KB - I'm already satisfied when I cut the file size from 16 MB to 160 KB)

I'd use a new command like this:

0x64 cc nn nn : override length of 0x62/0x63
cc - command (0x62/0x63)
nn - delay in samples

That's more flexible than a header value and should be fairly easy to implement in players and tools.

Any other suggestions? (Maybe larger delays by using cn nn nn?)

Btw: I currently plan to add an additional "Header Extention" field. (would be in v1.70) This field will contain pointers to various other fields. (ideas would be 2nd chip clocks and chip volumes)

16-bit nnnn should be enough, because it is a second already - don't think that songs with many delays of this length are common.

I actually waited for sth. like "Yes, do it this way. So we can save 2 whole bytes of a 175926 byte vgm in the rare case of a long delay at the end!" ;)

Also I wanted to let you know that this would be technically possible.

btw: I don't really want to use such features on e.g. YM2413 vgms, because it breaks compatibility with old players. (and compatibility is a little more important to me than smaller files)

...

I think it can be useful - especially for exporting VGMs, because you know what delays you can have.
I already inserted it into the vgm spec (the code above is a c&p from my WIP vgmspec), so it will be supported with v1.70.

Author	Message
Shiru Joined: 08 Oct 2006 Posts: 35 Location: Russia, Moscow	A feature for VGM format Posted: Sun Nov 13, 2011 4:34 pm
	Not sure who mantain the VGM format now, so I just post it here. There are special tags to wait 735 or 882 samples, which is very helpful. There is support for many chips from different systems, including ones that were used in arcades, so generally it is possible to have update rate other than 50 or 60 hz. For this case, it would be nice to have a tag to wait custom number of samples. I imagine it this way: - a tag to set up number of samples per wait. You just specify a number after this, like 735 or 882 or anything, this setting is remembered - a tag to wait the number of samples that was set by previous tag So you can use the first tag once at the beginning of the song, and then use second tag the same way as 0x62 or 0x63 used now.

mic_ Joined: 27 May 2008 Posts: 154	Posted: Sun Nov 13, 2011 5:10 pm
mic_ Joined: 27 May 2008 Posts: 154	How about additional fields in the header that lets you override the length of 0x62 and/or 0x63? Or do you still need them to have their original meaning for your purposes?

Shiru Joined: 08 Oct 2006 Posts: 35 Location: Russia, Moscow	Posted: Sun Nov 13, 2011 5:12 pm
	For my purposes it would be enough to have a header field that defines number of samples in 0x62/0x63, indeed.

Tom Joined: 16 May 2002 Posts: 788 Location: italy	Posted: Sun Nov 13, 2011 6:54 pm
Tom Joined: 16 May 2002 Posts: 788 Location: italy	This is a great idea. Having a special wait command for the most used values can save several bytes throughout all the song.

ValleyBell Joined: 15 Sep 2009 Posts: 314	Posted: Mon Nov 14, 2011 3:25 pm
ValleyBell Joined: 15 Sep 2009 Posts: 314	Currently I'm mantaining the VGM format. I actually like the idea of overriding the length of 0x62/0x63 commands. (although, IMO, 'a few bytes' don't make the file a lot smaller when it already has 200 KB - I'm already satisfied when I cut the file size from 16 MB to 160 KB) I'd use a new command like this: 0x64 cc nn nn : override length of 0x62/0x63 cc - command (0x62/0x63) nn - delay in samples That's more flexible than a header value and should be fairly easy to implement in players and tools. Any other suggestions? (Maybe larger delays by using cn nn nn?) Btw: I currently plan to add an additional "Header Extention" field. (would be in v1.70) This field will contain pointers to various other fields. (ideas would be 2nd chip clocks and chip volumes)

Shiru Joined: 08 Oct 2006 Posts: 35 Location: Russia, Moscow	Posted: Mon Nov 14, 2011 3:29 pm
	16-bit nnnn should be enough, because it is a second already - don't think that songs with many delays of this length are common.

ValleyBell Joined: 15 Sep 2009 Posts: 314	Posted: Tue Nov 15, 2011 8:14 am
ValleyBell Joined: 15 Sep 2009 Posts: 314	I actually waited for sth. like "Yes, do it this way. So we can save 2 whole bytes of a 175926 byte vgm in the rare case of a long delay at the end!" ;) Also I wanted to let you know that this would be technically possible. btw: I don't really want to use such features on e.g. YM2413 vgms, because it breaks compatibility with old players. (and compatibility is a little more important to me than smaller files)

Wraithverge Joined: 28 Oct 2011 Posts: 23 Location: Ethereal Plane	Posted: Wed Nov 16, 2011 2:29 pm Last edited by Wraithverge on Thu Nov 17, 2011 6:54 pm; edited 1 time in total
	...

ValleyBell Joined: 15 Sep 2009 Posts: 314	Posted: Thu Nov 17, 2011 8:26 am
ValleyBell Joined: 15 Sep 2009 Posts: 314	I think it can be useful - especially for exporting VGMs, because you know what delays you can have. I already inserted it into the vgm spec (the code above is a c&p from my WIP vgmspec), so it will be supported with v1.70.

Forums

View topic - A feature for VGM format