Idea to support multiple rom naming schemes and make things much cleaner

[tastyratz]

I was thinking about how much of a pain it is to re-name your roms to match your media, or vise versa based on the popular standards out there when I started to think... why? Why do it at all?

What about adding a line to the database xml... <alternate##> - sorta similar to clone but wouldn't report a game as a clone of. Simple. You can add as many <alternate> names as you want and it will search for them in order if it doesn't find the first file.

Then people can sync artwork using preferred naming schemes but on cd based systems they can easily have their xml populated with tosec/trurip/redump/darkwater/etc. names. Utilities could easily just import alternate1 while leaving original intact.

Wouldn't that make things cleaner and everyone with different collections happy? What does everyone think?

[brolly]

And who would add those tags to ALL the existing databases? You?

[sudopinion]

.

[emb]

I know a guy. Just sayin.

You talking about Bob? He'll do it if you pay him in cigarettes.

Sent from my iPhone using Tapatalk

[tastyratz]

I'm not saying hey how about we all just add every name to every database ever. I am saying it could be matched up. The solutions now, build a custom database... rename all your roms... rename all your media... then deal with that mess if you ever decide to upgrade your romsets? not a good solution. If this tag existed A tool similar to the Don's hyperspin stuff (and no I am not volunteering you) could crc match your roms to existing ones in the database and then instead of CHANGING anything there it would just inject the matched roms under an alternate name tag. If you ever decide to hypersync your database I am sure it would be very easy to extract the alternates list from the other database and match it up to the updated one.

[ghutch92]

I'm not saying hey how about we all just add every name to every database ever. I am saying it could be matched up. The solutions now, build a custom database... rename all your roms... rename all your media... then deal with that mess if you ever decide to upgrade your romsets? not a good solution. If this tag existed A tool similar to the Don's hyperspin stuff (and no I am not volunteering you) could crc match your roms to existing ones in the database and then instead of CHANGING anything there it would just inject the matched roms under an alternate name tag. If you ever decide to hypersync your database I am sure it would be very easy to extract the alternates list from the other database and match it up to the updated one.

I don't think I quite understand. You want to match only one good dump of a game to the hyperlist rom name?

Why have all the other dumps if you only plan on using only one dump?

If you plan on removing all the bad dumps, why even keep the same naming scheme for your roms?

Do you seriously want to have a complete collection of all the dumps, bad and good?

What if you were doing a system like PS2 for which each dump of a game can be 4GB+? Would you really want multiple dumps of a game for a system like this?

Having a list like this, still means you need to go through all of your roms and match them up to the HyperList names. So this doesn't save you from needing to match up your roms to the HyperList database.

Since you are already going through your roms one by one to match them to the HyperList names, why not just rename them to match HyperList name while you are doing this?

If your answer is someone could make a list for their own games and share it, that way the person they are sharing it with doesn't need to rename their roms. This is just not true, they will most likely still need to rename individual games to match either the alternative list or HyperList, so you aren't saving anyone from the task of needing to rename their roms. There is also no guarantee that the HyperList crc will match the rom you want to use.

If you do upgrade your rom sets, there is a probability that the rom you were using before might have had its name changed or that a better dump was found and you might want to use that one. After you update your rom sets would you not still perform a crc check on all your roms to make sure a name was not changed in the upgrade?

Is there a need this feature meets? What is that need? Why is that need important to meet? What does meeting this need mean for the community?

[tastyratz]

Well here is a scenario and exactly what inspired me, maybe it will paint the picture better:

I downloaded a complete game set for the playstation which was done to redump.org standards and naming. I want to access these games in hyperspin. Say I did decide to rename what I have to match hyperspin. Not every game in a redump set will match up because there may be different games. If I decide to rename what DOES match up then maybe half of my roms are hyperspin standard while the remaining are redump standard - a broken messy set. I don't want to have a mismatching broken half named set, and I don't have the hard drive space to just keep 2 of them - especially when getting to larger sets like playstation's, gamecube, etc. If I want to keep my set in its current name I could just generate a new xml but I then have a problem with media not matching. I would have to re-name all of my media I download... and as new media becomes available more manual labor or messy syncing.

So here is where an alternate name tag could be beneficial (and actually I could see alternate CRC in this instance). If it exists than a third party utility could be developed similar to a fatmatch/dons tools/etc. It could search your roms and instead of re-naming them it injects what it believes is the correct name into your database as an alternate name. All future hypersync media still links to the game, all future updates continue to function, and I don't have to change all my roms just to make them match what hypersync prefers at the time. What if I screw up and improperly rename my collection? That could be a nightmare while a database is easily replaced.

I am not looking at this from a random assortment of mismatched roms or broken bloated goodsets. I am thinking of different standards from places with dat files such as redump.org or trurip. Many people might prefer redump.org or trurip sets and aquire them, maybe they already have them. If I were to match up a redump.org dat file against the hyperspin xml then why couldn't I share it? Why wouldn't it work for someone else who also has a redump.org set?

This feature would PRESERVE your current roms as they are while allowing them to work with hyperspin and especially with hypersync.

[djvj]

So to get something like this to work, someone would have to maintain ini files for each system and its roms like so:

[section name] = your rom name as HS sees it

romNameAlt = the alternate filename

romInternalName = the internal name of the rom you want to load

HS -> GoodNes example

Remap.ini (For Nintendo Entertainment System)

[super Mario Bros. (World)]

romNameAlt=Super Mario Bros.

