Journey sound sample in mame2003-plus, solved

Riverstorm

@grant2258 - Then size doesn't matter...the samples! ;)

I think some of these OST's are much larger than they should be and look to have been up-converted. It could be the actual OST CD's were a poor quality source. You just never know these days. Some of these commercial sites sell up-converted low quality FLAC's as lossless.

Looking at the Moonwalker samples. Bad-01.wav (49.6MB) shows as 44100 Hz 16-bit. Basically CD quality audio but when you look at the spectrogram below it's more like a 128kbps MP3 even though it's the size of a lossless audio WAV.

Riverstorm

Here's a spectrogram of the original song Bad from his Number Ones CD which looks like a victim of the loudness wars and a low dynamic range. The original album has a much larger dynamic range. Looking at the graph basically the whole song is one volume level from beginning to end but does reach 22kHz.

The size is 41.5MB (smaller than the OST) but it is a true 44100 Hz 16-bit rip. I don't know the size of each channel once you break them out. I would guess the OST file which is almost 10 minutes should be around 100MB in true CD quality stereo, the size they are now.

The OST samples have a lot of wasted space and are much larger than need to be. I think they could be easily resampled at a lower sample rate (the actual rate) without loosing any quality but reducing the size if they cause any issues in the core.

Riverstorm

Looking through a bunch of the OST samples. They are mostly larger like what you would expect from a true CD rip but the quality looks to be around 15 or 16 kHz which would be more equivalent to a 128kbps MP3.

Here's some spectrograph screenshots below from Double Dragon, Final Fight and Outrun. You can see a line around 15/16 kHz that goes straight through the graph. Which is probably the actual quality. Everything above that line is pretty much garbage, white noise or static from ripping/upconverting.

They definitely could be smaller samples or if they were stay the same size the quality should be better depending on the original source. It's not a big deal but mostly just wasted space in the WAV/FLAC files and the file properties will reflect higher quality audio than they actually are.

Double Dragon:

Final Fight:

final fight.JPG

Outrun:

grant2258

Problems is there are so many samples kicking about and being changed you dont know what your going to get would be best to rip from a cd for moonwalker!

mahoneyt944

@grant2258
So why is it that this journey sample works in 2010 but not 2003plus? It's a mono track? Journey . The only thing I see is that it opens as 32 float in audacity. If I cut the time to 1:50 then export it as wav 16 bit it works in 2003plus but at the cost of not having the whole song.

Are you guys testing a sample that fully fits? Or are you just cutting it to 8 bit to fit? If you have a working version what file size is it?

@Riverstorm you can link your 8 bit version, I'll try it. But this seems like something we need to update like mame2010 did since it works with it. It seems like it needs allotted more memory to fit larger files, journey is probably one of the largest samples mame uses or close to it. So if that works mostly everything else should too.

From what I could tell, the samples are all read into memory then are able to be called at any time. I think that journey sample just over loads the memory and eventually crashes the system.

grant2258

The sample works fine i tested it on final fight you problems is else where. Do this on retropie in the bios folder make the following directories mame2003-plus/samples/ffight
copy the sepways.wav there and rename it too track02-01.wav

start final fight put the the cheats on and listen it play from start to finish it will start on the first level dont pass this level or you'll get the normal music because you missing the other samples.

mahoneyt944

@grant2258 interesting, if you take the journey sample from the link and test it in the journey service menu under cassette, do you get the same screech then crash after a few seconds I'm experiencing?

grant2258

well thats the sample tested is working fine

mahoneyt944

@grant2258 hmm well that's a good test anyhow. We must not be setting the parameters up right in our driver.

I saw this in common.h that looked interesting, but I'm just browsing through files. Game sample large caught my eye.

struct GameSamples
{
	int total;	/* total number of samples */
	struct GameSample *sample[1];	/* extendable */
};
 
#define	GAME_SAMPLE_LARGE		10000000 // 10MB

grant2258

thats stuff we added during adding flac support

mahoneyt944

@grant2258
Let's find the difference in cps1.c to our mcr2.c if the sample works there. The first difference I see is the attribute supports stereo. Final fight is using 2 channels.

grant2258

thats not a issue it support 2 mono samples for stereo if you have them both else it plays the one mono sample in both channels. Again this is part of the ost flac support update. Have you debugged it at all to see where its crashing?

mahoneyt944

@grant2258 no, I'm at work so I can't right now. What happens though is when I go to the service menu and enter the cassette test menu. When I flip the up button to start the cassette I hear screeching. If I press down it stops. If I let it play eventually after about 30 seconds it crashes the emulator and throws me to emulationstation. So I took that sample, opened it in audacity cut it to 1:50 (originally 3:03) then exported it as .wav 16 bit pcm. I retest the above senario and the sample works just fine. So next I try the cut sample at 1:55, this time I get the screech and crash. For some reason it doesn't like the sample size over a certain size.

But then you got the sample to work through final fight, so I really don't know. It must be related to how we are initiating the sample with the mcr driver? Maybe the output is wrong, 2010mame looks like this:

static DRIVER_INIT( journey )
{
	mcr_init(machine, 91475, 91464, 90913);
	mcr_sound_init(machine, MCR_SSIO);

	ssio_set_custom_output(4, 0x01, journey_op4_w);
}

And our 2003plus wip

static DRIVER_INIT( journey )
{
	MCR_CONFIGURE_SOUND(MCR_SSIO);
	install_port_write_handler(0, 0x00, 0x00, mcr_control_port_w);
	install_port_write_handler(0, 0x04, 0x04, journey_sample_select_w);

	mcr12_sprite_xoffs = 0;
	mcr12_sprite_xoffs_flip = 0;
}

grant2258

to be honest i just compiled it a while back and got the same result not really looked into it much yet cold be anything need to see where its segfaulting to get a clue else your just guessing. The driver is completely different to the one we are using

mahoneyt944

@grant2258 yeah that's the next step.

skj

Have you tried the sample at Twistys mame samples?

mahoneyt944

@skj I think it's the same sample from what I can tell

grant2258

https://github.com/libretro/mame2003-plus-libretro/blob/0134c428b75882aa474f78dbbf2c6ecde49b97b7/src/common.c#L302

comment this for now and change it to if(1) something else must be triggering this will need to follow the code at some point this code.

mahoneyt944

@grant2258 that's what I was looking at earlier but passed it when you said about in being flac related. Does that fix the issue with the sample loading? Can't we just raise the GAME_SAMPLE_LARGE to fit our sample it's capped at 10 mb and our sample is 15+

grant2258

I think i know what the problem is there is a flag that checks if contents is ost sample

https://github.com/libretro/mame2003-plus-libretro/blob/0134c428b75882aa474f78dbbf2c6ecde49b97b7/src/sound/samples.c#L32-L45

will check it later on i would guess this is the issue with using big samples like this.