V-Rally 2 - Expert Edition v0.002 (PAL) CDDA Problems
Moderator: Moderators
V-Rally 2 - Expert Edition v0.002 (PAL) CDDA Problems
I just tried the gdi of V-Rally 2 - Expert Edition v0.002 (2000)(Infogrames)(PAL)(M3)[!] in nullDC and the CDDA code seems to be messed up. In the audio settings screen where you can change the audio tracks, no CDDA is being played and nullDC's status window shows that the game accesses LBA 0 and doesn't play anything. When you start a level you get no CDDA-BGM unless you press Start and go to the sound options. This seems to trigger the CDDA-code and nullDC starts playing the CDDA-tracks. But it still starts at the wrong location (LBA 0), so the first thing you hear is the official warning that this is not an audio cd, followed by silence...
Is this an issue with nullDC? I never had any problems running CDDA-games with it. But since the dump is verified the game data should be ok. How does the original game behave in a Dreamcast? May be the person who dumped that game can clarify this.
Is this an issue with nullDC? I never had any problems running CDDA-games with it. But since the dump is verified the game data should be ok. How does the original game behave in a Dreamcast? May be the person who dumped that game can clarify this.
Well, I ripped Vanishing Point and it played all CDDA-tracks correctly, just like on the real Dreamcast, but I needed to tweak the CDDA-code a little bit to get it to work. Also other CDDA games worked just fine with it.
I converted the gdi to a valid CDI and it behaved the same way not using the correct LBAs for the tracks. Furthermore, it didn't start CDDA when it should and if it did it still used the wrong LBA (0). I tried the Echelon release which also features CDDA and that worked. That leads me to the conclusion that either the CDDA code of the original game is flawed in some kinda way, or that the dump is damaged. May be the code needs to be altered to make it work with fully featured rips, but then at least the original gdi should access the audio tracks LBA's correctly.
I converted the gdi to a valid CDI and it behaved the same way not using the correct LBAs for the tracks. Furthermore, it didn't start CDDA when it should and if it did it still used the wrong LBA (0). I tried the Echelon release which also features CDDA and that worked. That leads me to the conclusion that either the CDDA code of the original game is flawed in some kinda way, or that the dump is damaged. May be the code needs to be altered to make it work with fully featured rips, but then at least the original gdi should access the audio tracks LBA's correctly.
nullDC is bugged where it assumes that every disc it is given behaves like a cracked backup disc.Xiaopang wrote:Well, I ripped Vanishing Point and it played all CDDA-tracks correctly, just like on the real Dreamcast, but I needed to tweak the CDDA-code a little bit to get it to work. Also other CDDA games worked just fine with it.
I converted the gdi to a valid CDI and it behaved the same way not using the correct LBAs for the tracks. Furthermore, it didn't start CDDA when it should and if it did it still used the wrong LBA (0). I tried the Echelon release which also features CDDA and that worked. That leads me to the conclusion that either the CDDA code of the original game is flawed in some kinda way, or that the dump is damaged. May be the code needs to be altered to make it work with fully featured rips, but then at least the original gdi should access the audio tracks LBA's correctly.
I can assure you because of our double-dumping policy (2 discs dumped by 2 different people using 2 different Dreamcasts, and comparing the dump checksums) that the dump is not damaged.nullDC forum wrote:Problems Remaining:
There are audio related problems on some games that make use of CDDA tracks.
nulldc is bugged, indeed, but saying that nulldc expects everything it gets fed is hacked is just plain wrong. In fact, nulldc is highly incompatible with hacked content as you can see when you try running games with the echelon intro. Also, since you apparently worked together with the nulldc coders when designing the gdi layout, I guess they pretty much knew that gdis are exact copies of the game without any hacks.
But still, this statement is not just wrong, but totally unlogical. Hacked code is not identifiable by the program which runs it. If that was the case, then hacks wouldn't wouldn't work. Hacking means either bypassing code and jumping directly to other code, or altering it. Either way, if you screw up the code then nothing will work. If you do it right, then your code will be executed like the rest of the program. No way nulldc could determine which part was altered and which not, because the whole program behaves like it was programmed that way...
Anyway, even if your conclusion was right, then why doesn't my hacked version work? And also, seeing that my rip behaves the exact same way like the gdi, where the game expects a totally disk different layout, shows me that the CDDA code in my rip doesn't work correctly...whether its hacked or not. It has to be altered significantly. Echelon was capable of that, but noone else seems to be able to do that nowadays.
But still, this statement is not just wrong, but totally unlogical. Hacked code is not identifiable by the program which runs it. If that was the case, then hacks wouldn't wouldn't work. Hacking means either bypassing code and jumping directly to other code, or altering it. Either way, if you screw up the code then nothing will work. If you do it right, then your code will be executed like the rest of the program. No way nulldc could determine which part was altered and which not, because the whole program behaves like it was programmed that way...
Anyway, even if your conclusion was right, then why doesn't my hacked version work? And also, seeing that my rip behaves the exact same way like the gdi, where the game expects a totally disk different layout, shows me that the CDDA code in my rip doesn't work correctly...whether its hacked or not. It has to be altered significantly. Echelon was capable of that, but noone else seems to be able to do that nowadays.
I never said nullDC expects that everything is hacked. Perhaps I was misleading in my previous post. nullDC's CDDA implmentation is bugged where it assumes that every disc it is given behaves like a cracked backup disc.Xiaopang wrote:nulldc is bugged, indeed, but saying that nulldc expects everything it gets fed is hacked is just plain wrong. In fact, nulldc is highly incompatible with hacked content as you can see when you try running games with the echelon intro.
The Echelon intros are not hacks, they are newly-written programs.
I never worked with the nullDC guys to design the GDI layout. The Dumpcast founders and I had theorized about an XMLish cuesheet format to work for GD-ROM dumps, but we abandoned the idea, not knowing of nullDC's existence at the time nor knowing its authors.Xiaopang wrote:Also, since you apparently worked together with the nulldc coders when designing the gdi layout, I guess they pretty much knew that gdis are exact copies of the game without any hacks.
But yes, they are quite aware of what their own format is. That still doesn't change the fact that their CDDA code is bugged.
My suggestion is completely logical. If someone (warez groups) consistently uses a hack to achieve a certain effect, and an emulator assumes that hack will always be there and so will the effect, when it is presented with data that doesn't use this hack but it assumes it should, it will not properly work because it assumes the effect should be in place. We see this sort of thing every day on the web--there are HTML standards, but Microsoft violates them with Internet Explorer. Since IE has majority market share, web sites mostly support it and code for it, and other browser coders scramble to emulate IE bugs to ensure webpage compatibility for pages that rely on IE bugs existing to render properly, this behavior sometimes leads to proper markup being rendered improperly. This is how de facto standards start.Xiaopang wrote:But still, this statement is not just wrong, but totally unlogical. Hacked code is not identifiable by the program which runs it. If that was the case, then hacks wouldn't wouldn't work. Hacking means either bypassing code and jumping directly to other code, or altering it. Either way, if you screw up the code then nothing will work. If you do it right, then your code will be executed like the rest of the program. No way nulldc could determine which part was altered and which not, because the whole program behaves like it was programmed that way...
Anyway, even if your conclusion was right, then why doesn't my hacked version work? And also, seeing that my rip behaves the exact same way like the gdi, where the game expects a totally disk different layout, shows me that the CDDA code in my rip doesn't work correctly...whether its hacked or not. It has to be altered significantly. Echelon was capable of that, but noone else seems to be able to do that nowadays.
GD-ROM discs have two additional tracks in a low density session. These tracks are unimportant and contain data accessible from any CD-ROM drive (like wallpapers and stuff). This low density track takes up 10 minutes on a disc, so obviously warez groups throw it out. The high density session on GDDA games contains audio tracks flanked by data tracks--on the earlier side by a bootsector, ISO header, and dummy padding data, on the later side by the actual game's data. Because this track layout is difficult to replicate with standard CD-ROM mastering tools and it is rather pointless, games are simply distributed with CDDA tracks in front of a data track. This means that a CD-R backup has CDDA starting at LBA 0.
So what does this mean? It means nullDC starts playing CDDA from LBA 0, assuming that the disc has been hacked and modified to start with CDDA tracks. Since GD-ROMs don't, GD-ROMs don't play correctly. The emulator doesn't bother to find out where the CDDA is, it just starts playing from 0 because that's where it always is on CDDA games.
nullDC's GDI code was never intended to be largely used by the public, as its authors probably never anticipated any sort of GD-ROM dumping project, and the GDI feature is undocumented. This isn't the only bug in its code, I have already spoken to Raziel about other issues.
Yeah the audio code is buggy, but it is perfectly usable to tell whether or not a CDDA-rip will work on a real DC. So far my experience proves me right. I worked two months on Vanishing Point, which showed a similar behavior like V-Rally 2, but I managed to fix that eventually. I also first assumed that nullDc was too buggy and that my disc would work in a real DC, but my logic and Echelon proved me wrong and after perfecting my rip I know that the mentioned V-Rally 2-issue is not related to nullDc but to the V-Rally 2 code itself.darcagn wrote: I never said nullDC expects that everything is hacked. Perhaps I was misleading in my previous post. nullDC's CDDA implmentation is bugged where it assumes that every disc it is given behaves like a cracked backup disc.
The Echelon intros are not hacks, but hacked in programs. I wasn't clear enough there. Or to be more exact, they are inserted prior to the game code.
And still I ask you how a nullDC-version which wouldn't expect cracked content would behave? The only thing I can think of that is backup-specific about nulldc is, that it accepts mil-discs, but so does the DC. In fact those "cracked" backups don't behave much different from unaltered originals, except for the skipped copy-protection routines. A good backup is as compatible as an original and thus behaves as such, regardless if it's "cracked" or not.
Ah ok, I got that totally wrong then.darcagn wrote: I never worked with the nullDC guys to design the GDI layout. The Dumpcast founders and I had theorized about an XMLish cuesheet format to work for GD-ROM dumps, but we abandoned the idea, not knowing of nullDC's existence at the time nor knowing its authors.
Yeah, they are, but only for your Microsoft example. As for DC-hacking this doesn't comply. Your example isn't even remotely comparable to this problem. There are two ways of emulating games. Either you use the method you described, or you accurately emulate the hardware. Your example brings great compatibility for some games, but bad overall compatibility. That's why you hardly find that kinda emulation nowadays. nullDCs attempts to accurately emulate the hardware. That's why it doesn't need to care for violation of standards. One big error in your assumption is also this: While everyone knows about Microsofts re-interpretation of html code, you can hardly tell what was changed at every specific rip out there. So it would be impossible implementing all options. It's also useless, as you'll see below.darcagn wrote: My suggestion is completely logical.
Next thing is that Microsofts attempt is a violation of standards, but the hacks in DC-games are not, otherwise the DC couldn't interprete them. The code is executed in a very limited system. You can't just force new standards on it. You have to bow to the system's standards. That's how it works for consoles.
The next error is that you treat so called "hacks" and "cracks" as if they would put an extra problem on the emulator, for which the coder needs to implement a solution right from the beginning for the game to work. And this isn't the case. You speak of effects and that shows me that you never hacked a DC-game, except may be by using a program that does it for you. These so called effects are nothing more but little jumps most of the time to bypass code. There's nothing for the coder to consider here. In fact, you'll even find bypassed code in many original games (Hot Coffee Mod anyone? ). That doesn't have any effect on the emu, its performance or its stability. There are only very few examples where real cracking on DC-games was done, e.g. implementing loaders and decompressors, but since these also comply to the DC's standards they have good chances of working with the emu.
I know everything about the disc layout. I also said that I converted the gdi to cdi. Wouldn't have been possible without dealing with that structure. You didn't get what I was getting at. May be I was not clear enough, so here it goes again:darcagn wrote: GD-ROM discs have two additional tracks in a low density session. ... Because this track layout is difficult to replicate with standard CD-ROM mastering tools and it is rather pointless, games are simply distributed with CDDA tracks in front of a data track.
The audio in the gdi also starts at LBA 0 and that is clearly wrong. As you mentioned, the audio tracks are placed much more in the middle of the disc. So, the original rip makes nullDC believe that the audio tracks are at LBA 0, while on a real DC it would jump to LBA *insert really high number here* (=irhnh).
After I ripped this game, it still behaved the same way, sending nullDC to LBA 0. The conclusion is that if I burn that now, the DC will go to LBA irhnh and will start playing back the totally wrong audio track or even the data track.
So I have to modify the 1ST_READ.BIN to the new track layout accordingly. Echelon did it, thats why their version doesn't look at LBA 0.
Furthermore, whenever nullDC jumps at LBA 0, playback of the track is never even initialized, so I guess the game would only run with muted BGM
darcagn wrote: This means that a CD-R backup has CDDA starting at LBA 0.
Wrong. Did you ever see a game which looked at LBA 0 for an audio track? I haven't and that has a reason. All CDDA-games start looking at LBA 150 for the audio data. If you send them to LBA 0, you'll hear terrible noise for the first two seconds because of the pregap data....I know because I tried it...
Who says that? Who backs you up on this? Why I'm asking? Because as I already said for the umptenth time: I managed to alter Vanishing Point's CDDA-code before. It behaved the exact same way like V-Rally did. I changed it and nullDC picked the tracks up at their right locations. nullDc doesn't just jump because it assumes that all CDDA-games start there. It has to do what the game code tells it! nullDC doesn't have a built scanner that detects what treatment a game needs. The game code handles. If it had that kind of artificial intelligence then why does it jump at LBA 0 (which is also the wrong one, as you know by now) but doesn't start playing?? If nullDC were that smart then it would treat my rip and echelons both the same, but it doesn't.darcagn wrote: So what does this mean? It means nullDC starts playing CDDA from LBA 0, assuming that the disc has been hacked and modified to start with CDDA tracks. Since GD-ROMs don't, GD-ROMs don't play correctly. The emulator doesn't bother to find out where the CDDA is, it just starts playing from 0 because that's where it always is on CDDA games.
Then it's totally cool that they left it in. It sure is usefuldarcagn wrote: nullDC's GDI code was never intended to be largely used by the public, as its authors probably never anticipated any sort of GD-ROM dumping project, and the GDI feature is undocumented. This isn't the only bug in its code, I have already spoken to Raziel about other issues.
I've only assembled a handful of rips myself, and of the ones that had CDDA, they were all Windows CE, which is a whole different kettle of fish.Xiaopang wrote:basically just a hex editor and nulldc
However, for stuff that isn't Windows CE, don't you need to specifically patch the binaries for CDDA? For example, take a look at this entry for Vanishing Point at the Dreamcast Rip Database.
I'll start working on WinCE games with CDDA soon. You don't need to do any patching of some sort to get them to work, do you?az_bont wrote: I've only assembled a handful of rips myself, and of the ones that had CDDA, they were all Windows CE, which is a whole different kettle of fish.
Yeah you can do that. Unfortunately, there's no specific info on what exactly these hacks do. I don't remember whether I needed them or not. I'll have to look at the 1ST_READ.BIN again. I think one hack enabled/disabled CDDA. I don't know what the other one does. I remember using them both, but I don't remember whether I undid them or not. Either way, they didn't have any impact on the track layout itself. They don't even seem to do anything in V-Rally. I compiled several versions of the rip with and without these hacks and all behaved the same CDDA-wise.az_bont wrote: However, for stuff that isn't Windows CE, don't you need to specifically patch the binaries for CDDA? For example, take a look at this entry for Vanishing Point at the Dreamcast Rip Database.
I've still got all the files from my Resident Evil 2 rip, and I didn't have to do anything at all to CDDA. I have seen other releases where the track numbers have altered, but for mine, I just used three dummy tracks for the first three, so that tracks four onwards matched their respective numbers on the GD-ROM original.
However, I don't know if that holds true for every Windows CE game with CDDA. I know, for example, that V-Rally 2 has proven to be quite frustrating when it comes to CDDA, and I'm pretty sure some additional trickery is required there.
However, I don't know if that holds true for every Windows CE game with CDDA. I know, for example, that V-Rally 2 has proven to be quite frustrating when it comes to CDDA, and I'm pretty sure some additional trickery is required there.
Thats quite the way to go.az_bont wrote:I've still got all the files from my Resident Evil 2 rip, and I didn't have to do anything at all to CDDA. I have seen other releases where the track numbers have altered, but for mine, I just used three dummy tracks for the first three, so that tracks four onwards matched their respective numbers on the GD-ROM original.
It is indeed tricky, but I'm positive to manage that problem eventually. For now I'm stalling my work on it in favor for working on Shenmue backups. They promise to be an interesting challengeaz_bont wrote: However, I don't know if that holds true for every Windows CE game with CDDA. I know, for example, that V-Rally 2 has proven to be quite frustrating when it comes to CDDA, and I'm pretty sure some additional trickery is required there.
I'm sorry to intervent your little discussion , but:
first thing: if you found an all in one tool for ripping a DC backup then plz tell me where
in fact, those guys here did a lot of stuff. another fact is that NOT only echelon had/have the knowledge to rip/selfboot CDDA games (in all different favors - WINCE or not).
now for the interesting stuff:
furthermore, nothing is "skipped" or whatever you want to call it by echelon or someone else.
whats needed to get a rip from a dump are a few steps, depending on what everything is "included" in the gamecode:
first - and thats for ALL games - you need to change the LBA's. namely 4500, 45150 and 45166 - i think thats what you think of as skipping code
on CDDA games of course also CDDA LBA, and (in some cases?) also some kind of "CDDA protection".
on SOME games there IS a copy protection of different kinds (like sonic adventure 2), but thats NOT for all games.
then there are those WINCE games, which i actually don't know all too well - can't say much about those
there also is some special method of accessing the 1ST_READ.BIN done by the DC (scrambled/unscrambled BIN files) and there might also be a "GD" flag somewhere, but im not sure about that right now.
nontheless, i think you might have quite some knowledge about how to rip DC games etc, but you seem to miss something. did you get V-Rally to work on real hardware? - don't jump into my face now, just lets make sure that its not a problem with the basics
PS: dunno if i forgot sth while writing this stuff. just tell me if i'm obviously missing sth...
edit---> oh, and just to have this being said:
the GDI's are totally correct, just open them in any texteditor and take a look yourself, nothing points to LBA0.
i wouldn't jump to conclusions too fast...Xiaopang wrote:[...]You speak of effects and that shows me that you never hacked a DC-game, except may be by using a program that does it for you. These so called effects are nothing more but little jumps most of the time to bypass code.[...]
first thing: if you found an all in one tool for ripping a DC backup then plz tell me where
in fact, those guys here did a lot of stuff. another fact is that NOT only echelon had/have the knowledge to rip/selfboot CDDA games (in all different favors - WINCE or not).
now for the interesting stuff:
what darcagn wanted to say (at least i think so) is that nullDC just "sees" that the game you feed to it is CDDA and then jumps to LBA 0 (or 150, which on an GD as 45150 would be IP.BIN start), which is the default procedure for ripped DC games. no mystic AI there, just "routine".Xiaopang wrote:[...]It has to do what the game code tells it! nullDC doesn't have a built scanner that detects what treatment a game needs. The game code handles. If it had that kind of artificial intelligence then why does it jump at LBA 0 (which is also the wrong one, as you know by now) but doesn't start playing?? If nullDC were that smart then it would treat my rip and echelons both the same, but it doesn't.[...]
furthermore, nothing is "skipped" or whatever you want to call it by echelon or someone else.
whats needed to get a rip from a dump are a few steps, depending on what everything is "included" in the gamecode:
first - and thats for ALL games - you need to change the LBA's. namely 4500, 45150 and 45166 - i think thats what you think of as skipping code
on CDDA games of course also CDDA LBA, and (in some cases?) also some kind of "CDDA protection".
on SOME games there IS a copy protection of different kinds (like sonic adventure 2), but thats NOT for all games.
then there are those WINCE games, which i actually don't know all too well - can't say much about those
there also is some special method of accessing the 1ST_READ.BIN done by the DC (scrambled/unscrambled BIN files) and there might also be a "GD" flag somewhere, but im not sure about that right now.
nontheless, i think you might have quite some knowledge about how to rip DC games etc, but you seem to miss something. did you get V-Rally to work on real hardware? - don't jump into my face now, just lets make sure that its not a problem with the basics
PS: dunno if i forgot sth while writing this stuff. just tell me if i'm obviously missing sth...
edit---> oh, and just to have this being said:
the GDI's are totally correct, just open them in any texteditor and take a look yourself, nothing points to LBA0.