951 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

Pregap/Lead-In sectors are read randomly, you can read the -5000...-1100 area a couple of times and get different sectors each time. I think, DIC needs a special mode to read that area a couple of times and reconstruct the whole lead-in sector-by-sector.

READ_TOC(0x43) doesn't output the data area, though, only subs sad

Dumping lead-out is interesting. Why "6750 sectors"? Lead-out sectors go upto the very end of the disc. If the main data area is small (a few megabytes), the lead-out would be 300 000+ sectors.

Go to forum: General discussion

952 Reply by F1ReB4LL

(26 replies, posted in General discussion)

"Tales of Destiny 2 (Japan) (4, 5)" for http://redump.org/disc/15921/ would look weird, IMO. On the other hand, I can't completely agree with the versions in filenames in such cases: http://redump.org/disc/31934/ http://redump.org/disc/25815/ - v1.20 and v2.00 mean absolutely nothing. These should be either "7 (Seven) - Molmorth no Kiheitai (Japan) (v1.0)"/"7 (Seven) - Molmorth no Kiheitai (Japan) (v1.1)" or "7 (Seven) - Molmorth no Kiheitai (Japan) (1)"/"7 (Seven) - Molmorth no Kiheitai (Japan) (3)". Dunno. Maybe worth to use the Saturn/DC naming here and call these "7 (Seven) - Molmorth no Kiheitai (Japan) (1M)"/"7 (Seven) - Molmorth no Kiheitai (Japan) (3M)" where M means Matrix, though, Saturn and DC have these Ms on their rings. Maybe something like "7 (Seven) - Molmorth no Kiheitai (Japan) (Matrix 1)"/"7 (Seven) - Molmorth no Kiheitai (Japan) (Matrix 3)". We need to show the undumped ringcodes, not some useless internal versions. Same for PS1, Neo-Geo CD and other similar cases.

Go to forum: General discussion

953 Reply by F1ReB4LL

(26 replies, posted in General discussion)

https://github.com/libretro/libretro-da … Saturn.dat -- versions look useless and distracting here. As well as publishers.

Go to forum: General discussion

954 Reply by F1ReB4LL

(26 replies, posted in General discussion)

And what I'm trying to say is that the version should be visible if it clearly states the revision, like in the Nintendo's case. Check the old TOSECISO names for Saturn, for example. They are terrible.

Go to forum: General discussion

955 Reply by F1ReB4LL

(26 replies, posted in General discussion)

PS2 (as well as Sega systems) versions aren't tied to revisions, so you can't easily predict the missing ones. Like, http://redump.org/disc/39485/ is v1.04, but if to name it according to the version/revision, it should be v1.0/Rev 0 due to its ringcode that ends with "1". http://redump.org/disc/22458/ -- v2.01, ends with "1", so the earlier ones, like v2.00, don't exist _for this serial_ (which differs from the original release, which is http://redump.org/disc/15921/ which is v1.01, ringcodes end with 4 and 5, so it's worth to look for 1 or 2 with the possible v1.00 inside). TimeSplitters v2.00's ringcode ends with "4" and you can't say for sure, whether "1", "2" and "3" would differ or not until you find and dump all the missing rings.

Go to forum: General discussion

956 Reply by F1ReB4LL

(26 replies, posted in General discussion)

Jackal wrote:

Didnt read all the posts, but when there's multiple versions released of a game, and one of them is undumped, the version can be added to the filename for the one that is dumped. Is that what you mean with New Super Mario Bros. Wii?

