Wrong gaps?

[Vigi]

First of all, hi..

I've been following the progress of your project for a long time and I think it's a great effort..

edit: crap removed

I'm a dumper for the Redump.org project. We also added a Dreamcast section to our site. This section was added a long time ago and is so far only used by 2 dumpers (pnkiller78 and me).. our intention was not to replicate what TOSEC and you are doing (this will propably never happen unless some maniac with hundreds of discs joins us and starts dumping like a madman), but it was merely an experiment for us, because our dumps were done using an ordinary dvd-rom drive instead of a BBA.

Some time ago I managed to get my plextor drive working with gd-roms (before that I only got it working on a lite-on drive). I also wrote a small guide on how to dump gd-roms using a dvd drive: http://forum.redump.org/viewtopic.php?id=2620 (you might find it useful, but it will only work on recent non-rebadged plextor models)

Even though it's not as easy as using a BBA, the extraction is faster and the dumping is more flexible. If you use a tool like cdreader (http://www.cdtool.pwp.blueyonder.co.uk/ ... 1_2b20.zip) it's also possible to extract the subchannels and C2 data for real error detection, so you won't have to dump it twice to know if there are any errors.

Last but not least, I also feel it's my duty to tell you that your dumps don't have any audio offset correction applied. By correcting both the read and the write offset of the disc and the drive (this can be done easily using a hex editor), all audio tracks of the same size will also have the same checksum and the audio data will no longer be shifted. Instead, the audio data will be restored to the position it was in before any mastering (even though the read offset appears to be the same for each dreamcast drive, there are various write offsets)..

