Hello Everyone

I was wondering if it's possible to introduce a modification in Download page to put in evidence the DATs modified in the last 7-10 days in a similar way done on No-Intro Dat-o-Matic.

I update every weekend and this would be very useful to identify what has been changed during the week.

Thanks in advance

Oops, beaten by a mile by fuzzball.
Sorry, I got a phone call right after I started writing the reply

I am learning Japanese so I might share my opinion.
The romanization is somewhat difficult sometimes because Japanese is ofter used in a particual way in game titles.

Ki Suishou vs Kisuishou

yes, ki 輝 and suishou 水晶 are stand alone words and I think you'll never find Kisuishou in any dictionary. But there ki was added to specify suishou, I think that they omitted the no -> 輝(の)水晶 to create an unique word (bright or shining crystal), but this is a very common practice in Japanese language. I actually think that Kisuishou would be the most correct one here but ki suishou is not completely wrong either.
Surely Asapy can clear any doubt as he is very skilled in romanization.

Daisenryaku

This is correct. The prex dai is added to chinese origin words and as prefix it becomes part of the word.
Another common example is 大冒険.
Also, daisen means nothing in Japanese and is not a standalone word.

Ushinawareta

This is ok. wareta is not a separate word, it's the inflected auxiliary verb that is connected to verb stem to inflect the whole verb and create verb forms (potential, passive, causative)

4

(43 replies, posted in General discussion)

Haldrie wrote:

A lot of our dumps are being shared on torrent networks now as well as usenet and most people in the torrent community want something that is easy to extract and not all of them have the latest and greatest hardware. A lot of them even have a problem figuring out packIso (like that's real hard to use). Basically if we are going to use this to help spread our dumps we need to make sure it's going to be usable and accepted by everyone first (or at least the majority of people that know what they are doing) before we start migrating everything to a new format.

Seriously, this...
How could you share the dumps on UG or similar with patches, or unusual ridiculous compression program? 99% of the regular users will just ignore those torrents and the redump.org project will never be out of the niche.

It could annoy more people and offer to the tosec guy another fact to make joke on us. Already now in nearly every UG TOSEC torrent you can read things like "redump.org artificially forges dumps" "redump.org method is the worst of the internet and it's very difficult to implement""redump.org dumps are ghost dumps because 90% of discs listed on their site doesn't exist on the internet" etc... I already can imagine "lol, redump.org dumps are compressed in an abstruse way that it takes hours go get back to a common format, and maybe you have to be an engineer to make this happen")

To go head to head with TOSEC the compression format should be the common torrentzip or winrar.
Just my humble opinion, but I think to have a very strong point here.
Of course I'll help to seed on UG when the torrents will be out no matter the final compression standard. Keep up the good work to finally spread the dump! smile

asapy wrote:

流通評価用体験版 lol
It's quite rare.

Ha ha, indeed! smile
Is my interpretation correct, 先生?

First one:

Gaia Master - 神々のボードゲーム
Gaia Master - Kamigami no Board Game (translation "the board game of the gods")
流通評価用体験版 - ryuutsuu hyouka-you taikenban. Only means "distributable evaluation use trial version"

Second one:

天誅
Tenchuu (translated means "heaven's punishment" but there is no need)
The game title became "Tenchu" in the West, so losing the final "u"

Third one:

サルゲッチュ
Saru! Get you!
Saru, means "monkey". The sentences above the title are not part of the title or subtitle, they say something like: "Dual shock use only" and "dual action game"

7

(7 replies, posted in General discussion)

Dremora wrote:

Expect a new parser soon.

Thanks for your hard work and dedication for this project! smile

8

(7 replies, posted in General discussion)

Same problem here...
I slowed down my dumping speed in the last weeks because of this. I updated CLR and now I don't know how to rollback. For my latest 4 submissions I had to edit the CLRMAME data manually bacause the New Disc form doesn't accept the new dat format.

9

(9 replies, posted in General discussion)

Dremora wrote:

I think prototypes should be preserved (No-Intro does preserve them).

I completely agree with you. The eternal problem with the protos is that often you don't know the souce of the info/dump (dumping method, the hacking it may have suffered, etc) as they are very scarce as original media.

Great post!
This should go in a small guide along with the dumping guides!
It's very useful for everyone, especially for newbies!

11

(2 replies, posted in General discussion)

