This is a games database and now you want to mix games and movies together in the same system?

2

(2,747 replies, posted in General discussion)

sarami wrote:
reentrant wrote:

Anyway I have some good news. After some coding and experimenting with F1 command I can enable reading more sectors from cache.

Great works!!

Added your code and some changed. Test Plz. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

I'm not a coder, but it seems like you are trying to combine sectors from cache reads based on the assumption that they are all data sectors with correct sync/header? How will it handle audio sectors or mastering errors safely?

3

(2,747 replies, posted in General discussion)

Agent47 wrote:

Quake redumped with latest test version: https://mega.nz/file/bzBjGCJK#U0WD3bymv … 03o5wnvhFs

But why should Track04 be 02:00 ? @F1ReB4LL?

Especially when discs without MCN have the same 01:73 gaps: http://redump.org/disc/2251/

And if this fix is valid, it means that we have to recheck/redump every dump with a new version?

4

(2,747 replies, posted in General discussion)

sarami wrote:

P and Q-channel of the track02 of Hexen are estimated that it matches because all P and Q-channel of the other track match. As a result, 021027 belongs to the track02.
P and Q-channel of the track04 of Quake are estimated that it does not match because all P and Q-channel of the other track don't match. As a result, 050680 belongs to the track03.

So the logic before the 2020-11-01 version was to look at P-channel when Q-channel wasn't available? I agree with F1ReB4LL that it's best to stick with this logic, unless there is such a thing as a P-Q offset tongue

I don't understand the new fix. With the new fix, the Quake track04 pregap would become 02:00? This seems wrong, when the other tracks are all 01:74.

5

(2,747 replies, posted in General discussion)

- fixed: output incorrect pregap when Q-channel's pregap is 00:01:74 and the adr of 00:01:74 is 2(MCN) or 3(ISRC)

I'm lost now

This new version produced the same (bad?) dump as old versions (from 2019 and earlier) for this disc: http://redump.org/disc/25734/

"01:74 is wrong, because the P and Q gaps are in sync and P-channel shows 00:02:00 gap there"

That disc was the reason that we were rechecking everything: http://forum.redump.org/topic/31979/wro … he-damage/

New logs: https://cdn.discordapp.com/attachments/ … 0/Hexen.7z

So please tell us. How to identify possible bad dumps and which version should be used to redump them? And this new fix is invalid?

6

(2,747 replies, posted in General discussion)

Very strange difference. Same ringcode, 2 different dumps:

http://redump.org/disc/25734/ - logs from 2017: http://www.mediafire.com/file/ce4b73luc … fo.7z/file and 2019: http://www.mediafire.com/file/qonu94lfb … se.7z/file (.cue not included but matches db)

http://redump.org/disc/73543/ - new logs: http://www.mediafire.com/file/pkf96uk40 … en.7z/file + http://www.mediafire.com/file/1nw1uf9iy … ck.7z/file (slower speed and /s 2)

7

(2,747 replies, posted in General discussion)

PC game giving all audio tracks: https://drive.google.com/file/d/1WtnX2a … sp=sharing

http://forum.redump.org/post/84049/#p84049

8

(34 replies, posted in General discussion)

user7 wrote:

green key is the production crypto key, it's what they use to encrypt the XVDs for production. there's also the red key which they use for development that all devs have

https://github.com/emoose/xvdtool
is the tool to use supposedly :shrug:

So this is for Xbox One, not Xbox neutral

9

(34 replies, posted in General discussion)

LedZeppelin68 wrote:
user7 wrote:

Any chance you would consider open sourcing this?

sure, here it is: https://github.com/LedZeppelin68/dvd-shrinker

all credits for the algorithms goes to JayFoxRox

The "green key" has been leaked, whatever that is. Would it be of any help in obtaining the second type seed?

Also, I noticed that the wiki was updated since our last posts, so maybe there are new insights: https://xboxdevwiki.net/XDVDFS#Random_blocks

The ringcodes would be more useful

user7 wrote:

>However, if I ordered the game from the US, I would still get to choose the artwork?
No, the USA packaging variant had been distributed to USA-based webshops. I would have to import from a European seller if I wanted the European packaging.

>And anyone from anywhere could order any artwork variation? So I fail to see why it should get (USA) region then.
You would have to import it. So the second sentence is an incorrect premise.

If this is really the case here then I guess USA region makes sense. Updated the region and comments for that dump.

If there are any other dumps left that are worth discussing, post them here.

>So the barcode is Dutch
Same with many Action Replays. Same barcode worldwide, different executeables.

>, the disc was made in Germany.
All PS2 made in Austria, unless you agree all PS2 should be marked as Austrian region, this argument is inconsistent.

I meant to say that the combination of a European barcode and European disc should mean that the dump gets Europe region.

Fixed, but they were all submitted that way by you.

yeah, Ignore that bad logic, if you go my manufactured region then all discs mastered by nimbus should be assigned to Wales.

Nimbus isn't exclusive to Europe. USA discs with IFPI L125 are from a facility in Charlottesville USA. I don't remember any European manufactured Nimbus discs with non-Europe region?