romInternalName=Acid Bros (SMB1 Hack)

You would need a section for each game named after your HS xml romName. Good sets for example have entirely different archive file names then the roms inside. This goes completely against what I enforce with 7z support.

You see the mess this would be to create and even maintain? Not one, but 2 databases now need to stay in sync. Fuzzy matching is not 100% where tools can do it for you. Now do this for 1000 games. It would be easier for naming schemas that use the same archive name as what's inside, then you only need romNameAlt. But if you want crap like good tools naming? It's a mess.

Do all the naming schemas out there have this f'd up naming differences?

[Rain]

IMHO Renaming ROMS should always be done in NO-INTRO. That is one of the main reasons that I was drawn to this community in the first place is because of their standards and practices. Now, don't get me wrong I have Good sets and NO-INTRO; and the completion side of me loves my Good sets and Good Merged sets; but the organized side of me has to have my nice clean, well behaved NO-INTRO sets. But then again I am just a stickler for tidiness I suppose; and for those of you whom have remote connected with me and seen my massive collection of files (over 1.6 million files spanning 164 systems) know that I have a very specific order to things and like things a certain way. If it were just a matter of reading an alternate tag via HyperSync to download media than that would be as simple as pumpkin pie. However, DJ makes a good point regarding the maintenance of said databases; and what is good for the goose has to be good for the gander.

I am very familiar with Good sets and how they work and the naming utility which I am working on (to be included in HyperSync 3.0) can easily rename ROM files from Good sets to NO-INTRO with little or no effort. However, I do not see the need to make this a full blown project; but I do admire your courage when staring this renaming beast in the face. The naming schema for Good sets is brilliant as it can tell you volumes of information just by looking at the title of the name, such as region, color schema, multiplayer and much more; but then at the end of the day NO-INTRO just makes better sense for the sake of sanity and helping new users become used to HyperSpin as a whole.

But then again if it were up to me, I would also strictly enforce the naming of systems as well (ie Nintendo Entertainment System not Nintendo NES, NES, Classic Nintendo.) The majority of the problems with tools such as HyperSync is the naming conventions, and peoples lack to adhere to such conventions. I think that tossing another officially supported naming schema into the fold would ultimately create more chaos than the possible benefit.

[sudopinion]

.

[tastyratz]

Good sets toss the idea of clean and organized RIGHT out the window for the sake of completion, good sets are terribly messy if you ask me and I was thrilled to just get away from and dump those roms when I got into hyperspin. Cartridge based games are not a huge download, and proper sets are easy to acquire. It becomes more of a problem when you start looking at cd based sets which are significantly larger and the variety is sparser. When you have a 2 terabyte ps2 set, you don't really want to just "get another one".

Officially supported multi name databases and ini files? well... that's a whole other ball game for what I might consider a step 2 if people are willing to back it. I am thinking for now just the capability to not have to change everything I have just to match hyperspin.

A tag for <alternate##> came to me as what might be what I thought was the best way to handle it. A second INI/XML might make the most sense the more I think about it I like your idea. I would say alternate CRC would be a good value to include as well. People could share their ini's (be it officially or unofficially) and utilities (such as hypersync) could for example use ini's if a user were to check a box "preserve original file names". Those files could make it a lot easier for people starting with a different set to just download without breaking their hyperspin if they sync their database. Could reduce the work needed for new users.

There are other groups with rather clean naming conventions and they include more/less/different information of relevancy. For some those names could be considered better for some people, and for others just staying true to the set they have is important. Maybe they manually renamed their files to a format that THEY prefer for their needs. Either way I consider hyperspin as a front end to be a slick and excellent way to work with my collection... not my collection as something adapted to work with hyperspin - that feels backwards to me. What if I want to use something else and hyperspin is abandoned in 5 years for example? Those in the emulation scene long enough have seen plenty of great emulators just completely stop support after a few for one reason or another. Consider new user appeal there.

There are a lot more redump.org games for ps1 for example than TOSEC, and hyperspin uses tosec standards for cd based systems not no-intro correct?

There are probably plenty of dumps tosec doesn't even HAVE as part of a redump set. As time goes on and they get added then hyperlist gets updated and I have to go through my collection again to rename files (still having a messy split set with 2 naming conventions).

Not everything outside of tosec is a bad dump or duplicate. Having a complete set from somewhere else means I will have games that may or may not match up, and I will end up with a split set if I change it. I would rather keep my dumps complete and genuine to what they are while linking hyperspin to them.

For arguments sake Lets consider the bigger and most popular: redump.org , trurip.org , Darkwater. Those are going to really encompass the majority of legitimate optical dumps you find out there. Good tools naming is an absolute mess and makes things WAY more complicated for a minimal gain. Trying to cross link a good set to a no-intro is suicide.

Redump has been around a while and has a massive amount in the wild, they use no-intro naming now with very clean files.

Trurip is what I would consider a VERY popular new up and comer with a very verbose file name and very packed archives with things like artwork, merged sets, etc. They includes some catalog numbering in their file names which imho makes it much easier to exactly match a game from a set across naming schema changes.

All 3 groups include actual track data in their rips instead of just iso's packed in a 7z.

For naming: Here is a link to the dreamcast superdats for redump, tosec, and trurip respectively:

http://redump.org/datfile/dc/

http://www.tosecdev.org/index.php/downloads/category/20-2013-04-13?download=35%3Atosec-dat-pack-complete-2095-tosec-v2013-04-13