Thanks! I'll start the back-up process as soon as I finish my CD Based collection!

12

(2 replies, posted in General discussion)

Is the current method the best one (i.e. the one that produces a perfect lossless dump)? Is there a way to make PS2 raw dumps? Is there a method to calculate factory write offset?
I have many PS2 games here and I'd like to dump them only once; if a better method will be discovered I will have to redump everything.
Another question: is there a way to check PS2 images? I mean the equivalent of CdMage for DVD images. I want to be sure that the images I submit are 100% free from errros and corrupted sectors.

13

(7 replies, posted in General discussion)

It may be useful if madmagician thinks so. After all, he is the Saturn guru.
A dedicated infobox for 1st sector would be useful as I agree that in the current state (in comments) it's very ugly. I usually place other info in the comments about alternate serials and versions.
The Saturn database is still very empty, it's easy to decide to add things before many dumps are submitted. I think that the more accurate the documentation is, the better!

pepsidrinker wrote:

I think maybe we should include mastering errors in the comment section. If we include them then people that would know them so when verify and checking a dump and find errors they don't think someone is trying to pull something with a faulty dump as it's documented.

I don't know if it's the right idea...I think that the "faulty" discs should be left alone and wait for an appropriate copy of the game from another dumper. The mastering errors should be very rare and the probability that a game copy has them is very low. It is pointless to submit something that will be replaced by the error free dump IMHO.

15

(39 replies, posted in General discussion)

Welcome Yuki!!!
I really appreciated your work at UG! I hope you can contribute here with many rare japanese games for Sega Saturn, PSX and PC Engine!
For DC I don't know, I'm waiting for a proper DC dumping guide to perfect dump my disc collection (not so big, around 20 games). Surely a moderator such as vigi can help with a more competent answer!

Where should I submit those info? In the comments section of the "new disc" webpage?

Thanks for the replies!
If I knew earlier I wouldn't have wasted so much time on those "faulty" discs.
BTW, I scan the image with CD Mage and up until now when it reported corrupted sectors I deleted the dump, so CD Mage has never altered any of my dumps. I thought than the scan with CD Mage was mandatory for non-PSX CD games!

From now on, I won't delete them but I'll post the dumps with corrupted sectors/bad headers in the dump forum (and not the "New disc" function) so that a mod can decide if it can be accepted.

A basic question: if my disc has a corrutions error due to bad mastering, is it suitable for the database in the first place? It's very unlikely that many other identical game discs have the same mastering error so I think we should not submit them in the database and wait for a proper copy to be dumped. Just my thought!

Hello!
I spent my day off work to dump many games but I found more than 1 problem.
It seems that not so rarely when I dump a PSX game when I check the image with psxt001z 1 "bad" header is found. As always I scan the image with CD Mage too and that bad header translates in 1 corrupted sector! I can't fix the error with psxt001, not even with CD Mage.

But the question is: why does this errors occur? EVERY disc I have is mint/flawless/like brand new ,barely played, scratch and fingerprints free!!
I tried everything: I dumped the problematic discs multiple times with 3 different drives and different methods (so I wasted A TON of time, in an entire day I would have been able to dump maybe 20+ discs?), ALWAYS the same problem with each disc!

What's even stranger is that perfectrip everytime gives the message "Congrats, you got a perfect rip", and Isobuster, CDRWin never find an error during the dumping process.

Any suggestions? Are these dumps good anyway?

Thanks but I need the confirmation that +702 EAC / -702 Perfectrip (the one I used) is correct.
I know that the disc factory write offset would be +672 (I did the calculations with the px-760a, drive offset +30).
From the previous posts I assume that 702 is correct, I'll submit dump data tomorrow in the morning!
Thanks for the collaboration!

I dumped the game and as combined read+write offset I put +702.
In the previous post I copy-pasted the output of the command
D:\Controllo>px_d8 e: 0 0

here's the output of the command shifted by 1 sector:

D:\Controllo>px_d8 e: 1 0

