You are not logged in. Please login or register.
Active topics Unanswered topics
Post new reply
Post new reply
Compose and post your new reply
You may use: BBCode Images Smilies
All fields with bold label must be completed before the form is submitted.
Topic review (newest first)
So this is a little bit more complicated for Dreamcast because of SD/HD area. Gluing SD and HD area makes a little sense for Dream but we follow the same rules as we set for other systems. Ideally we would want to preserve everything that comes between SD/HD area but there is a current technical limitation in doing that. For instance, SD area leadout contains unscrambled logo data (Sega CD art you can see on data side), I would even want to preserve it as well. We slowly evolve our methods but everything takes time.
Thanks for the explanation, it wasn't clear where the gap came from and why TOSEC wouldn't have it. CHD is supposed to be lossless, so it was surprising to me that they would remove data (not to mention Dreamcast is the only system to have the issue). I didn't say they're right, I know Redump tries to be accurate and I'm all for it. I'll see if that gap trim can be dropped on the chdman side.
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.
Hi all, I'm the author of oxyromon, yet another rom manager. We are running into an issue where some Dreamcast dumps don't match the database anymore after being converted back and forth to CHD. This is apparently intended because chdman uses the TOSEC layout, which is different from yours, so they strip some padding.
Relevant GitHub issue: https://github.com/mamedev/mame/issues/11903
I'm not sure what the best course of action, was it a conscious decision to use a layout that differs from TOSEC? Seems like the additional data in the Redump dumps is just a blank gap. Is the TOSEC layout something that could be considered for Redump dumps, or do I have no choice but to "repair" the reverted BINs?