You are not logged in. Please login or register.
Redump Forum → Posts by F1ReB4LL
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 
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.
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.
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".
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.
Logs of the dump from disc 1: https://mega.nz/#!VEkRyabQ!Cy1M8Z01E6sL … ggFoNri46s
Logs of the dump from disc 2: https://mega.nz/#!kZdjSDbT!FAvOQVd54b1G … dtvDOAjPMY
Logs of the dump from disc 1: https://mega.nz/#!8YtWSDgQ!9YHwWSCzUzTL … fAQe2j_H6E
So, you can provide subs now?
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.
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.
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.
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.
http://forum.redump.org/post/59267/#p59267 -- any chance to add this disc type for offset autodetection? Somewhat similar to Jaguar CD.
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).
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.
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.
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.
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.
-Upgrade discs for the cheat cartridges? (which were audio only in format, but contained data within the audio
This.
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 Better not to use for dumping the Mega CD discs.
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.
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.
I try to dump it but it appears too many errors with DIC.
I'm afraid there's no way other than to wait for all those DIC rereadings. The only thing you can possibly do is to disable the rereading of the bad sectors (but you will probably need to dump it twice to be sure the data is constant).
Have you tried to read it with isobuster again? Did the checksums match? Also, what variant was chosen for the non-readable sectors? Or the whole data track is readable and the 'brushes area' entirely belongs to the 2nd track's pregap?
The gap is 00:28:53.22, and I'm not sure if we have to take in account the miliseconds.
You need to dump the subchannels somehow, either to wait DIC dumping process to finish or try subdump (won't be faster, though) - http://forum.redump.org/topic/14725/subdump/. You can also try to experiment with the CloneCD (enable the subchannels reading in the profile and "play" with the skip sectors value to possibly speed up the process) or, maybe, with the ranges to read with subdump.
Confirmed. And the last 149 sector of the last track is also padded with 0xff.
Yes, that is correct.
The p-channel of the last Information Track in the User Data area shall end with a Flag of 2 s to 3 s (i.e. 150 to
225 Sections). Its end shall indicate the beginning of the Lead-out Track. In this track the bits of the p-channel are
set to ZERO during 2 s to 3 s."
And is 'NiGHTS into Dreams... (Japan)' irregular? Some sectors of the former pregap are also padded with 0xff in the all track.
Probably. According to the books, "During master disc encoding, the P code is generated automatically from the Q code", so, any P-channel vs Q-channel mismatchings should be some kind of mastering error.
And, as I've already said, according to the Redbook, "The encoding of channel P is delayed by one subcoding block with respect to the encoding of channel Q" (hence the 1-sector shift).
F1ReB4LL wrote:Various Saturn titles come to mind.
e.g. Puyo Puyo Sun? That is, "The first sector of the 2nd track's pregap is a scrambled data sector."?
Many different ones. The ones with the scrambled sector, the ones with xx:01:74 gaps (Q-channel gaps are 149 sectors, P-channel gaps are often 186 sectors on those), the ones with 'serpentine' pregaps (http://redump.org/disc/1874/ is the example, if I remember correctly) and others.
F1ReB4LL wrote:If they differ
Do you know the disc which they actually differ? Or is such the disc typical?
Well, they aren't rare. Various Saturn titles come to mind.
Main track part is padded with 0x00, gaps are padded with 0xFF, nothing special. Gaps padding is shifted by 1 sector, btw, so, the first sector of the gap is padded with 0x00, the 2nd sector of the gap is padded with 0xFF, the first sector of the track after the gap is padded with 0xFF, the next sector is padded with 0x00.
Have you thought about comparing gaps/tracks_sizes detected by Q-channel (like now) vs detected by P-channel? If they differ, you could additionally generate "dump.p.cue" (with the additional set of tracks split according to the differently detected gaps) and "dump_img.p.cue".
Redump Forum → Posts by F1ReB4LL
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.