http://database.trurip.org/index.php?page=mnu-Database-DAT-List&showSuperDAT=1

If I pull a game out of all 3 for example, sega rally 2.

This is what you see pulled from a TOSEC dat

game (
name "Sega Rally 2 v1.003 (1999)(Sega)(NTSC)(US)[!]"
description "Sega Rally 2 v1.003 (1999)(Sega)(NTSC)(US)[!]"
rom ( name "Sega Rally 2 v1.003 (1999)(Sega)(NTSC)(US)[!].gdi" size 658 crc 9e8e9684 md5 0b14a1895fb630b25970778773572080 sha1 f84362ea1a5c599c85f3ad0a37a23e70fcc7eab6 )
rom ( name track01.bin size 705600 crc 294f0495 md5 3ce64896d6800de568c54afa3ca68a17 sha1 55e613230ca66bcdddcf58f69301d6f92b318059 )
rom ( name track02.raw size 1237152 crc 48fff429 md5 87af6d21a8b10aeffb90874118531e29 sha1 b0d28980a64765c022b4b3e47244aad32a345270 )
rom ( name track03.bin size 185264688 crc 25242337 md5 9c7c92e17458ccbaca62ae842ff50602 sha1 26aff7db54c590e512bb7e18ff6941cc31b7dde1 )
rom ( name track04.raw size 10979136 crc f7bd3bda md5 a5f6b16168ad5bcc181bc39b53189191 sha1 82088b0c8425f5c3243a0c1b7c21ac3ae607e535 )
rom ( name track05.raw size 39859344 crc bfc7609e md5 1a5283afa42cb48695741c61f8c54b28 sha1 e741dee4d77e23f460dc4fbd26293578f6992d8c )
rom ( name track06.raw size 34094592 crc 5617152e md5 e001af6c7b390ec645af52cb6b4a8f12 sha1 ee9aea39727c6a344e4e51c858d55c4a6488cfbd )
rom ( name track07.raw size 42514752 crc ddd5934a md5 156b56780b130f10dfda25be50dfd66e sha1 40f52216d7c2866d7bb7f48c790d845eb05be454 )
rom ( name track08.raw size 39713520 crc 4c7c5a80 md5 f29c96720071e1a6be37a4105d0294d5 sha1 f3b69e5814eda9a94dc03d3703fc84b9d9f78eee )
rom ( name track09.raw size 43900080 crc ee1a82bb md5 a48235a74d057636058afa65293c4653 sha1 a1e8e18634673a66dd1e03aa815afd6ddb23241a )
rom ( name track10.raw size 41002416 crc 59157532 md5 e0238c6ac6b511a82787bfe5c33aef74 sha1 df95beb0fa61bb9c5103bbf010f56aa4eb913c28 )
rom ( name track11.raw size 46640160 crc 23433db9 md5 c7152138a9c69da9146b9cba30cf44b5 sha1 77e69217b5640663d9934ce69a6263d64b6e9003 )
rom ( name track12.raw size 39720576 crc e857828f md5 6922a831acfbe217416ba99d7dc0061d sha1 a3fe283642e46094733f9eba8f911a0f476c3b96 )
rom ( name track13.raw size 30491328 crc dd2b7e54 md5 51bc7fa40d01367116eb3bd2cd101b67 sha1 05f903bc8aaad3a88347503123ddd1f58141d93f )
rom ( name track14.raw size 39297216 crc 2d6f040a md5 ada4f70c2e88ccb37496ace4501590f1 sha1 0dc520553e94e2b2a2e71d4678cd5d0aabea7737 )
rom ( name track15.raw size 34155744 crc 674bbe8d md5 e3fdd4fad6dfbb7403cbdcbe83001e5f sha1 047801f599eec29c8dfca01cccc5046e04a99fd2 )
rom ( name track16.raw size 1639344 crc afbdcf00 md5 139c0d1e4f38312f20d9e2f59d4e5de8 sha1 f4d4577c5e9c0ccaba4fea9b41edd8c8688ff0ac )
rom ( name track17.raw size 3880800 crc 0e24ac41 md5 56eb959ca7732187eebae10ccdbcf430 sha1 8786c377443f80fd6638406d47a3c8cdeecafe55 )
rom ( name track18.raw size 11233152 crc e8978d66 md5 45670414aa16c8451b95546ffd3e5336 sha1 3867cd2a45344c70bc70f178c0422053d4528419 )
rom ( name track19.raw size 10711008 crc 84db8ac5 md5 c29a7b5e286c04203ac7ff9640d43f7f sha1 5c1c13bd61747b099904dac0668c8d64fee615db )
rom ( name track20.raw size 31712016 crc 105c027e md5 e62a02659de0ebac05aa953c76e70973 sha1 7e9d5841ffbb74648acebb86274dff9edcdafc35 )
rom ( name track21.bin size 498245328 crc 57be9544 md5 d0a1f89e0dd36b12e7a058535e5cf53d sha1 c4a208166652cac70aa95334fbca5599c365570f )
)

This is what you find in a redump dat file:

