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.
VGM 2.0 suggestions / ideas
orig. title: Multiple AY chips with stereo
Technical discussion about the VGM format, and all the software you need to handle VGM files.
Moderator: Staff
- vampirefrog Offline
- Webmaster
- Posts: 1508
- Joined: 2014-01-28, 5:51:54
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.
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.
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.ctr wrote:The zlib compression should do a good job at reducing the file size caused by repetitive wait / chip commands.
(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?ctr wrote: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 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
vampi edit: added magic word
be a hero and stop coppa now!
http://chng.it/DNc2L8LvLJ
http://chng.it/DNc2L8LvLJ
- nitrofurano Offline
- Posts: 115
- Joined: 2016-02-16, 12:54:37
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)
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)
- blitzlunar Offline
- Posts: 127
- Joined: 2012-12-21, 15:30:24
- Location: UK
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.
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.
Re: VGM 2.0 suggestions / ideas
Hi, I also did a new spec... It's completely different from current VGM, though. https://github.com/LTVA1/NuVGM
We worked with ValleyBell on this. I don't think I alone have enough time and programming experience to make the player (and ripper btw) and it compile-able automatically on github actions for every OS and for it to work as library or standalone app.
I don't know if I will receive any notification about a reply there, so better send the message there AND in my DM.
We worked with ValleyBell on this. I don't think I alone have enough time and programming experience to make the player (and ripper btw) and it compile-able automatically on github actions for every OS and for it to work as library or standalone app.
I don't know if I will receive any notification about a reply there, so better send the message there AND in my DM.