Redump already modifies data by not using rawdump. We're organizing data in a useful way. Fixing bad mastering falls in line with that. Just note and offer patches for the bad parts.

302

(3,497 replies, posted in General discussion)

Sarami, so far so good. I dumped two variants on GTA Vice City, the subindexes in the cue do not match:
https://drive.google.com/file/d/1BULb9E … sp=sharing
https://drive.google.com/file/d/13IReoY … sp=sharing

303

(3,497 replies, posted in General discussion)

I have an unlicensed Mini-CD that has a full-size-CD TOC. Is there anyway to tell DIC to just dump the maximimum mini-CD TOC length, instead of trying to dump the part of the disc that doesn't exist?

If you don't treat betas differently, you could have hundreds of entries for the same builds with a few byte differences just because the burner used some crap software / poor quality discs.

305

(3,497 replies, posted in General discussion)

sarami wrote:
user7 wrote:

Dumped with /sf /nq /c2 twice each on my 760SA and 708

All four dumps "no unintentional c2 errors", none of the hashes matched either...

It seems 708 is good.

The two 708 dumps don't match hashes hmm

306

(3,497 replies, posted in General discussion)

Sarami, would it be possible for dic to auto-detect multisessional discs and use "/ms" automatically?

Thanks again for your amazing work, its very cool to see multisessional discs correctly represented in redump smile

F1ReB4LL wrote:

That's surely a mistake, these need to be added as separate entries. Just look at the Saturn or Mega CD pre-releases - many of them have the same data, but only differ in gaps or have a differently shifted audio.

And I wouldn't call our current handling of those sega systems ideal.

Non-pressed discs should be treated differently - for example Total NBA 98 was handled correctly.
I have a couple PS2 final betas I never submitted to redump because I don't believe an 8-byte difference warrants having an entry or collecting a rom for. However the result is that the particular disc is not accounted for in redump.

Thank you iRobot, here's my updated cue dumped with /ms: http://forum.redump.org/post/72070/#p72070

How long before we can add Mil-CD? Thanks!

