1

(24 replies, posted in Guests & account requests)

@iR0b0t dont discredit someone because of the e-mail address that they are using!

The ip is Austrian. AtariBuff is known to be Austrian.

Grand Theft Auto IV (World) (En,Fr,De,Es,It) (Disc 2) was "USA, Europe", and was then dumped by Pietro, as Brazillian. It is my opinion that in this case, it should just stay "USA, Europe" with "Brazil" in the comments

I think you are taking the "World" thing too literal. It basically mean different continents, but not (just) the continents that are in the typical twin regions.

USA + Europe + Australia should be World, not USA, Europe.
Same goes for USA + Europe + Brazil.

Interstate '76 is Europe + Brazil

Let's not make new twin regions for every new combination of countries that pops up. If we have like 5 or more discs with the same twin region then it's worth adding, but not for 1 or 2 discs imo.

http://forum.redump.org/post/20649/#p20649

Seems to be legit

The thing is, the ringcodes are all different, and we checked the AOE3 dump and it has 10 errors and the data seemed fine. The data differences are not in the error sectors but around them. So I guess you should add both your dumps as (Alt).

Could you try to dump both discs on a non-plextor drive with CDM or CloneCD and see if you can get matching dumps with 10 errors?

ajshell1 wrote:

Sarami recently released a new test version of DIC. It dumped Fable TLC with a proper checksum, so I dumped the other two discs with it as well.

And wouldn't you know it, my CDManipulator dumps match the new version's dumps. And CDArchive doesn't give me any errors after scanning them.

With that in mind, I've uploaded my logs here.

With Jackal's permission, I'll adopt these checksums as the proper dumps.

Do you have the ringcodes for your dumps? They are prolly mastering differences. I don't see how different dumps from the same disc could cause differences? I mean, the only way it could mess up is if one dump has more than 10 errors?

Just make sure your dumps have 10 errors, otherwise it's a bad dump. You could also use CDM or CloneCD. The only difference with DIC should be in those 10 sectors. The last 2336 bytes should be 0x55 bytes.

8

(1,693 replies, posted in General discussion)

sarami wrote:

I'm not sure about it, but many sony dadc discs have -647. At least, I hope all 99 modified SecuROM discs are dumped again to get _disc.txt.

Does your Colin McRae Rally 2 disc also have -59 in one mode?
I guess we only need to check a couple discs and if they all have this problem, just fix all -59 discs to -647.
I dont know if this also affects discs with +588 offset which should be 0? Many discs have +588.

Jackal wrote:

SubCode[0] dumps only main-channel. dic only uses this to output offsets in _disc.txt. No problem about sub-channel.
Or does this question mean that SecuROM sector 157 haven't fixed yet?

No, this was the only disc

9

(1,693 replies, posted in General discussion)

sarami wrote:

Uploaded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file But I haven't tested yet because I don't have same type of SecuROM.

Jackal wrote:

- Could the write offset of +576 be wrong? it's -12 plus 588 samples (1 sector). I've never seen this offset before.

Colin McRae Rally 2.0 http://redump.org/disc/31587/
This disc has also same issue.
1. OpCode[0xd8]: SubCode[0] shows -59.
2. OpCode[0xd8]: SubCode[2] shows -647.
3. OpCode[0xd8]: SubCode[8] shows -647.

I think -647 is correct.

So is it safe to assume that all discs in the database with -59 offset are actually -647, and +576 are actually -12?
Is it possible that other offsets are also affected?
And securom data remains the same? (the test version produces the same data)

