VGMPlay for MSX

Page 39/47
32 | 33 | 34 | 35 | 36 | 37 | 38 | | 40 | 41 | 42 | 43 | 44

By Pencioner

Paladin (933)

Pencioner's picture

05-02-2019, 20:51

Grauw wrote:
Pencioner wrote:

(i will explain in more detail later if there's need of it).

Would be appreciated to have more detail. I need to know how the C2 works so I can see which parts are similar and which parts are different, and what I need to do to distinguish them from each other.

I'm trying to find some time for recalling and writing it down. I hope i can do maybe at this weekend Smile

EDIT: Sorry i read later that you have found the info at the C2 docs - then i don't need to explain. Yeah...

By Parn

Champion (403)

Parn's picture

06-02-2019, 11:47

Grauw wrote:
Parn wrote:

(MegaRAM support on VGMPlay)

Hmm, it would complicate the mapped buffer to support different mapper types. I think for me the priority is to invest in reducing the memory requirement by doing this or this. But you can file a ticket on the project page, that way the idea won’t get lost.

Thanks, I will follow your advice. I might take the opportunity to make a couple extra suggestions as well. :) Just a question: would any of those be helpful with Mega Drive VGMs? Currently they seem the most memory-hungry VGMs I've seen, even more than SCC ones.

Graw wrote:
Parn wrote:

What about VGMPlay? Can it use all available memory mappers transparently or does it just pick one?

It uses all mappers that are found by DOS2.

Oh, I see. I'm sorry by my ignorance. Actually I had no idea how that worked and I was expecting something more complicated before checking out the DOS2 documentation at the MSX Assembly Page. Great resource, by the way, I use it all the time. Thank you very much.

By Grauw

Ascended (8406)

Grauw's picture

11-02-2019, 20:25

Pencioner wrote:

@Grauw i had MMM detection false positive with Carnivore 2 - after some investigation and looking into docs of MMM and into source code of the FPGA firmware of C2 i found out that it uses same mapper control logic as MMM (i will explain in more detail later if there's need of it). So basically vgmplay plays DCSG tunes when MMM is in lower slot than C2 but other way around it has false positive and there's no sound (because SN chip activation sequence reaches C2 not MMM so chip is silent)

Pentarou wrote:

Yes, the problem is caused by my Carnivore2.

I just pushed a change which detects and ignores the Carnivore2 when attempting to find an MMM.

Parn wrote:

Thanks, I will follow your advice. I might take the opportunity to make a couple extra suggestions as well. Smile Just a question: would any of those be helpful with Mega Drive VGMs? Currently they seem the most memory-hungry VGMs I've seen, even more than SCC ones.

Thanks! Yeah, unfortunately it won’t help MegaDrive VGMs. The sample data can’t be discarded since the OPN2 PCM data is all streamed from RAM by the CPU. It will help for chips with sample RAM such as for the MSX-AUDIO, OPL4, OPNA or OPNB. And the decompression on the fly will be disabled for OPN2 with samples, because the CPU won’t have time remaining for it due to the sample streaming.

There are quite sizable OPNB and OPM VGMs too, though.

By Grauw

Ascended (8406)

Grauw's picture

11-02-2019, 20:35

I’ve just made a release candidate build for VGMPlay 1.3. Check here for the preliminary list of changes. Can I ask all who would like to help out to thoroughly test this build, with all sound chips you can get your hands on?

Get the 1.3-rc1 build here.

If you find an issue in the coming days, I may still be able to resolve it before the final release.

By Manuel

Ascended (15697)

Manuel's picture

11-02-2019, 22:34

Great news, Grauw! Smile I'd love to hear some demo at the fair!

By Parn

Champion (403)

Parn's picture

12-02-2019, 13:13

Grauw wrote:

If you find an issue in the coming days, I may still be able to resolve it before the final release.

I'm looking forward testing it! Smile

Just a small question: when emulating DCSG on PSG, do you do any amplitude conversion? I mean, the logarithmic curves of the DCSG and the PSG are different, do you account for that difference? By listening and looking at the source code I'm under the impression that you don't. Do you think that's possible and/or desirable?

EDIT: If so, I can provide some data, since I made some tables to satisfy my own curiosity about the subject. Nothing special, honestly.

By Grauw

Ascended (8406)

Grauw's picture

12-02-2019, 18:15

No I don't. I think the DCSG is -2dB per step and the PSG is -1.5dB per step, right? I suppose I could, however I don't think the difference is significant enough to make a big difference? (Feel free to prove me wrong of course Smile.)

By Parn

Champion (403)

Parn's picture

12-02-2019, 20:09

Both manuals don't make it very clear, but the DCSG is -2dB amplitude per step, while the PSG is actually -3dB amplitude per step (-1.5dB power per step). I checked the Wikipedia table against the Yamaha table, which has some of the values written out, and calculated the remaining values myself to see if they matched. The tables I created are here:

Sound chips volume to amplitude tables

So a closer match would be:

   DCSG      PSG
Attenuation Level
     0   ->  15
     1   ->  14
     2   ->  14
     3   ->  13
     4   ->  12
     5   ->  12
     6   ->  11
     7   ->  10
     8   ->  10
     9   ->   9
    10   ->   8
    11   ->   8
    12   ->   7
    13   ->   6
    14   ->   6
    15   ->   0

I will craft a small proof of concept later today. At low amplitude levels it's very had to discern any differences, but I think they're very audible at higher levels.

By Parn

Champion (403)

Parn's picture

12-02-2019, 22:08

Ok, I think this makes a decent case for amplitude conversion:

  1. Gradius POC (DCSG Version)
  2. Gradius POC (PSG Version)
  3. Gradius POC (DCSG on PSG Version)

The first version was made with SnevenTracker, a tracker for DCSG based on FamiTracker. The second and third versions were made with 0CC-FamiTracker, a tracker for NES which supports the PSG as the Sunsoft 5B. The second used the exact same instrument definitions as the first version, while the third used the same table in the posting above, in order to try to "emulate" the DCSG dynamic output on the PSG. All these were normalized.

I think the difference between versions 1 and 2 is very noticeable, while the difference between versions 1 and 3, while still noticeable, is not as dramatic. What do you think?

By Grauw

Ascended (8406)

Grauw's picture

13-02-2019, 16:06

I see, thanks for the good example Smile. I’ll see if I have some time to do some tests and still address this before the release.

Page 39/47
32 | 33 | 34 | 35 | 36 | 37 | 38 | | 40 | 41 | 42 | 43 | 44