Meteor Blaster DX Reprint

[Arkhan Asylum]

yeah mine too.

I thought we had to preorder through the  mailing list.  I checked MindRec and didn't see a link for it or any mention of it on the main page.

[VestCunt]

Can someone please copy and post the preorder announcement here?
I got my Turbolist subscription worked out, but missed today's email.

Edit: or PM me a copy?
Edit: thanks!

[Bt Garner]

Here is the posting to the list.  Same pre-order discount applies to folks here too.

Hello List!

After going through several different CD manufacturing places for CDs, I have finally found one that not only can press Turbo Duo CDs, but the owner is also a Duo owner!

With all the logistics taken care of, the 2013 re-release of Meteor Blaster is all set to go, and I am expecting to have the CDs in my hands within a couple of weeks.

As promised, I am giving list members a chance to pre-order at a discounted price.  The following link will allow you to pre-order MB, or the MB+Implode pack   There is also a special collectors' item listed there -- you can buy one of the test CDs that the CD replication house sent out to verify that they could actually make Turbo Duo CDs:

http://mindrec.com/?main=mbdx2013/index.php

That link will be valid through June 5, after that, you will need to go through the regular MindRec store link for ordering.  Also, that is for Paypal processing, if you want to do payment via another way, let me know and I'll help get you sorted out.

The 2013 Re-release of MB contains the signature edition of MB (5 ships versus the normal 4), some different hidden features and a few other improvements.

Let me know if you have any questions, thanks!

[TheClash603]

I tried the mailing list twice and somehow it didn't work.  Will someone order me 2 copies and I will send money + shipping + handling charges their way?

[esteban]

I pre-ordered just now.

TO DO LIST: I need to order Pyramid Plunder and Lock-N-Chase, too, but I'll have to wait until next paycheck

[ParanoiaDragon]

Just ordered mine.  Infact, I ended up doing the dual pack with Implode for the hell of it, couldn't hurt to have an extra copy of it.

[esteban]

Just ordered mine.  Infact, I ended up doing the dual pack with Implode for the hell of it, couldn't hurt to have an extra copy of it.

Me too, I added Implode as well. I'm going to give a friend a copy. I don't think he has ever played it, in fact.

[Duo_R]

Ordered yesterday!

[hoobs88]

Just placed my pre-order!

[Keranu]

Preeeeee-orderededed!!!

[GohanX]

Dual pack bought. Weee!

[Bardoly]

Just ordered 2 dual packs!

[TheClash603]

Who wouldn't get the dual pack?  That is a super deal!

[ParanoiaDragon]

Hey, just to help BT unload some more Implodes is worth it, since homebrew doesn't sell like hotcakes, who knows how many stacks of Implodes are currently & unfortunately coasters!

[VestCunt]

Paypal just sent me a shipping notice!

[jlued686]

Me too!

[esadajr]

Me too!

^^^^^

[Duo_R]

Me, because I already had it...lol. Now I feel like I should have got an extra.

Who wouldn't get the dual pack?  That is a super deal!

[Nazi NecroPhile]

Me, because I already had it...lol. Now I feel like I should have got an extra.

Same here..... it woulda made a good raffle maybe.

[FiftyQuid]

Paypal just sent me a shipping notice!

D'oh!  No shipping notice here yet.  Damn me for living in Canada.

[CrackTiger]

Paypal just sent me a shipping notice!

D'oh!  No shipping notice here yet.  Damn me for living in Canada.

D'oh!  No shipping notice here yet.  Damn me for living in Canada.

[JoshTurboTrollX]

I have GOT to start paying closer attention to these forums!  LOL- Got my 'Pre-order' in thru Paypal.  I had no idea this game was so close to being available again!!

Thanks BT!!

WOO!!!

[Mishran]

I'm rather looking forward to this, even though I own the original. Has anyone been able to finish all 99 levels of this? I usually made it to the 10th or 11th level and die horribly. Tried a level skip cheat in magicengine to check out the level 99 boss once and died repeatedly as soon as the level began. Lol His shots are near impossible to avoid.

[roflmao]

Don't fret, I haven't received my notification yet either, and I ordered as soon as the mailing list message came though - before it was posted here.  I'm sure they'll all go out soon.

[esteban]

I'm rather looking forward to this, even though I own the original. Has anyone been able to finish all 99 levels of this? I usually made it to the 10th or 11th level and die horribly. Tried a level skip cheat in magicengine to check out the level 99 boss once and died repeatedly as soon as the level began. Lol His shots are near impossible to avoid.