<game name="Sega Rally 2 - Sega Rally Championship (USA)">
	<category>Games</category>
	<description>Sega Rally 2 - Sega Rally Championship (USA)</description>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA).gdi" size="1726" crc="69450d41" md5="463dc21142018154b8c1619e426bc5f4" sha1="3c902f717141e83c403c0d58c7fb2d73a704a5bc"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 01).bin" size="705600" crc="294f0495" md5="3ce64896d6800de568c54afa3ca68a17" sha1="55e613230ca66bcdddcf58f69301d6f92b318059"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 02).bin" size="1589952" crc="8557fcaa" md5="824ff123fbce45b5883962eb3fa43cab" sha1="a3705cb0ce53c7adf906c5af76887406984de6a9"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 03).bin" size="185264688" crc="25242337" md5="9c7c92e17458ccbaca62ae842ff50602" sha1="26aff7db54c590e512bb7e18ff6941cc31b7dde1"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 04).bin" size="10979136" crc="072b4c39" md5="6ab3a6902a30ec9a5ad23f0c4857b769" sha1="555ee0f0029de36383f9a04154543ea474cee35c"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 05).bin" size="39859344" crc="42adfd68" md5="9f24bfa85566d5f5426bf4ede629578d" sha1="0d61f678d1aa2b8fae9d1db111b8f748a0d50d73"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 06).bin" size="34094592" crc="757f13a6" md5="9405340ac56448e1ea68bd666200b273" sha1="2ce0ac9cd6c433f739068c7dedd4b60a500c8c65"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 07).bin" size="42514752" crc="af67fda8" md5="8c156775b7f458c57bf71f2c314f1484" sha1="812717cb5e91a75951e40adf53ca990c288e35b9"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 08).bin" size="39713520" crc="00656b4d" md5="71d2709f7979e2f0710789f182697fe0" sha1="3e3267355e4d0abc5841c1cbd1c41889d5748d02"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 09).bin" size="43900080" crc="11468a12" md5="fbbc6567842b65d88215de925bdf5f6c" sha1="a89d739235bf0cdc9767318548c8bc5b03cd76b0"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 10).bin" size="41002416" crc="48293e62" md5="d9a351b7013b2356a4f57d454cc6c05b" sha1="829766e36e32768564c89c40dfa20c5e05ecdf06"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 11).bin" size="46640160" crc="c1be560e" md5="3627495a30f2f636e80d64f60ca2f4ae" sha1="84810174387ae98a73def54243c5445eaed392f5"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 12).bin" size="39720576" crc="6a0f9aa1" md5="1921abfebb2b8ae6266fc872cd5ad593" sha1="e769c91d7416ee8ee2571571d969b744f97479fc"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 13).bin" size="30491328" crc="3a8a3167" md5="6462709f5df3429d4dd48e68a612e4e2" sha1="cdbb3dcadd2373b87dbe55b25d11c88004c6e71d"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 14).bin" size="39297216" crc="1e219b18" md5="9d01af8d80e3233b811b259d48b65ac4" sha1="3fdf3a6093fc95e1c94c655632bf24a57b15d149"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 15).bin" size="34155744" crc="82f2a2b9" md5="115b79159e0e32fea18300fca5e23a92" sha1="e4e005132aec17f601e223c34e08f5d505cacbd9"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 16).bin" size="1639344" crc="bc260087" md5="2dfaf26b2c2374fbb0b2048f99ff9969" sha1="e906c31c9ff65829ed54e4614c452f870750632d"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 17).bin" size="3880800" crc="d5a3d008" md5="3f519f5f8abc030bb2a2da93acfdafca" sha1="06fdaf74ebcabad0a39227628eb3412fefc8ee46"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 18).bin" size="11233152" crc="20428766" md5="97b0408be138f2b084ad449a45020829" sha1="48ee7fa72e60cb32c7a75ca9081501d036378a93"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 19).bin" size="10711008" crc="5a9311f4" md5="8774cc32339b8b2a159e70423de6a3ee" sha1="87db6629dfbd0db1550ad9d399ac1b10d355d37c"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 20).bin" size="31888416" crc="fb8ce2ad" md5="23d2bc7165ccb1a032ee95a5637c242b" sha1="a75553d76a3b886e4a03df51007d39de48439081"/>
	<rom name="Sega Rally 2 - Sega Rally Championship (USA) (Track 21).bin" size="498774528" crc="c82f3716" md5="98b0a0d46a951a23f042e841c0ecf7d6" sha1="73810418d588635512db981b1e7de6614bdf17dd"/>
</game>

And this is what you find in a trurip dat file:

