|
Post by Haldrie on Oct 22, 2006 11:12:19 GMT -5
How would I be able to tell if a Playstation game has LibCrypt protection on it? If I were to scan a CloneCD image with CDmage would a notice a pattern of corrupted ECC Q entries similar to how you can see a pattern of corrupt sectors with Safedisc protected PC games?
I'm just curious about this because this is the first time of hear this much detail about LibCrypt. I knew it had something to do with the subcode data but that was about it.
|
|
|
Post by pSX Author on Oct 22, 2006 11:16:38 GMT -5
I don't think there is a reliable way to detect LibCrypt protection other than looking at the code.
The problem with scanning for corrupt subcode sectors is that you will generally find corrupt subcode on most CDs. The reason for this is that the subcode is only protected by a simple CRC - it has no error correction (it is not important for all of the subcode to be present normally - anything stored in subcode that needs to be reliable is usually stored redundantly).
|
|
|
Post by states on Oct 23, 2006 4:39:00 GMT -5
It wouldn't be the first time I never really understood the subcode notion really... I always thought that the 8 bytes after the header (subheader) were the subcodes... Now this is something I'm so damn confused about right now... Someone must be mistakened here, either you or Golden Hawk (creator of cdrwin) cause if you check this link, which is the feature list for cdrwin, you will see that it supposedly does read the subcode from the disc... Like I said before... I never really understood the whole subcode concept... I'm going to have to read the CD-ROM faq completely... If anyone is interested in taking a look: www.cdrfaq.org/My description of the EDC/ECC holds true for Mode 2 Form 1, if you add up all of the bytes you will end up with 2352 bytes of payload. The Mode 1 that you are talking about doesn't have subheader data, here is a quote from this site: "Such a high error rate is unacceptable for data or highly compressed video, therefore the CD-ROM Mode 1 format defined sectors containing a third level of software error correction. Every 2352 byte Mode 1 sector contains 12 bytes of sync, a four byte header, 2048 bytes of data, and 288 error correction bytes." But the PSX discs also have Form 2 in some sectors. You already know this but I'm just saying this for the sake of saying this... Mode 2 Form 2 discs do not hold ECC codes, only EDC codes. This will leave you with more space for the user data. I was mistakened when I said that the CD had 8 bytes of subcode data, what I meant to say was subheader... sorry 'bout that little misinformation... my mistake. The CloneCD format is comprised of 3 files: a .ccd which is comprised of a description of the ISO, a .img which is exactly the same as a .bin (you can try it out if you want to, compare a .bin and a .img of the same game and you will see that the bytes are exactly the same) and finally a .sub file which contains the subcode information. (which you already stated above...) And the question of the day is: If the .bin and .img files are exactly the same (down to the last byte... I just couldn't resist saying that), and GoldenHawk claims that cdrwin can read subcode data, then what is the .sub file from the CloneCD file format for? Is it just to speed up some kind of process which CloneCD executes at some point?
|
|
|
Post by pSX Author on Oct 23, 2006 5:01:44 GMT -5
I never really understood the subcode notion really... I always thought that the 8 bytes after the header (subheader) were the subcodes... No, that is called the sector header - it has nothing to do with the subcode which is something completely different. The sector header does, obviously, appear in .bin files (for every sector format other than MODE1/2048). The .img file contains exactly the same data as a .bin file (of the same format) - it contains the sector data. The .sub file contains the subcode data (96 bytes for each sector).
|
|
|
Post by states on Oct 23, 2006 6:36:14 GMT -5
Yes I know that... but, since GoldenHawk reads the subcode, why doesn't it create another file, or for that matter, a bigger single file, since it will contain extra information? It just leads me to believe that the subcode data is already in the iso, only that you have to extract the subcode data with some special algorithm or something...
|
|
|
Post by patrickp on Oct 23, 2006 11:40:02 GMT -5
GoldenHawk actually says:
he doesn't say this refers to the .cue/.bin format. I haven't used CDRWin, but I understand it also supports the CloneCD .ccd/.img/.sub format, so it may be that this is what he is referring to here.
|
|
|
Post by pSX Author on Oct 23, 2006 13:36:40 GMT -5
Yes I know that... but, since GoldenHawk reads the subcode, why doesn't it create another file, or for that matter, a bigger single file, since it will contain extra information? It just leads me to believe that the subcode data is already in the iso, only that you have to extract the subcode data with some special algorithm or something... For one thing - the name "iso" refers to a file system - the iso9660 file system. NOT a disc image. (sorry, but that really annoys me!). Secondly, .cue/bin cannot contain subcode... it just can't... unless you add a new track format specifier - which would make it incompatible with all existing programs that support .cue/bin. The subcode is extra to the 2352 bytes of data in each sector, as I've been saying the data is out-of-band - it is not part of the sector (although technically there are 96 bytes of subcode associated with each sector). If a .bin file contained subcode it would have 2352+96=2448 bytes per sector. There is no way to "extract the subcode with some special algorithm" because it just isn't there! It isn't needed for most purposes - this is why .cue/bin doesn't support it. A lot of writers do not even support writing user specified subcode (although these days an increasing number do). Usually it is "made up" on the fly (a good example of this is the TOC - this is stored in the P and Q channels during the lead in on the CD). In fact this is what pSX actually does when using a format that doesn't contain subcode (although for PS1 only the Q channel is ever needed anyway). Formats which actually embed extra data in the subcode are pretty rare (CD+G, or CDTEXT for example), so it hasn't historically been that important. Also, for those formats it is better to extract just the info required rather than dumping the subcode raw... so thats the way it is usually done. Only formats such as CloneCD and the one used by Alcohol120% (mds/mdf) support raw subcode.
|
|
|
Post by states on Oct 23, 2006 13:54:19 GMT -5
Ok, I get it now. Thanks for the clear up and sorry for saying iso...
|
|
|
Post by Haldrie on Oct 23, 2006 14:41:26 GMT -5
Actually CDRwin is capable of extracting CD+G subcode data and it does store it into the .bin file along with all the other data. It then uses a CDG tag in the .cue file to identify it. I know this because I have actually made images of two CD+G discs that I have. The cue/bin image that was created was compatible with everything I used it on and was even able to burn the image back to disc without any problems. All of the graphics from the disc played back perfectly. I happen to have had a protable DVD player that supported CD+G playback. I can't be too sure about the subcode for data tracks but it definitly reads subcode data from audio tracks of course it only stores CD+G data in the .bin file. CD-Text is stored in it's own file and all other information such as UPC and MCN/ISRC are stored in the .cue file along with the index and track times.
pSX Author, you said that some copy protected games started working once you added subcode reading support in version 1.7. What were some of those games? I want to perform my own little experiment and see what I can find out myself.
|
|
|
Post by states on Oct 23, 2006 16:30:18 GMT -5
But the fact still remains... The sound still cuts off during the cut scenes in Spyro 2 and Spyro 3, and I have Spyro 2 in CloneCD format, whilst I have Spyro 3 in .bin/.cue format. So I assume it's got nothing to do with subcode or whatnot...
|
|
|
Post by Haldrie on Oct 23, 2006 17:08:23 GMT -5
Yes, pSX Author finally admitted that he was using the PAL version and that it might just be a problem with the NTSC U version.
|
|
|
Post by smegforbrain on Oct 23, 2006 22:29:11 GMT -5
Yes, pSX Author finally admitted that he was using the PAL version and that it might just be a problem with the NTSC U version. Oh, good, because I stopped following awhile back.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 28, 2007 6:16:53 GMT -5
BUMP. Spyro the Dragon 2: Ripto's Rage SCUS_944.25and Spyro the Dragon 3: Year of the Dragon SCUS_944.67Losing audio in cutscenes is still present in 1.13. I was hoping that this would be fixed along with the other stream fixes this release had, but oh well. Perhaps next version.
|
|
|
Post by thewanderer on Dec 13, 2007 18:17:56 GMT -5
Not to bring a dead thread back but was a solution ever found for the Sound lost in cutscenes thing?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 14, 2007 9:29:47 GMT -5
Nope. All you can do is to keep your fingers crossed for the next emu version.
|
|