You are not logged in. Please login or register.
Redump Forum → Posts by Jackal
This is how we've been dealing with multisession discs so far:
http://redump.org/disc/39048/
http://redump.org/disc/10299/
http://redump.org/disc/48363/
So what's wrong with using the IsoBuster "standard"? it contains all the relevant information for a functional image? It seems overkill to define lead-out etc, when all other dumps have them excluded.
Did a first test on Kreon drive today with CloneCD. It would skip through the first couple error sectors, but would stop reading and start making noises as soon as it reached the first ring. So a different drive or custom tools would be needed to dump this data. Will try some other drives later with disc swap.
>Preservation enthusiasts will do the needed dumps sooner or later, but there should be a proper software for that.
Ha. HAHAHAHAHAHA!!
Not everyone wants to waste time and cash for pointless, unverifiable sectors.
There are yellow Xbox 360 dumps that nobody cares to fix, and many Xbox NTSC discs that nobody wants to buy - http://wiki.redump.org/index.php?title= … sing_Dumps (because the PAL discs are already dumped). So, don't expect anyone to to buy and redump 4.000 discs, even if it's confirmed that the missing data can be dumped/verified.
"the data is not useful" - agreed
"its not fully retrievable" - yes, if you're talking about the physical rings that are unreadable, but we don't know yet how many sectors can't be retrieved because of this.
"and the result will be no dumps verify" - tests need to be done in order to confirm this
F1ReB4LL started a discussion on discord about Xbox / Xbox 360 dumping.
Our current dumping method skips through the full range of every security sector range and fills this data with zeroes.
For Xbox1 discs, it's 16 x 4096 sectors and for Xbox 360 it's 2 x 4096? with each sector being 2048 bytes.
The argument is that this is not in line with the "redump dumping method" and that all data within the main reading area of the disc should be preserved.
Arguments against the current method:
- Fails to preserve all the (readable) data that is located in the security sector ranges.
Arguments in favor of the current method:
- It might be difficult or impossible to dump the missing data. Reading through the physical rings could take a lot of time, and different drives and/or discs could give different results (with some drives being able to read more sectors at the start and end of each ring than others), meaning it could be difficult to verify a dump that is done this way.
- The Xbox console itself blocks out access to the full range of every security sector. Dumping a game on an actual console (using dvd2xbox) results in the drive giving read errors in the the same sectors that are currently skipped on the PC dumping method.
- The data inside the security sector ranges seems to be random garbage that has no meaning or purpose.
I'm aiming to do some tests soon to see how long it would take to do a full dump using different drives and if the results are different between different drives. I only have 1 Xbox1 disc here ATM and it seems to have 5 physical rings, whereas the Xbox 360 discs that I have all seem to have 2 rings (one close to the center and one near the outer edge of the disc). It remains to be seen if all Xbox1 discs have 5 physical rings.
Hope sarami can have a look at this, but for the ring sections you'll need something other than a plextor / DIC.
The No-Intro rules aren't suited for Chinese releases.. games can have really weird box titles that are completely different from the (often English) ingame title.
A randomly generated password has been sent to your email, please change it upon login.
A randomly generated password has been sent to your email, please change it upon login.
A randomly generated password has been sent to your email, please change it upon login.
A randomly generated password has been sent to your email, please change it upon login.
A randomly generated password has been sent to your email, please change it upon login.
@iR0b0t, before you add any new moderators, maybe remove some?
Rocknroms - hasn't been around since 2011, why is he still a moderator?
gorelord4e - last post 2015.. he's still around, but clearly not moderating
LedZeppelin68 - perhaps a nostalgia thing, but he's also not a moderator
And whoever wants to be a moderator has to realize that it's a long term commitment. Some of the recently appointed moderators were very active in the beginning but then started getting busy IRL.
Then there's also some moderators (including myself as of lately) who are mainly adding their own dumps and not bothering at all with forum submissions due to late of time. The WIP discs are also packed full. I guess tenyuhuang should be nominated as moderator also for adding all the Chinese stuff.
There seem to be no errors, it just forgets to dump layer2.
There's a problem where DIC is only dumping the first layer for double layer games.
Previously, this game was affected: http://redump.org/disc/46022/
And now another disc from Kludge. Attached some logs.
I really hope there aren't any other bad dumps in the db because of this bug 
@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.
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.
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
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)
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 
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)?
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
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.
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?
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?
Redump Forum → Posts by Jackal
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.