<game name="Games (US)\Sega Rally 2 (US) [MK-51019] [-]">
	<description>Sega Rally 2 (US) [MK-51019] [-]</description>
	<rom name="Media\GD-ROM [F6C8][u][0799B11][MK-51019][19991026] [V1.003][!].gdi" size="658" crc="9e8e9684" md5="0b14a1895fb630b25970778773572080" sha1="f84362ea1a5c599c85f3ad0a37a23e70fcc7eab6"/>
	<rom name="Media\track01.bin" size="705600" crc="294f0495" md5="3ce64896d6800de568c54afa3ca68a17" sha1="55e613230ca66bcdddcf58f69301d6f92b318059"/>
	<rom name="Media\track02.raw" size="1237152" crc="48fff429" md5="87af6d21a8b10aeffb90874118531e29" sha1="b0d28980a64765c022b4b3e47244aad32a345270"/>
	<rom name="Media\track03.bin" size="185264688" crc="25242337" md5="9c7c92e17458ccbaca62ae842ff50602" sha1="26aff7db54c590e512bb7e18ff6941cc31b7dde1"/>
	<rom name="Media\track04.raw" size="10979136" crc="f7bd3bda" md5="a5f6b16168ad5bcc181bc39b53189191" sha1="82088b0c8425f5c3243a0c1b7c21ac3ae607e535"/>
	<rom name="Media\track05.raw" size="39859344" crc="bfc7609e" md5="1a5283afa42cb48695741c61f8c54b28" sha1="e741dee4d77e23f460dc4fbd26293578f6992d8c"/>
	<rom name="Media\track06.raw" size="34094592" crc="5617152e" md5="e001af6c7b390ec645af52cb6b4a8f12" sha1="ee9aea39727c6a344e4e51c858d55c4a6488cfbd"/>
	<rom name="Media\track07.raw" size="42514752" crc="ddd5934a" md5="156b56780b130f10dfda25be50dfd66e" sha1="40f52216d7c2866d7bb7f48c790d845eb05be454"/>
	<rom name="Media\track08.raw" size="39713520" crc="4c7c5a80" md5="f29c96720071e1a6be37a4105d0294d5" sha1="f3b69e5814eda9a94dc03d3703fc84b9d9f78eee"/>
	<rom name="Media\track09.raw" size="43900080" crc="ee1a82bb" md5="a48235a74d057636058afa65293c4653" sha1="a1e8e18634673a66dd1e03aa815afd6ddb23241a"/>
	<rom name="Media\track10.raw" size="41002416" crc="59157532" md5="e0238c6ac6b511a82787bfe5c33aef74" sha1="df95beb0fa61bb9c5103bbf010f56aa4eb913c28"/>
	<rom name="Media\track11.raw" size="46640160" crc="23433db9" md5="c7152138a9c69da9146b9cba30cf44b5" sha1="77e69217b5640663d9934ce69a6263d64b6e9003"/>
	<rom name="Media\track12.raw" size="39720576" crc="e857828f" md5="6922a831acfbe217416ba99d7dc0061d" sha1="a3fe283642e46094733f9eba8f911a0f476c3b96"/>
	<rom name="Media\track13.raw" size="30491328" crc="dd2b7e54" md5="51bc7fa40d01367116eb3bd2cd101b67" sha1="05f903bc8aaad3a88347503123ddd1f58141d93f"/>
	<rom name="Media\track14.raw" size="39297216" crc="2d6f040a" md5="ada4f70c2e88ccb37496ace4501590f1" sha1="0dc520553e94e2b2a2e71d4678cd5d0aabea7737"/>
	<rom name="Media\track15.raw" size="34155744" crc="674bbe8d" md5="e3fdd4fad6dfbb7403cbdcbe83001e5f" sha1="047801f599eec29c8dfca01cccc5046e04a99fd2"/>
	<rom name="Media\track16.raw" size="1639344" crc="afbdcf00" md5="139c0d1e4f38312f20d9e2f59d4e5de8" sha1="f4d4577c5e9c0ccaba4fea9b41edd8c8688ff0ac"/>
	<rom name="Media\track17.raw" size="3880800" crc="0e24ac41" md5="56eb959ca7732187eebae10ccdbcf430" sha1="8786c377443f80fd6638406d47a3c8cdeecafe55"/>
	<rom name="Media\track18.raw" size="11233152" crc="e8978d66" md5="45670414aa16c8451b95546ffd3e5336" sha1="3867cd2a45344c70bc70f178c0422053d4528419"/>
	<rom name="Media\track19.raw" size="10711008" crc="84db8ac5" md5="c29a7b5e286c04203ac7ff9640d43f7f" sha1="5c1c13bd61747b099904dac0668c8d64fee615db"/>
	<rom name="Media\track20.raw" size="31712016" crc="105c027e" md5="e62a02659de0ebac05aa953c76e70973" sha1="7e9d5841ffbb74648acebb86274dff9edcdafc35"/>
	<rom name="Media\track21.bin" size="498245328" crc="57be9544" md5="d0a1f89e0dd36b12e7a058535e5cf53d" sha1="c4a208166652cac70aa95334fbca5599c365570f"/>

I really just wanted to highlight the differences more than turn this into a discussion over who has the best format and what we should officially support. Ultimately if support for alternate names exists people could use any set they want unofficially and not change what they may have explicitly decided on long ago. This gives them (and any respective third party utilities) the ability to do so. See the tree before rejecting the forest.

Here is some more information comparing the more popular ones from someone who has worked as a dumper, they have some excellent insight if you're curious:

http://romshepherd.com/smf/index.php?topic=2011.15

Loooooong confusion here, this is basically down to the long past of esotericism of TOSEC ISO (this trend is continued by TOSEC for some length but it might change), some FUD spread by Redump to conceal some of their glaring weaknesses and the fact that Trurip was kinda developed in secrecy and still keeps a lot of info private.
So, allow me to give some insights from a dumper that has worked with both TOSEC ISO and Trurip. I even had some talks with the Redump guys when they started their attempts at Dreamcast. These are mostly personal opinions (although influenced by some knowledge of the dumping methods and talks with members of all groups) and anyone wishing to debate anything may do so. I will also keep it from a collector's/gamer's perspective because the dumping issues are not much of a concern to a gamer and even less for a collector of ISOs. Let's just state that any form of half-accurate dumping is excellent for playing the games in emus or even real hardware in most cases and that there's currently no "perfect" dump with any method. And probably will never be, since the nature of the CD media is "inaccurate" by design.
Apologies in advance for wall of text...  :