So we have a couple different cases:

- PAL or NTSC-US console discs manufactured in for example Japan, in the case of Nintendo games.
- Datel unlicensed stuff released with the same barcode worldwide and all manufactured in Europe. However, the USA releases have USA specific information on the box and the mastering ringcode contains USA or NTSC and the discs are region locked.
- USA manufactured IBM PC stuff released in other regions, for example some Asia/Pacific EA releases, and some early Activision games (MechWarrior 2, Pitfall Europe). The barcode and box/covers indicate the correct region.
- Web order (Unlicensed, Kickstarter etc.) stuff where the same disc is sold from a central place and distributed worldwide.

With these exceptions in mind, I think this would be the correct way to determine a region?
Was a disc manufactured for release/distribution in a specific region (excl. World, so Europe / USA / Asia, etc.)? If so, then that region should be assigned, if not then the region of origin should be assigned.

And this is basically the rule that we've been applying so far?

By this logic, a game would only get (World) region if there's different discs from different regions with matching dumps, like we have with Xbox (360) and some other systems.

You can't go assigning (World) regions to these Web order discs just because they are distributed worldwide. They are still products of a particular region/country of origin. The ringcode and barcode clearly indicate a specific region.

But the reason why this topic was created is yet another different case, where we have a web order game with European ringcode and barcode that is sold with different artworks, supposedly for different regions. However, if I ordered the game from the US, I would still get to choose the artwork? And anyone from anywhere could order any artwork variation? So I fail to see why it should get (USA) region then.

So the barcode is Dutch, the disc was made in Germany.

For normal (licensed) console titles, the region is easy to determine.

For unlicensed discs and some PC discs, determining the region can be a challenge.

Is this a European release exported to the US, albeit with different packaging?

If it's a US release, then why is the barcode European?

My solution would be to leave region (Europe) and comment as is.

14

(2,747 replies, posted in General discussion)

Xbox 360 error handling still seems not safe.. 5 retries and "Retry OK", but the sector seems to be corrupt.

15

(9 replies, posted in General discussion)

user7 wrote:

They need the subs to properly function, so redump should either add the subs for download or include in the dat.

I'm sure that iR0b0t will get into high gear when reading this post (not)

16

(2,747 replies, posted in General discussion)

sarami wrote:
Jackal wrote:

but the output dump is 3825798 sectors?

https://www.mediafire.com/file/eq80y20l9cwf48f/file
- fixed: seek position when reading error occurs [xbox only]

Indeed fixed cool

17

(2,747 replies, posted in General discussion)

I dumped with:

dic xgd2swap e nfsu 4 3825924 108976 3719856

but the output dump is 3825798 sectors?

logs attached

I think the bottom line on this is gonna be that we can't verify that the dump is good or bad unless you buy a disc that's already dumped and verify that. It's possible that due to different mastering, the USA disc has more errors.

Here are some places to buy Tropico (Europe):
https://www.medimops.de/tropico-pc-von- … 5AM6R.html (3 EUR shipping to US)
https://www.ebay.com/itm/Tropico-pc-gam … SwWxNYuH-S

Could you post a scan or picture of the disc? I guess I could look for a copy, if it's a different release from the one that's dumped.

It's probably a driver issue. Most drives such as that Optiarc should be able to read single errors with CloneCD.

I think CodeLock is always single errors. If it reads in blocks of 2 or more errors then something is wrong with your drive or drivers or the read mode that is used. The correct error count is most likely 758 for your disc, just like the Europe one. Do you have any other drives that you could try? And no point in retrying sectors. Either the drive reads them or it doesn't. Plextors are unable to read single errors.

22

(2,747 replies, posted in General discussion)

@sarami I tested the xgd2swap command today and it works. The dump matches the 0800 dump from Xbox Backup Creator.

I have some questions though:

D:\dic>dic xgd2swap e prostreet 4 3825924 108976 3719856
AppVersion
        x86, AnsiBuild, 20200711T101216
valid extension was omitted. -> set .bin
CurrentDirectory
        D:\dic
WorkingPath
         Argument: prostreet.bin
         FullPath: D:\dic\prostreet.bin
            Drive: D:
        Directory: \dic\
         Filename: prostreet
        Extension: .bin
StartTime: 2020-07-18T10:24:16+0200
Set the drive speed: 5540KB/sec
Reading DirectoryRecord    3/   3
Creating iso(LBA)  4167012/ 4167012
Hashing: prostreet.iso
EndTime: 2020-07-18T10:37:19+0200

You can see here that I entered 3825924 as size, and the output file has the correct size, but still, the drive reads up to sector 4167012. Is this necessary?

Also, for xgd3swap you would need a swap disc that is 4267015 sectors long. I will see if it's possible to burn a fake TOC, because normal DVD9's (and DVD+R DL) are much smaller.

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

24

(3 replies, posted in Fixes & additions)

Do you have any other disc with audio tracks dumped before where DICUI gives matching checksums?

25

(3 replies, posted in Fixes & additions)

Hi, can you redump again with a plextor drive? We can't trust any other drives.