I won't go in depth about it, because you're propably not as maniatic about having a 1:1 bit-perfect offset corrected dump (at least TOSEC isn't) and your dreamcast dumps don't have any missing data (TOSEC's CD dumps do sometimes) so it's really just a matter about how much you care about having 100% correct dumps. With all the dumps being spread through torrents already I can imagine my post is too late to make any difference (at least I'm glad you switched to RAW dumping before it was too late ).

[Maddog]

Well, hi...

You are conveniently forgetting all our lengthy discussions on IRC. Or to put it better, forgetting the parts that should be ignored to make your project seem "better".
Let me repeat some things then...

When we set out to make GDI dumps, the primary goal was to dump as close to what a real Dreamcast would read as possible. This makes sense as the images can only be run on a Dreamcast emulator, using a custom format (GDI) created specifically for use with said emulator and there's ABSOLUTELY NO WAY to put them back to disc. Why then would anyone want to "feed" to the emulator data that the real hardware wouldn't "see" at all (ie data pregaps) or change the position at which the real hardware would "see" them (ie change audio offset)?
This means that as soon as we proved that all Dreamcast drives have the same offset (or at least all drives we know of atm and we have a very good variety of consoles tested) , correcting the audio offset to something the real Dreamcast doesn't have is pointless. The offset issue might be important when dumping on a PC, since every drive under the sun has a different one. But when the dumps are done on a specific drive with a standard offset (=the Dreamcast drive) why would anyone want to hack the data to a place different than what the DC drive uses? If you ask your Dreamcast to read audio track X, it would start reading exactly where our dumps are starting. Why make the dump different or the emu read something else?

As for this line, it is completely absurd:

What it comes down to is that the last data track has 2 seconds of audio data appended to the beginning of the track. This data however belongs at the end of the last audio track.

Here's an ASCII translation for the first few bytes of our dump of track 5 for Star Wars - Episode I - Racer US. You pointed that one out as faulty:

Code: Select all

  y"U	 	 	 	 	 	 Πa)!’+! Π+@	      ―‰   ΞŒLib Handle Start                
~Ί©½ΡŠλ `•b_                Lib Handle End  6ΤAdMdD‹ DGdDGd C`ζ/Φ/Ζ/¶/"Oό U“Cn	@	@Ι 9 πΛ@)Σ2bB

[darcagn]

To me, there's really three ways to go about setting a standard for a dumping project: what was intended to be mastered to disc, what actually was mastered to disc, and what is actually read from the disc by the intended target machine.

What we're doing represents how the disc is actually read by the intended target machine. We're lucky that every Dreamcast has the same read offset, because it means that we will all be consistent in our dumping methods and in our standard.

TOSEC usually takes a hybrid path of "what was intended to be mastered to disc" and "what was actually mastered to disc." This means that barring any funny business related to copy protection, the ISO and WAV files represent roughly what the developer intended to be mastered to disc. It doesn't really make sense to distribute in BIN/RAW because that doesn't concern the developers one bit, and all of that data can be extrapolated from what you're given with ISO/WAV anyway. The one deviation that TOSEC takes from "what was intended to be mastered to disc" is that TOSEC does not edit to compensate for write offset in audio tracks. This gives the advantage that you are getting what the developer intended to master, but at the same time you also get to see different disc manufacturing runs and reissues and so forth.

From what I can gather, Redump also takes a hybrid "what was intended to be mastered to disc" and "what was actually mastered to disc" approach as well, but in the opposite manner. From a "what was intended to be mastered to disc" approach, you fix the manufacturer's write offset, which is good because it creates consistency among all issues of the disc with the same intended data, regardless of manufacturing differences. However, for a project that claims to be a "disc preservation" project, it doesn't make sense to me, because it isn't preserving what's on the disc, but rather what was intended to be put to disc. And from the "what was actually mastered to disc" side, Redump includes the ECC, which is useful in the dumping process, but is not really necessary for the end user, but does fit in with the "disc preservation" goal.

Now, for the Dreamcast, TOSEC takes a different approach than usual, and that is to replicate exactly what the Dreamcast reads. Given that every system reads the same way, it makes sense to leave the audio data alone and not mess with it. For other systems, this is not the case, as every drive reads differently, and the best place for everyone to compromise and set their dumps to is a 0 offset. So TOSEC takes a "what is actually read by the intended target machine" approach. I have seen no reason to arbitrarily "fix" the audio read and write offsets. And I think what we do is an excellent job at providing dumps with the most logical dumping philosophy.

With regards to your suggestion that we append 2 seconds of audio data to each data track that follows, I think Maddog addressed that already.

[Vigi]

Thanks for adding constructive information to what started out as a useless thread..

@Maddog, you're right, I was already aware of your goal and I already thought it made sense. I wasn't sure about Dumpcast's vision concerning offset correction but apparently it's the same as yours.

About the gaps issue: I was wrong here too.. I came to this conclusion after simply comparing the filesizes. I wasn't sure though (that's why I left a question mark in the topic title )

I guess the differences between the filesizes of Redump vs TOSEC can be explained as follows (plz correct me if I'm wrong again):

My dump has the (first?) audio pregap of 352800 bytes included, so the audio tracks are 352800 bytes total larger.

Your last data track doesn't have the data pregap included. My dumps does: (00FFFFFFFFFFFFFFFFFFFF0080554701000000000000000000000000000000000000000000000000)

Either dumps should work fine in emu's as long as the proper cuesheet is included, though I still prefer to have the 705600 bytes of useless dummy sectors included, simply because the gdrom has them

Thanks for the information and sorry for the mess I didn't mean to prove myself, I only thought I spotted an issue (I was wrong).

[Maddog]

I am wondering if I understand you correctly.
The way I understand it, you are including the data pregap before the actual data of the track for track 05.

Don't know if by doing it this way you might be breaking compatibility with the emulator. The emulator (maybe...) expects to find actual game data at the point you are defining in the GDI as start LBA of the track. Not sure how GD-ROM emulation is programmed at all. Bear in mind here that track 05 data is cross-linked from track 03. I mean, the ISO filesystem resides in track 03 while the actual data are in track 05 which has no filesystem present.
Which brings me to the question: Have you tested your Star Wars dump in NullDC? If it works, all fine and dandy. But if it doesn't, you can blame the pregap data.

Regarding TOSEC/Dumpcast, we have made a conscious decision (after quite some discussion and getting opinions from a few people with specific knowledge of the DC hardware) not to include any pregap data in our dumps, as the real Dreamcast will never access those (in fact it will return a read error if you attempt to force it to). I think you are right about the audio size difference being due to that.
In any case, support is included in httpd-ack to play around with the settings. By changing the "gap" parameter or defining "section" and "track" values >100 you can access any area of the GD-ROM you like. All these are described in the readme of the program. Ack just made the default settings as close to what a real DC would be reading as we could. This was due to the specified targets of the project. But we still catered for anyone wishing to try other things.

I think darcagn put it quite well. Having different targets doesn't make any project better or worse. Refrain from posting negative comments about TOSEC methods left and right (Dremora clearly said dumping with httpd-ack is "bad"), since we never did the same for your project (in fact I've constantly pointed anyone asking about PSX dumping to your site).
Specifically regarding Dreamcast, we have experimented and given quite some thought to the matter before starting out. In all honesty, our DC dumps are excellent quality and well within the specified target of the project.