|
Update @ RB's: Regarding CHDMAN in 0.146u2
#291181 - 07/08/12 05:26 AM
|
|
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Smitdogg]
#291194 - 07/08/12 09:42 AM
|
|
|
Where to get the newest version of CHDMAN?
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: rad_killer]
#291195 - 07/08/12 09:50 AM
|
|
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291197 - 07/08/12 10:37 AM
|
|
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: rad_killer]
#291203 - 07/08/12 01:26 PM
|
|
|
Even with this, the computer will eat you alive on a memory.
So there is a website you can grab them all.
And very soon will be added all. 
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Lewis King]
#291240 - 07/08/12 07:43 PM
|
|
|
Some if not most people do not have bandwidth to burn for nothing and besides that, it's more fun to convert your own.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291273 - 07/09/12 02:11 AM
|
|
|
I prefer to convert my own but I wouldn't call it fun. 
|
|
|
| H@P |
|
Lurker in perpetuity
|
|
|
|
|
Reged: 09/22/03
|
|
Posts: 234
|
|
Loc: Seattle area
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Smitdogg]
#291292 - 07/09/12 05:12 AM
|
|
|
So...
Now that all OS's create identical files, when someone converts all their v4 CHDs to v5, can they post a list of ms5sums or sha1sums of the whole .chd container so we can make sure everything worked as expected?
And isn't it dependent on the compression method chosen? Or is there only one compression method supported now?
H@P
|
|
|
| *=/STARRIDER\=* |
|
MAME Punk
|
|
|
|
|
Reged: 02/06/12
|
|
Posts: 335
|
|
Loc: an open field west of a white house with a boarded front door.
|
|
|
|
Send PM
|
|
|
Isn't the compression chd? nt
[Re: H@P]
#291295 - 07/09/12 05:48 AM
|
|
|
ntmf
|
There is no law in the arena
|
|
|
Re: Isn't the compression chd?
[Re: *=/STARRIDER\=*]
#291307 - 07/09/12 11:30 AM
|
|
|
WTF does that even mean? CHD supports a number of compression algorithms (Huffman, LZMA, FLAC, uncompressed, etc.). If you don't explicitly tell it to use a particular compression scheme it will choose one based on the data. Given the same data, the automated choice should be the same for any OS.
|
|
|
|
Re: Isn't the compression chd? nt
[Re: *=/STARRIDER\=*]
#291308 - 07/09/12 11:35 AM
|
|
|
no, chd is the container which uses various compression methods depending on the data
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: H@P]
#291309 - 07/09/12 12:20 PM
|
|
|
> And isn't it dependent on the compression method chosen? Or is there only one
> compression method supported now?
disk by disk, chdman does some test and chose the method which gives the best result
hence, unless you force a specific compression scheme (which might give a different end result), the default one should give the same result on every machine and every OS
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Smitdogg]
#291319 - 07/09/12 06:21 PM
|
|
|
> http://rbelmont.mameworld.info/
I'm so glad that I stayed with 0.145
I'll wait till 0.150, because I expect more fixes to chdman in the future. It seems v5 chd format is not ready yet.
|
Daffy Duck
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: DaffyDuck]
#291322 - 07/09/12 06:46 PM
|
|
|
Personally, I'm hoping its possible to create a diff file to patch the recent slew of bad dumps. Seems like it would be simple if all they're missing is gap data....errr...whatever is supposed to be missing.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: DaffyDuck]
#291324 - 07/09/12 07:03 PM
|
|
|
> > http://rbelmont.mameworld.info/
>
> I'm so glad that I stayed with 0.145
>
> I'll wait till 0.150, because I expect more fixes to chdman in the future. It seems
> v5 chd format is not ready yet.
you're wrong.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: DaffyDuck]
#291325 - 07/09/12 07:28 PM
|
|
|
> > http://rbelmont.mameworld.info/
>
> I'm so glad that I stayed with 0.145
>
> I'll wait till 0.150, because I expect more fixes to chdman in the future. It seems
> v5 chd format is not ready yet.
It should be ready now, with the fixes we pass valgrind cleanly and it's verified that conversions match across machines/OSes.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: etabeta]
#291330 - 07/09/12 10:14 PM
|
|
|
> > > http://rbelmont.mameworld.info/
> >
> > I'm so glad that I stayed with 0.145
> >
> > I'll wait till 0.150, because I expect more fixes to chdman in the future. It seems
> > v5 chd format is not ready yet.
>
> you're wrong.
Plus, why wait 3 years of official releases to use something it has been tested by community and developers?
I think I can finally test the tool on those SEGA CD/PCE CD CHDs, they're taking too much space. But just in case I'll painfully backup everything on DVD-RWs first.
EDIT: Wrong idea, that's at least 70 DVDs. I'll get another drive.
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: R. Belmont]
#291334 - 07/09/12 11:34 PM
|
|
|
> It should be ready now, with the fixes we pass valgrind cleanly and it's verified
> that conversions match across machines/OSes.
What would happen if I took a version 5 chd that was pre 0.142u2 and did a copy of that using chdman version 0.142u2? Would that end up with a 'correct' chd?
Is there anywhere that has the check-sums posted?
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291335 - 07/09/12 11:46 PM
|
|
|
> What would happen if I took a version 5 chd that was pre 0.142u2 and did a copy of
> that using chdman version 0.142u2? Would that end up with a 'correct' chd?
>
> Is there anywhere that has the check-sums posted?
You need to be more specific with detail about what you're doing.
CHDs that were dumped as V5 with the latest chdman (at that time) pre 0.142u2 will be just fine. An example of that would be voyager.chd or undefeat/gdl-0035.chd
As far as making a copy I'm unsure why you would need to do that. Always work with the latest version of chdman when possible and applicable.
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291336 - 07/09/12 11:51 PM
|
|
|
I converted my chds before the bug was found where the files differed between OS's. I think I used chdman from 0.145u6 or something like that. After I was done and they all passed verification, I deleted the originals. I do not have all of them.
I have some (not all) backed up in a Ghost image, so I guess I could try to convert a version 4 chd and see if it comes out the same as the ones I recently copied with chdman version 0.146u2.
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291337 - 07/09/12 11:53 PM
|
|
|
Oh BTW, some of the chd files did differ when I recopied using chdman 0.146u2. Some were exactly the same.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291338 - 07/10/12 12:02 AM
|
|
|
> > It should be ready now, with the fixes we pass valgrind cleanly and it's verified
> > that conversions match across machines/OSes.
>
> What would happen if I took a version 5 chd that was pre 0.142u2 and did a copy of
> that using chdman version 0.142u2? Would that end up with a 'correct' chd?
From my understanding, that's exactly what we should do if we want to have seedable chd's. If wont seed it, you don't need to do anything, 'cause the check-sums didn't change, just the sizes.
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Ramirez]
#291339 - 07/10/12 12:09 AM
|
|
|
The checksum of the chd file is different too. I'm not talking about it's contents, nut the actual chd file.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291340 - 07/10/12 12:19 AM
|
|
|
> The checksum of the chd file is different too. I'm not talking about it's contents,
> nut the actual chd file.
Strange... I thought only the GDroms (that need redump) would change the checksums.
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Ramirez]
#291342 - 07/10/12 12:36 AM
|
|
|
There was a bug in chdman that caused things to be compressed in a different order across OS's causing the chd file itself to differ. The chd is still good but could be different than one made on another OS.
I just converted several v4 CHDs to v5 using chdman version 0.146u2 and compared the results to the ones I converted from v4 to pre 0.146u2 v5 to 0.146u2 v5. The results are seem to be the same. So, if someone converted to v5 before 0.146u2, their chds may differ than someone else's chd file made with chdman 0.146u2.
The chd's on my D Drive were double converted.
The chds on the F drive were just converted from v4 chds just for comparison.
They match perfectly.
Quote:
Path: D:\MAME\chds\area51\
Name: area51.chd
Size: 498022497
CRC32: b353301d
MD5: ef3b1b835540f1fa00e37b98b0623a17
SHA1: f568066ec4039a615757281e590629f84bf98f7e
Path: F:\
Name: area51.chd
Size: 498022497
CRC32: b353301d
MD5: ef3b1b835540f1fa00e37b98b0623a17
SHA1: f568066ec4039a615757281e590629f84bf98f7e
Path: D:\MAME\chds\calspeed\
Name: calspeed.chd
Size: 458857944
CRC32: c21db670
MD5: 328d2f209d2ddab489b62d177c4177ab
SHA1: f5de6d157d7311feb3d0fcbd2ee8f471f280dc21
Path: F:\
Name: calspeed.chd
Size: 458857944
CRC32: c21db670
MD5: 328d2f209d2ddab489b62d177c4177ab
SHA1: f5de6d157d7311feb3d0fcbd2ee8f471f280dc21
Path: D:\MAME\chds\sf2049\
Name: sf2049.chd
Size: 786481919
CRC32: 89366889
MD5: 235ed2926b67cfa7e8d54d10f8d40807
SHA1: 71348f083b1610e89e5e2c7190f168bb30708fdd
Path: F:\
Name: sf2049.chd
Size: 786481919
CRC32: 89366889
MD5: 235ed2926b67cfa7e8d54d10f8d40807
SHA1: 71348f083b1610e89e5e2c7190f168bb30708fdd
Path: D:\MAME\chds\sfrush\
Name: sfrush.chd
Size: 46799360
CRC32: 13bca723
MD5: c1e3c56512a70f6e1a9e34a4cc107e88
SHA1: 8a0ff76f7005fbdaeb472e6f0026f21711967e05
Path: F:\
Name: sfrush.chd
Size: 46799360
CRC32: 13bca723
MD5: c1e3c56512a70f6e1a9e34a4cc107e88
SHA1: 8a0ff76f7005fbdaeb472e6f0026f21711967e05
Edited by redk9258 (07/10/12 12:43 AM)
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291346 - 07/10/12 01:21 AM
|
|
|
Funny, just now I started to convert from v4 to v5, everything was going smooth... until this:
beatmania IIDX (863 JAA) [system: Twinkle System - folder: bmiidx - size: 1mb]
wrong chd sha1: 863jaa01.chd [wrong: 0f40d835e8a7bbe574fba2cd9e51c5df4cc05bb1] [right: aee12de1dc5dd44e5bf7b62133ed695b80999390]
wrong chd sha1: 863jaa04.chd [wrong: a6fd6a69cd67a90e03c4b5a19ef7cbeee9c6c0b3] [right: 8f6a0d2e191153032c9388b5298d8ee531b22a41]
I'm re-downloading 'cause I've deleted the old one... let's see what happens...
EDIT:
It happened again... was this game a bad dump or it's a problem with CHDman? Or maybe I did something wrong...
Edited by Ramirez (07/10/12 01:34 AM)
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Ramirez]
#291349 - 07/10/12 02:22 AM
|
|
|
> Funny, just now I started to convert from v4 to v5, everything was going smooth...
> until this:
>
> beatmania IIDX (863 JAA) [system: Twinkle System - folder: bmiidx - size: 1mb]
>
> wrong chd sha1: 863jaa01.chd [wrong: 0f40d835e8a7bbe574fba2cd9e51c5df4cc05bb1]
> [right: aee12de1dc5dd44e5bf7b62133ed695b80999390]
>
> wrong chd sha1: 863jaa04.chd [wrong: a6fd6a69cd67a90e03c4b5a19ef7cbeee9c6c0b3]
> [right: 8f6a0d2e191153032c9388b5298d8ee531b22a41]
You're not supposed to convert that one because it changes SHA1 when converted. That particular one as well as many others should stay in your set as V4.
Also, please do not discuss downloading and such as it's against the rules of this board.
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Ramirez]
#291350 - 07/10/12 02:28 AM
|
|
|
I don't have those two, so I'm not sure. I think this is one of the ones that are reported as a bad dump..
Code:
ROM_START( bmiidx )
TWINKLE_BIOS
DISK_REGION( "cdrom0" ) // program
DISK_IMAGE_READONLY("863jaa01", 0, BAD_DUMP SHA1(aee12de1dc5dd44e5bf7b62133ed695b80999390) )
DISK_REGION( "cdrom1" ) // video CD
DISK_IMAGE_READONLY("863jaa04", 0, BAD_DUMP SHA1(8f6a0d2e191153032c9388b5298d8ee531b22a41) )
DISK_REGION( "drive_0" )
DISK_IMAGE_READONLY("c44jaa03", 0, SHA1(53e9bd25d1674a04aeec81c0224b4e4e44af802a) ) // was part of a 1st mix machine, but "c44" indicates 8th mix?
ROM_END
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291351 - 07/10/12 02:31 AM
|
|
|
> Also, please do not discuss downloading and such as it's against the rules of this
> board.
What rule is that? I didn't see him ask for any files or links.
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291353 - 07/10/12 02:46 AM
|
|
|
> I just converted several v4 CHDs to v5 using chdman version 0.146u2 and compared the
> results to the ones I converted from v4 to pre 0.146u2 v5 to 0.146u2 v5. The results
> are seem to be the same. So, if someone converted to v5 before 0.146u2, their chds
> may differ than someone else's chd file made with chdman 0.146u2.
>
> The chd's on my D Drive were double converted.
> The chds on the F drive were just converted from v4 chds just for comparison.
>
> They match perfectly.
None of those in your quotebox were CD and GD-ROM CHDs and just because you lucked out on some of the ones you converted, it doesn't mean the majority of others can roll the same luck. And believe me they did not in a lot of cases.
Since you deleted them you no longer have the option of re-conversion even if you wanted too, which is too bad.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291356 - 07/10/12 03:47 AM
|
|
|
> > Also, please do not discuss downloading and such as it's against the rules of this
> > board.
>
> What rule is that? I didn't see him ask for any files or links.
I also didn't understand this one...
Anyway, it was my mistake. I'm using the last ClrMame build that Roman posted here (not official yet, but seams very good), that isn't supposed to complain about baddumps (it succeeded in this). It complained about one chd in that set, but I updated all chds.
EDIT:
The ClrMame build I'm using was posted here (and I suppose it's newer than v4.06):
http://www.emulab.it/forum/index.php?topic=3428.msg13282#msg13282
Edited by Ramirez (07/10/12 04:00 AM)
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: Ramirez]
#291359 - 07/10/12 04:13 AM
|
|
|
There is much you are not understanding. The version of CMP you are using does not matter in this instance. You are blindly converting all then only realizing you have problems when CMP prompts you or complains. What you're doing is not correct.
A 100% complete set as MAME expects it will be some CHDs converted to V5, some CHDs that were already dumped as V5, and everything marked BAD_DUMP will stay at V4 and is not meant to be converted at this point because of the unintended side effect of the internal SHA1 changing when converted.
Here is a list of what should stay at V4 (from 145) and you are only wasting time and CPU cycles blindly converting.
http://pastebin.com/M3E08jdN
|
|
|
| redk9258 |
|
Regular
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 3968
|
|
Loc: Troy, Illinois USA
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291360 - 07/10/12 04:14 AM
|
|
|
> None of those in your quotebox were CD and GD-ROM CHDs and just because you lucked
> out on some of the ones you converted, it doesn't mean the majority of others can
> roll the same luck. And believe me they did not in a lot of cases.
>
> Since you deleted them you no longer have the option of re-conversion even if you
> wanted too, which is too bad.
I don't think I have any CD or GD-ROM CHDs. I suspect the all others will be OK. I did verify them before I deleted the old ones.
The only difference would be in the compression anyway. It is like using two different applications for a zip file. Both files contain the same thing, but the zip file itself may be different because of the difference in the way the application compresses the file.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291368 - 07/10/12 05:49 AM
|
|
|
> There is much you are not understanding. The version of CMP you are using does not
> matter in this instance. You are blindly converting all then only realizing you have
> problems when CMP prompts you or complains. What you're doing is not correct.
>
> A 100% complete set as MAME expects it will be some CHDs converted to V5, some CHDs
> that were already dumped as V5, and everything marked BAD_DUMP will stay at V4 and is
> not meant to be converted at this point because of the unintended side effect of the
> internal SHA1 changing when converted.
>
> Here is a list of what should stay at V4 (from 145) and you are only wasting time and
> CPU cycles blindly converting.
>
> http://pastebin.com/M3E08jdN
The ClrMame build that I'm using don't complain about baddumps (it came configured this way, but you can change this setting), so I'm not blindly converting anything, I'm converting everything that isn't a baddump. The case about bmiidx, is that I did a mistake.
Thanks for the list, but at first I believe it wont be needed.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: redk9258]
#291369 - 07/10/12 05:50 AM
|
|
|
> I just converted several v4 CHDs to v5 using chdman version 0.146u2 and compared the
> results to the ones I converted from v4 to pre 0.146u2 v5 to 0.146u2 v5. The results
> are seem to be the same. So, if someone converted to v5 before 0.146u2, their chds
> may differ than someone else's chd file made with chdman 0.146u2.
but ramirez was 100% right when he stated that if you don't seed those CHD, then there is no harm in keeping the old one with different checksum: the data is the same, so MAME won't see any difference
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: etabeta]
#291377 - 07/10/12 06:58 AM
|
|
|
Correct. The internal SHA1 will be identical, but the file hashes will be completely different.
|
|
|
|
Re: Update @ RB's: Regarding CHDMAN in 0.146u2
[Re: B2K24]
#291385 - 07/10/12 08:06 AM
|
|
|
> Correct. The internal SHA1 will be identical, but the file hashes will be completely
> different.
I was trying to fight the apparently hysterical "OMG v5 is completely busted" reactions which followed Arbee's post on his blog.
weird, since that post makes quite clear that now the format is solid not only locally (as it already was) but also across multiple OSes
maybe he could have stressed that no CHD for CD or GD have ever been reported to be damaged by the previous chdman (the one between 0.146 and 0.146u2), but probably he did not see it as important given that all GD-ROMs were anyway in need of a redump due to a different (and older) problem in the code...
in conclusion, the uninitialized variables could theoretically bust some files under corner-case circumstances, and even if no one reported it to happen (not even in the conversion of MESS lists), it's good to have them fixed now.
no expected breakage and consistent results across OSes are minimum requirements if we ever want the CHD format to be taken seriously by other emulators 
|
|
|
Previous 
Index 
Next 
Threaded 
Update @ RB's: Regarding CHDMAN in 0.146u2
Reply
[Re: 