D:\Controllo>px_d8 e: 1 0
CF7194246F5B6C3B6DD36D9DEDA98DBE
E5B04B34375756BEBEF0704424335B55
FB7F036001E8004E80346017680EAE84
7C6361E9E84ECEB454777F66A02AF81F
028801A6807AE0230819C68AD2E71D8A
89A726FA9AC32B11DF4C5835FA97032E
81DC6059E83ACE93146DCF6D942DAF5D
BC39B1D2F45D8779A2A2F9B982F2E185
886326A9DAFEDB005B403B7013640DEB
458F732425DB5B1B7B4B637769E6AECA
FC5701FE80406030571D1AEF486436AB
56FF7EC020A540C90A91C72C529DFDA9
81BEE0704824369B56EB7ECF6054283F
5E90386C12ADCDBD95B1AF347C1761CE
A8547EBF607028241E9B486B76AF66FC
2AC1DF10580C3A85D3231DD9C99A57F0
126F485436BF56F03EC410A760C9F5D1
871C6289E9A6CEFAD4431F71C824569B
7EEB604F68342E975C6EB9EC72CDE595
8B2F275C1AB9CB32D7559EBF28701EA4
087B46A372F9E582CB2197586EBAAC73
3DE5D18BE275412AB6CF36D416DF4ED8
34F4977B2EA35C79F9E2C2C99196EC6E
CDEC558DFF257CD3C8EEB37785DFA321
B9D872DAA59B3B2B535F7DF821824B04
4D2B4B76A0BF780C2285D9A31AF9CB02
D7419EB068742EA75C7A414BA985B73D
DE61D81C5A89FB26C35AD1FB1C4349F1
F6C4CD43B95FA52400FFFFFFFFFFFFFF
FFFFFF0001820061536D475FA05B2541
..................
...........etc

In sector 1 I found the string 00018200 so I did the following calculations:

sector 0 is 588 samples, sector 1 has the following number of samples before synchro string:
28,5 * 4 = 114

So in the end: 588 + 114 = 702
I used 702 as correction value in perfectrip and I got the dump.
I checked the tracks with CD Mage, 0 errors.

I wait for confirmation on my offset calculation to submit the dump data.
Thank in advance

Hello!
I'm trying to calculate the offset of the game Aris Adventure (SS).
Track 2 pregap is 2.00 sec but I'm not able to calculate the offset with the traditional method (my drive offsets are +48 and +30, probably disc factory offset is very high). Here's the output of D8 command...
I can't understand the offset with this kind of output. Any help?
Thanks


