vgmrips

The forum about vgm files
It is currently 2021-04-16, 1:42:46

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
 Post subject:
PostPosted: 2018-10-24, 9:58:54 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 457
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.


Top
 Profile  
 
 Post subject:
PostPosted: 2018-10-24, 18:13:52 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 721
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


Top
 Profile  
 
 Post subject:
PostPosted: 2018-10-24, 21:03:15 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 145
ctr wrote:
The zlib compression should do a good job at reducing the file size caused by repetitive wait / chip commands.

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.)

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.

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.


Top
 Profile  
 
 Post subject:
PostPosted: 2019-04-17, 18:47:54 
Offline

Joined: 2019-04-13, 15:38:34
Posts: 51
please add support for namco wsg

vampi edit: added magic word

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


Top
 Profile  
 
 Post subject:
PostPosted: 2020-10-20, 20:09:37 
Offline
User avatar

Joined: 2016-02-16, 12:54:37
Posts: 108
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)


Top
 Profile  
 
 Post subject:
PostPosted: 2020-10-24, 16:37:14 
Offline
User avatar

Joined: 2012-12-21, 15:30:24
Posts: 78
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.

_________________
http://iridescentaudio.co.uk


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
[ Time : 0.016s | 17 Queries | GZIP : On ]