Search options (Page 1 of 4)

Good luck and all the best!

Yes, this again fixes some bad CDi masterings because they actually store data sectors without sync headers.

The only thing I know of that comes from the CD specification is that if there is sync header and track is data, it needs descramble. Most of these test cases came from bad mastering cases such as early masterings and Philips CDi.

Same is about mode0 sectors. Specs say that those should be empty, but in reality I see discs where

Each filename has a number suffix that indicates the expected LBA. When redumper descrambles, it knows the position of of the sector and if it matches, it's the strong check for the successful descramble.
So .42 means that expected LBA of the sector contents is 42, on the other hand .null means that there is no positional information.
For the details see https://github.com/superg/redumper/blob … ts.cc#L187

The bottom line is, DIC never followed CD specs in the first place (always descramble if there is sync header and it's data track). Long time ago I've been checking your descramble code and you have a lot of logic that checks if padding is empty, if mode is correct and some other things. So the current status quo is to have clean dumps without garbage and redumper is doing exactly that. The test cases were created solely to make sure that any subsequent redumper code change is not affecting whole redump.org database.

That disc is shifted 2 seconds into the lead-out, that's 150 sectors.
PLEXTOR can read only 100 lead-out sectors. ASUS with patched Rib's firmware can read unlimited lead-out sectors.
You have to either use audio trap disc with PLEXTOR to trick the drive into reading more or ASUS with patched Rib's firmware and redumper option `--overread-leadout`

Ok, couple more findings:
Indeed, Gekido has a backup libcrypt key in audio subchannel, http://redump.org/disc/833/ updated.
Net Yaroze disc doesn't have mirror or backup keys, just 6 bits in 6 first libcrypt sectors, http://redump.org/disc/45854/ updated, .SBI or .LSD can be downloaded from there.

I've also updated my redumper libcrypt detection code so it should be a little bit better although theoretically there might be false positives. nocash - thanks for all the hints!

Lastly I have yet to find my PAL PSX to check if the disc boots, chances are low but I'll try to finalize it this week.

PM with link sent, sorry I didn't notice you asked to filter out good sectors, if that's show stopper let me know.

Hmm, I'm not familiar with .LSD, probably not from redump. I can easily generate anything from redumper output, .SBI is lame, but that's the only way we can have it right now. Without going too much into the details, we currently have no way of improving the website because the communication with our keyholder is literally non-existent for years.

I could do something like this easily on my romset, this is a good idea just to identify potential missing candidates.

I am well aware of that, all my Medievil EU retail copies have only one encoding scheme, that is hardcoded based on the only discs I have here. I'm very open for a better detection method, please suggest.

As of newer libcrypt protections, as you've already figured out, I have a list of all possible sector numbers (64 different sectors, 32 at minute 3 and backup 32 at minute 9) which might potentially be used by libcrypt and a very strong check that two invalid Q frames 5 sectors apart (anti scratch). The only thing I could potentially change is to account that minute 9 backup might be truncated but I remember I was checking Track 1 sizes for the whole library and I haven't found any candidate for that.

Also, subcode sucks. For minty PS1 discs, I get hundreds of Q crc errors and this is really the best situation because people dump all kind of discs in different conditions. That said, in Net Yaroze case I cannot really rely on 6 other Q sectors to be intact. Let me think on this a bit.

By the way, this is the list of all known libcrypt protected discs: http://redump.org/discs/libcrypt/2

P.S. Let me know if you want/need RAW or processed subchannel for the Net Yaroze disc, I can share.

Thanks for the technical info nocash, very interesting!
From redump perspective I would like to detect this scheme when dumping and preserve subchannel of the altered sectors so we could potentially detect it on the other discs (if any).
I have that disc here.

I will check that later.

The padding you refer to is 150 sectors at the start of Track 2.
At redump when we perform the track split (not only Dreamcast but all systems) we preserve gaps (index 0 entries) for each track. There are multiple reasons for that:
1. sometimes gaps aren't empty and have meaningful data (audio cd for example)
2. this allows for an easy merge of all tracks into one if needed (CloneCD .img) without losing any data.

In general, redump.org strives to be the most precise 1:1 optical media preservation and I don't see why would we favor lossy formats.

http://forum.redump.org/topic/45004/audio-offset/

Some general things first. I think we should totally separate TOC and subchannel things. Some data tracks are marked audio in TOC and data in subchannel in Photo CD. Some CD-I have hidden track in subchannel that is not listed in TOC. Jaguar often has different track flags in TOC vs subchannel.
As we have two concepts here, primary TOC based split and secondary subchannel based split (Subs Indices).
For TOC based split we should use only data/flags from TOC, for subchannel based split we should use only data/flags from subchannel. The only data we want to use from subchannel for a TOC based split is when we're finding track split points as this data is not present in TOC.

(1),(2) - strongly agree

(3) - no sync, I'd say it's audio. But I'd add one exception to that rule. There are some CD-I discs where whole sync is zeroed but data is scrambled, it's more than one disc, so ideally:
if(standard_sync || zeroed_sync && expected_scrambled_msf) it's data. In general I find MSF is a very handy and strong check for scrambled.

(6) - definitely audio

(4),(5),(7),(8) - this is a source of discrepancies because of TOC subchannel properties mix.