And what about audio tracks that are dumped with -59 offset? (I'm not sure if there are any)

wiggy2k wrote:
Jackal wrote:

Kludge could prolly help you out, but he's AFK.

How fast do you need it? When do you start working again (I'm assuming you're here because you have vacation)?

It’s not an immediate need, Just soon or i’ll Get distracted.

Nah I’m back at work now,
Only had Xmas day and Boxing Day off.

Things have calmed down a lot lately though, we employed some new staff who are actually up to the job so I’m not so busy anymore (Linux sysadmins are hard to come by) And have sorted more care for mum so I don’t have to look after her so much now so have more free time as not travelling down to see to her every other day.

Ah ok smile I guess Kludge will be back soon

Kludge could prolly help you out, but he's AFK.

How fast do you need it? When do you start working again (I'm assuming you're here because you have vacation)?

12

(1 replies, posted in Fixes & additions)

Plz resubmit as IBM PC DVD-5. If it's not just DVD-Video then it should be IBM PC multimedia

I'm getting confused about this discussion. It will always be about filling holes.

There are basically 3 options which essentially do the same thing:

- Use PREGAP, which is already available and supported (but which you both don't like)

- Use "REM SINGLE-DENSITY AREA" + "REM HIGH-DENSITY AREA", which can only be used by emulators and requires hardcoded LBA values. (this seems to be the only option that F1ReB4LL is willing to discuss)

- Come up with a new command, which would get easier approval by other developers (e.g. IsoBuster), even if in the end it would only actually be useful for Dreamcast discs. For example:
REM STARTLBA "HIGH-DENSITY AREA" 45150
REM STARTMSF "HIGH-DENSITY AREA" 10:02:00
REM AREA "HIGH DENSITY" 45150

or even a simple GAP (in LBA of MSF) command to put in between tracks:

REM GAP 09:42:68

F1ReB4LL wrote:

No global commands are needed right now. These commands will be only useable when and if we decide to dump lead-outs/lead-ins (which are standard in 99,99999999% of cases and can be generated with REM LEAD-IN/REM LEAD-OUT commands, similar to PREGAP/POSTGAP). You're trying to alter the whole cuesheet logic and don't even understand that, nobody will support such a complicated format.

REM SINGLE-DENSITY AREA
REM HIGH-DENSITY AREA

This would require coders to implement 2 commands exclusive to dreamcast discs, one with a prefixed start LBA of 0, and the other with 45150.

It would be less complicated and more useful to have a single new command, START or AREA or whatever you want to name it, which requires input of the start LBA.

I hope you will agree, so that we at least have something to work with and to submit to developers.

iR0b0t wrote:

Honestly, I would be fine with what you suggest @F1ReB4LL but in the end the emulaton / mounting devs have to adapt their tools to that. Independently of what they would accept, if I developed such a tool myself I would rather prefer a global command which can be used on any system, not just one.

Let the devs know and arrange an adaptation, if they decided anything I will go by that, its not a big deal.

See my previous post. I agree it would be best to implement a global command. What do you think about my suggestion?

iR0b0t wrote:

A separator is not really needed. Anything between "REM" and traling "START LBA NUMBER" is to be treated as a plain comment or a COMMAND, which will be recognized if its called "SESSION NUMBER" or "LEAD-IN" or "LEAD-OUT" or whatever commands you want to have there.

I think it should start with a real command and require input of a number, for uniformity and to allow other uses besides dreamcast.

REM <COMMAND> <OPTIONAL DESCRIPTION> <START LBA NUMBER>

REM AREA "SINGLE-DENSITY" 45150

or

REM START "SINGLE-DENSITY AREA" 45150

Where the " " are optional and the last number is assumed to be the start address?

F1ReB4LL wrote:

SINGLE-DENSITY AREA always starts at 0, HIGH-DENSITY AREA always starts at 45150, additional commands aren't needed here. These are to be discussed later for the multisessional discs (though, even they should have REM LEAD-OUT and REM LEAD-IN generating commands, not that LBA thing).

iR0b0t wrote:

You know that they start there because you are aware of that, but mounting tools do not know it.

Yeah, but anyway: REM NAME / START LBA  is also a new implementation that isn't supported yet by any software.

If you want to assign a unique command for dreamcast discs that assumes fixed starting positions, then maybe 'LDA' and 'HDA' are better names.

I like this solution:

iR0b0t wrote:

REM SINGLE-DENSITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

As long as the start address of a track can be specified, there is no more need for PREGAP.

Maybe add a separator between the data area description and the start address, e.g. like this:

REM HIGH-DENSITY AREA ; START LBA 45150

and should we use LBA or MSF?

REM HIGH-DENSITY AREA ; START MSF 10:02:00

or a more abbreviated (but less descriptive) alternative, where the second part value is assumed to be the start address:

REM HDA 45150

Or a description with spaces would require " "

REM "HIGH-DENSITY AREA" 45150

And yes, this standard could be used for other disc types, e.g. multi session, and more data areas could be added when needed.

F1ReB4LL wrote:

I've already mentioned such a solution. The problem is that such a cue is only "correct" for isobuster, other tools will "see" this track 9+ minutes longer than it should be.

Actually, Track03 is shown with the correct size and starting address.

The only problem is that the Track02 end address aligns with Track03, but when you browse outside of the data range, it gives read errors.

I don't think this is a problem, it's merely a restriction of the .cue standard.

REM SESSION 01 and REM SESSION 02 are also wrong, these commands generate a multisessional disc TOC, while GDs aren't multisessional, those are 2 separate images written on the same media (or 3, if to count the security ring area).

I only suggested it because it's the only way to make IsoBuster detect the filesystem of Track03. But for emulators etc. we could stick to REM SINGLE-DENSITY AREA and REM HIGH-DENSITY AREA.

that's why I've offered to do separate cues, so you could load them independently, just like a real thing. You either load and work with the LD area with 2 tracks or with the HD area with the track 3 and beyond (if any), not both.

You still need the PREGAP line, even with separate cue's, because otherwise you would be pointing Track03 to start at sector 150 instead of 45.150.

So, I think this solution still stands?

Demolition Racer - No Exit (USA).cue wrote:

REM SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 09:42:68
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

Or tell us what the benefit would be of having 2 .cue's, like this?

Demolition Racer - No Exit (USA) (LD).cue wrote:

REM SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

Demolition Racer - No Exit (USA) (HD).cue wrote:

REM HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 10:02:00
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

The start address of the first Track03 sector is 10:02:00.

When we use a normal single cuesheet (with or without REM), the problem is that normal applications place the Track03 start time relative to the previous tracks.

So in order to get the correct sector addressing, a PREGAP will needs to be calculated based on the length of the previous 2 tracks.

Example: http://redump.org/disc/52815/

10:02:00 minus the combined length of the LD tracks (17:07) = 09:42:68

With this cuesheet, IsoBuster correctly loads the Track03 filesystem and other applications like CDmage have the correct sector addressing:

REM SESSION 01 ; SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM SESSION 02 ; HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 09:42:68
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

What do you guys think about this implementation?

It would require some extra coding, but it maintains the existing "standards" for .cue.

If you want to conform to the standards that are already set by IsoBuster with multisession discs, and have the best compatibility with other tools, the cuesheet should be like this:

REM SINGLE-DENSITY AREA
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

edit: Because the HD area apparently starts with Track03, we no longer need to think about Multi-Cue or other alternatives.

22

(1,693 replies, posted in General discussion)

Here's a type of SecuROM that seems to be different from all previous types:

http://redump.org/disc/45559/

http://redump.org/disc/58232/

The things that are unclear to me:

- For Diablo II: Lord of Destruction, SecuROM sector 157 was not included in the SubIntention. What was causing this?

- Could the write offset of +576 be wrong? it's -12 plus 588 samples (1 sector). I've never seen this offset before.

- Can you plz double check if the SecuROM data is correct and if there are really 99 "modified" sectors for this SecuROM version?

Here are the log files for Diablo, and also an unmodified CloneCD.sub from another drive:
https://www50.zippyshare.com/v/jUraqxWb/file.html
https://www50.zippyshare.com/v/dVsXalzo/file.html

Thx for your help smile

Hi, do you have the mastering SID code and the last digit/letter of the mould SID? And also the write offset. Otherwise there's no point in adding incomplete ringcodes.

Unless, there's a language selector or English voice option, it's probably best to only list the foreign language?

I think it would be better to skip dual cuesheets completely and stick to the single cue with the proposed improvements? It's just way more practical. Multi session discs should have a similar solution.