LeoneFamily wrote:

Well I always deleted one of the logs every time I confirmed that 2 or more dumps were identical. I did that for all my dumps, including the 500+ I haven't yet posted. So I don't have the other log. But that's exactly the point, I don't need to be credited twice for dumping the same game twice. Just pick the one log that's left, and in the "Edition" field of this disc, you can add both "Original" and "Includes Music CD" versions.

And if that's still not enough and you don't want to "believe me" that the 2 releases are identical, then at least you got one version and you can just post that one and ignore the other release in the second "!submissioninfo". It only comes at the detriment of having less useful info on Redump for that disc.

Well there's not much we can do about the ones you've already deleted - I'll try to match the single set of logs provided to a given edition and add only that one. For future reference, the requirement is that each physical disc requires an associated set of logs - this applies to everyone, no matter how many dumps they've submitted or how "trusted" they are.

LeoneFamily wrote:

I explained this exact situation in my "READ ME REDUMP MODERATORS" text file at the beginning of my Google Drive. I must assume you have not read it. It says:

Sometimes, I may have dumped multiple discs that matched for the same "game" (i.e. identical discs). When this happens, I delete all the duplicate logs (I keep only one) and only keep the "!submissioninfo" files. I then edit the file name only to differenciate between the two (or more) releases by adding "(xxx)" at the end of the file name. Example: (Original [NA]), (Original [CA]), (Greatest Hits [NA]). EVERY TIME I did that, I always made sure to check if all the MD5, size, CRC and SHA all matches. I only ever kept one of the logs for each identical release since I have already verified that it matches. For games that were dumped outside of MPF (such as PS3), I have checked for MD5 matches using MD5checker and checked for identical file sizes in Windows. When it applies, I always check if the protection info is the same, and I leave only one (!protectioninfo) file when they are identical.

Let me be a lot clearer - I don't care what you say in your readme, we have a standard submission process that you're being asked to follow. Either do so or your submissions will be discarded.

This needs another set of logs - the post indicates that Road Rash has been dumped twice from two separate discs, but only one set of logs is included

4

(1 replies, posted in Verifications)

PMed dumper to recheck toolstamp - all other entries are in the format T-8101H #/95 ##SB#

5

(7 replies, posted in General discussion)

Nemok wrote:

Everything was in the tone, I could have said something like "ok then, never mind". You are feeling offended for no reason.

See, here's the thing - language isn't all in the tone, it's also in the word choice. You're right, you could have said "never mind", but you chose to say "F*** consistency". Whether or not that phrasing is softened with an emote, is hard to read as anything other than offensive and dismissive.

To bring this discussion to a practical close, for what it's worth this is something we've been discussing recently amongst staff and we may have a resolution at some point soon.

6

(7 replies, posted in General discussion)

Nemok wrote:

Alright... f*** consistency then smile

What's with the bad attitude? We have well over 100,000 items in the database, added as part of a project spanning nearly 20 years, with about 1,000 new items a month being added. Of course there are times when there are inconsistencies in the way that information has been or is being added.

Staff work incredibly hard and are constantly discussing ways to improve the quality and consistency of information that we hold, and we're always open to hearing feedback on how it can be improved, but this kind of throwaway comment doesn't exactly motivate anyone. Try and think a bit before posting this kind of thing next time.

Submission is missing ringcodes - DM sent to dumper

Asked UnlockerPT to double-check the mastering code for Disc 1

9

(1 replies, posted in General discussion)

I've been trying to track this for UK coverdiscs for a while, so I've moved over my notes for most of the smaller magazines now, hopefully some of the pages are looking a bit more filled out.

I've got a fairly comprehensive list for PC Zone but will take a while for me to get the most recent updates translated properly to wiki formatting - just a note so that people focus efforts elsewhere, I can definitely get that page complete in time.

10

(3,508 replies, posted in General discussion)

sarami wrote:

@mictlantecuhtle
I'm changing the code for dumping the multi-session disc https://github.com/saramibreak/DiscImag … issues/208 . Please wait a few days.

EDIT
Updated test version. https://github.com/saramibreak/DiscImag … r_test.zip
- deleted: /ms and the related code

@sarami

Thanks for this, unfortunately it doesn't solve the issue I'm having. In order to correctly calculate the session lengths (see comments for http://redump.org/disc/102164/) we need _disc.txt to contain the following as it did previously:

- Lead-out length of 1st session
- Lead-in length of 2nd session
- Pregap length of 1st track of 2nd session

No version after 20220909 (including the test version above) includes this information. As such we are unable to process some multi-session dumps made with recent DIC builds

11

(3,508 replies, posted in General discussion)

FAO sarami

Recent builds of DIC (tested with 20230309 and 20230413) appear to be outputting incorrect information for multi-session discs. As far as I can see it is no longer correctly analysing the 1st sector and its lead-out, and is effectively treating the entire 1st sector as if it were lead-in for the 2nd. See as follows info from _disc.txt for http://redump.org/disc/102164/:

20220909

Set OpCode: 0xd8, SubCode: 8(Raw)
 Lead-out length of 1st session: 6750
 Lead-in length of 2nd session: 4500
 Pregap length of 1st track of 2nd session: 150

20230413

Set OpCode: 0xd8, SubCode: 8(Raw)
 Lead-in length of 2nd session: 208897
 Pregap length of 1st track of 2nd session: 150

Track sizes and hashes remain consistent across builds, it appears to just be the information output that is incorrect.

12

(2 replies, posted in Guests & account requests)

Balle wrote:

Hello, i would love to join this project.

I mainly wanna contribute with budget series(main focus is Sold Out Software and Ubisoft eXclusives) and odd titles.

Hey, welcome and thanks for your interest!

Great that you want to contribute - I personally have an interest in UK budget labels so excited to see more on that front.

There are only a couple of people who can approve accounts and they're both very busy so it could take a little while. In the meantime, a lot of the community is active on the VGPC Discord so feel free to join that and chat while you wait for your account to be approved.

I have a copy of PocketPC Power-Pack (https://usk.de/usktitle/12597/), a compilation of games and applications for PocketPC published on a DVD. Could DVD be added as an option for Pocket PC submissions please?

14

(1 replies, posted in Guests & account requests)

Would like wiki access please to be able to help curate some info around undumped IBM PC discs

Digitoxin wrote:

I tried using a flatbed scanner, but the resolution wasn't high enough (Only does 300 DPI).

My phone was a little better, but getting the right angle was difficult and there were too many reflections.

I ended up going with a 15x handheld magnifying glass with a built in light.
https://www.amazon.com/dp/B08C7KN2YC?ps … ct_details

I use a combination of the smartphone method from this forum post, which works well for 99% of discs I've tried it on so far, plus a cheap loupe with 30x/60x magnification that I picked up from Amazon. That helps to get some of the really tiny mould SID details that a camera won't capture.