I don't get too far before choking on some silly nonsense. My daughter thinks my inability to stay calm and focused is pathetic, but insists that I keep practicing.  

[Arkhan Asylum]

Mine came yesterday!  I forgot to mention this.

[esteban]

Mine came yesterday!  I forgot to mention this.

Damn, unless my daughter forgot to check the mail today, I haven't received anything.

[FiftyQuid]

Shipping Notification arrived in my Inbox!

[Keranu]

Received mine! Will test it in a bit!

[tggodfrey]

mine came as well.  I plan to jam out on it tomorrow evening.

[TheClash603]

Still jealously waiting for mine!

[PunkCryborg]

got my shipping notice!

[Duo_R]

Mine came today too!

[ParanoiaDragon]

WOO-WOOOOOOOOO!  Here comes the Turbo train, cuz mine just shipped!

[roflmao]

Mine came in this evening.  Yeehaa!

[jperryss]

So it's officially too late to try to unload my CDR version that I just bought a few months ago? LOL

[Nazi NecroPhile]

Got mine yesterday and played a few rounds (I sucked bad) and a bit of Implode Caravan too. 

[NightWolve]

It wouldn't if it were just a recomendation. It's not. See iso/iec10149, section 20.

If this really is the problem, it's such a minor thing and unfortunate. No burning software that I know of thought the concept important enough to allow you to burn it exactly as called for. Obviously, most standards ARE important (TOC, sector format, etc.) and need to be strictly/precisely followed because you won't have a working CD by the end of it, duh, but in this case, where you can at the very least encode a 3 second pregap with most burning software (and meet that standard), it shouldn't matter so much that the 1st second of those sectors in this pregap area (75 sectors we're talking about) won't be flagged as type audio, just like it doesn't matter if the actual data in this area is all 0's or 1's...

If the pressing software rejects our mixed-mode CDs simply because a 3 second pregap on a data track doesn't have the 1st second of that pregap flagged as audio sectors (when it comes to audio to data transitions), it just strikes me as way, way too damn picky is what I'm trying to say, I guess... I had just heard that the current, popular software used by pressing plants just has problems with mixed-mode CDs period and I kinda wanna know exactly what the problem is here!

the PCE doesn't check tracks that closely (even to the point of ignoring data track checksums, iirc).

Hm, that doesn't sound right, the ignoring of an EDC/CRC code. Years ago I asked David Michel (Magic Engine emulator author) about the last data track typically found in NEC discs that is mostly a duplicate of the 2nd working data track. He confirmed that it is indeed a "backup" track, that there is code in the BIOS/system that'll resort to using that track if the 2nd track suffers from enough read failures/can't be read, etc. As to the details, how many read failures/retries does it take before resorting to using the last backup track, I didn't ask, but I just wanted to know what purpose, if any, that duplicated track had. Point is, read errors of data sectors must be detected somehow for obvious reasons and for this switch to the backup track to occur, etc.

Anyway, ignoring pregaps in data tracks is one thing, it happens naturally since the TOC only stores the LBA of index 01 (where valid user data actually begins in a track), they're supposed to be ignored content-wise (I have heard of copy protection schemes making use of them because of this, though), but ignoring EDC codes is quite another.

I'm not so sure the LBA's would match, though - and I'm pretty sure the time stamps encoded in the track headers would be wrong.

The LBA/Time data of the TOC will match the original if all files in the ISO/WAV/CUE image file set were read and stored properly, etc. That's not hard! If you couldn't even accomplish that, well, then a significant % of burned CD-R games (e.g. Dracula X) would suffer from numerous problems: crashes, lip-syncing issues when a cinema plays, or background music starting at the wrong time, etc. I dunno about the time stamps in the track headers that you mention, which I guess refers to the time data burned into the subchannel sectors, but yeah, the LBA/Time data found in the TOC *will* match if the original image was read properly.

Quick aside: There used to be an infamous problem with all those ISO/MP3/CUE image file sets floating around precisely because when a MP3 file is decoded back into a WAV file, the original file size is lost and you get a file that's either smaller or bigger than the original. Thus, burning that image set to a CD-R would result in a TOC much different than the original and would cause the problems I mentioned because of how a % of games are coded: Games like "Dracula X" have the LBA address hardcoded for the audio track to play, while games like "Ys IV: Dawn of Ys" dynamically obtain the LBA from the TOC, so for such games, you could replace all audio tracks with either smaller or bigger ones and it wouldn't break the game, etc. SignOfZeta once offered his own replacement soundtrack for "Lords of Thunder" because it happened to be one of the games that operates this way. Anyway, that whole ISO/MP3 craze was what led to me creating TOC Fixer which will resize all files in your image set to what they should be so that the TOC will match the original when burned. This was another good use of the NEC TOC Database which is what allows emulators like Magic Engine and good ole TurboRip to detect and title a disc when it's inserted.