Q: What will happen with TOSEC ISO (iso+wav) dumps? Which type of dumps will TOSEC "endorse"?
A: TOSEC is currently returning to a pure renaming project and will be neutral regarding the all time classic question of which dump is "best". This means that at some point there will be dats for all flavors of ISO dumps, regardless of dumping "group" (Trurip, Redump, Darkwater or TOSEC ISO). Even the removed ISO ones (like the SegaCD set mentioned) will probably reappear and it will be up to the individual collector to decide if they want all types or (more realistically) just limit themselves to what interests them more. This makes more sense and is in tune with the original stated goal of TOSEC, which is to catalogue and rename existing dumped roms for all systems. Since roms for other systems are renamed without any regard to who dumped them, it makes no sense for ISO to be different. Like you have Spectrum TAP, Spectrum TZX and Spectrum Z80 or Commodore D64, T64, PRG etc etc, you will have Saturn CCD (Trurip), Saturn BIN/RAW (Redump), Saturn ISO/WAV (TOSEC ISO) and Saturn BIN/CUE (Darkwater). This evolution will probably take a LONG time (renamers don't even have complete collections of ISOs from all the dumping groups ATM and there's not any renamer really dedicated to this task). TOSEC is aware that some dumping groups see that as "stealing" their dumps and are even trying in the background to "punish" TOSEC for doing so, but that's irrelevant. Want the latest and greatest, you can grab the dats from, say, Trurip or Redump site. Want a dat with ISOs renamed in TNC, you can wait until TOSEC adds it. End user gets the best of both worlds. TOSEC can't really "steal" a dump unless they claim they made it. Else every dump for every system in the TOSEC database is "stolen" from its' original dumper and we are stuck with a pile of files without consistent naming. Counterproductive or?

Q: Yes, but I want only the "best" dump. Which is it?
A: At the current level of knowledge Trurip is probably the best. Dumping program is very sensitive to even minor errors on the disc, it can detect small faults that were getting through with the other methods and it supports weird disc formats that other dumping methods couldn't even touch properly (eg PCE, PC-FX, Jaguar, Dreamcast MilCD, CDi-Ready). Also a lot of work and experimentation went on in the background, increasing knowledge of the CD format inner workings. I only wish they made their work more public in this field. Many false assumptions exist ATM on the net.

