(1,362 replies, posted in General discussion)

Just tried to dump TOC & pregap with one of the last year's test versions (15.11.17) and got an immediate black screen & system hang with an error record "LMS lost connection to Intel(R) MEI driver" in the events log. Earlier and later versions work fine. Just to warn you that DIC can be dangerous smile

If they have an additional serial on the outer package, it won't hurt to mention that in the comments.

user7 wrote:

Any particular reason you removed the info about how some discs were packaged together and that packaging had it's own serial number?

Sounds like Edition to me (except the serial, that would go either to the serial field or to the comments, depends on the situation).

ajshell1 wrote:

And should the Turbo-CD database be split based on which version of the System Card they use?

Not really. Many of the Super System titles have some fancy screens if run on 1.x/2.x cards. Dracula X even has a mini-game there. And you can't run Win32 programs on Win16 at all (there's a Win32s extender for Win 3.x, though, but it's a different story).

Win16, Win32, Win64 sections should be enough, Win95/98 can go to the comments, though, there are titles that require exactly Windows 95 and can't be run on Windows 98 as well as titles that want Windows 98 or newer and can't be run on 95.

OS Tag isn't enough for these. Also, x64 soft requires x64 hardware and it is way different from x86, that's just not correct to put them into the same section.

1. (World) is a replacement for (Japan, Europe, USA), all the other cases of its usage are incorrect. Australian releases usually match the European ones, so it sounds more like (USA, Europe), but, ofc, it should be proven the Australian release matches the European one first.

2. 3DO/PSX Return Fire has Arabic.


(1,362 replies, posted in General discussion)

sarami wrote:
F1ReB4LL wrote:

I think it's better to generate the .cue variant as well.

I'll code it in the future.

Technically, you can't add a DC dump into db without the .cue smile So, it's an important feature.

Probably worth to split the Mac section to 68k, PPC and Intel sections, these are different devices with a different architecture. Same for 'normal' Amiga and Amiga PPC.


(1,362 replies, posted in General discussion)

sarami wrote:

Maybe It's common for saturn, but I think it isn't common for other discs.

Common for PC, Mega CD, FM-Towns, PC-98.

sarami wrote:

To begin with, is it true that "G.THORNTON" is based as the offset? What are the reasons? Nobody can know how many offsets audio disc has originally.

But it's not an audio CD, it's a program CD mastered/burned as audio. I see no reason to intentionally include empty data before "G.THORNTON".

sarami wrote:

I don't think the program data of these discs exists in the pregap area. For saturn, I think it's unintentional that the program data exists in the pregap area.

Let's wait for more dumps, then.


(1,362 replies, posted in General discussion)

So, you can provide subs now? smile

Sarami: I think it's better to generate the .cue variant as well. All the redump gdis are incorrect, anyway.
Also, scrambled image checksum isn't supported for GDs? T-42301M_disc.txt => only the descrambled image checksum there.


(1,362 replies, posted in General discussion)

sarami wrote:

If "G.THORNTON" is based as the offset, some byte of 2nd track belong to 1st track and some byte of 3rd track belong to 2nd track. In short, dic needs to search the 1st non-zero byte of all track and adopt the smallest value, I think.

Disagree. For Saturn overlapping tracks are common, so we can't assume it doesn't happen here.

user7 wrote:

Does this mean checksums are bad for these or no? I have the Karat disc to run some tests if necessary.

Checksums are 'bad', the dumps are ok, offset needs to be tweaked for them.

kHn wrote:

It's true for Datel/Karat/InterAct discs.
This magic (or identifier, whatever it is) was changed in CCL discs.
http://www.psx-place.com/threads/gs-par … ken.11379/
And Blaze/FCD discs are completely different.

Let's wait for the dumps.


(1,362 replies, posted in General discussion)

http://forum.redump.org/post/59267/#p59267 -- any chance to add this disc type for offset autodetection? Somewhat similar to Jaguar CD.

maxoojc wrote:

Yes hope he will find another way to dump the saturn kit it properly.

http://redump.org/disc/49823/ -- dumped nicely the same way, the layout is a little more bizzare.

