add support to extractcd for GDROM .cue/.bin #7717
Conversation
src/lib/util/cdrom.h
Outdated
| enum gdrom_pattern | ||
| { | ||
| GDROM_TYPE_UNKNOWN = 0, | ||
| GDROM_TYPE_I, | ||
| GDROM_TYPE_II, | ||
| GDROM_TYPE_III, | ||
| GDROM_TYPE_III_SPLIT | ||
| }; |
There was a problem hiding this comment.
As I said before, this is an artificial classification based on observation of pressed discs, not something inherent to the format. It doesn’t belong here.
There was a problem hiding this comment.
I've split the GDROM routines out to gdrom.h and gdrom.cpp and updated build files. 38a7fd7
There was a problem hiding this comment.
No, it doesn’t belong in a public header at all. It should be internal to the CHD conversion code. It’s an artificial classification and not something inherent to the disk format.
There was a problem hiding this comment.
It's used in two source files chdcd.cpp and chdman.cpp. It could go in chdcd.h although that's also a public header. If no header is acceptable what's the alternative?
There was a problem hiding this comment.
Moved to chdcd.cpp and chdcd.h in 0d4bb49. The function is used in chdman.cpp:do_extract_cd() so the prototype and enums need to be in chdcd.h. If that's wrong there is a more disruptive option that involves moving the bulk of do_extract_cd from chdman.cpp to chdcd.cpp. However that will affect existing code that's unrelated to this pull request so the least-disruptive option is on the table first.
…nto extract_gdrom_cue
ghost
requested a review
from
src/lib/util/cdrom.h
Outdated
| static inline uint32_t reverse32(uint32_t x) | ||
| { | ||
| x = ((x & 0x55555555) << 1) | ((x & 0xAAAAAAAA) >> 1); | ||
| x = ((x & 0x33333333) << 2) | ((x & 0xCCCCCCCC) >> 2); | ||
| x = ((x & 0x0F0F0F0F) << 4) | ((x & 0xF0F0F0F0) >> 4); | ||
| x = ((x & 0x00FF00FF) << 8) | ((x & 0xFF00FF00) >> 8); | ||
| x = ((x & 0x0000FFFF) << 16) | ((x & 0xFFFF0000) >> 16); | ||
| return x; | ||
| } |
There was a problem hiding this comment.
There are helpers for doing this stuff in one of the headers in src/osd already.
There was a problem hiding this comment.
You’ll have to be more specific. I don’t know the helper you’re thinking of.
ghost
closed this
|
Hello @nhand42, I see you closed this request. Does it means we will be able to rollback .chd files into Redump .bin/cue files with the new chdman 0.237 release ? |
|
The functionality was not merged. At some point it will need to be handled, since as it stands now you can't round trip Redump cue based chds. That said, I don't know the exact situation as it stands now. Seems like changes were requested, with one side waiting on changes and the other waiting on feedback that wasn't provided/available. Presumably the closure was based on frustration with that standstill, rather than any actual statement on viability or readiness. |
|
Hello @Sanaki and thank you for your explanation. I find this way is too bad. I know some people are looking for this functionality too. I understand Dreamcast dumps support is not essential here because MAME doesn't emulate this hardware. But if Nhand42 can provide a forked version and/or a Windows binarie of the chdman tool with its own code to rollback .chd files into ReDump's .bin/.cue files, it could be very helpfull. |
|
It's sad to see this closed instead of being part of MAME. Redump CHD is the better format and it would be great if chdman supported it (completely). No idea why we ended up in a dead end to begin with (@cuavas could've merged this ages ago since it's basically ready) but it is what it is. @KingKebab Edit: The files this PR touches aren't actually much different compared to February, so a rebase was pretty easy. I applied my fix and had to change a line (see diff) but it compiled and a quick test confirmed that it still works. |
|
Hello @Anuskussssss, Thank you very much for your personal compiled release. I performed a try with the 4 Wheel Thunder (USA) dump and I was able to rollback my .chd into it's original .bin/.cue format. I did a binarie comparison for each file and it's absolutely perfect. Now I will try with the Dreamcast fullset (it will probably take a long time) and then I will let here a feedback. |
|
@KingKebab I've updated chdman to v0.236 just for the hell of it. Please test. |
|
@Anuskussssss I performed a rollback test using the Sega - Dreamcast - Datfile (1364) (2021-01-13 15-00-42).dat file from ReDump. I did a binary compare of all files. All .bin and .raw files rollbacked are excatly the same as their original file except for 3 disc dumps only : . Shenmue II (Japan) (Disc 2) . Shenmue II (Japan) (Disc 3) . Shenmue II (Japan) (Disc 4) For this 3 disc dumps, the Track 3 files are missing data at the end of the file in the rollbacked file. I tried a full process (.bin/.cue => chd => .bin/.cue) with your two chdman version from 0.228 and 0.236. I find this result is strange. Because there is no data trouble with other Shenmue II european disc dumps. Now I'm looking to update my Dreamcast set with the latest 2021-10-06 .dat file from ReDump. Perhaphs my original dumps for Shenmue II (Japan) were corrupt and their .chd wrongly compressed. |
|
@KingKebab Thanks for testing, I can reproduce this. Will investigate once I find some time. |
|
Hello @Anuskussssss @nhand42 I updated my Dreamcast romset and I was able to rebuild the fullset with the latest ReDump .dat file (2021-10-06). 0 missing. I did a full and long process to convert/rollback all GD-Rom dumps. And I found another one with the same issue than Shenmu II's discs : Virtua Figher History & VF4 (Japan) So this game has only one disc and it's easier to test in an emulator than using Shenmue II's additional discs. In Flycast, I can boot and start the original .bin/cue dump of Virtua Figher History & VF4 (Japan) porperly. But the .chd converted file can only boot the disc, but not start the game. I suspect something broke while the chdman tool convert the original dump into CHD format. Because all other converted .chd can boot and start properly. I think, this is the reason why the rollback into .bin/.cue is wrong too. I performed the same test with the official chdman tool release and I get the same unworking .chd file for this game. In any cases, thanks a lot you two for your help. This chdman hacked version works with most GD-Rom dumps. It's an incredible great job. Now I will be able to free many disc space on my hard drives and keep them as CHD files for storage. Except Shenmue II, Virtua Fighter History and all MIL-CD dumps (for them I use .7z). |
|
Thank you very much for the modified chdman. It would be helpful to a lot of people if either you or @nhand42 put an up-to-date modified chdman (fork?) on your github page since that the MAME team seem to be uninterested in implementing this in the official chdman. |
|
The MAME team is not uninterested, as you can see in earlier comments. They simply weren't content with the quality of the PR as it remained, and none of them have expressed interest in dropping their other priorities to pick this up themselves. If someone addresses the concerns mentioned in review earlier and submits a new PR, they'd likely be happy to merge it. |
|
Sorry for misunderstanding |
|
I'm absolutely interested in having the support in official MAME, but the PR had issues that were never resolved by the submitter. If @Anuskussssss has a better version of the patch and is willing to correct anything found on review, they can submit it themselves. |
@Anuskussssss contributed nothing to this patch and has been blocked for abusive language. He keeps evading the blocks by creating alt accounts. I asked for more info and was ignored for around 9 months. I have no idea what the concerns are and the reception was ice-cold, so the PR is withdrawn. |
|
@rb6502 I fixed the code, but the changes are garbage because I'm not a C++ developer. I personally don't care how it looks, as long as it works. Feel free to do whatever you want with the code, but it's probably not up to MAME's standard. Guess you guys will be stuck with a broken chdman until somebody writes better code then. @KingKebab I only tested Shenmue 2, but all broken (Pattern III without audio) ROMs should be fine now. My changes don't affect any other game besides the broken ones. Do you actually have a full set? I'm actually relieved knowing that we have 100% compatiblity now (minus the MIL-CDs of course). Hopefully the guy on the Internet Archive maintaining the Redump CHD set will update those broken CHDs (and finally remove the bad Redump GDI CHDs). If it's not too much work, I'll rebase and recompile an EXE once in a while until either somebody creates an actual PR or this thread gets locked. Edit: I didn't realize that v0.237 has already been released. See below for an updated build (#7717 (comment)). @KingKebab No need to retest this version, as no functional changes have been made. |
|
@Anuskussss and @Anuskusssss and @Anuskussssss and @Anuskusssssss keep it civil! |
|
@Anuskusssssss Congratulations. I just did a quick test with your new chdman release for these dumps : And everything is all right. Your fix doesn't affect previous working dumps like Ikaruga or Jet Set Radio. But it fixes Shenmue II (Disc 2, 3 and 4) and Virtua Fighter History dump issue. Their .chd can now boot and start in Flycast emulator and I can rollback their .chd into .bin/.cue. All audio and data track have the same binary sum. I own the fullset Sega - Dreamcast - Datfile (1405) (2021-10-06 20-36-04).dat from ReDump and I will make a new full test with your latest release to be absolutely sure everything is perfect. I wrote some scripts to did it. It will take few days on my computer then I will let a feedback to confirm. I'm optimistic about the result. |
|
@happppp Don't try to stir up drama when there's none. I don't care about @nhand42, or anyone else in this thread for that matter. I would like to use this functionality myself, saw that somebody created a PR and tried to help where I could. Latest version (v0.237): chdman.zip |
|
No drama? To me it looks like it's more than enough to put in a soap opera arc, I'm not blaming you for him closing this PR. That's on us for ignoring his code review requests for 9 months. |
|
Anyway, this PR is dead after the author removed his branch and left github. It looks like RB is pretty lenient on you so no matter how much I'm disgusted with your lack of etiquette, I don't expect to see a ban coming. |
|
@Anuskusssssss I restarted my conversion script process with your new chdman 0.237 release... so now, wait and see for the result. If we don't get new issue to rollback .chd files into .bin/.cue, any user can easily keep your fixed chdman release as a standalone binarie tool. But only for use with Dreamcast .bin/.cue dumps. In my memories, some MAME members were disliking ReDump's dumps and they prefer Tosec's dumps instead (cf: #6466). This means, you'll not need to provide a next release. It's a finalized tool. And no matter about how code is writted inside, nobody knows^^ |
|
It isn't finalized. It's a kludge solution that's good enough for one use case on one operating system. Support will still need to be added in another PR at some point. |
|
@happppp Again with the gaslighting. Just drop it. If you wanna talk about your feelings, send me an email. This is not the place for that.
It's always "or anyone". Why don't you just take my code and merge it then? Or even better, improve it? Otherwise, please refrain from creating any more useless comments. You know that everyone in here gets a notification everytime you speak. If you find a game that doesn't work, and isn't a MIL-CD, you may comment again. @KingKebab Well, I know that it's technically finished, but I'd still like to inherit any new changes/improvements made to the codebase. I also dislike the idea of having to keep multiple copies of chdman, so I will keep supporting it as much as I can. I don't mind spending less than an hour a month rebasing and recompiling this. Only when it takes longer than that (possibly when CHDv6 releases), will I probably stop uploading new builds. @Sanaki I know you have no idea what you're talking about, but I'll entertain the idea that you're really that oblivious. If you would've read my comments, or you know, downloaded my ZIP, you would've found out that I included diffs. If you need help applying my patches and compiling MAME, google it. This is not a support forum. |
Cool, I stand corrected on the one operating system part. Still needs to be fixed up and submitted properly at some point. I compile MAME myself, I just have no need of this feature until it's properly merged, because my use case involves more widespread deployment where "grab a file someone uploaded" isn't viable. As such, I didn't bother looking at it directly, since it would serve no purpose in my hands at this time. To be clear, I'm not disparaging the work done. It's great for people who have a use for it now. It just isn't "done" until it's merged. And had I the knowledge to fix it up to MAME's standards, I'd be more than eager to do so, but unfortunately that's beyond me. |
|
If you want to maintain it with diffs and attachments, do it at https://github.com/Anuskuss/chdman |
This adds support to chdman extractcd for Redump GDROM .cue/.bin format. This complements an earlier patch adding Redump GDROM .cue/.bin support to createcd.
This has been tested and works well for TYPE_I and TYPE_II discs. For those GDROM types the output from repeated createcd -> extractcd cycles is byte-identical.
Type I disc.
Type II disc.
For TYPE_III some of the Redump data is thrown away by createcd. For example frames 75 - 224 in the final track. These are zero frames and can be recreated by populating the sync bytes, the MSF, the mode, then calculating the EDC/ECC. The EDC routines have been copied mostly verbatim from cdrtools (licensed LGPL). For the TYPE_III titles tested so far, the output from repeated createcd -> extractcd cycles is byte-identical.
Type III disc.
This code does assume the zero frames don’t contain any purposefully inaccurate EDC or ECC data as for copy-protection. This should be true for every legitimate Dreamcast GDROM but if there is an exception please let me know.