Meteor Blaster DX Reprint

Started by jlued686, 04/02/2013, 09:41 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

turbofan1

Excuse my ignorance,I thought Mindrec was based in the Uk or England or something?.On the back of Meteor Blaster dx it says Durham Nc.

NecroPhile

I'm pretty sure they've always been in NC.
Ultimate Forum Bully/Thief/Saboteur/Clone Warrior! BURN IN HELL NECROPHUCK!!!

NightWolve

#252
Quote from: TheOldMan on 06/12/2013, 02:53 AMCool. So (forgive my asking for this) Is there any way to correlate both the P and q channel changes with the index number changes, and see how accurate they are in relation to the TOC data? It might be possible that a change in the P and/or Q bit signifies the 'real' end of a track. (I still haven't figured out what the P bit actually indicates... )
Well, the TOC always gives you the start LBA of a new track right at index 01 (the first sector marked as 01 in the Q data). That's a guarantee as far as the rules go. The previous sectors *might* be marked as index 00 and have the same track number, so then you've got a pregap/pause situation, etc.

The best strategy (so far I think) to find the true end/stop LBA of the current track would be to use the LBA of the next track listed in the TOC minus one sector like you normally would, subtract a second (75 sectors) to read backwards from that point, and see if the track number from the Q data still matches. If index is 00, and the track # is +1, then it belongs to the next track, so you'd subtract another second and try again until you get the track # in the Q data to match the track # that you're reading (TOC-wise). Then you've got the true end/stop LBA for that track. Many programs take the LBA of the next track minus one for the stop/end LBA with no Q subcode analysis, like when you ask to read that first audio track in a NEC disc, and when they hit a pregap to a data track transition, they error out (the problem we've talked about). This was one of the failures of programmers in track by track ripping, a detail they missed.

Anyhow, that's how I'm thinking of doing it with TurboRip if that makes sense, something like that. That's the equivalent of the "Quick" version of CDRWIN's subcode analysis I would bet. I use the MMC 0xBE read raw command, but with a flag set for returning the Q data. So I've never played with the P data. The other flag available is for raw 'P' and 'W' together, or 'RW'. Maybe I'll look at this P data too, to see if it helps in someway, but I think it can be done with just the Q data (finding the true end of the track you're reading and multiple index detection).

QuoteQuick aside: Does anyone know if you can combine audio, data and CD+G information on a CD? I can't see any reason you couldn't, but thought I'd ask first.
I would think so in different tracks.

Bt Garner

Quote from: guest on 06/26/2013, 09:31 AMI'm pretty sure they've always been in NC.
Not always (started out in Seattle), but ever since we've been doing PCE games, NC has been home.

esadajr

great quality product, dont miss it
Gaming since 1985