Such a data track would simply have 3 seconds of extra sectors in the beginning and it would get burned back in the duplicate exactly as it was in the original resulting in a more 1:1 copy. Pregap = index 00, same thing, just that when you use the pregap command in the CUE file, the burner will determine what data is actually burned there (and not read from the file), probably just all zeros, etc.

Yes, the data track would have 3 seconds of extra sectors at the begining; I'm not so sure it would be a 'more' 1:1 copy,

What I was talking about was in situations where you'd want to preserve the actual data burned in a pregap as opposed to discarding it (like I currently do in TurboRip for NEC discs). The other method I showed preserves it, so if there was copy protection information hidden there, the new disc would still work, so yeah, a "more" 1:1 copy in *that* sense... Obviously, if you want a perfect 100% 1:1 copy, you need to go all the way in terms of methods with something like CloneCD and read the original disc in "RAW 96 mode" (2352 data sector bytes and 96 bytes of subchannel data), and then set the burner to "RAW DAO 96" (if supported) mode to burn everything back byte for byte. That is for copy protection schemes that intentionally burn wrong/bad subchannel data where letting the burner/software recalculate/rebuild that data will result in a non-working disc.

Because pregap != index00. Again, the iso/iec docs state that gaps are encoded as a 'pause' type sector (pq=00), whereas indexes are encoded as information sectors. They are not the same thing, though many program treat them as such.

Just how different are they beyond labeling ?? The SCSI-3 MMC docs basically state index 00 is a special index, and it defines the pre-gap or pause before the audio starts. Information sectors start at index 01. Here it is verbatim:

The CD media standards require transition areas between tracks encoded with different types of information. In addition, transition areas may be used at the beginning or end of any track. For audio tracks the transition areas are called pause areas. For data tracks, transition areas are called pre-gap and post-gap areas.
...
An index is a partition of a track. Pre-gap areas are encoded with an index value of zero. Pause areas at the beginning of audio tracks are also encoded with an index value of zero. The first information sector of a track has an index value of one. Consecutive values up to 99 are permitted. Index information is not contained in the TOC. Not all sectors are encoded with the index value in the Q sub-channel data (the requirement is 9 out of 10). A sector without an index value is presumed to have the same index as the preceding sector.

or

Every sector contains an index which is a number between 0 and 99. Index 0 and 1 have special meanings: 0 indicates a pause sector and 1 the beginning of the data in a track.

Beyond flagging the index byte as 00, what else is a program supposed to do to create further distinction ??

And for the record, the burner only writes what it is given - the software determines what is in the pregaps. Sometimes it is all 0's, but not always.

Well, the burner's firmware is responsible for some aspects of the burning process depending on the mode. If you burn a wave file in a basic mode, the firmware is responsible for generating the subchannel data, etc. But yeah, if the mode is set to something like "RAW DAO 96," then the burning software and/or image is entirely responsible for what is written and must provide it - must come either from the image or be recalculated/rebuilt by the software. I wasn't intentionally specifying that the burner itself was handling pregap content though, I could've said "burner/software," etc. I hadn't thought about the distinction at the time.

Whether such things -should- matter is open for debate; the fact is, to produce an iso standard disc as required by the pressers, it -does- matter. And yes, we've already covered that the PCE will run CDs that are not iso compliant; they work fine. That should not be taken to mean that they are 'correct' as required by the presser, however.

I've had this discussion with many, many people. They all seem to make the same mistake: Just because a particular program burns a particular disc that works does not mean the program burned it correctly. Furthermore, just because a particular cue sheet appears to give you a correctly formatted cd does not mean it is iso compliant.
Programmers are lazy: in my general experience, different progams implement the mixed-mode cd slightly differently.
Different programs create different discs from the exact same cue sheet and file. We live with it, and work around the problems when needed.

*Here's what I wanted to ask you: Did an engineer from a pressing company specifically tell you that the 3 second pregap must have the first second of sectors flagged as audio and that this was the reason their software was rejecting the disc ??? I wanted to know if you were specifically told this was the problem by someone from a pressing company versus if this is your own conclusion as to why "Mixed Mode Layout fails Eclipse," etc.

This specifically:

The problem <apparently> is that the p-q codes which indicate the track type have to change at those intervals...which seems to screw with the pressing software.
(ie, the 2 sec gap has to be encoded as an audio track, while the 1 sec extended gap has to be encoded as a data track.)

I also have a suggestion for someone to try in the future. I'd be curious if it gets a different result because, now, I don't think NEC discs are actually proper. I'm gonna repaste the rule I added before:

****  6.2.11.7. Post-gap ****
   If a Data track is followed by another kind of track (such as an audio
   track), this Data track ends with a post-gap. A post-gap is placed at the
   end of a Data track, and is part of the Data Track. A post-gap does not
   contain actual user data. The minimum length of post-gap is 2 seconds. The
   drive does not perform any action for a Post-gap.

OK, here's the thing, NEC discs made what apparently should be a 2 second post-gap a pre-gap instead! Moreover, the pre-gap belongs to the next audio track, when according to this rule, it should belong to the same data track! I wonder if this is why their pressing software complains! In other words, a CUE should look like this:

FILE "01 Fighting Street (J).wav" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "02 Fighting Street (J).iso" BINARY
  TRACK 02 MODE1/2048
    PREGAP 00:03:00
    INDEX 01 00:00:00
    POSTGAP 00:02:00
FILE "03 Fighting Street (J).wav" WAVE
  TRACK 03 AUDIO
    INDEX 01 00:00:00

In reality, NEC discs are actually burned like this:

FILE "01 Fighting Street (J).wav" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "02 Fighting Street (J).iso" BINARY
  TRACK 02 MODE1/2048
    PREGAP 00:03:00
    INDEX 01 00:00:00
FILE "03 Fighting Street (J).wav" WAVE
  TRACK 03 AUDIO
    PREGAP 00:02:00
    INDEX 01 00:00:00

So yeah, technically NEC is wrong here... Any thoughts ?? BT ?? I believe you once said that NEC discs were not of proper format, or something to that extent... If the rule I posted is accurate, that would seem to be the case. I could be over-analyzing here and the issue is how exactly a "post-gap" is implemented.

Anyway, I had 2 final things on this:

1) Did somebody ever send an *original* NEC disc for duplication ?? I wonder if they get the same type of problems or not, etc. That'd answer some questions.

2) I wanted to offer a suggestion to PCE homebrew teams if they can try burning a new disc with the use of a post-gap command and send that to the pressing company (like the first style that I posted) on say the next homebrew project, etc... I'd be curious if that makes a difference.