REM SESSION 01
FILE "Acclaim_At_ECTS_ (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "Acclaim_At_ECTS_ (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Acclaim_At_ECTS_ (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Acclaim_At_ECTS_ (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Acclaim_At_ECTS_ (Track 5).bin" BINARY
  TRACK 05 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Acclaim_At_ECTS_ (Track 6).bin" BINARY
  TRACK 06 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Acclaim_At_ECTS_ (Track 7).bin" BINARY
  TRACK 07 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM LEAD-OUT 00:00:00
REM SESSION 02
REM LEAD-IN 00:00:00
REM PREGAP 00:00:00
FILE "Acclaim_At_ECTS_ (Track 8).bin" BINARY
  TRACK 08 MODE2/2352
    INDEX 01 00:00:00

This is what was submitted.

Submitted.

iRobot, does this help? http://forum.redump.org/topic/23287/pc-multisession-x1/

I think just as often, mismatching could be bad mastering.

For example, read the comments: http://redump.org/disc/607/

It would be nice to have xdelta patches attached to entries for such items. Ideally the CRC32 for all variants would still show up in searches.

314

(3,497 replies, posted in General discussion)

Dumped with /sf /nq /c2 twice each on my 760SA and 708

All four dumps "no unintentional c2 errors", none of the hashes matched either...

Disc is scratchless. (Its an action replay ps2 disc)

logs: https://drive.google.com/drive/folders/ … sp=sharing

315

(3,497 replies, posted in General discussion)

"Creating .scm (LBA)   4497/323849 LBA[004498, 0x01192] Detected C2 error 2324 bit
Creating .scm (LBA)   4498/323849 LBA[004499, 0x01193] Detected C2 error 1124 bit
Creating .scm (LBA) 219173/323849
LBA[219174, 0x35826]: Failed to reread because crc16 of subQ is 0. Read back 100 sector
Set the drive speed: 4233KB/sec

LBA[219174, 0x35826]: Failed to reread because crc16 of subQ is 0"


Is dic telling me i should try to redump at a certain drive speed? I got that bolded message when dumping at 8x and 2x

316

(3,497 replies, posted in General discussion)

sarami wrote:
user7 wrote:

here is an unlicensed PS2 disc that does not work with /sf flag

If there is not BIG.DAT, DIC can't detect protection.

https://imgur.com/3UIO2lJ

All four files copied over fine, but not for dumping hmm
IsoBuster doesn't like it either.

317

(3,497 replies, posted in General discussion)

https://drive.google.com/file/d/1t_nCkh … sp=sharing

Sarami, here is an unlicensed PS2 disc that does not work with /sf flag. I wonder if there are any clues for getting this one to dump? I have been buying many unlicensed PS2 discs lately, some of them behave very strangely, others dump fine with /sf.

Presuming we stay with Jackal's numbering system, then the Italian entries should be modified to line up with the other OPS2M demos.

For example if the title should be renamed: Official PlayStation 2 Magazine Demo [number relating to UK release contents] (Italy).

Which carries none of the original information. I'm not sure why Italy did not receive the Jackal naming treatment yet, but Germany has - both of which refer to dates on their disc labels and not issue numbers.

>The disc title is "ops2m demo 73/benelux". ops2m = Official PlayStation Magazine.

The benelux demo is a regional exclusive for that serial number / data variant. A different number is on the sleeve, the correct chronological number in the series. Again, you're ignoring the fact that there are TWO demo #s for these releases and picking the one that is NOT linear to the local series.

>Using the magazine titles and issue numbers doesn't appear to be a good solution, especially because different magazine issues from different countries can have the same disc.

Its not just "Magazine titles and Issue Numbers" its the Demo Disc # on the sleeve. The sleeve demo numbers are ordered linear, the demo disc numbers are not.

>especially because different magazine issues from different countries can have the same disc.

These are already tracked inside the master (UK) entries - which are completely dumped, however this does not relate to regional exclusives.

> The solution that you provided for those cases of just picking one of the countries / issue numbers to go in the filename (and thereby ignoring the other ones) is unacceptable imo.

Its better to use one accurate title, than an inaccurate one. These regional exclusive discs are NOT released as the titles you're putting them as. You're ignoring the proper regional order and title/Demo# on sleeve, while defaulting to UK titles that don't even appear ANYWHERE on disc or packaging.

Here's an example of why your system of numbering is terrible.

Looking at AUS by going off the Disc Label Demo #s for issues 10-15, this is how your system would title them:
10
16
12
31
32
33

By going off the Sleeve Demo #s:
10
11
12
13
14
15

You're giving these entries Demo #s that came from re-used artwork, rather than their proper release order (sleeve demo #'s).

There are TWO Demo #'s on all these releases. You're choosing the bad system to act as title entries.

>One one hand, of course we want to use the titles used on the disc/box

Well to be clear, the box has one Demo # and the disc label has another Demo # often. Within a region, the box Demo # flows in a stable order: 1, 2, 3, 4, 5, 6..., whereas the disc label Demo # follows an uneven order: 3, 2, 7, 12. The reason is because the disc labels #s are adapted from the UK disc labels.

This usually doesnt matter because they'll match the UK entries (which are treated as master titles with sans-UK in their name), but when regional variants are unique builds, the waters get murky. This is why I believe using the packaging Demo # is more accurate, because the Disc Label #s are repurposed out from other counties out-of-order numerically. The disc label Demo # refers to "random grab bag region where we pulled disc label art from without updating it".

This is why it makes the most sense to use the packaging Demo #s.

However with NL Demo 80, it had a disc label # of 101. I can see this being a nice bookend and why it's tempting to name it as 101 in the redump entry, but in the context of all regions with exclusive variants, it's not the best approach due to the above mentioned chaos of disc label demo #s.

Yes, they did this in many instances. They reused UK labels, even when modifying the data so that it does not match UK releases. That's why there's such a huge mismatch between packaging #s and disc label #s outside of the UK releases.

MOST disc label numbers do NOT match their packaging #'s for anything outside of UK.

The packaging numbers count like this:
1
2
3
4
5
6
7
8
9

The disc label numbers count like this:
1
2
5
7
8
10
13
9

Re-read. This is about choosing one system of numbering over another. This does not relate to a specific incident but MANY, but your arbitrary changing of the most sensible system of numbering of random entries.

There are two Demo #s on all OPS2M releases, you're choosing the irrational option for the titles.

Attention *clears throat* *taps podium mic*

As many of you know I've been hunting PS-series PAL demos for quite some time. OPS2M PAL demos are particularly tricky for several reasons. One of the biggest reasons is that discs from Region A often get released into Region B and the data is modified between regions. This by itself wouldn't be an issue, however the disc label from Region A carries over to Region B, which conflicts with the Issue # and packaging Demo # from Region B.

For example:
This demo was released as an exclusive to Benelux. This serial number has never been spotted in another region. Now there are technically two different demo #'s this could be labeled as:

* Officieel PlayStation 2 Magazine Demo 73 (referencing the disc #)
* Officieel PlayStation 2 Magazine Demo 57 (referencing the packaging # and issue #)

I argue the disc # is the incorrect one to use because it is incongruent with the regional ordering. If we used disc titles for all regional variants and lined them up, you'd see numbers wildly skipping around.

In addition to Jackal modifying / favoring disc label numbering (which is unintuitive), he also is renaming entries with the UK titles, for example this entry is named: "Official PlayStation 2 Magazine Demo 73". Nowhere on this disc or packaging does "Official PlayStation 2 Magazine" appear, period!

In addition, many other entries go by packaging / issue numbering (which makes perfect sense), however Jackal's modifications do not!

Here's another example: http://redump.org/disc/51793/
The packaging number is 9, the issue number is 9. It is the 9th disc released in the series in France.
HOWEVER! If Jackal's reign of terror continues, this would be relabeled as "ops2m demo 11" because that's what the disc label says. Is it from the 11th issue? NO. Is it listed as the 11th Demo on the packaging? NO. Is it arbitrarily called the 11th issue on the disc label because the disc label art was ported from another region? YES.

For these reasons, we should go with the packaging Demo #'ing system and not the inaccurate disc labels that Jackal is so keen to use and mess up the database with. Right now, Redump OPS2M regional entries are a mish-mash of packaging/issue and disc label numbering.

Please let us bring accurate order to this chaos, not add to the misinformation.

*Pokes iRobot with a sharpened stick.*

*Pokes this thread*

Are we at a standstill at getting Multisession discs added to redump, or are we waiting on DIC for an update?