search

vgmrips / vgmtools

A collection of tools for the VGM file format
GNU General Public License v2.0
118 stars 18 forks source link

vgm_sro cannot handle OPL4 using custom ram pcm #10

Closed denjhang closed 3 years ago

denjhang commented 3 years ago

I am studying MSX Moonsound recently, and used openmsx to extract a lot of OPL4 VGM, I found that using the latest version of vgm_sro can handle most of the captured vgm, but the following file cannot be processed. opl4 ram pcm.zip

ValleyBell commented 3 years ago

It can not optimize OPL4 RAM when the VGM writes every byte with a single command.

You need to trim the file first, stripping all the silence from the beginning. This will coalesce all the single-byte RAM write commands into one large "OPL4 RAM data block", which can be optimized.

ValleyBell commented 3 years ago

Okay, it should just "do nothing" in this case. (and maybe strip off the initial OPL4 RAM block) A crash is definitely bad.

I fixed the crash with c1faf51ebd86069418eb7e3b9fc8d300c89b0337.

denjhang commented 3 years ago

If I trim the file first and delete all the silence from the beginning, the instrument will be missing or abnormal. How can I solve this?

ValleyBell commented 3 years ago

You need to carefully trim at a point where the song didn't set up its intruments yet. This point is usually a bit earlier than the first change of the waveform in a rendered WAV.

In timesup_optimized.vgm, the optimal start sample is 2600982.

I usually make a vgm2txt of the song up until 5 seconds after the beginning of the song. 

VGM Text Writer
---------------
File Name:      R:\timesup_optimized.vgm

Start Time:     0
End Time:       1:05

In the text file, I search for the beginning of the song. According to the WAV render, this is at 00:58.98. Then I go back in the text file until I see a larger "wait" command and pick that time. (I usually go for something >= 100ms. Maybe >= 1 second if I want to be sure.)

0x00187E27: 61 FF FF    Wait:   65535 samples (   1486.05 ms)   (total  2550502 (00:57.83))
0x00187E2A: 61 AB 7F    Wait:   32683 samples (   741.11 ms)    (total  2583185 (00:58.58))
0x00187E2D: D0 02 02 10 YMF278B:    Port 2 Reg 0x02 Data 0x10
0x00187E31: 61 85 45    Wait:   17797 samples (   403.56 ms)    (total  2600982 (00:58.98))
0x00187E34: D0 02 54 01 YMF278B:    Port 2 Reg 0x54 Data 0x01
0x00187E38: 75          Wait:    6 sample(s) (   0.14 ms)   (total  2600988 (00:58.98))
0x00187E39: D0 02 55 13 YMF278B:    Port 2 Reg 0x55 Data 0x13

Here I would pick either 2583185 or 2600982.

Small note: The last release of vgm_trim is unfortunately outdated. Trimming VGMs with OPL4 RAM only works properly when building the GitHub version from source.

denjhang commented 3 years ago

understood. Building the GitHub version from source is not a problem, I have already done it.