Samples missing in the DAT file

[Wilstorm]

@mahoneyt944 - It looks like somewhere in one of the updates the DAT was changed and all the clone samples were removed but the sample header tags left in place. In order to build a set properly, if using ClrMamePro, ROMVault, RomCenter, DatUtil, etc. is having that information available in the DAT.

You can't verify the set without it as the clones have no information for comparison and the parent doesn't need it. It makes the sampleof tag useless in the game headers. Basically the samples have been deprecated and incomplete. You'll get a false-positive when building a set. Also if you pull like dkong Japan only sets with DatUtil or whatever it will also see them as alternate sample sets and they'll be added as a sample-only with those definitions.

[mahoneyt944]

This was a change grant was recently working on. I'll have to see about fixing it or reverting it.

[Wilstorm]

I think it would help to make it more clear to go with one of two directions. One is to remove the sampleof tag in the clone headers because as it sits it's doing nothing now (since the sample lists have been removed from the clones) or you could add the samples lists back (I would prefer this method as it's more complete and correct). You can't assume all clone ROM have samples that match the parent. You can have a parent ROM that is working perfectly with no samples and the clones still do have samples (but probably not the case with this core but with newer builds).

After the update ClrMamePro reads the DAT as if there are no samples for dkongjp or any clone in the entire core for that matter.

Here's an example of how ClrMamePro sees it with dkong/dkongjp (Donkey Kong/Donkey Kong (Japan Set 1)). I added some screenshots as it's a lot easier to illustrate. Notice the "after removal" screenshots shows no sample sounds for the set but the "before removal" shows the same sample sounds list for both the parent and clone.

I guess you could rely on the parent for sample verification for all clones and call it a bit of "blind luck" that the ROM management tool doesn't throw errors but the DAT is a bit butchered and has extraneous tags doing nothing.

I would say it's similar to ROMs, they are redundant and repeated over and over in clones but that's just how it works. You can get to the same place either way really and samples aren't as important or as precise as ROMs but one way is a more properly structured file and it makes for a cleaner DAT.

Speaking of samples I would have left out the OST samples as more of "hey here's a cool alternative!" as my vote. They are extra "unofficial" samples that are not needed to run the games properly. If you have two sample sounds that have identical names but a different hash (as in a different sound) then you have a conflict also but I would imagine that it was fore thought when planning the OST's.

Donkey Kong (dkong--parent):

Donkey Kong Japan Set 1 (dkongjp--clone rom--before removal):

Donkey Kong Japan Set 1 (dkongjp--clone rom--after removal):

[Wilstorm]

@mahoneyt944 - So I did read Grant's comments and I can tell you with certainty the DAT is structurally incorrect after that update. The examples above do illustrate that ClrMamePro is not verifying any of the clone samples. In fact it doesn't even recognize there are samples for any of the clones.

I agree you can't have split-merge samples but you can have dedicated samples per clone different from another clone or parent. In current MAME there are even alternate samples that are not listed in the DAT that function just fine. How it is structured now it is only verifying the parent samples which would technically work if all the clones use the exact same sample set but regardless this is not correct or how it was intended to work.

The point is to cover all scenarios and to make the DAT structurally correct so it can work properly with all rom management tools the samples should be listed in the DAT in addition with the use of the sampleof tag.

Basically Grant is saying how it was originally for years is not "preferred" only because it will save 200, 300k maybe 1MB of space in a DAT file. I don't think he understands how the sampleof tag works when he handed you the change to push into the main repo. Anyway when I did suspect something wasn't right I went and chatted with the developer of ClrMamePro. Here's was his response:

"If I see this correctly, as long as the clone doesn't list any samples it [has] no samples, no matter if there is a sampleof [tag] or not but then - being picky - the sampleof element should be removed. If it should use samples (from the parent), they should be listed."

I have no big issues with Grant and do respect him as he is incredibly knowledgeable and a quick study on new subjects but this is his old way of pushing his own logic into how he thinks it should work or mudding the conversation with sidebar chat unrelated to the mainline but enough to make the conversation confusing and go on for days or dozens and dozens of posts. I just don't want to go down the road answering all his sidebar comments. It takes to much time and energy to do everything that way.

