PSIO Supposedly Working

FAIL!
http://nocash.emubase.de/psx-spx.htm#cdromdiskformat

[SIZE=+2] "[/SIZE]The .BIN file does not contain ALL sectors, as said above, the first 2 seconds are not stored in the .BIN file. Moreover, there may be missing sectors somewhere in the middle of the file (indicated as PREGAP in the .CUE file; PREGAPs are usually found between Data and Audio Tracks).
The MM:SS:FF values in the .CUE file are logical addresses in the .BIN file, rather than physical addresses on real CDROMs. To convert the .CUE values back to real addresses, add 2 seconds to all MM:SS:FF addresses (to compensate the missing first 2 seconds), and, if the .CUE contains a PREGAP, then the pregap value must be additionally added to all following MM:SS:FF addresses.
The end address of the last track is not stored in the .CUE, instead, it can be only calculated by converting the .BIN filesize to MM:SS:FF format and adding 2 seconds (plus any PREGAP values) to it."
Do you want continue to collect fails?
Also on there are ton of discussion on redump forum aganist the "incompatible" format used in the database.
But they are fossilized on that ancient and complicated process.

"This is common format, and this is format most widely used in preservation. Often Neil Corlett's ECM utility is used to compress data tracks."
This is another fail. Ecm doesen't compress anything, simply removes ECC EDC info and rebuild it after decoding.

"Subchannel data can be preserved for these 10 games which are using libcrypt, end of story."
Another fail. Most of pal realases contans libcrypt protection. Like modchip protectionused in NTSC relases.

I don't know really why continue....

Also talk for yourself, me and trimesh we are already clarified

 

Yes, because "first 2 two seconds" doesn't contain any useful info. Also I don't see any single reason to preserve PREGAPs. They are empty, and they are unused in game. Nobody preserves them. You here are talking about features, which don't add value to games. This is the same, as saving silence when dumping audio CD (which can be 1:1 reconstructed if you properly generated CUE).
Really, what you're talking about? How "first 2 seconds" or "PREGAP" are related to PSIO?

ECM (Error Code Modeler) lets you prepare CD image files (such as BIN, CDI, NRG, CCD, or similar) so that they'll compress far better in programs such as WinRAR.
Which is what I meant.

Read between words. There is limited amount of them, from what I know, around 60 PAL versions, which is far from "Most of pal realases".

You contradict yourself.

 

Far, far from it. There must be about 60 PAL games with libcrypt, which isn't even 5 % of the released games.

If you want to add Libcrypt support with bin/cue format, you can use SBI files.

Edit : superg was faster :smile-new:

 

Yes, desoncronize problems, with crash. They are common crash problem on emulators. PSX NEED postgap sectors. Specially for games that uses 2+ second of postgaps beetwen tracks (150+ empty sectors)
So don't call useless thing you don't know.
That's why in w**** relase they uses multibin non standars .cue rip.
PROF? Try with Tomb Rider in cue format. Lol assicurated
So it can affect also PSIO.......

prepare how? I've telled in more tecnical mode. Not simply copy\paste from official site

They are more. Dont' trust of documents that are made on 1999\2000 era, when libcrypt start to be widly used.
SBI can be replacement. But it's way better clone cd or alcohol format.
It's logically impossible that are 60 games.


P.S.:

Wrong. Say it to redump.org. They do all that mess with dumping because of that you call useless....
So inquire before saying certain things. I'm not here to be arrogan or start flames.

 

I am repeating myself: CUE has support for PREGAP/POSTGAP. Of course there can be crashes, if data after some offset will be shifted, that's why CUE should have these definitions. But what I am saying here is that data under these sections can be empty. PSX don't need PREGAP/POSTGAP sectors. What you're saying is problem in misalignment of sectors due to incorrect handling of image (either dumping or reconstructing). Is this clear to you?

Technical? You've misinterpreted root of crash problem,

Alcohol and CloneCD are proprietary formats, I wouldn't recommend anyone to support it or use it.

Even if 100, this is still very low percentage of all released titles.

 

I repeat, psx need pregap (and i've told also a test game), cue should have those definitions, but it's bin that have this problem.
That's why dumper add manualy when doing redump dump
And again, why redump do all this mess to dump also postgaps? not because it likes make hard life to the dumpers.
Make a dump of TR in bin\cue format ant test it. The game crash in the main menù
(some emulators try to fix it but return errors in log).
That's absolutely not true that nobody "preserves" them.

what?

In part i agree, but they are only the real 1:1 dump format

more more

 

Can a moderator please rename this thread to "The anger venting thread where people attack each other all the time"? :biggrin-new:

 

we're just having technical differences. that's all.
At least we try to say constructive things

 

Because redump people are desperate to have "perfect" rips, and doesn't matter, game uses that extra bit of data or not.

I am tired of this, but I would like to check Tomb Raider, will buy a disc.

 

I'll start to post when I see this happening and kindly ask someone to resume the opera to me.

 

dont need cry to air))). better if every one off us : offer your method what we need to do to solve this problem. and i'll notice it and try test it.

 

In my contry we say:"non c'è peggior sordo di chi non vuol sentire", translated: "there are none so deaf to those who do not want to hear"

I've posted you documents ,proof and test. IT also documented in official sony documents.
But you continue to ignore them.
This is the last time, because I'm starting to piss me off.

Redump have only ancient and laborious method (because the are fossilized on that format), but they are tho only working dump method with bin file.
They are not disperated people. They simply know what they do.
A member of THIS forum, haved some problem withis his tool for ps2 pops (krachen!?). He made a workaround for this issues to resolve his problems with bin\cue dump. And guess how works?

At this point we can use iso format. Who cares.

@cybdyn: LOL Do you want help after all? no thanks.

 

"after all" - after what? something happened? )))

 

actually discussion helps me too. so when you say about "no help" after you told much - it's too late)).

 

@TriMesh : "In any case, can you give me the exact P/Ns that you need? There are quite a lot of MAX IIs and SAM3Us " - i sent you in PM, no answer.

 

Man, you should know where to stop...

Can you please highlight, which documents you've posted?
What documented in official Sony documents? Mystical data in PREGAP/POSTGAP which are used ingame? Can you provide references? It would be nice to see that in official doc
Have you ever seen them?

 

I got it - check your PMs

 

http://redump.org/discs/system/psx/libcrypt/2/
Remove the multi-disc games and country dupes, you'll be closer to 60 than 160.

Of course bin+cue format works perfectly on Playstation... Why do you think CDRWIN was the tool of the trades in the PS modchip era ?

Anyway, this conversation is useless. Libcrypt protected games can be played with BIN + CUE + SBI.
Add support for the latter, and PSIO would match 100% compatibility.

 

guess SBI is something like .SUB from CD Clone))

i dont exclude about PREGAP or how it call, info on first track. SONY use it for store "SCEx" code maybe for something else.


i need research it in practice...

 

It fulfills the same purpose, but the approach is different - a CloneCD .sub file stores everything and the .sbi file only stores the subcode for frames that don't have the contents you would expect based on the red or yellow book spec. In both cases, the lack of error correction on the subcode channels means that the data stored may simply be garbage resulting from disc damage rather than intentionally written variant data.