D:\Controllo>px_d8 e: 0 0
CF7194246F5B6C3B6DD36D9DEDA98DBE
E5B04B34375756BEBEF0704424335B55
FB7F036001E8004E80346017680EAE84
7C6361E9E84ECEB454777F66A02AF81F
028801A6807AE0230819C68AD2E71D8A
89A726FA9AC32B11DF4C5835FA97032E
81DC6059E83ACE93146DCF6D942DAF5D
BC39B1D2F45D8779A2A2F9B982F2E185
886326A9DAFEDB005B403B7013640DEB
458F732425DB5B1B7B4B637769E6AECA
FC5701FE80406030A325E867486436AB
56FF7EC020A5B1C90A91C72C529DFDA9
81BEE0704824369B56EB7ECF6054283F
5E90386C12ADCDBD95B1AF347C1761CE
A8547EBF607028241E9B486B76AF66FC
2AC1DF10580C3A85D3231DD9C99A56B8
19EA485436BF56F03EC410A796C9F5D1
871C6289E9A6CEFAD4431F71C824569B
7EEB604F68342E975C6EB9EC72CDE595
8B2F275C1AB9CB32D7559EBF28701EA4
087B46A372F9E582CB2197586EBAAC73
3DE5D18B1705B827B6CF36D416DF4ED8
34F4977B2EA35C79F9E2C2C99196EC6E
CDEC558DFF25EBC0B2FCFF382491A321
B9D872DAA59B3B2B535F7DF821826D04
5E2B7E76A0BF780C2285D9A31AF9CB02
D7419EB068742EA75C7A24D02C2A0337
8A5FD81C5A89FB26C35AD1FB1C4349F1
F6C41A435C5F972400FFFFFFFFFFFFFF
FFFFFF00018174610028001E80086006
A802FE8180606028281E9E886866AEAA
FC7F01E0004800368016E00EC8045683
7EE1E0484836B696F6EEC6CC52D5FD9F
01A8007E80206018280A9E8728629EA9
A87EFEA0407830229419AF4AFC3701D6
805EE0384812B68DB6E5B6CB36D756DE
BED8705AA43B3B53537DFDE181886066
A82AFE9F0068002E801C6009E806CE82
D4619F68682EAE9C7C69E1EEC84C56B5
FEF700468032E015880F26841AE34B09
F746C6B2D2F59D8729A29EF9A842FEB1
80746027681AAE8B3C6751EABC4F31F4
14474F72B425B75B36BB56F37EC5E053
083DC69192EC6D8DEDA58DBB25B35B35
FB57037E81E0604828369E96E86ECEAC
547DFF618028601EA8087E86A062F829
829EE1A8487EB6A076F826C29AD1AB1C
7F49E036C816D68EDEE4584B7AB76336
A9D6FEDEC058503ABC1331CDD4559F7F
28201E98086A86AF22FC1981CAE05708
3E869062EC298DDEE5984B2AB75F36B8
16F28EC5A4533B7DD3619DE8698EAEE4
7C4B61F76846AEB2FC7581E7204A9837
2A969F2EE81C4E89F466C76AD2AF1DBC
09B1C6F452C77D92A1ADB87DB2A1B5B8
7732A695BAEF330C15C5CF13140DCF45
94332F55DC3F19D00ADC0719C28AD1A7
1C7A89E326C9DAD6DB1EDB485B76BB66
F36AC5EF130C0DC5C593132DCDDD9599
AF2AFC1F01C80056803EE010480C3685
D6E31EC9C856D6BEDEF058443AB35335
FDD7019E8068602EA81C7E89E066C82A
D69F1EE8084E86B462F76986AEE2FC49
81F6E046C832D6959EEF284C1EB5C877
16A68EFAE4430B71C76452AB7DBF61B0
28741EA7487AB6A336F9D6C2DED1985C
6AB9EF32CC1595CF2F141C0F49C436D3
56DDFED9805AE03B0813468DF2E5858B
232759DABADB331B55CB7F17600EA804
7E836061E8284E9EB468776EA6AC7AFD
E30189C066D02ADC1F19C80AD6871EE2
8849A6B6FAF6C306D1C2DC5199FC6AC1
EF104C0C35C5D7131E8DC86596AB2EFF
5C4039F012C40D9345ADF33D85D1A31C
79C9E2D6C99ED6E85ECEB85472BF65B0
2B341F57483EB69076EC26CDDAD59B1F
2B481F768826E69ACAEB170F4E843463
5769FEAEC07C5021FC1841CAB057343E
97506EBC2C71DDE4598B7AE7630AA9C7
3ED2905DAC39BDD2F19D8469A36EF9EC
42CDF195846F236C19EDCACD9715AE8F
3C6411EB4C4F75F427075A82BB21B358
75FAA7033A81D3205DD8399A92EB2D8F
5DA439BB52F37D85E1A30879C6A2D2F9
9D82E9A18EF86442AB71BF64702B641F
6B482F769C26E9DACEDB145B4F7B7423
6759EABACF331415CF4F14340F57443E
B35075FC2701DA805B203B58137A8DE3
2589DB26DB5ADB7B1B634B69F76EC6AC
52FDFD8181A0607828229E99A86AFEAF
007C0021C018500ABC0731C29451AF7C
7C21E1D8485AB6BB36F356C5FED3005D
C0399012EC0D8DC5A5933B2DD35D9DF9
A982FEE180486036A816FE8EC064502B
7C1F61C828569EBEE8704EA4347B5763
7EA9E07EC82056983EEA904F2C341DD7
499EB6E876CEA6D47ADF631829CA9ED7
285E9EB86872AEA5BC7B31E35449FF76
C026D01ADC0B19C74AD2B71DB689B6E6
F6CAC6D712DE8D9865AAAB3F3F50103C
0C11C5CC5315FDCF0194006F402C301D
D4099F46E832CE95946F2F6C1C2DC9DD
96D9AEDAFC5B01FB40437031E4144B4F
777426A75AFABB033341D5F05F043803
5281FDA041B830729425AF5B3C3B51D3
7C5DE1F98842E6B18AF467076A82AF21
BC1871CAA4573B7E93606DE82D8E9DA4
69BB6EF36C45EDF30D85C5A31339CDD2
D59D9F29A81EFE884066B02AF41F0748
02B681B6E076C826D69ADEEB184F4AB4
37375696BEEEF04C4435F35705FE8300
61C028501EBC0871C6A452FB7D8361A1
E8784EA2B479B762F6A986FEE2C04990
36EC16CDCED5945F2F781C2289D9A6DA
FADB031B41CB7057643EAB507F7C2021
D8185A8ABB27335A95FB2F035C01F9C0
42D0319C1469CF6ED42C5F5DF8398292
E1AD887DA6A1BAF87302A5C1BB10734C
25F5DB071B428B71A7647AAB633F69D0
2EDC1C59C9FAD6C31ED1C85C56B9FEF2
C04590332C15DDCF19940AEF470C3285
D5A31F39C812D68D9EE5A84B3EB75076
BC26F1DAC45B137B4DE37589E726CA9A
D72B1E9F486836AE96FC6EC1EC504DFC
3581D7205E98386A92AF2DBC1DB1C9B4
56F77EC6A052F83D8291A1AC787DE2A1
89B866F2AAC5BF13300DD4059F432831
DE94586F7AAC233DD9D19ADC6B19EF4A
CC3715D68F1EE4084B46B772F6A586FB
22C35991FAEC430DF1C58453237DD9E1
9AC86B16AF4EFC3441D7705EA4387B52
A37DB9E1B2C87596A72EFA9C4329F1DE
C458537ABDE33189D466DF6AD82F1A9C
0B29C75ED2B85DB2B9B5B2F735869722
EE998C6AE5EF0B0C0745C2B311B5CC77
15E68F0AE4070B428771A2A479BB62F3
6985EEE30C49C5F6D306DDC2D9919AEC
6B0DEF458C3325D5DB1F1B480B768766
E2AAC9BF16F00EC40453437DF1E18448
6376A9E6FECAC057103E8C1065CC2B15
DF4F18340A97472EB29C75A9E73ECA90
572C3E9DD0699C2EE9DC4ED9F45AC77B
12A34DB9F5B2C73592972DAE9DBC69B1
EEF44C4775F2A705BA833321D5D85F1A
B80B328755A2BF39B012F40D8745A2B3
39B5D2F71D8689A2E6F98AC2E7118A8C
6725EA9B0F2B441F734825F69B06EB42