I think you pushed the commit and I guess I would ask you to make the decision if you think the examples above and information from the developer are sufficient to demonstrate that the DAT was more structurally correct and cleaner the old way and not the new way with all the sample lists stripped out.

[mahoneyt944]

@Wilstorm I agree the dat looks better and seems logical with the new change. However, if rom building softwares are not handling this change as it's intended, perhaps it's best to just list the samples. I'll have to tweak the code a bit.

[mahoneyt944]

@Wilstorm ok so I added the samples back in but it still includes the sampleof tag for now. Let me know if this commit works for you properly. https://github.com/libretro/mame2003-plus-libretro/commit/dc4eadc77a34dd30573df9f63d1ae79e2ba9772a

[Wilstorm]

@mahoneyt944 - Ok, sorry if I am not explaining it well but the "sampleof" would still be needed so leaving it in place is correct.

Think of it more of way to connect the clone to the parent in the fact they both would be named the same sample zip or another way of saying it is they use same sample zip. For example listing the same samples under dkong (Donkey Kong) and dkongjp (Donkey Kong Japan Set 1) without the sampleof tag element isn't enough. Both are needed per game (the sample list and the sampleof element).

Doing it without the tag would direct the management tool to parse it as two different samples one named dkong and one named dkongjp (with the same samples in either zip of course) but once the "sampleof=dkong" tag is applied in the game header they will merged, so to speak, as one sample zip named dkong.

Also the core has to recognize what are valid samples for a particular game I would guess. When running say Donkey Kong (Japan Set 1) the emulator/core is not looking for dkongjp (but dkong) so it would not work that way anyway if that makes sense.

I don't know of any examples that are split-merge sample sets unlike ROMs which pretty much every clone has at least 1 merge ROM or their would be no point making them "cloneof" or "romof" depending on the tool used.

There are some sets that have different samples altogether which I would assume would just merge under the same zip using the tag. Most samples are pretty much merged sets though. It would be easy enough to test the theory if needed.

I'm not saying there's not a better more efficient way to do DATs but that's how they are done and still are today. Current MAME has a DAT from hell, huge! Even on an SSD the search function within Notepad++ can't take several seconds to parse through the xml to find what you're looking for.

[Wilstorm]

@mahoneyt944 - It looks good but there are a few minor errors. Michael Jackson's Moonwalker (Set 1) (moonwalk) has sampleof="moonwalker" which it shouldn't have anything since it's the parent (the tag needs removed). Two of the clones need sampleof="moonwalker" changed to sampleof="moonwalk" which are clones moonwlka and moonwlkb.

Also there are several games that have the same name but a different hash on certain files. ClrMamePro will warn you of the issue and rename on full merge. Grant renamed conflicts so he didn't have to explain to people the issue and to click "Ok" or "Ok To All" on merge conflicts. It's confusing to new people and you do wonder if your set is getting messed up. It's up to you how you want to handle it. It's not a big issue due to emulators searching based on hash. I listed them out if you do want to fix the conflicts between the clones and the parent. They are Dotrikun, mk2 and mk3.

Dottori-Man Jr. (dotriman) | parent - (dotrikun)
<rom name="14479a.mpr" size="16384" crc="4ba6d2f5" sha1="db805e9121ecbd41fac4593b58d7f071e7dbc720" region="cpu1" offset="0"/>

---------------------------------------------------------------

Mortal Kombat II Challenger (hack) (mk2chal) | parent - (mk2)
<rom name="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

Mortal Kombat II Plus (Beta 2) (mk2p) | parent - (mk2)
<rom name="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

Mortal Kombat II (rev L1.4) (mk2r14) | parent - (mk2)
<rom name="su2.l1" merge="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

Mortal Kombat II (rev L2.1) (mk2r21) | parent - (mk2)
<rom name="su2.l1" merge="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