(Apologies for the long post/interruption. It's an interesting subject for me. Proper handling of indexes is something I still wanna fix for TurboRip.)

[Arkhan Asylum]

We won't be doing it.   We're makin HuCards, sucka.

[NightWolve]

We won't be doing it.   We're makin HuCards, sucka.

You've made your last CD ???

[shubibiman]

Haven't followed all the thread but I'd like to order a copy. Any link?

> http://mindrec.com/index.php?main=store/info.php&id=BTCD0402

[Nazi NecroPhile]

Haven't followed all the thread but I'd like to order a copy. Any link?

From a couple pages back: http://mindrec.com/?main=mbdx2013/index.php

[VestCunt]

Got mine today. Awesome to see this project come to fruition.

[Mishran]

Got mine in the mail yesterday too, but didnt check the mail till early this morning.

This isn't a complaint, but something on the package and/or CD stating that this is a reprint would have helped differentiate this from the original CD-R version a little better. Aside from the clear case and Ximati ad on the inside insert, there doesn't appear to be a difference between the two. Although I haven't compared them side by side yet and merely going by memory.

[OldMan]

Nightwolve:
It's going to take me a while to get all my thoughts in line to explain this to you. So rather than post a huge wall of rambling text, I will send you an email with a text document explaining things as I see them. PM me your e-mail, please.

<Relatively> Short replies below, for everyone else whos curious....

it's such a minor thing

Not really. There is a reason the p-q bits have to be set that way....

that doesn't sound right, the ignoring of an EDC/CRC code.....

I did not mean that the pce ignores the error correction - what I meant was that is handled by the hardware in the CD-ROM drive. All the pce sees is a set of error flags when it requests a track. If there is an error, re-tries are issued. I -believe- bios makes 3 attempts...but note that the read is restarted from the beginning if there is an error. 3 failures of any kind will kick in the alternate base address for the cd data track, assuming there is one....

Which brings us back to the p-q bits. The q bit is used to turn on/off the circuit that checks the EDC/CRC. It may take some time for this circuit to initialize and stabilize in older cd players. Which is why the q bit has to be set when it is.

Quick aside: There used to be an infamous problem with all those ISO/MP3/CUE image file sets

I am initimately familiar with that problem. For more info, ask rover.
FWIW, it also happens if the wave files you used for audio are not single block files, in most burning software. (Wav's can have multiple blocks. If the file you try to burn actually has more than one block, some really strange things can happen, depending on the burning software)

Just how different are they beyond labeling ?? The SCSI-3 MMC docs basically state index 00 is a special index, and it defines the pre-gap or pause before the audio starts.

From my understanding, index 00 is never stored on the disc itself. It is inferred from the p-q bits. Also note that referring to the pause areas as pre-gap or post-gap is in itself misleading. The CD itself only know that there is a gap. Pre and post are used to distinguish between whether the gap appears 'before' or 'after' a track. What is a post-gap for one track is also the pre-gap for the next.
The problem with index 0 defining the gap is that index 0 is the time a track changes to a particular type. Which it can do in the middle of a sequence of pause sectors.

Did an engineer from a pressing company specifically tell you that the 3 second pregap must have the first second of sectors flagged as audio and that this was the reason their software was rejecting the disc ??? I wanted to know if you were specifically told this was the problem by someone from a pressing company versus if this is your own conclusion as to why "Mixed Mode Layout fails Eclipse," etc.

Not me personally. Arkhan handled all the details for getting the disc pressed. At one time he sent me the text of some of the error messages they said the got. Searching for the text on-line provided real english explanations of what the errors actually were. Adjusting the times made the errors go away. We don't -know- that that was the problem : we only know that adjusting the times 'fixed' it.

a CUE should look like this:
.....
  TRACK 02 MODE1/2048
    PREGAP 00:03:00
    INDEX 01 00:00:00
    POSTGAP 00:02:00

There's only one problem with that. You may have either a pre-gap or a post-gap, but not both.
Also, just for completeness, if you use Index 0, you may not have a pre-gap.
I'll have to double-check, but I'm pretty sure thats what the docs I have for cue sheets say....
.........................................................................
Please keep this one simple fact in mind: Burning CDs is largely a software matter.

Without access to the source code for *all* the software, things may be happening that you don't see. The data can be modifed by the control program, the cd drivers, and the cd burner firmware. Not all pieces play by the same rules. Heck, I haven't even found 2 burner programs that interpret CUE files the same exact way. It's largely a matter of tweaking things until you get what you want, and then remembering how you did it.

[VestCunt]

aside from the clear case and Ximati ad on the inside insert, there doesn't appear to be a difference between the two.

Different tray + different rear insert + real CD = pretty big difference.

[jlued686]

Got mine as well! Sadly, I'm out of town and won't be able to play it until I get home.

Thanks for doing this, BT!

[TurboXray]

What is a post-gap for one track is also the pre-gap for the next.

Hah, yes. I remember finding that out and thinking wtf??? Why even have a post-gap cue sheet command. And not all burning software treats it the same. I do remember the red book and yellow book documents stating that you can more then two indexes to a track (whether CD players do anything with it, I dunno. Never tried to test it). Most burning software puts the post-gap command of the last track as the pre-gap for the next. If you use both, it's probably just a gamble as to how each burning software treats it at that point. Might create a third index (supposedly legal) on the track and pad with 0x00. As far as post-gap goes, nothing in either red book or yellow book docs ever mentioned it. So I just chalk it up to some legacy cue sheet command or some such crap.

[OldMan]

Pre-gap, post-gap and index 0 were part of the specifications for making a cue sheet. The intent was to allow you to build an audio cd with a specific layout. The software required you to set the gaps yourself (no automatic adjustments), and the various directives determined where data came from and what kind of data is was.
I don't remember the specifics right now, but one of the setups allowed you to burn data from the file into the gap area.
You can have more than one index per track. This was used (for example) to allow you to seek to a particular movement in a symphony. The entire symphony would be recorded as one track, with different movements as indexes in the track. The guy who designed the original CD layout was a classical music buff.
(Which, incidentally, is where the size of a cd comes from. It had to have enough space to hold a particularly long symphony, because he didn't want to have to change the disc.)
It's been a while since I played with it, but iirc using the wrong combination of pre-gap/post-gap/index 0 would give you an error (Bad layout) before the burning started, because the TOC couldn't be built correctly. I'm not sure all burning programs do that, but I remember fighting to get those things correct in cdrdao many, many times.

[shubibiman]

Thanks for the link. Ordered a copy plus an extra copy of Implode.