Journey sound sample in mame2003-plus, solved

mahoneyt944

@arcadez2003 I'm using a rpi3b+, the sample works in 2010 fully. I had to use audacity to cut the sample from 3:03 to 1:50 for it to work in 2003plus. Then saved it as 16 bit mono. It started as 32 float mono. Cutting it down makes it work. If not I get a screech that crashes the emulator.

The volume thing is tricky because you have mixer volumes and levels and the sample volume. I'm not sure exactly why but if set to 100, I can hear it but the other game sounds are much louder. If I set it to 10,000 it hits clipping. If I set it to 5000 I get clipping. 2000 is too loud, 1500 is slightly too loud, 1000 is probably just right.

grant2258

this mame wont use stereo samples only mono you need to save each channel

mahoneyt944

@grant2258 Im pretty sure it's right. I got it from here http://www.progettosnaps.net/samples then I used audacity to cut it down more. The sample won't work in 2003plus if it's 3 minutes long. But it does works at 1:50 just fine (audacity- export wav 16 bit). So it's a space issue I think. 1:55 crashes.

grant2258

aarg ive done it now i cant even check the size of the ost samples i forgot to back them up when i updated retropie. I have no idea where to download them now to check the sizes its using

Riverstorm

To much quarantine-time...or something...

I was messing with the sepways.wav sample and you can get it pretty small and still keep it sounding decent. It's a mono channel sample. I used Foobar with SoX to resample. I tried it 4 ways.

Samples 2 and 3 I've always struggled to hear the difference depending on the source audio. You're basically trading off the sample rate (44100 Hz) for bits per channel (8/16-bit) as both sound pretty decent but a higher sample rate will have a larger frequency range but less samples which basically translates to more background "noise".

So even though you have a larger frequency range to hit the highs/lows it might sound slightly "muddy". Both sound good but I prefer the 44100Hz/8-bit between the two. Someone with better equipment or ears might hear a difference! =/

Number 4 at under 4MB actually sounds pretty decent but with an ever slight distortion but not bad at all. I can upload them if you want to try a smaller file.

Depending your speakers and hearing frequency range it could make a difference (or none) to what you hear as highs and lows usually go first and we're mainly cutting out the higher frequencies. I'm sure I've done some damage in my early years at concerts but at some point in there I started wearing plugs! ;)

44100 Hz, 16-bit, 1 channel - 15.4MB (Original WAV)
44100 Hz, 8-bit, 1 channel - 7.73MB
22050 Hz, 16-bit, 1 channel - 7.73MB
22050 Hz, 8-bit, 1 channel - 3.86MB

grant2258

i managed to find the ost samples moonwalker has a 24 meg sample and works fine

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