Mortal Kombat II ((rev L3.2 European)) (mk2r32) | parent - (mk2)
<rom name="su2.l1" merge="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

Mortal Kombat II ((rev L4.2, hack) (mk2r42) | parent - (mk2)
<rom name="su2.l1" merge="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

Mortal Kombat II (rev L9.1, hack) (mk2r91) | parent - (mk2)
<rom name="su2.l1" merge="su2.l1" size="524288" crc="5f23d71d" sha1="54c2afef243759e0f3dbe2907edbc4302f5c8bad" region="cpu2" offset="20000"/>
<rom name="ug16-vid" merge="ug16-vid" size="1048576" crc="8ba6ae18" sha1="465fe907de4a1e502180c4e41642998dd3abc8e6" region="gfx1" dispose="yes" offset="100000"/>
<rom name="ug20-vid" merge="ug20-vid" size="1048576" crc="809118c1" sha1="86153e648834c749e34573151cd4fee403a81962" region="gfx1" dispose="yes" offset="700000"/>
<rom name="uj16-vid" merge="uj16-vid" size="1048576" crc="39d885b4" sha1="2251826d247c3c6df421124718401fb35a672f83" region="gfx1" dispose="yes" offset="400000"/>
<rom name="uj20-vid" merge="uj20-vid" size="1048576" crc="b96824f0" sha1="d42b122f9a57da330192abc7e5f97abc4065d718" region="gfx1" dispose="yes" offset="a00000"/>

---------------------------------------------------

Mortal Kombat 3 (rev 1.2) (umk3) | parent - (mk3)
<rom name="um312u54.bin" size="524288" crc="712b4db6" sha1="7015a55f3d745c6aeb8630903e2d5cd9554b2766" region="user1" dispose="yes" offset="0"/>
<rom name="um312u63.bin" size="524288" crc="6d301faf" sha1="18a8e29cc3e8ce5cc0e10f8386d43e7f44fd7b75" region="user1" dispose="yes" offset="1"/>

Ultimate Mortal Kombat 3 Plus (Beta 1) (umk3p) | parent - (mk3)
<rom name="um312u54.bin" size="524288" crc="a46ee73c" sha1="2ad13bf20b9e42729773307b55fa67e430b1cf87" region="user1" dispose="yes" offset="0"/>
<rom name="um312u63.bin" size="524288" crc="4f200db2" sha1="25bab2c52df59056e3018d88491de1f2b1a8eed2" region="user1" dispose="yes" offset="1"/>

[Wilstorm]

The files listed above are the ones that potentially need renamed due to the parent already having a file with the same name but a different hash. The name can be the same for all clones since most of the list above is from mk2 with the same 5 files matching. You would probably need to update the code to reflect the name change too.

[Wilstorm]

@mahoneyt944 - Here's a few screenshots using the same games from the example (dkong & dkongjp) after the change. Now ClrMamePro sees the list as valid samples for the clones and will also verify them when building or verifying a set.

Donkey Kong (US Set 1):

Donkey Kong (Japan Set 1):

[mahoneyt944]

Good. Not sure why moonwalk would be wrong. I'm guessing because the parent doesn't work (listed as gamex) and the clone does (game)?

[Wilstorm]

@mahoneyt944 - Yeah that's an odd one for sure, it just seems so random. Take a look below as moonwlka has another issue. It's listing the game name field twice. I'm kind of spot checking through and haven't spotted any other issues. I checked other OST's like nbajam, outrun and mk, all looked ok.

You're right though. I know moonwalk doesn't work but Arcadez worked his magic got us moonwlkb working and it's a fine game. I don't remember if it was an encrypted ROM I'm just not 100% certain.

Here's how the 3 games look in the DAT:

moonwalk:

<game name="moonwalk" sourcefile="system18.c" sampleof="moonwalker">

moonwlka:

<game name="moonwlka" sourcefile="system18.c" cloneof="moonwalk" romof="moon    <game name="moonwalk" sourcefile="system18.c" sampleof="moonwalker">walk" sampleof="moonwalker">

moonwlkb:

<game name="moonwlkb" sourcefile="system18.c" cloneof="moonwalk" romof="moonwalk" sampleof="moonwalker">

[mahoneyt944]

Ohhhh that's because the samples called moonwalker. It's not an error. Just the naming convention that was used. We could update it.

[Wilstorm]

Ah! Nice catch! Did you also notice moonwlka above? I'm not sure but it almost looks like it wrote out part of the DAT header and then restarted half way through it.

[Wilstorm]

Just a quick comment before heading out. What ClrMamePro does is it will try and find a parent rom named "moonwalker" (which doesn't exist) but it has a sampleof tag with that name so it will basically warn you of the issue and add it as an alternate sample-only. It kind of forces your samples to match your rom name. That was my only thought on OST's above, if they match a game that has a pre-existing sample pack you would need to do a quick test and see if they merge properly but I don't think that's the case on this core. Any samples and OST's matching that is.

[mahoneyt944]

Moonwlka might be a white space error?

[Wilstorm]

I wondered that if it's some tab error or something. It has part of the header information twice.

[Wilstorm]

Here's the part in the line that is duplicate and needs to be removed.

<game name="moonwlka"

Also romof=moon is truncated right before the line above and has a few spaces where "walker" should be.

[Wilstorm]

Ok, sorry there are several things wrong with it, it looks like just that one line with an issue in the whole DAT that I can find. Here is just the line in question with no other information around it.

<game name="moonwlka" sourcefile="system18.c" cloneof="moonwalk" romof="moon    <game name="moonwlkb" sourcefile="system18.c" cloneof="moonwalk" romof="moonwalk" sampleof="moonwalker">sourcefile="system18.c" sampleof="moonwalker">walk" sampleof="moonwalker">

[Wilstorm]

@mahoneyt944 - I apologize, sorry, I just regenerated the DAT from scratch to make doubly sure and it looks correct now. The only issue is sampleof="moonwalker" vs sampleof="moonwalk" and the "dup name equal hash" files issue. I better quit while I'm ahead and get a cup of coffee or something stronger. ;)

[mahoneyt944]

Lol ok.

[mahoneyt944]

The only concern I have for updating the sample name for moonwalk is it will break setups that are using the current sample.

[Wilstorm]

@mahoneyt944 - Yeah it was a long day yesterday at work and I was making elementary mistakes and figured it was time to give it a break.

Just a short message on the thoughts rolling around in my head so I wanted to put pen to paper real quick. I'm heading out here for a while to visit my father's grave, kind of quick Merry Christmas, God rest his sole! :)

Yeah it would break OST's for existing users or they could verify through rom management tools to correct the name. I definitely don't have a pulse on the number of users that would be affected or that are using OST's.

Also the name is a bit unorthodox. Typically samples are named to match the parent ROM. So every time you build a set you get this error. When I first saw that error years ago it took me forever to understand it.

Missing Alternative Samplefolder will be added as sample-only set.

Also my thoughts think of other platforms. I am thinking old school here. Are there any platforms this core runs on that require the 8.3 naming convention? You would know more than I here. As the moonwalker sample is the only file to break the 8.3 naming convention. Not sure why they did it that way.

Here's my biggest issue though, to me by adding the OST's as part of the DAT your kind of forcing the OST's on to the user without them knowing it. A typical user anyway. Most of the folks that pass through RetroPie don't care about any of this and just want to spend minimal time getting games up and running. I would even get caught by this. I would build the set/samples and dump them in the appropriate folders and go play.

You have to make choice really to make the original default sounds or the OST's set as the default audio. Or somehow convey to the user to remove these specific samples if you want hear the original arcade sound. I think having the original arcade experience is the better way to go and have the OST's as "HEY there's also a cool alternative sample pack!" It's exactly what current MAME does. They have alternate samples that work but they are not listed in the DAT.

I remember when the OST's first came out and there was a boat load of confusion here on Github of what parent and clones used them. I still don't know precisely. Is there any chance to maybe list exactly what ROMs (parents and clones) that are using what OST samples in the docs?

[Wilstorm]

One other small thought. Renaming moonwalker wouldn't totally break the audio. If I understand it correctly if it can't find the OST it will fall back to the default audio. So changing the name would just force the default audio play.

Even quicker than re-verifying is just change one file in the sample folder by dropping the "er" from the moonwalker and boom everything works again.

If having a longer sample name doesn't hurt anything then it's not a big issue either.

Then it would be mostly a decision on the default audio. I think that's why current MAME does it, basically alternate audio samples for a game vs. the original.

[mahoneyt944]

https://github.com/libretro/mame2003-plus-libretro/commit/5376ac941177816272efcc28c380a0585132350d#diff-7506bb718d24b09caede781ce08b3aedb187b4988acfad61c858e34afa5edfca

That should fix moonwalk

[Wilstorm]

Ok thanks, I’ll test it and post back. Were you able to take a look at removing the sampleof tag from the parent moonwalk? With the sampleof tag on the parent it throws two errors. It looks almost cyclic. One error complains that it’s missing it’s own samples (normal) and then another error that it’s missing it’s sampleof samples, basically samples of itself. Everything else built like a champ.

If you want I can give you the list of parents and clones using OST‘s? If the DAT is correct I can extract them and they could be added to the docs for others to know which games/clones use OST’s and how to revert back and forth by removing or adding them. Honestly I’m a purist in regards to retro gaming but I do use these OST’s.

[mahoneyt944]

I think the sampleof tag is only present when the sample name does not match the parent. So by changing it to moonwalk, I think it will remove the sampleof tag. 2 for one deal.

[mahoneyt944]

We recently added specific tags for ost so finding them and processing them in general is easier. It's just not configured in the dat yet.

All ost samples now have the ost tag, outrun example: MDRV_SOUND_ADD_TAG("OST Samples", SAMPLES, outrun_samples_set)

It could be setup to skip ost samples in the dat by checking for this tag.

[Wilstorm]

It could be setup to skip ost samples in the dat by checking for this tag.

I agree that's the question. I go back and forth on that one. I like the idea of having the original audio as the default and enhanced audio as the alternative. On the other hand you need the DAT to build/verify the OST sets. Then I think many will consider them official samples and just dump them straight away into the core samples folder. They'll either take the audio as official samples or wonder what's different in this old game, the audio seems to have changed. I don't know the right answer here or a good solution.

I think those of us that are a little more familiar with the core it really isn't an issue either way as we can flip them back and forth but newcomers or a someone looking for the best OOBE that's a different story. Through the years I am surprised to see so many on the RP forums that really just want set it and get going with little to no fiddling. For me that's part of the fun. I suppose that's what makes the mini NES/SNES so popular even though I would consider them somewhat inferior to the PI that can run all those game and so much more but then again they are a great hobby console too! I am ok with whatever you think would provide the best experience.

Here's the link to the documentation I was referring to but I see the games with OST's are already listed. https://docs.libretro.com/library/mame2003_plus/#Building-romsets-for-MAME-2003-Plus. I don't know if this full list is to detailed to add but here the exact list of games with the parent and clones. It will be here at a minimum.

Sample: ddragon Double Dragon (Japan) [ddragon] Double Dragon (US) [ddragonu] Double Dragon (World) [ddragonw]

Sample: ffight Final Fight (World) [ffight] Final Fight 30th Anniversary Edition [ffightae] Final Fight (Japan set 1) [ffightj] Final Fight (Japan set 2) [ffightj1] Final Fight (US 900112) [ffightu]

Sample: mk Mortal Kombat (rev 5.0 T-Unit 03-19-93) [mk] Mortal Kombat (rev 1.0 08-08-92) [mkla1] Mortal Kombat (rev 2.0 08-18-92) [mkla2] Mortal Kombat (rev 3.0 08-31-92) [mkla3] Mortal Kombat (rev 4.0 09-28-92) [mkla4] Mortal Kombat (prototype, rev 9.0 07-28-92) [mkprot9] Mortal Kombat (rev 4.0 T-Unit 02-11-93) [mkr4]

Sample: moonwalk Michael Jackson's Moonwalker (Set 1) [moonwalk] Michael Jackson's Moonwalker (Set 2) [moonwlka] Michael Jackson's Moonwalker (bootleg) [moonwlkb]

Sample: nbajam NBA Jam (rev 3.01 04-07-93) [nbajam] NBA Jam (rev 2.00 02-10-93) [nbajamr2]

Sample: outrun Out Run (set 1) [outrun] Out Run (set 2) [outruna] Out Run (set 3) [outrunb] Turbo Out Run (set 1) [toutrun] Turbo Out Run (set 2) [toutruna]

[Wilstorm]

I modified the list of games above [to try and make it easier to understand]. The first line is the OST sample name and then below it are the games tied to that sample with the rom listed on the end after the name.

[mahoneyt944]

Ok, verified the moonwalk ost samples are correctly named in the dat now and all samples are included as per the original issue. Don't forget to rename the sample!

In order to remove ost samples from the dat, we need to check for the new ost tag....I see grant took some initiative in starting this in his core, so I'll let that go for time being.

As far as romsets with the same rom name using different checksums (hacks). This is technically correct because they are modifying the original rom. Renaming works, but then it's not following any naming convention. I'm not necessarily against this but it would be nice if it followed some convention. How does current mame handle hacked roms?

[Wilstorm]

Yeah, sorry I verified it when you had posted a few days ago. Yeah it all looks great. If you were waiting for me I apologize.

I don't think it's so much what current MAME is doing but more of what do you want to do on this core. Current MAME does nothing and allows the hash collision. It's what I'm used to seeing and know how to answer all these different errors that happen in DATs to build proper sets.

Grant saw this one and decided to tweak the merge tag [on this core] so it has a different name. The code would need to reflect the name change (or not) as hash matching will find it eventually. I have no idea if Grant had a naming convention he liked to use in these situations. I think he just wanted to eliminate all the warnings you receive and have to answer or acknowledge when building sets.

ClrMamePro has no idea what to do with it so it warns you at least. On rebuild it will dump those files into a subfolder in the zip. I have no idea if this core searches sub-folders?

The issue isn't a big one by no means but something Grant started. If you want to continue it you could ask him how handled it or you can leave it too, either is ok. I just saw them pop up when rebuilding.

@arcadez2003 - Thanks a bunch for the FBNeo goodness. I was really behind and just go around to building a FBNeo 1.0.0.0 set. You and "gamez fan" are credited in the main thread on the PD forums. Good stuff!

[mahoneyt944]

If you're good with the current state of the dat, this can be closed until we decide how we want to handle the finer details down the road.

[Wilstorm]

Yeah that sounds good. Some of the merge tags have been tweaked through the years to correct the issue but I have no idea how a guy could know which sets without looking at the commits. I just wanted to mention it since quite a few of the new additions are starting to create merge errors again. The core can't fully run full merge sets anyway (parent only) and it probably doesn't matter to most users.

I understand what Grant was saying but think the corrections made are an improvement and more correct over what it was before with samples. Now they are being verified even though the parent will build the set just fine.

Yeah official MAME sees a lot of those issues. From hacks, bootlegs, encrypted, older chips in the original cab vs. newer, etc. that create collisions.

I do see some people that decrypt the ROMs handle it by renaming the extension with a "d" like ".u2d". Points for being creative. Anyway the official MAME dat is getting close to 250MB. It's a beast.

Thanks for making the changes and have a good weekend. Closing it out.

[Wilstorm]

@mahoneyt944 - I just thought I would share some OST sample testing I did with "moonwalk" on a Pi 3. I decided to throw in the 325MB (yeah that's right--325 megabytes) 16-bit stereo WAV samples and it seems to run them fine. It loads about the same (with or without), FPS was good and it sounded great. I didn't play extensively but it looks good so far.

I don't know what I was expecting but I didn't think it was going to run or at least have issues with samples that large so that's good news.

[Wilstorm]

Update the list above with the Final Fight plus clones OST samples.