Q:Pros and cons for each dumping method and dumps collection?
A:
Trurip:
+well researched and still actively developed
+offset correction
+support for weird disc formats, which noone else handles properly.
+closed dumping from trusted dumpers (also tool helps exclude potential foul play on any party's side)
+-intended inclusion of other files (scans etc) in same zip. All dumps of similar disc bundled together. Some like that, some not (less zips floating around and all relevant data packed together but has drawbacks-eg you need to download/handle 4GB+ of data to play one version of the japanese Virtua Fighter 2)
-ccd format is harder to use, only CloneCD supports it very well. Also can't use tools like region patchers on the format.
-smaller collection for many systems, since the method is the newest around and dumpers are few (not helped by tool not being public)
-naming scheme with many numbers in the filename, confusing to (my...) eyes. Also lack of clear language indication (good luck determining if any German PSX disc supports English, good luck finding games that support languages other than English without running them first)
-inclusion of files with bad subs, these are virtually unusable in most cases
-subchannel files can never be verified and contain random errors, even when reading same perfect condition disc on same system twice (nature of CD media)
Redump:
+huge coverage for some systems like PSX, only choice for systems like PS2 and Gamecube ATM.
+offset correction
+-single dump for most cases (con: different offsets are hacked to match "intended" data on disc, disregarding actual positioning of data on the real disc. Gives less data to download, is not a real representation of actual different discs)
-unverified games included (quite some dumps proven wrong later and changed and certainly more lurking in there) and dumps included even from untrusted sources (not completely unknown to find "scene" dumps masquerading as Redump dumps-just last week I found one on PSP. Have info it also affects PS2, maybe more?)
TOSEC ISO:
+rigorous verification, only includes dumps from trusted sources that were matched by two dumpers working independently in dumping different discs. Leaves no room for unintended errors or intentional foul play.
+excellent collection on many systems, still unsurpased by the others.
+-good descriptive and concise naming scheme (TNC). Sometimes results in unreasonably long filenames though.
+wav files usable outside of virtual drives (eg you can directly listen to disc audio tracks)
-no offset correction
-no active work being done (except DC)
-method is older, so minor details like gaps and small (milliseconds, inaudible...) amounts of CD Audio information at end of disc might be lost.
Darkwater:
+Aimed to gamers, with decent quality dumps
+Big collection on some systems like Saturn.
-Haphazard method using only off-the-shelf tools, much less researched than any others.
-Results can't be verified by other dumpers unless working with same drive.
-No offset correction
-Very inconsice naming
-Harder to come by/collect if not member of the group

Q: Best collection, by system?
Can't be done without mixing and matching, since all groups have dumps not done by others.
With that in mind, here are my suggestions on what's "best" currently if wanting to only collect one. Not mentioning niche systems as you can easily grab everything available for those and I am not too familiar with them either:

3DO: TOSEC-ISO. A huge collection of verified dumps, certainly the most detailed 3DO set around ATM. Disc format is simple, so you are losing nothing compared to newer methods.
CD32/CDTV: TOSEC-ISO. Again a massive and almost complete collection
CD-i: in terms of regular discs, TOSEC-ISO again has the most exhaustive collection on the net. Regarding movie discs and CD-i Ready, Trurip, since the former were conciously not added to TOSEC-ISO, while the latter is a strange format not supported by other dumping systems. But they still haven't appeared in public...looks likely to change soon though...
PSX: Redump is a huge and almost complete collection. Drawback that the relatively few Libcrypt games need additional files to support them properly, so I'd prefer Trurip for those.
PS2: Only Redump handles this ATM
Gamecube: Only Redump handles this ATM
XBox: Only Redump handles this ATM
DC: TOSEC-ISO has the most updated and complete collection of verified dumps. Trurip comes close (most dumps are identical since dumping method for GD-ROMs is the same and I share dumping info between TOSEC-ISO and Trurip, matter of naming choice only there) but it also supports MilCD (unhandled by other methods) and includes a few unverified dumps that won't be added to TOSEC-ISO until verified. But Trurip tends to lag behind when it comes to new additions to the dat.
SegaCD: Trurip...high quality and almost complete.
Saturn: Redump has a huge collection in all regions. Trurip might have won for higher overall quality if it wasn't so lacking in the US set.
PCE: Trurip all the way
PC-FX: Trurip all the way
NeoGeo CD: Trurip is more accurate and thorough than anybody else.
Jaguar CD: Trurip all the way
PC: Redump is massive...if you can find it anywhere...

Might come up with more answers, if given more questions. 
/EOWall of Text

[sudopinion]

.

[djvj]

tasty that's a ton of information that I'm not concerned about. I'm only concerned about the programming aspect of it to make it work and the feasibility of the alternate databases (which are required for any of this to work regardless of what you may think) can be created and/or kept upto date. We don't have HS xmls complete, so how is a 2nd remapping set going to be worked on and by whom?

What everyone needs to remember who is pushing for this, is HS is database driven. Everything has to match the db otherwise it doesn't show. There is no other way around this, naming must be strict and clean. To match one set of strict names to another, which cannot exist in the same xml file, requires 2 databases, your HS xml, and your remapping one. The remapping one can be ini or xml. I suggest ini because it's easier to read for end users, and much faster in ahk. XML has more potential though and can contain a crc and be possibly be loaded directly into clrmame to rebuild your set if you wanted.

It would actually be relatively easy to get a simple romNameAlt to work. The more difficult one to create and maintain is the goodsets one. I agree with you and deal with it over on my end. I have 2tbs of PS2 and GC rips that I can't use simply because I need to seed them on a torrent and can't change their name. You don't need to convince me of the usefulness of it, I care not about validity of rip A or rip B and who did it. I don't have time to play any of this shit with all the time I spend on HL.

Rain, I 100% agree with you, but for many this is a problem and has spawned many threads and it's hard to ignore as a real problem. And I would love to throw more hds into my server, but it's full now and unless I throw a ton of money into a bigger one, I can't fit everything I collect (movies/games/music/pr0n). Which is why it's not feasible to have my cake and eat it to.

So from the example dats tasty, it looks like they all maintain the same file name as they do inside, which is good, except trurip....Wtf is up with Games (US) foldername?? Is that some joke to strictly make everyone's life difficult? Also trurip doesn't maintain the same filename inside. So that falls under the same boat as good sets.

[tastyratz]

Trurip is certainly one I would think much harder to tackle - it just seems that their sets are becoming far more prevalent (why I mentioned them). Might be able to loosen requirements up for 7z support and either look for *.xyz filetype upon extraction, or rename on extraction (Might not work as cleanly). Definitely probably more of a pain in the ass to deal with. Since they do at least provide dats, so maybe parsing what to expect is the better answer in that case? It looks like it's always in order of game name - game file name - sub files.

So if this was done in INI format, it couldn't support a crc tag?

Get your ps2/gc set from UG? That's what I'm looking at now too and I am trying to seed them. I sure would love to just play though...

[djvj]

A CRC tag is only useful when you want to match the file to a name in a renamer, like clrmame. In the ini for HL, it has no use. Sure you can put it there, but HL would never use it and clrmame doesn't read inis, so what's the point?

The folder in trurip serves no point and should never be in the dat. That's just someone trying to enforce a dumb idea on everyone else for no good reason. All it does is add to confusion and make it difficult for devs to support running their games directly. I think what I would do on extraction though is ignore all folders and place the files all in the romname folder. I'm pretty sure this will still work from the looks of that dat. But the annoying part is the internal name, this has no match. I would either require the other internalName var or somehow assume the first file is the rom. Problem is how does this differ from system to system. Do I go by extension? Cause other systems won't be a gdrom.

I have checks in place in 7z so that I do not bother to extract if I didn't find your romName inside. This avoids errors after extraction, which could take a minute or 2, about not finding romName to send to the emu.

I think my sets were from BCG and UG

[brolly]

For goodmerged sets, I'd simply list all the roms inside the zip and let the user select one, no one should be using these sets for gaming anyway so if they are it's because they actually want to be able to play the 100 variations of each game... goodsets are not for optical discs based systems so their size is small, there's no real reason for a user not to have another set of roms with proper names for playing.

For stuff like trurip, a good workaround would be to simply find the rom you want to run inside the zip file that matches the extensions in the ini file, in that example it would be the first .gdi file found regardless of the name, extract it and launch that file.

[tastyratz]

Brolly has a good point... and on that thought... Why fail out when multiples are detected at all? Why not instead trigger a dialog when hl doesn't know what to do?

This could even be controlled in the INI under "prompmultiples=true" or something along those lines if people DON'T want that capability on a set.

[djvj]

Because creating an environment for a user to select such things is 10x more work then simply erroring out. HL no longer has the old msgboxes you are used to. I do not use standard windows to navigate. It's all in GDI. The environment has to adjust in size to your resolution, font's have to be big enough to see. There are more things that I'm not getting into right now, but it's easy for someone to sit back and say "give a choice" when you don't understand what's involved.

Problem with simply matching an ini extension is what when you have more then 1 ini extension? Users like to put cue/iso/bin. They will start loading wrong images and getting errors not knowing why. And because I let it through and assume it's the right file, I cannot error on it. I dislike programming in assumptions and guesses that it's what you want to use because someone will break it. One name comes to mind....

[johnsanc]

It's hard to have your cake and eat it too. I see where tasty is coming from. I too think that ideally HS should work with my sets and not the other way around.

I really only see this a concern as we get to disc based games:

1) There are different dumping approaches and users may have a preference for one but still must use various sources to cobble together a (mostly) complete set. This means people are trying to maintain their sets by dumping group.

