vgmrips

The zlib compression should do a good job at reducing the file size caused by repetitive wait / chip commands.

Dividing the sample rate (if the CPU clock is used) is already assumed, I think. Consider that the 68K and Z80 (for example) have fixed memory cycles and can't hammer memory (and thus sound chips) every cycle anyway.

The reason why I mentioned inserting a marker is because you can then use that marker to optimize files. For example, some sound drivers are interrupt-based, so they only write to the chip when a timer interrupt occurs, so that would help to find loops and to close the sample gaps between chip writes.

With the current format, I guess one can insert a zero-sample wait 0x61 0x00 0x00 as a marker. Perhaps emulators can be modified to insert such a marker if the CPU receives an interrupt, such as the vsync interrupt in a ZX Spectrum? And then that would help find loops and optimize perhaps.

_________________
vampi.tech

Mmyeah, as usual I’m thinking about my MSX player… Currently I decompress the entire file in memory so the unzipped size still matters to me. And also more bytes to process means less performance, a second 2-byte command would simply be caught by the jump table at no extra cost, while an extra port byte will require an extra buffer read, compare and branch to process. It’s not the end of the world but it’s still something that I think about.

(As for decompressing the entire file to memory, for a long time I have on my wishlist to decompress on the fly to a small buffer (and snapshot the decompressor at the loop point), but as you can imagine this is not trivial to implement.)


What do you mean by assumed?

The Z80 has a variable number of cycles per instruction, indeed never less than 4 cycles, but usually not a multiple of 4, so it’s not quantisable.

please add support for namco wsg

vampi edit: added magic word

_________________
be a hero and stop coppa now!
http://chng.it/DNc2L8LvLJ

i don't know how valid this suggestion is:

using 0x64 as multiples of 0x62 delays, and 0x65 as multiples of 0x63 delays meaning:

0x64 0x03 as the same as 0x62 0x62 0x62 0x62 0x62
and
0x65 0x03 as the same as 0x63 0x63 0x63 0x63 0x63

0x03 because, if no multiples nothing would be used, if just one multiple would be the same as the original shortcut, and using 0x02 would be at least 2 multiples - 2 multiples (0x00) + 0x03 would result into those 5 multiples shown above

taking 0x64 (based on 0x62 as example) would be:
0x64 0x00 - 2 multiples of 0x62
0x64 0xFF - 257 multiples of 0x62

i think this would result into vgm files a bit smaller, and easier to be read and performed from more limited hardware (lke 8bit computers and game consoles)

I have had a skim through the thread. A lot of this goes over my head, but it's exciting to know many interesting ideas are being thrown around. To be completely honest, I had no idea the degree to which a successor format had been discussed.

This is probably an obvious and more simple consideration for 2.0, but I have to make sure it gets mentioned: more robust tags! Ideally the full gamut of what ID3 tolerates, including custom tags. I personally have this problem resolved on desktop foobar2000 by using External Tags for all of the media that foobar2000 plays, but when it comes to VGMs in mobile foobar2000, External Tags aren't supported there (at least not yet, who knows if they ever will be?) so the internal VGM tags remain important to functionality. One very obvious example of where they become insufficient is soundtracks which have multiple composers/artists. Without an album artist tag, I have (for example) five X-Men Arcade soundtracks in my phone's media library, split apart by artist. The lack of track numbers is also a problem on mobile, where VGMs are sorted alphabetically by title instead. I'm sure missing tags create other kinds of problems as well.

_________________
http://iridescentaudio.co.uk

Too many replies to look through before posting. My suggestion: divide the VGM file into multiple concurrent data streams: one for each chip with independent timing based on each chip's clock.