126

(3,531 replies, posted in General discussion)

MrTikki wrote:

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.

Novicami wrote:

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 00

What is the "FIXED"?

127

(3,531 replies, posted in General discussion)

Neon Beast wrote:

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)

128

(3,531 replies, posted in General discussion)

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)

129

(3,531 replies, posted in General discussion)

Novicami wrote:

I have a problem with another multi-platform disc (mainly Amiga) : Dream 41

Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file

130

(3,531 replies, posted in General discussion)

usurper wrote:

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.

131

(3,531 replies, posted in General discussion)

usurper wrote:

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?

Dump: https://www.mediafire.com/file/lnxuoyp5 … st.7z/file

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.

132

(3,531 replies, posted in General discussion)

Novicami wrote:
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.

133

(3,531 replies, posted in General discussion)

Novicami wrote:

the problem seems to come from a special character (F1 > ñ and D1 > Ñ) :

Probably yes. Is there latest test build logs?

134

(3,531 replies, posted in General discussion)

Novicami wrote:

I have an analysis problem when dumping an Amiga disc

Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file

135

(3,531 replies, posted in General discussion)

F1ReB4LL wrote:

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)

136

(3,531 replies, posted in General discussion)

Cyo.the.vile wrote:

Do you need additional data from me to help fix this ?

Latest test version logs.

137

(3,531 replies, posted in General discussion)

wiggy2k wrote:

The last 3 versions of Dic are broken.

https://www.mediafire.com/file/eq80y20l … st.7z/file
- Not return FALSE by ReadCDForFileSystem L775

user7 wrote:

i dumped a few BD-Rs (PS4 kiosk discs).

http://forum.redump.org/post/81632/#p81632
I added /avdp for -R disc.

138

(3,531 replies, posted in General discussion)

superg wrote:

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.

139

(3,531 replies, posted in General discussion)

sarami wrote:
Neon Beast wrote:

It has some weird CD-text, probably causing the problem.

CD-TEXT supports "ISO/IEC 8859-1", "ISO/IEC 646", "MS-JIS (CP932, SJIS)" https://www.gnu.org/software/libcdio/cd … 80x8f_0029
But this disc uses Unicode. Therefore, unicode needs the conversion to these character codes.

Added. https://www.mediafire.com/file/eq80y20l … st.7z/file

140

(3,531 replies, posted in General discussion)

Neon Beast wrote:

It has some weird CD-text, probably causing the problem.

CD-TEXT supports "ISO/IEC 8859-1", "ISO/IEC 646", "MS-JIS (CP932, SJIS)" https://www.gnu.org/software/libcdio/cd … 80x8f_0029
But this disc uses Unicode. Therefore, unicode needs the conversion to these character codes.

141

(3,531 replies, posted in General discussion)

NovaAurora wrote:

CD-R Enhanced CD (Multisession)
Errors out the entirety of the data track, dumped twice with same hashes.
Data track is functional on the actual disc, so it is not a burn error.

I got the same title disc, but its no problem.

Your disc exists a problem.

_disc.txt wrote:

========== FULL TOC ==========
:
:
    Session 1, Ctl 0, Adr 5, Point 0xb0,   NextSession, AMSF 69:28:33 (LBA[312483, 0x4c4a3])
:
:
    Session 2, Ctl 4, Adr 1, Point 0x0e,      Track 14, AMSF 69:00:00 (LBA[310350, 0x4bc4e])

Track 14, AMSF is incorrect. Try to dump it by the other drive except for PX-716.

142

(53 replies, posted in General discussion)

I recently analyzing some prx files. The result is here. https://github.com/saramibreak/UmdImage … master/Doc

If someone can read MIPS code, please tell me the usage of the SCSI-like function (e.g. sceUmdExecReadUMDStructureCmd, sceUmdExecRead10Cmd, etc).

According to the function name, sceUmdExecReadUMDStructureCmd looks like ReadDVDStructure of the SCSI-command, which can read PFI and DMI etc.

143

(3,531 replies, posted in General discussion)

Foxhack wrote:

Okay.

Attempted to dump http://redump.org/disc/62090/ , two different discs produce the same result. I ran it through MPF, and the window closed. So Silas suggested I do it from a command line and DIC just closes after detecting the securom version on this disc, with no errors. I tried two different copies of the same disc, they all crashed the same.

Removing /ns and /sf allowed the disc to dump fine.

Try this build.
https://github.com/saramibreak/DiscImag … issues/122

144

(3,531 replies, posted in General discussion)

Foxhack wrote:

Tried to dump what I believe was this disc http://redump.org/disc/21540/

And it crashed when scanning the files on it. See attached image.

This is E_WISE_W.EXE error, not DIC. I can't fix it.

145

(3,531 replies, posted in General discussion)

user7 wrote:

Thanks, has this affected all recent x360 dumps or just specific discs then?

Not recent. All x360 disc except the unlock length is 3697696 or 4246304.

========== TOC ==========
      Data Track  1, LBA        0 -  3697695, Length  3697696
                                              Total   3697696

146

(3,531 replies, posted in General discussion)

user7 wrote:
sarami wrote:
user7 wrote:

Sarami just so it doesn't escape your notice. Xbox 360 bug http://forum.redump.org/topic/43472/xbo … rial-disk/

Is there your disc logs of the latest version?

http://forum.redump.org/post/100345/#p100345

https://www.mediafire.com/file/eq80y20l … st.7z/file
- fixed: version check (Use "Version of challenge table", not the disc size)

147

(3,531 replies, posted in General discussion)

user7 wrote:

Sarami just so it doesn't escape your notice. Xbox 360 bug http://forum.redump.org/topic/43472/xbo … rial-disk/

Is there your disc logs of the latest version?

148

(3,531 replies, posted in General discussion)

F1ReB4LL wrote:

It's there, but its size is 0 bytes.

fixed.
https://www.mediafire.com/file/eq80y20l … st.7z/file

149

(3,531 replies, posted in General discussion)

F1ReB4LL wrote:

why not to dump it separately as Pregap.bin or Track 00.bin?

Is there .pre file? If yes, it's the pregap sector of the track 1.

150

(3,531 replies, posted in General discussion)

F1ReB4LL wrote:

Does it mean the leadout has non-zero data?

No, LBA 288285 is the 1st lead-out sector, therefore "LBA 288285 + -1" indicates the last sector.