Search options (Page 50 of 66)

Well, I believe jap PS1 titles should be hyphenless in general, PAL and NTSC ones seem to be with hyphens. Dunno about other systems (except PCE, where there's no logic for hyphens and spaces at all). Maybe would be a good idea to ask ir0b0t to remove all the hyphens for ps1 jap and to manually fix all the exclusions, if any.

There is, someone was even trying to explain me all those spaces, Ts and >s belong to the certain standard, different types of barcodes fall into different standards (something like different ringcode types help to identify different mastering companies). Anyway, better to keep them as is, since it's way easier to retype these properly, compared to the rings.

Well, it's ok if you change those radiobuttons to checkboxes, so each release could be checked for the db. But it's pointless to list all the countries in the filename (which is limited to 255 symbols, including the path), otherwise, it would be a mess in the PC section, where 1 game can be released in dozens of countries. Generally, Asia = Japan, even if the same disc was released with different serials and barcodes for different Asian countries - the internal serial is still Japanese. If the discs themselves were different - of course, these would be (Japan) for one and (Asia) for another.

I don't think we accept "remove the entry" requests, especially, if the dump itself is correct, just hoarded.

Adding a non-existant hyphen is "accurate" for you? And you were so disappointed in removing the hyphens you've decided to leave? Sounds funny

"Asia" is for Hong-Kong, etc. releases, remember those PAL-60 Sega MD consoles for Asian non-Japanese market? These are "Asia". As for the games, you should probably check the barcode, not the serial (and who said ULJM means Asia? UCAS is for Asia, iirc).

Let that "somebody" use your special keys/parameters and make the default search like it was a month ago. Default search should be as complete as possible and if someone doesn't like to see certain results there - make a personal workaround for him.

"I have limited the default quicksearch engine to look for: title + foreign title + serial" -- make a "/tfs/" parameter for him, in addition to those "/only/" ones.

Theoretically, there should be some kind of "advanced search" page with lots of checkboxes, so you could choose, where to search and where not to search.

A little offtopic, but Jackal recently had problems with a disc with twin-sectors protection and DIC, it wasn't able to read them (twin-sectors) properly.

Always about gaps, since the drives without that capability can't read anything before sector 0.

There are 2 limitations: audio cds are capped at -75, data cds at around -142...-143. When you use 0xd8, audio cd limitations are used.

For Plextors (PX-708 to PX-760, at least) there is a possibility to read the whole TOC and full first pregap area: you should open cdtool, disable c2 errors reporting and dump either -5000 to 0 range or $FF000000 to 0 range. You should get the TOC dumped multiple times and the first pregap somewhere inside the dump, sometimes there are even data sectors from 0+ range (yes, somewhat random, but you should be able to find all the needed TOC and pregap sectors there).

Well, there was a standalone branch of Redump.org called "Rawdump.net", which tried to include first pregaps and TOC dumps, but it's dead now. The only real advantage is that the dump is more "complete", if TOC area is there and, theoretically, you can use a 2448/sector data+sub dump with TOC area as a single rom file, with no cue or metadata needed.

I'd say that it's way more problematic to dump the lead-out area, since different drives stop dumping at different addresses and it's hard to determine the very last lead-out sector for the dump. Saturn and Dreamcast are even more problematic due to those rings, which are also dumpable, but different drives are able to dump different amount of sectors.

http://redump.org/disc/33940/ -- http://www.mediafire.com/download/q943c … C_logs.rar
Errorlog says everything is fixed? Or do I misunderstand something?

Professor Oak says: "There's a time and place for everything! But not now."

Yeah, 02:01 confirmed. My disc is a bit scratched - https://www.sendspace.com/file/1nfovg - either the gap misdetected due to that or simply overlooked something. Cue was locked on Jan 09 2012, 02:19, that's before the DIC and only a few weeks after the trurip's leak, most likely used PerfectRip or manual splitting&descrambling.

TOSEC/TruRip guys dumped most of these, single-track titles & no protection, AFAIK.

Well, it was just an example of the possibility. Haven't seen anything except R-W padded with 0xFF and T padded with 0xFF.