You are not logged in. Please login or register.
Redump Forum → Posts by sarami
both are SafeDisc protected
I don't know the detail about the SafeDisc DVD.
the latest build is not dumping Xbox beta discs
The reason is unknown. Try to use 'dvd' command.
however IsoBuster is dumping them fine
Can IsoBuster dump the xbox disc? I didn't know it.
Is there something we can do?
You can use /f flag. This is used to control "FlushDriveCache" function.
/f Use 'Force Unit Access' flag to delete the drive cache
val delete per specified value (default: 1)If you use "/f" (no value), app call "FlushDriveCache" per sector.
If you use "/f 1", app calls "FlushDriveCache" per sector.
If you use "/f 2", app calls "FlushDriveCache" per 2 sectors.
If you use "/f 3", app calls "FlushDriveCache" per 3 sectors.
:
:
If you use "/f 10000", app calls "FlushDriveCache" per 10000 sectors.
Couldn't DIC compensate by rereading sectors that spawn an error for sanity checks?
I'll consider it. But sync is corrupt for some protection and bad mastering discs. App can controls rereading when the protection flag (/sf /ns) is used, but it can't judge if the disc is bad mastering or not.
see
probably the dump is not correct.
I don't know why Lizard thinks of it.
Interestingly, the hashes are different than those of the redumper app (logs for which are also present in this archive entry).
Mastering Code is different. Simply, it's another version? I'm not sure.
If a track has an invalid ISRC code (example: "0@4010000000"), will that mean DiscImageCreator will not add it to the cuesheet?
Yes. I check it by the "IsValidSubQAdrISRC" function.
If a track has an invalid ISRC code (example: "0@4010000000")
Does it means you have the weird disc? If yes, upload logs plz.
perhaps it is hard-coded to always attempt no more than 5 retries?
Should support for the /rr flag be added for dumping xbox and xbox 360 discs?
Added. Not test.
https://www.mediafire.com/file/eq80y20l … st.7z/file
More changed.
https://www.mediafire.com/file/eq80y20l … st.7z/file
Sorry, fixed typo.
https://www.mediafire.com/file/eq80y20l … st.7z/file
Fixed, thank you!
Thanks, but misdetection still exists.
LBA 357, Check if the directory record length (114) is really correct -> incorrect. Fixed it to 54
LBA 1690, Check if the directory record length (128) is really correct -> incorrect. Fixed it to 67
LBA 1142, Check if the directory record length (112) is really correct -> incorrect. Fixed it to 51
LBA 1369, Check if the directory record length (114) is really correct -> incorrect. Fixed it to 54
LBA 1480, Check if the directory record length (152) is really correct -> incorrect. Fixed it to 91
LBA 3352, Check if the directory record length (128) is really correct -> incorrect. Fixed it to 67
LBA 523, Check if the directory record length (102) is really correct -> incorrect. Fixed it to 41
LBA 2219, Check if the directory record length (132) is really correct -> incorrect. Fixed it to 71
More test please if possilble.
https://www.mediafire.com/file/eq80y20l … st.7z/file
It's a empty file
Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file
but rather than exporting all of the data dumps into a flat, text file...it seems like it would be more beneficial if the data were also exported in a supplemental CSV format. This way we could eventually use the CSV format to streamline disc uploads by auto-populating the data fields by uploading the CSV directly.
It's impossible to replace all of the data to the csv.
New little problem with a Amiga stuff...
There is a irregular? record in LBA 910.
0140 : 76 00 00 00 00 00 00 00 ._....,.v.......
0150 : 00 00 00 00 00 00 00 00 00 00 5F 03 1E 11 12 2C .........._....,
0160 : 00 00 00 00 01 00 00 01 07 46 49 58 45 44 3B 31 .........FIXED;1
0170 : 52 52 05 01 89 4E 4D 0A 01 00 66 69 78 65 64 50 RR...NM...fixedP
0180 : 58 24 01 FF 81 00 00 00 00 81 FF 01 00 00 00 00 X$..............
0190 : 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01A0 : 00 00 00 54 46 1A 01 0E 5F 03 1E 11 12 2C 00 5F ...TF..._....,._
01B0 : 03 1E 11 12 2C 00 5F 03 1E 11 12 2C 00 00What is the "FIXED"?
CD-TEXT not showing correctly, is this normal?
I tested it using same CD-TEXT data, and it's no problem. I'm not sure why the string is not showed correctly.
========== CDTEXT ==========
Entry 0 crc[0657] is good
Entry 1 crc[315e] is good
Entry 2 crc[7786] is good
Entry 3 crc[e163] is good
Entry 4 crc[9205] is good
Entry 5 crc[bc6b] is good
Entry 6 crc[bf6d] is good
Entry 7 crc[2729] is good
Entry 8 crc[3b44] is good
Entry 9 crc[23ae] is good
Entry 10 crc[4a86] is good
Entry 11 crc[d75d] is good
Entry 12 crc[828e] is good
Entry 13 crc[5537] is good
Entry 14 crc[9619] is good
Entry 15 crc[6544] is good
Entry 16 crc[db0b] is good
Entry 17 crc[94d5] is good
Entry 18 crc[a4af] is good
Entry 19 crc[d9d4] is good
Entry 20 crc[e416] is good
Entry 21 crc[6e59] is good
Entry 22 crc[c7ec] is good
Entry 23 crc[ffb4] is good
Entry 24 crc[c835] is good
Entry 25 crc[bf60] is good
Entry 26 crc[bace] is good
Entry 27 crc[a5a8] is good
Entry 28 crc[3176] is good
Entry 29 crc[bca4] is good
Album Name: 新しいタイトル (7)
Song Name[1]: トラック 01
Song Name[2]: トラック 02
Song Name[3]: トラック 03
Song Name[4]: トラック 04
Song Name[5]: トラック 05
Song Name[6]: トラック 06
Song Name[7]: トラック 07
Song Name[8]: トラック 08
Song Name[9]: トラック 09
Song Name[10]: トラック 10
Album Performer: 新しいアーティスト (7)
First track number: 1
Last track number: 10
Lead-out(msf): 44:04:61
Track 1(msf): 00:02:00
Track 2(msf): 04:15:27
Track 3(msf): 08:23:64
Track 4(msf): 12:50:19
Track 5(msf): 17:07:59
Track 6(msf): 21:30:44
Track 7(msf): 25:54:34
Track 8(msf): 30:08:20
Track 9(msf): 34:48:37
Track 10(msf): 39:36:00
Character code for this BLOCK: 0x00 (ISO/IEC 8859-1 [Latin-1])
First track Number: 1
Last track Number: 20
Mode2 PACKETs: No
Program area copy protection: No
Copyright asserted for $85: Yes
Copyright asserted for $81-$84: Yes
Copyright asserted for $80: Yes
Number of PACKS with $80 (ALBUM_NAME) : 17
Number of PACKS with $81 (PERFORMER) : 6
Number of PACKS with $82 (SONGWRITER) : 0
Number of PACKS with $83 (COMPOSER) : 0
Number of PACKS with $84 (ARRANGER) : 0
Number of PACKS with $85 (MESSAGES) : 0
Number of PACKS with $86 (DISC_ID) : 0
Number of PACKS with $87 (GENRE) : 0
Number of PACKS with $88 (TOC_INFO) : 4
Number of PACKS with $89 (TOC_INFO2) : 0
Number of PACKS with $8a : 0
Number of PACKS with $8b : 0
Number of PACKS with $8c : 0
Number of PACKS with $8d (CLOSED_INFO): 0
Number of PACKS with $8e (UPC_EAN) : 0
Number of PACKS with $8f (SIZE_INFO) : 3
Last Sequence number of BLOCK 0: 29
Last Sequence number of BLOCK 1: 0
Last Sequence number of BLOCK 2: 0
Last Sequence number of BLOCK 3: 0
Last Sequence number of BLOCK 4: 0
Last Sequence number of BLOCK 5: 0
Last Sequence number of BLOCK 6: 0
Last Sequence number of BLOCK 7: 0
Language code BLOCK 0: 0x69 (Japanese)
Language code BLOCK 1: 0x00 (not applicable)
Language code BLOCK 2: 0x00 (not applicable)
Language code BLOCK 3: 0x00 (not applicable)
Language code BLOCK 4: 0x00 (not applicable)
Language code BLOCK 5: 0x00 (not applicable)
Language code BLOCK 6: 0x00 (not applicable)
Language code BLOCK 7: 0x00 (not applicable)https://github.com/saramibreak/DiscImag … g/20220606
*2022-06-06
- added: check Latin-1 character when reading DirectoryRecord
- added: support CD-TEXT with Unicode
- changed: PFI.bin to (fname)_PFI.bin and DMI, SS, PIC are also the same
- fixed: when subQ is fixed, if the adr of next subQ is not 1, prev subQ is used
- fixed: allow "Data Length 0" (for some linux and amiga disc)
I have a problem with another multi-platform disc (mainly Amiga) : Dream 41
Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file
Ok, thanks. Any advice on what to do to dump it properly?
1. As is.
2. It's descrambled as mode 1 forcibly and fixed to mode 1 sector.
3. It's descrambled as mode 1 forcibly and not fix to mode 1 sector.
We need to select any of the number.
Hey sarami, there seems to be a problem with descrambling this disk: Super Stardust (Europe).
Descrambler is ultra slow doing one sector in several seconds. I've interupted the process. Latest test version used.
Could you please have a look?
Mode of the data sector is all 0. According to Ecma-130 pp14-15, 2336 bytes of the mode 0 sector are all zero. But Super Stardust (Europe) is not so. It's irregular.
sarami wrote:Novicami wrote:the problem seems to come from a special character (F1 > ñ and D1 > Ñ) :
Probably yes. Is there latest test build logs?
of course, yes
https://mega.nz/file/5U8jxR7Y#9BoVDcp18 … mIKAfoUloU
https://www.mediafire.com/file/eq80y20l … st.7z/file
- added: Check Latin-1 character.
the problem seems to come from a special character (F1 > ñ and D1 > Ñ) :
Probably yes. Is there latest test build logs?
I have an analysis problem when dumping an Amiga disc
Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file
http://forum.redump.org/topic/44369/3do … o-almanac/ - another weird case of sub-toc desync misdetection for a 1-track disc (olaf hasn't included the "sub indexes" files, but they were created).
https://www.mediafire.com/file/eq80y20l … st.7z/file
- fixed: when subQ is fixed, if the adr of next subQ is not 1, prev subQ is used. (NOT TEST)
Do you need additional data from me to help fix this ?
Latest test version logs.
The last 3 versions of Dic are broken.
https://www.mediafire.com/file/eq80y20l … st.7z/file
- Not return FALSE by ReadCDForFileSystem L775
i dumped a few BD-Rs (PS4 kiosk discs).
http://forum.redump.org/post/81632/#p81632
I added /avdp for -R disc.
sarami, just FYI, two CDi DIC dumps have scrambled sectors close to the end of the track:
http://redump.org/disc/24962/ - 1 sector
http://redump.org/disc/78871/ - 2 sectors
We've corrected that in the database but I guess that have to be fixed on the DIC side.
Some discs have erroneous sector(s) in the end of the track. These sector(s) stay scrambled in some cases. Do you know it? I'm not sure The 7th Guest has these, though.
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.