2) The sizes are just huge. Lets be honest, most people want to seed these or be able to rebuild their sets as updates come out. It's just not feasible to have a 2nd copy of several TB of games just to abide by a front ends naming convention.

3) The HS naming conventions and data basing are top notch, but each group will always name however they see fit and they will never really match HS out of the box. (Aside from no intro)

I think solutions should be built based on the need. And this an issue where there is a need. However, people like tasty and I may be in the minority and this may not be worth solving if the majority only care about slapping sets together purely to work in HS.

Whatever happened to the concept of a massive CRC database? That wouldn't solve the alt names issue but would at least extend the exact match renaming to disc based systems.

Has anyone really sketched out an ideal state and how we might be able to make it work?

[djvj]

HL's media folder surpasses HS's now and we use the HS romName's to do the matching. This reason alone is why HS still needs to pass the standard romName to HL, not a romNameAlt. I mean, HS could always pass a 3rd parameter and I can handle it. but I doubt BBB is ever going to add that.

[ghutch92]

I can see how its not feasible to have 2 different sets of 2 TBs worth of roms.

I see no alternative other than:

%SystemName%\Remap.ini

[%HyperListRomName%]

#RomAltName is the name of the file (sans extension) to be sent to the emulator, if 7zip is enabled it is the name of the rom you want to use inside the archive. If this key does not exist or is empty assume user does not want a remapped name.

romAltName = altname.extension

#this key is for 7zip use only. If this key does not exist or is empty, HL will use romAltName as the name of the archive.

romArchiveName =

HyperLaunch.ini

[7zip]

#If enabled, HyperLaunch will display a list of all the files in the archive if romAltName or romName (if romAltName doesn't exist) could not be found

7zip_Multiple_Roms_List_Enabled = false

#If enabled will write the name of the chosen rom to the remap.ini romAltName key

7zip_Multiple_Roms_List_Remember_Chosen_Rom = false

7zip_Multiple_Roms_List_GDIKeys = whatever keys djvj or bleasby feels like putting here for the gdi screen

If this feature is implemented in HL, it most likely postpone HL Beta for at the very least three months. This means editing the 7zip function, creating a new GDI menu, and editing all of the modules (100+ and growing).

[tastyratz]

Please forgive my ignorance here as I am not a programmer and only somewhat assume the ramifications, but could we assume an archive and search by extension type? i.e. when an archive is detected with that file name, but a file with a valid extension by the same name is also detected - ignore the archive. If the archive is there but the preferred file extension is not, treat as archive.

The assumption is that the archive name does not follow suit with the rom naming - and this is sometimes but not always the case.

Also again forgive my ignorance- with hl2 global settings ini... why modify every single module unless needed? Can we assume those settings specified are default unless otherwise overridden in the module?

Remember chosen rom should always be the case, however more appropriately Automatically_launch_last_chosen_rom should be it's own setting. If that is true, it just opens the last opened game. If it's false you still have the selection screen highlighted on the last chosen rom.

3 months is a lot of time and work and i know there is a long list of wants and needs. If you guys do this please make sure to weight it accordingly to what you feel is best for the project and your time.

[djvj]

Trust us, how the modules work, every one has to be updated to support this. Currently every module has a line something like this:

Run, %executable% "%romPath%\%romName%%romExtension%", %emuPath%

romName cannot change, because it will break art being used in features in the module thread. All art is pulled using this var. I don't need to change 7z() in the module because it's an injected/external function, so I can put confitionals in 7z() itself. Module Run lines are NOT a function because these lines can be very different from one module to the next. They need to stay this way. Some emu's you do not pass a romname in the run line, so it needs to be passed a romNameAlt earlier. So that line needs to use a ternary conditional like this:

Run, % executable . " """ . romPath . "\" . (If romNameAlt ? romNameAlt : romName) . romExtension . """", %emuPath%

[tastyratz]

ahh ok. That makes sense.

Thinking about this more in the way you 2 presented it this could open up support for merged sets too...

[djvj]

Spent the day thinking about this and I decided to separate romName from the rest of HL. So in HL, romName is no longer the var used. I use dbName now. romName now only exists in the module and will only reference the actual rom being loaded. Think of this as romnamealt and romname, but being separate, opens up the ability to freely change romName and not affect artwork throughout HL. So I should not need to change anything in the modules as I inject for now "romName := dbName". Later, I can change that to something else like "romName := romNameAlt" and not affect artwork. Much better idea then changing every module.