p_star wrote:

xenogears , your disk is not GS-9198. it's GS-9169 !!!
Date track of GS-9198 cannot coincide with GS-9169, even because has other version - 1.004.
Inner ring number of GS-9198 CD1 is : GS-9198P-02243A
But ring number of my GS-9169 CD1 is not coincide with your number smile
Has copied CD 3, it has coincided with yours.

I re-checked and the box, every disc is labeled GS-9198!
Inner ring serials are indeed starting with GS-9169. Very strage!
Program version is 1.002 (I looked at sector 0 with Isobuster)
One question: where can I see the EXE date in Saturn games?

SORRY but it seems that I was wrong...
My dumps of disc 1 and disc 2 match with the dumps of p_star
I simply did the wrong comparisons with the hash info...

I made a few researches about Sakura Taisen 2 and I found out a possible explanation for the different dumps.

p_star dumped the version with serial GS-9169 which is the Shokai Tokutenban as in Sakakore Database

http://www.satakore.com/sega-saturn-gam … n-JPN.html

My version has serial number GS-9198 and is the regular version

http://www.satakore.com/sega-saturn-gam … e-JPN.html

both SKUs have 3 discs, I don't know why p_star did not dump Disc 3.

Furthermore yesterday I swapped disc 2 with 3 and I discovered that disc 2 matches with the dump of p_star.
The mystery remains for disc 1 which is different.
I'll submit dumps info in the Dumps forum.

Themabus, you are GREAT!!
I followed your guide step by step and the result is the same as perfectrip!!
The dump was good after all!!
I got the same result with every drive I have here at home (yes, it was a great amount of work!)

Here are the details of the new track02 created with EAC:

Name:    newtrack02.bin
Size:    4092480
CRC32:    a49c5592
MD5:    79c5b164aa1a305eb41b259fd6a2d12a
SHA1:    4a97dfc5f6f5f24b94e9a26393b1e25733b0909c

To recap, the dump is surely good; I dumped 3 times (with different drives too) the discs with the traditional method and 1 time with perfectrip with the PX-760A. Everytime the size/CRC32/MD5/SHA1 of the tracks are always the same!
I still have to figure out how to check the EXE date and why p_star dump is so different.