tomaitheous

Yup, that's me My random PCE coding blog is: http://pcedev.wordpress.com/ Yeah, but I haven't talk to him in over 8 months or so. Famous, eh? Which country? What's the emulator fork/version are you guys using of mednafen? I've worked with the author over the years doing REing of the system (CD and base), and she's constantly updating it (I talk with and do tests for AamirM's TurboEngine emu too, though I don't think there'll ever be an xbox port of that). I don't have my xbox modded (yet) mostly because I already have my PC in the living room area. I don't use ISO/MP3 setups. I've heard from the author that MP3 conversions can though off the audio timing a bit (relative to the audio data itself. Sort of like variable rate audio resampling that goes in and out of sync. Temporal stretching and shrinking of the audio data). I did do have some OGG sets though (ISO/CUE/OGG) that I think I've used with the PC version of mednafen. OGG preserves the temporal domain, so it works as a supplement to WAV files (I guess OGG is both a container and a compression codec? Strange). I can see why MP3 is desirable, but it still has inherent problems of effecting audio lengths (the lossy conversion is the least of any of the problems). Sorry that I probably can't be too much help specifically with the xbox version. Yeah, data itself is OK regardless of the pregap size. The system card (bios) records the absolute LBA of index 01 of the current data track (you can select any number of tracks once the game boots), and adds that the relative LBA sector offset sent the bios read commands. So data will always be in the right place regardless of the pregap size or even starting track number (and this is why my Lords of Thunder CD works. I also changed the data track from 2 to 1 on the PCE side). I've never seen a game read data beyond the data track it's currently in, unlike CDDA (CD audio) requests. That's the problem I was talking about if you change the pregap offset. But if emulation itself it getting it wrong, then you could very well be applying a bandaid fix that corrects this (though it doesn't correct the original issue, which can show up on another emulator). Adding/changing post gap will also effect this. Hell, anything can because like I said; it changes the absolute LBA offset of all audio tracks. And games that rely on this method (LBA vs track play) will have out of sync audio (cinemas or in game). I've seen it go as far back as it playing the end of one track before starting the next. Or even the ending part of a data track >_> It's highly game dependent. I would first figure out and make sure the emulation is correct/accurate (not to bad mouth the PCE emulator on PSP, but accuracy is the last thing that comes to mind for PSP emulators). You have a number of variables you're dealing with. MP3 temporal domain distortion, unknown accuracy of the emulator, unknown reliability of the downloaded rips (you can never be completely sure unless you did the rip from the original yourself and use the correct ripping method/tool). Anyway, if you found a work around that fixes the problem, even if by trial and error, that's probably the best you guys can do given the situation - no? Assuming it meant specifically for that version of that emulator. Heh - I was just looking for Ruin RPGs pics/snaps for the game when I came across this thread (wanted to see what some of the later parts of the game were like). And just wanted to correct the two bits about the sector offset, the index 01 issue, and how it can effect games. That's how it works on the real hardware. Hopefully that can be of some help? If you're still confused about either, I can try to explain them in more detail. Again, nice compact list of the games with shots and short description. Mind if I link this thread for others (post #3,4, and 5) ? On a side note, Esperknight was new to the PCE translation scene and was working on Tengai Makyō (far east of eden). It's a great series (though TM2 is just an incredible game even compared to other consoles). He took a break, but I think he's back now (from what we've talked). He's also doing a special version of mednafen. It's a script based text overlay system. It's based on sector offsets (read requests). There's a script file that goes along with the game, and the LBA read request triggers the script. The script does things like overlay translated text and such over the video so you can read what the cinemas or ADPCM parts (voice only in game) are talking about. I take it this would be something of interests for the xbox version?

Well the cdda music don't stoping is only a problem with the cds, the turbo chips (cards) uses mostly chiptunes and midis so if the music don't stop in darius is because the game is developed that way, in the other hand, the replacement of the tocs with the ones generated in turborip is not a real solution because turborip was designed by RIGG in order to be used with the HU-GO emulator, besides many factors make a game play wrong, from the fact of having a crappy image (ISO/MP3) to even have a "verified" image with synch problems, Turborip only checks and correct the length of the files, but if the audio tracks are wrong, crappy, distorted, or even modified the tool can't detect that, for an example I made a custom Double Dragon II image for my xbox sometime ago in which I replaced the original music tracks with the ones in the arrange album (which actually sound thousands of times better), the only thing necesary to do it was to rename the wave tracks in the correct names and use toc fixer to make the lengths of the tracks match with the toc in turborip, when I used Turborip to make my ISO/CUE/MP3 the tool recognizes the valid toc and say that the image was valid with no mistakes. Besides the problem are the files inside the "pcetoc.zip" file, the .lsn files are just tocs (open those with notepad) but that tocs are designed to emulators with the cores of HU-GO, in most of the cases the games works fine but in others totally screws the game, the start sector in this files is 0000 which is wrong because some pcecds start at sector 150 and then you must do ceiling calculations (and yes I can't do that calculations because I'm not into programing) so it only need a person (like madmab) with the skills and the experience necesary in order to be fixed (besides even if it sounds to be very troublesome and complicated it is not in reality, is just a quick revision and correction thing) so I will work in the list with my limited knowledge and see if that proves usefull to madmab. That's not true AFAIK. TurboRip was made much after Hu-Go was made obsolete. TurboRip was made because of the inaccurate rips out there in relation to pregap and other misaligned track offsets. The fact that it can't CRC a track to the original is irrelevant. As long as the length and offset and structure are to spec, the actual audio data doesn't effect anything. Unless you're ripping a burned CDR, which isn't what the app is made for. It's made for ripping original formats. Also, ISO/WAV format is preferred. There's nothing wrong with a cooked format. Makes it easier for patching games too. RAW format makes it a pain for translation hacking because of the additional unneeded sector bytes, which make dumping or looking for text and graphic data extreme painful. And the PCE system card does not use 150 sector offset for boot. That would be a 2 second hardcored pregap. Only SegaCD does that. The PCE system looks for "Index 01" of the first data track it finds. CD specifications list chapter support for Red book format. Indexing is how you do it. The pregap is the space between Index 00 and Index 01. Spec says minimum of 2 seconds, but there's no maximum. And some games use a 3 second pregap. A lot of PC-Engine CD games use absolute LBA offsets for CDDA playback, instead of track play mode (some do use that though, like Lords of Thunder). If you have the wrong pregap size, the whole rest of the audio can be out of sync because of this. And for games that use 'track play' method for CDDA instead of LBA mode, need to have that last repeat data track at the end. Because the translated command requires a ending track #. If you omit it, it won't play that last CDDA requested track. If my word isn't proof enough, I have made a test CD to prove it. I made a Lords of Thunder Dual boot CD. It plays in both the SegaCD and the PCE/TGCD/Duo system. It works because the SegaCD has a hard offset of 150 sectors pregap, but the PCE does not. And the CD specification says there's no maximum pregap for the first track (some audio CDs are known to hide audio track like this, that you have to 'rewind' or seek backwards to get to them). I merged the two systems ISO tracks and set Index 01 to the start of the PCE's track, replaced the SegaCD audio tracks with the PCE, and hacked the PCE's game code to play the new track order/layout. Video here: http://www.youtube.com/watch?v=K9Zby5sQkuI Also.. nice list of games,shots, and descritions Sounds about right. PC Engine CD Offline Catalogue app is somewhat old now and lists 480 CD games.