redump.info Forum

hi! very nice project.
good to see you're doing something to sort all this huge data amount.
and also it's obvious you guys have spent a lot of time examining various aspects of psx disc structure and cp schemes and such.
and so i wandted to ask:
1. i've checked my SCED-02492 pal demo disc that you have listed in db and indeed i can get all crcs
excep 1st audio track, because it gets pushed in pregap with offset and i have +6 dvd and +400 something cd, i guess i would need ~+700
to fetch out first bytes. but it seems weird because as far as i can read it's still data, all other audio tracks have wav header
and then few k.bytes with 00s and only then data. could it be that there is no wav header in audio track or data starts right after header?
2.in guide you say: 'psxt001z.exe --fix "Track 01.bin"' what seems like ecc/edc repair+some structure checks
sorry if i'm wrong but doesn't this defeats the whole idea of dumping in raw? i mean if i dump original cd and ther's some mess with sectors
and then fix it and somebody else dumps and fixes we will likely get same crc but is it ok, shouldn't it have been left messed?
...one more thing
3.i'm sorry for this but i don't mean to offend anyone. i can see why dumping from originals is so well defined and in need of extreme precision.
and when it is done people can check their stuff with .dat. but i think most don't have files seperated in that way, by tracks, and those offsets can
really mess things up and i just thought that maybe you would attract more people if there would be some gui tool that could do scan on images like
your commandline program can, or something similar. like crcs and structure and offsets and probably around 1kbyte of 1st audio track (it's the main
concern, right?) would be reported by dumper (like is now) and defined in tool and then all could have image checked with one click or something.
but maybe i'm way off from reality. i know that images are different, as far as i can remember one had zero bytes as ascii 0 other as hex or
something and others have headers and subchannel stuff but can't it be pulled off? i mean maybe people would be so much into this if they could just
point and click at their images and get results.

Hi,

themabus wrote:1. i've checked my SCED-02492 pal demo disc that you have listed in db and indeed i can get all crcs
excep 1st audio track, because it gets pushed in pregap with offset and i have +6 dvd and +400 something cd, i guess i would need ~+700
to fetch out first bytes. but it seems weird because as far as i can read it's still data, all other audio tracks have wav header
and then few k.bytes with 00s and only then data. could it be that there is no wav header in audio track or data starts right after header?

Ordinarily, CDDA tracks SHOULD NOT have RIFF headers. Those are oversights by the guy who mastered the disc. Some discs have have tracks bear RIFF headers while others do not (I don't have that particular disc, so I can't tell). The offset of your drive should not really matter too much, though the ability to read data from gap-sectors does (at least if that data is not all zeroes). Quite a couple of drives have trouble with that, unfortunately.

themabus wrote:2.in guide you say: 'psxt001z.exe --fix "Track 01.bin"' what seems like ecc/edc repair+some structure checks
sorry if i'm wrong but doesn't this defeats the whole idea of dumping in raw? i mean if i dump original cd and ther's some mess with sectors
and then fix it and somebody else dumps and fixes we will likely get same crc but is it ok, shouldn't it have been left messed?

Usually, --fix will fix one sector only, that being the very last sector in the data track if audio tracks are following. This corruption is not necessarily deterministic across drives. If psxt001z attempts to fix or fixes more sectors, something is wrong and the --fix should not be performed. This is on a case-by-case basis, really.

...one more thing
3.i'm sorry for this but i don't mean to offend anyone. i can see why dumping from originals is so well defined and in need of extreme precision.
and when it is done people can check their stuff with .dat. but i think most don't have files seperated in that way, by tracks, and those offsets can
really mess things up

Yes, the format is not the same you see "usually" on the net (.bin/.cue).  Offsets are not taken into account when ripping with, say, isobuster or cdrwin. If all you are interested in is an imperfect copy, there are plenty of other sources that'll give THAT to you, and don't care about any errors or variations across drives. This is just not one of those places.

and i just thought that maybe you would attract more people if there would be some gui tool that could do scan on images like
your commandline program can, or something similar. like crcs and structure and offsets and probably around 1kbyte of 1st audio track (it's the main
concern, right?)

The audio tracks would all be shifted, and the last audio track will have similar issues. Furthermore, it can be hard to detect ripping errors on audio tracks when not using C2 error information or the EAC secure ripping modes. Many, many images out there have exceptionally crappy quality in this regard (often, they are dumped from copies that may or may not have been cracked, tagged, or whatever else, and even if not, no care has been taken to get a bit-accurate stream of the disc). Even single datatrack images suffer from this. It's just a sad reality that many, if not most, images out there are of shoddy quality, and limited information which would help determine which ones ARE of shoddy quality. Add to that the many folks that just don't care if the boot sector picture has been replaced or a video contains artefacts or some audio samples are broken, 'cause, after all, "it plays the first level, so it MUST be a good image".

would be reported by dumper (like is now) and defined in tool and then all could have image checked with one click or something.
but maybe i'm way off from reality. i know that images are different, as far as i can remember one had zero bytes as ascii 0 other as hex or
something and others have headers and subchannel stuff but can't it be pulled off? i mean maybe people would be so much into this if they could just
point and click at their images and get results.

What you are referring to with zero bytes would be the EDC checksums that are often zeroed on older discs' XA form 2 sectors. This is not something you can just "check" and change to whatever the database says. Some discs have been released in diffferent versions, both with and without EDC but otherwise the same data. How would the tool know that the disc you just dumped isn't a DIFFERENT version from the one in the database, i.e. a different release/edition/pressing ?
(The other way a previously zero-edc track would gain EDC would be "intelligent" burning utilities or burners that just add this information when not burning in raw mode. Dumps from copies are always dubious; few, if any, cd copy or burning programs take the drive write offset into account, for instance. Whoops.

As for a shiny GUI tool that does most of this automatically : sure it's possible. Are you volunteering a big chunk of your time and knowledge to develop and support such an application ? I'm not, sorry. Maybe somebody is, and if you find that somebody, all the power to them.