When the only currently known release is internally marked as a revised version (so, an earlier one is highly likely to exist, just hasn't been found yet).

Go to forum: General discussion

957 Reply by F1ReB4LL

(26 replies, posted in General discussion)

johnsanc wrote:

However, even that has caveats. For example there may be 1.01 without a 1.00 ever existing.

Still, nothing bad in calling it (v1.01) to motivate people to look/check for (v1.00). Again, as far as I understand, No-Intro names their roms according to the version/revision, if known, even if the existence of the earlier ones is only suggested, not proven.

Go to forum: General discussion

958 Reply by F1ReB4LL

(26 replies, posted in General discussion)

Yes, I see the logic now. Most of the releases are v1.00 with the ringcodes end with "-0", some have the updated ones, like v1.01 with the ringcodes end with "-1", etc., so, when you see a standalone v1.01/"-1" or v1.02/"-2", you can assume the earlier versions should exist.

So, the suggestion should be not to "state the version in the dat name even if there is only one version", but to "state the version in the dat if the earlier version/revision is likely to exist". Sounds reasonable, I'm OK with that, but I'm not the GC/Wii/WiiU sections maintainer, so I'd like to hear their dumpers'/mods' opinions as well.

Go to forum: General discussion

959 Reply by F1ReB4LL

(26 replies, posted in General discussion)

Why do you need to know the version? What does it tell you?

Go to forum: General discussion

960 Reply by F1ReB4LL

(26 replies, posted in General discussion)

RetroGamer wrote:

Fireball, why this disc http://redump.org/disc/8169 is marked as Rev A? The ringcode says that it's a Rev A but i dumped a lot of discs from different sources, original box and plastic box and i never found the older revision, so it probably doesn't exist... and i never heard of annyone finding it neither...

Because, judging by other discs, the Rev 0 should exist as well. No-Intro also adds the revision, when it's known and when other ones are likely to exist.

https://www.satakore.com/sega-saturn-ga … n-EUR.html -- also lists the Rev 0 as unconfirmed, but possible to exist.

Hiccup wrote:

Currently it is quite confusing. I can't actually tell that it is v1.1 without opening the ISO (e.g. in Dolphin) to check.

And why do you need to tell that?

Go to forum: General discussion

961 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

Dark Frost wrote:

How Can I Copy This My Cd

You either need to buy a specific drive that supports 0xD8 reading command or you can try to use the swapping - http://forum.redump.org/post/60603/#p60603

Go to forum: General discussion

962 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

rosewood wrote:

Sample 2:
[CDI] Philips CD-i/Video CD Titel-Neuheiten I/95 (818 0058)
2a. Good dump with 20171010
2b. No dump possible with 20171210

Sample 3 (impossible to dump with either version):
[CDI] Philips CD-i/Video CD Titel-Neuheiten II/95 (818 0089)
3a. No dump possible with 20171010

Are you still here? Any chance for TOC & 1st track pregap dumps?

Go to forum: General discussion

963 Reply by F1ReB4LL

(5 replies, posted in General discussion)

diego-rbb-93 wrote:

As ive been talking recently with JHMiller, our DC dumps made by Redump method are totally functional over Inolen's Redream emulator.

I've just checked its Windows build and I couldn't get any CDDA sound of it, so I'm not sure if it's truly supports Redump-style gdis. Also it crashes every time you try to close it and doesn't seem to support the controllers. Maybe the Android build is better, but clearly not the Windows one.

diego-rbb-93 wrote:
F1ReB4LL wrote:

I still insist on switching to 2xcues+bins smile

Thats a question that the DC dumpers and the rest of the gang with enough technical skills to understand the process should talk on your side. xD

The process and tracks will be the same, just the db should generate cues instead of broken gdis.

Go to forum: General discussion

964 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

Well, c2 errors are reported by the drive, not by the tool. According to the log, a couple of errors were fixed, but the process was stopped by the user. I'd recommend to wait for the process to finish normally.

Go to forum: General discussion

965 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

I don't think everything will need to be redumped, non-zero data doesn't go upto the very end of the last track, so the offset can be fixed quite safely, we just need to define some standard.

Go to forum: General discussion

966 Reply by F1ReB4LL

(15 replies, posted in General discussion)

В личку отпиши как надумаешь новые дампить или если вдруг появится желание перепроверить некоторые сдампленные перед продажей.

Go to forum: General discussion

967 Reply by F1ReB4LL

(5 replies, posted in General discussion)

I still insist on switching to 2xcues+bins smile

Go to forum: General discussion

968 Reply by F1ReB4LL

(11 replies, posted in General discussion)

The Japanese rerelease is dumped and its internal serial and ringcode are from the Asian release, so, 99.9% yes (0.1% for some version difference, but that's unlikely).

Go to forum: General discussion

969 Reply by F1ReB4LL

(15 replies, posted in General discussion)

Нет, я про более ранние косяки с аудиотреками и их прегапами из-за которых по всем последующим дампам возникали вопросы. По точности верификейшнов в том числе. Вопросов не будет в случае дампов с плекстора, но условно удовлетворительные результаты можно попробовать получить и на обычном приводе (речь, ессно, про диски с аудиотреками). В идеале хотелось бы и передампы тех, что уже в базе.

Go to forum: General discussion

970 Reply by F1ReB4LL

(15 replies, posted in General discussion)

Потому что часто попадались косячные. Надумаешь опять дампить - можно попробовать другими программками, которые косяки и вопросы сведут к минимуму.

Go to forum: General discussion

971 Reply by F1ReB4LL

(11 replies, posted in General discussion)

http://redump.org/disc/8335/ -- this one was released in Asia and then rereleased in Japan, What do you think, shoudn't it be (Asia, Japan)? smile
I don't think No-Intro ever faced such issues, so it's pointless to look for examples in their dats.

Go to forum: General discussion

972 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

We need to decide, how to detect the offset on them. But the 'magic' bytes in the first track should be located at the same address for all the dumps.

Go to forum: General discussion

973 Reply by F1ReB4LL

(8 replies, posted in General discussion)

benclaff wrote:

I attached anyway the DIC logs in the post if something had to be checked later.

The logs in the first post are from the March DIC version, which isn't the most recent one (there were CD-i Ready-related fixes a week ago, you should get a different track 1 checksum with the May version).

Go to forum: General discussion

974 Reply by F1ReB4LL

(8 replies, posted in General discussion)

You need to d/l the most recent version of DIC for the proper dump.

Go to forum: General discussion

975 Reply by F1ReB4LL

(3,488 replies, posted in General discussion)

sarami wrote:

Added this, but still buggy, I think.

Works almost fine for me. The dump is correct, but the cue is missing the CATALOG entry (the drive itself reads the subchannels correctly).

Also, the image sizes (and the checksums) of the .scm and .img files are incorrect (too small). Split tracks are correct.

And why doesn't it show any progress (which sector is being read) during the dumping process?

http://redump.org/disc/32569/ -- this disc was used.

Go to forum: General discussion