You are not logged in. Please login or register.
Redump Forum → Posts by sarami
My concern is with discs like that Wing Commander Prophecy
Is it this disc? http://redump.org/disc/12961/
If yes, as I said, large ofs disc is not supported yet on Asus.
If no, upload logs, please.
To get scrambled sector(s), plextors use 0xd8 while other drives use 0xbe with cdda flag.
If /be is used, 0xbe with all flag is set forcibly. As the result, it can't get scrambled sector(s).
In other words, it can't get correct combined offsets.
if I omit /be, all ripped tracks match the redump entry. If I include /be, the data track matches, but all audio tracks have different checksums.
If you want to dump mixed mode disc on ASUS, do not use /be.
It's been free for personal use for some time now ?
Free version is limited.
Up to 32 commands can be captured
Only the first 8 bytes of each data transfer are captured
Runs only on 32-bt Windows, XP and later
I'm working ASUS on Win10 64bit.
sarami wrote:Madroms wrote:could you check the log for this disc ?
Also try to use subdump.
subdump added.
LBA 91152 is the start address of track 14 on TOC.
Data Track 14, LBA 91152 - 93436, Length 2285But It's the end of address of track 13 on sub.
LBA[091151, 0x1640f]: P[3f], Q[411301040808002017264de6]{ Data, Copy NG, Track[13], Idx[01], RMSF[04:08:08], AMSF[20:17:26]}, RtoW[0, 0, 0, 0]
LBA[091152, 0x16410]: P[3f], Q[41130104080900201727f796]{ Data, Copy NG, Track[13], Idx[01], RMSF[04:08:09], AMSF[20:17:27]}, RtoW[0, 0, 0, 0]
LBA[091153, 0x16411]: P[00], Q[41140100000100201728797b]{ Data, Copy NG, Track[14], Idx[01], RMSF[00:00:01], AMSF[20:17:28]}, RtoW[0, 0, 0, 0]It looks like real sub indexes. F1ReB4LL judges it.
re-ripping with my ASUS drive with /be also yielded the correct result.
No need to use /be except plextor.
could you check the log for this disc ?
Also try to use subdump.
he just edited the command in the buffer with bushound.
Could he really get the scrambled sector data by the method? I can't use bushound readily because it's really expensive.
I have read 30+ sectors into the lead out with 0xF1, not sure why you can't unless the lead out on your disc doesn't contain many sectors.
Would you upload your code that can read 30+ sectors and upload the 30+ sectors?
0xF1 can support multiple sector overreads:
"F1 06 00 00 00 00 00 00 0b 00" = last read sector
"F1 06 00 00 0b 00 00 00 0b 00" = last read sector + 1
"F1 06 00 00 16 00 00 00 0b 00" = last read sector + 2
and so on.
Then, how about the last read sector + 3, + 4, + 5 ...?
I tried "F1 06 00 00 21 00 00 00 0b 00", but it couldn't get the last read sector + 3.
Updated test version. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
@wiggy2k, @Lizard
Logs, please.
@Nextria
According to 5ch, it seems a lot of 708 users met with the same problem. So I changed it as 1.04 works.
Someone on Discord stated it's because of the large offset on the disk (1101 samples)
http://forum.redump.org/post/72760/#p72760
Complete dump but with too many c2 errors.
I also got this disc and a few of c2 errors occurred. c2 errors are the disc's problem, not dic.
disc eventually produced a Lead-in indicator
Uploaded http://www.mediafire.com/file/eq80y20l9 … st.7z/file
this should solve the false error problem.
I want to check these logs.
Here is the disc
I'm going to get it from an auction.
*2020-02-03
- added: call ReadDiscInformation for CD-R/RW
- added: ReadTOCPma for CD-R/RW
- added: If valid extension was omitted, ".bin" is set to path automatically.
- added: stores subP channel because first sector is EAN/ISRC
- deleted: /m flag
- fixed: splitted the subs indexes CUE
- improved: TOCATIP logs
- improved: Reading erroneous directory record (support [PSX] Tokimeki Memorial - forever with you, [PSX] Aitakute... - Your Smiles in My Heart)
HALP PLZ
I have no idea about it now.
*EDIT
*2020-02-04 was uploaded
Here are the sector dumps of corrupted directory entries. Just 1 sector dump per game.
Thanks, uploaded test version. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
I didn't dump the other stuff
Then, you can upload only the error directory record sector by using IsoBuster or your tool.
Aitakute... - Your Smiles in My Heart (Japan) (Disc 1) (Track 1).bin
Aitakute... - Your Smiles in My Heart (Japan) (Disc 2) (Track 1).bin
Aitakute... - Your Smiles in My Heart (Japan) (Disc 3) (Track 1).bin
Aitakute... - Your Smiles in My Heart (Japan) (Disc 4) (Track 1).bin
Aitakute... - Your Smiles in My Heart - Oroshitate no Diary - Introduction Disc (Japan) (Track 1).bin
All Star Racing 2 (Europe) (Track 1).bin
All Star Racing 2 (USA) (Track 1).bin
Formula GP (Europe) (Track 1).bin
MLB 2005 (USA).bin
Strike Force Hydra (Europe) (Track 1).bin
Tokimeki Memorial - Forever with You (Japan) (PlayStation the Best) (Track 1).bin
Tokimeki Memorial - Forever with You (Japan) (Rev 2) (Track 1).bin
Tokimeki Memorial - Forever with You (Japan) (Rev 4) (Track 1).bin
Truck Racing (Europe) (Track 1).bin
I got tokimemo rev4 and confirmed a corrupt directory record in LBA 14515. Also, can you upload all logs of these discs you reported except for tokimemo rev4.
When processing CDs with differing subchannel indexes, DIC splits the subs indexes CUE across multiple files matching the track names and doesn't fill the main subs indexes CUE. See attached logs: https://mega.nz/#!xRAzFAoK!6l9w3Ja5IAH5 … at4t5oXIN0
Ah yes. This was fixed by 20200123 test version.
If F1ReB4LL says http://forum.redump.org/post/76423/#p76423 and http://forum.redump.org/post/76442/#p76442 were fixed correctly, I'll upload the latest test version as release.
Some PSX discs have corrupted directory entries
Can you upload LBA 16 of these discs?
I didn't want to mix it in with the dot fixes
Does it still need? I added that If the valid extension was omitted, ".bin" is set to path automatically in the latest test version.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: If valid extension was omitted, ".bin" is set to path automatically.
New _subinfo.txt log:
Weird... 11 sectors (-1, 5000, 6404, 7373, 7613, 9628, 9986, 10837, 12164, 14344, 14419) have correct RMSF and AMSF. Is this other securom version? I don't know.
The mode of the last 4th sector is changed. If this disc is securom, it's correct.
LBA[334159, 0x5194f], MSF[74:17:34], mode 1
LBA[334160, 0x51950], MSF[74:17:35], mode 1
LBA[334161, 0x51951], MSF[74:17:36], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[334162, 0x51952], MSF[74:17:37], mode 1
LBA[334163, 0x51953], MSF[74:17:38], mode 1
LBA[334164, 0x51954], MSF[74:17:39], mode 1if the current sector is EAN/ISRC, the next sector's Q-channel has its index changed to 01, but the next sector's P-channel is padded with 0x00, then the current EAN/ISRC sector does not belong to pregap, but belongs to the track's index 01 (because the first sector of the 01 index should have its P-channel padded with 0xFF). Even if you take the 1st indexes from TOC, this check is still important for the TOC/cue desync detection.
Changed it to your logic. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Burnout find no protection but ProtectionID & Alcohol 120 find it has SecuROM.
Added log to _subinfo.txt. If there is random error(s) in LBA -1 sector, it's difficult to detect.
when the EAN or ISRC sector is detected and its P-channel is 0x00, you need to check the next sector's P and Q channels: if the Q-channel's track number is increased and the P-channel is filled with 0xFF, then the EAN/ISRC sector belongs to the next track.
Coded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
I checked it by Cosmic Fantasy 3. If this code is no problem, I'll remove /m flag.
>superg
This has been written to KnownIssue.txt as "Extension problem" since several years ago.
If you want to escape this problem without new coding, you should specify the extension.
I get the below errors in Linux
Try to use su or sudo.
Now the swap command worked and started dumping; however at one point DIC crashed.
No scrambled data. Perhaps PX-760A doesn't support swap trick.
Here's sector 16 from IsoBuster, both RAW and non-RAW:
volume space size is 0x265b. It's 9819 sectors. 9819 * 2048 = 20109312 bytes.
It's easy to use volume space size instead of TOC, but I'm not sure volume space size is correct disc size.
When trying to run the swap command, I get invalid argument:
D:\apps\redump\dic_test_20191227>DiscImageCreator.exe swap H foo.bin
Missing the drive speed.
----
As user7 says, if your disc have a fake TOC, I want to know the volume space size. Please upload 16th sector using Isobuster.
the LG has a different write offset value.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- fixed: parse driveOffset.txt
One thing I noticed when checking IsoBuster: the files in the disc are 19.1MB; however if I check the properties of the CD/Session/Track, IsoBuster says the disc size is 921.290.752 bytes (449.849 blocks).
Yes. TOC says the last sector is 449.849.
========== TOC ==========
Data Track 1, LBA 0 - 449848, Length 449849
Total 449849I tried entering 449849 in the Sector View window, and it did the same noise as when trying to dump with DIC(however I'm not sure if that's the number I should have entered), then showed this error:
Device reported Error code : 03/02/8D
Perhaps it needs swap trick. See wiki https://github.com/saramibreak/DiscImageCreator/wiki "Dumping Guide for CD with swap"
At least, kreon drive supports it.
Redump Forum → Posts by sarami
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.