LedZeppelin68 has proposed us a cue<=>gdi converter, should be fine to switch to cues after that (right now, there's no way to run cues in any emulator). Keep in mind, that each game is going to have 2 cues: 1 cue for the SD zone (first 2 tracks), 1 cue for the HD zone (track 3 and above).


(5 replies, posted in Guests & account requests)

I don't think registered members should ask for the Wiki access in the guest section. Try to PM iR0b0t or make a thread in the Dumpers section.

pool7 wrote:

Alternatively, if there must be a new disc category, I'd choose a more generic name, based on the info I provided above (maybe "PlayStation Enhancement CD (Audio)" (as some of these discs contained not only upgrades but more cheat codes and maybe some other goodie).

I agree with this.

user7 wrote:

Differently as in not with DIC? I have that Karat disc so let me know. khn will be dumping a dozen or so soon so now is a good time to fill in any missing details.

As far as I understand, all our 'PSX-CDDA' dumps belong to the same family and the first track should start with "G.THORNTON". So far:

GameShark - The BigWave Enhancement CD (USA)        +629
GameShark - The BigWave 2 Enhancement CD (USA)    +41
GameShark - The BigWave 3 Enhancement CD (USA)    +677
GameShark - The BigWave 4 Enhancement CD (USA)    +658
GameShark Enhancement CD Version 2.2 (USA) (Unl)    +629
Karat PS-you Action Replay Higi Code CD Vol. 4 (Japan)    +1034

Meh, PlayStation has a GameBoy emulator attachable to the console, let's add all the GB roms into the PSX dat, because they can be played on PSX with some external device.

If PSX itself (even modded) doesn't recognize the discs, they aren't for PSX.

pool7 wrote:

Thanks for clarifying.
I'd keep those in the main Sony PlayStation CD

As I've alredy said in another topic, I'm not sure these are even handled by the PSX itself, probably, the programs are for the cheat devices themselves, therefore, it's not correct to put those into the PSX section.

pool7 wrote:

-Upgrade discs for the cheat cartridges? (which were audio only in format, but contained data within the audio


There's a read error, fix it with CDMage or psxtoolz (if fixable, but it is only in ECC and EDC areas, should be fixable), then check the hashes again.

iR0b0t wrote:

I would prefer to get some more data (dumps) before adding new systems.

Agree, worth to examine the dumps first. Also, all those Audio-CD format tools needs to be dumped with a proper offset, which is detected differently, compared to the normal data CDs.

For the speed, the fastest you read something, the more you may have error, like jitter correction on audio track is more active, and as the speed increase, the algorithm can't think out the box, so it forces interpolations to keep a constant bitrate.

Erm, no, you're misunderstanding the reading process. Interpolation only appears on hardware CD-players (when you're listening to the music), not when you read the data digitally, sector by sector. It is either copied properly (0 C2 errors) or not (>0 C2 errors).

Btw do you think that if I remove the brushes, there would be little holes, something will change or the holes would make the same ? (I assusme that hole = read error too)

Less errorneous sectors maybe, but I'm not sure. Also, it's still not clear, why the 24x dump has all the errors fixed.

One of our members has the "Cleaning Kit for Sega Saturn", I hope he will try to dump it, so we could compare the 'brush area' results.

M-20001  AG308A   FD827K

M-20001  AG308A[TAB]FD827K -- correct?

Sarami, could you take a look at this? freshcleaner24x reports all the c2 errors fixed, but is it possible? Logically, some errors should stay 'unfixable' there. Could it be a misread of the nearby sectors due to c2 offset or something else again?
On another hand, this disc clearly doesn't feature any protection, so it should be safe to assume there's no data in the 'brush area'.

maxoojc: what's about the ringcode? And, btw, why do you use the "/nl" switch with DIC? I think it is only needed for Libcrypt-protected PAL PSX titles smile Better not to use for dumping the Mega CD discs.

maxoojc wrote:

I'm trying to understand evrything and see what's is the .sub purpose.

The .sub is exactly where all the gaps are marked as gaps.

maxoojc wrote:

It seems like the brushes area is in the 2nd track pregap. The data at the end of the first track is full of 0 and there where no errors reading.

That is interesting, because IsoBuster doesn't detect gaps and if you've extracted the 1st track as track (not as some sector range), it should include the entire 2nd track's pregap.