There were a fair number of you interested in the Meteor Blaster DX
Re-release, and I have decided to go ahead and do this. In fact all the
digital assets were either uploaded or sent to the CD Replication house
today for the CD pressing. This is going to be a small run (300 units), and
there are a few differences between this and the original 2004 release.
2013 Updates:
New "MindRec" opening logo when the CD starts
Loop has been replaced with Loop v2 -- same frustrating as hell game, now
with powerups.
Couple of bug fixes in Implode Caravan Edition
Addition of a 5th ship to Meteor Blaster DX (seen in the Developers
Edition)
Several new or changed hidden features
Minor GFX enhancements in MB.
The CD packaging is also going to be different. There will be an official
UPC code on the game, and the white tray will be replaced with a clear tray
(and the inner tray artwork is an advertisement for Xymati). Including the
traditional white tray would have increased the cost of the project by
almost $200.
I am hoping to have the CDs in house around May 1.
Have not completely decided on pricing yet, leaning toward $15 for all Turbo
List members during the first month; $20 after that (and for non members).
I am not accepting pre-orders yet, I want to make sure that the CDs made do
actually work (I've been through this before).... but as always, let me know
if you have any questions.
-bt
This http://turbo.mindrec.com/ is the site for subscribing, but I don't think the server is working properly because it sent me back a bunch of gibberish.
Woot! My Duo will be happy to finally have a nice pressed disc to play instead of those dang CDRs it hates so much.
Did you guys try BT Garner's email? btgarner ( at) mindspring.com
[EDIT] Thanks bt!
Woot! My Duo will be happy to finally have a nice pressed disc to play instead of those dang CDRs it hates so much.
I am hoping this all works out so that I don't get any more reports of "Meteor Blaster ate my DUO!"
that has not been a valid email for years (10+) -- I still own it, but I do not check it on anything resembling a regular basis, and honestly when I do, it's to simply mark every thing as spam. it is also not a good idea to post email addresses in forums like this as spammers use web crawlers to find addresses and use them for targets. Replace "mindspring" with "mindrec" and you will have a more current address. =)I removed the email address. :)
lol "just sent this out"
I got that like 4 years ago. (Not really, but a few weeks maybe)
lol
There was one about the pressing awhile ago, I thought.
Maybe I am delusional, lol.
April Fool's joke?The charge on my credit card bill would disagree with that.
There was one about the pressing awhile ago, I thought.
Maybe I am delusional, lol.
Well he did mention it a bit back, but since then me and a few others responded so he wrote the above response. :)
There was one about the pressing awhile ago, I thought.
Maybe I am delusional, lol.
Well he did mention it a bit back, but since then me and a few others responded so he wrote the above response. :)
Yeah Arkhan! Now back off or I will f*cking cut you! Wanna start shit? Meet me in Fighting Street after school, a$$hole!!!
;)
I keep trying to join the turbo list.
And keep getting back
We're sorry; your message to "turbo-digest-request@mindrec.com" has failed. The recipient's mail server responded with: "Diagnostic-code 550 - (5.7.1
PM me the emall address you are trying to subscribe from, and if known the IP address of it.
@bt
In the thread, it mentions that you were only planning to press 300 copies. Let me encourage you to press 500 instead, if the number is not already locked in, so that the need for pressed CDs can be filled. If financing is an issue, then perhaps people would be interested in purchasing 2 copies for $25-35? I know that I would. If you were to promote that sales of Meteor Blaster DX would be helping Xymati to be developed for TurboGrafx/PC Engine, then I'm sure that a lot more interest would be drummed up. I would love to see Xymati finished up for the PC Engine!
awwww yeah.
BT: Are you going with Nationwide Disc as well?
On another note, I am not having much luck with the Turbo List. I was able to join, but every command I try I just get an error in return. Guess I gotta keep my eye out here. :)
BT, as for other PCE projects that could be doable....anything any of us know about, or you talking about secret stuff(I can't recall if I know anything that general public is not supposed to know, so I don't want to spill any beans).
@bt
In the thread, it mentions that you were only planning to press 300 copies. Let me encourage you to press 500 instead, if the number is not already locked in, so that the need for pressed CDs can be filled. If financing is an issue, then perhaps people would be interested in purchasing 2 copies for $25-35? I know that I would. If you were to promote that sales of Meteor Blaster DX would be helping Xymati to be developed for TurboGrafx/PC Engine, then I'm sure that a lot more interest would be drummed up. I would love to see Xymati finished up for the PC Engine!
I chose the 300 number based on the amount of interest that I have received over the past few months. It is somewhat of a gamble, the money I spent on the CDs could have gone for the (required) business expenses that will arise with Xymati. True, I could have gone for the 500 quantity for another $100 or so, but it took the better part of 8 years to sell off the first 500. I just don't have the storage space for a couple hundred extra CDs to be sitting around for that long.
Think of it this way, with supply and demand, you get your copy now, it will be worth a whole lot more in 4 years than had I gone for 500, and still had some available.
For a PCE version of Xymati to happen, a lot of things would need to happen, not only in the game code, but also in the community. The reason I chose to go with the PC market was for 2 main reasons. 1) Number of PCs that could run the game (compare this with the number of PCEs out there); 2) the things I wanted to do in Xy were over burdening the poor Duo's CPU and memory, and this was with only a limited amount of in game stuff there (no weapons yet).
I am not saying it cannot happen, but a game this size takes a lot of time, and the PCE development takes 2-3 times as long as PC development, I am lucky if I get 2 hours a day of non stop "extra curricular" coding time.
In addition to the PC audience, very little effort is needed to move a XNA based PC game to the Xbox; further, all I would need to do is port the dX code to OpenGL and I could have a version that runs on the PS3 and Vita too. That is a tremendous audience for less effort that a scratch made PCE version; and version that will not be able to have all the features I have in the current PC version.
Please keep in mind that everything beyond this line is speculative:
If the MB re-print shows that there is interest in the PCE scene still, then there is a game or two sitting on the back burner ready to come out (well, it's not ready, but ready to begin development on), and depending on how that does, that would certainly have some bearing on the PCE version of Xymati.
Now, ideally, I can take the game engine that the PC version of Xymati uses (MSL4) to quickly create other games (just need the digital assets and virtually any sort of 2D game can be made very easily), so if Xymati is successful, or I can get someone to license MSL4, then that would allow me to focus more time on the game making which would give more time for PCE ports, rather than releasing sadistic games like Loop v2.
BT, as for other PCE projects that could be doable....anything any of us know about, or you talking about secret stuff(I can't recall if I know anything that general public is not supposed to know, so I don't want to spill any beans).
I was thinking if maybe we PCE Devs should put our heads together and see what we could come up with. If nothing else, maybe put out a CD that has a game from each of us on it.
For a PCE version of Xymati to happen, a lot of things would need to happen, not only in the game code, but also in the community. .I'm confused about the Xymati/Mindrec/Eponasoft relationship. It's great that you're considering work on Xymati again, but last I heard Fragmare and Eponasoft had already revived the project. I'm not even clear who Eponasoft is (a Rover side project?). Can anyone explain?
On another note, I am not having much luck with the Turbo List. I was able to join, but every command I try I just get an error in return. Guess I gotta keep my eye out here. :)
Make sure your commands are in the Subject line, and in plain text only (no colored or fancy fonts). As I said earlier, the server is old and does not handle *any* MIME encoding.
##>> "This is a multi-part message in MIME format." - Failed.
MIME encoded messages are not going to get you far on this mailing list
How about making it an Arcade Card release? That should give you the additional RAM that you need (or at least be a lot closer to what you need.
... maybe would have to come up with something new.
Motherf*cking Tetris!!!! :mrgreen:
But I want a fancy version with tunes, sound effects, prettier graphics, and multiplayer!
BT - I really appreciate your continued updates about this. Thanks for the PM too.
Are you dead set on a clear tray? I understand white is expensive, but black would be nice and it would at least match U.S. games.For a PCE version of Xymati to happen, a lot of things would need to happen, not only in the game code, but also in the community. .
I'm confused about the Xymati/Mindrec/Eponasoft relationship. It's great that you're considering work on Xymati again, but last I heard Fragmare and Eponasoft had already revived the project. I'm not even clear who Eponasoft is (a Rover side project?). Can anyone explain?
Are you dead set on a clear tray? I understand white is expensive, but black would be nice and it would at least match U.S. games.MindRec has always used White Trays and tried to match the style of the Japanese releases (for artwork). The backing art for the clear try is tasteful (in my opinion), it is a dense star field (this will show through to the front), and Coming Soon text, along with a few screen shots of Xymati. The Xymati web address is also included (I need to get that site updated).
I'm confused about the Xymati/Mindrec/Eponasoft relationship. It's great that you're considering work on Xymati again, but last I heard Fragmare and Eponasoft had already revived the project. I'm not even clear who Eponasoft is (a Rover side project?). Can anyone explain?Here is the abbreviated history of Xymati.
Here is the abbreviated history of Xymati.Thank you!
Are you dead set on a clear tray? I understand white is expensive, but black would be nice and it would at least match U.S. games.
MindRec has always used White Trays and tried to match the style of the Japanese releases (for artwork). The backing art for the clear try is tasteful (in my opinion), it is a dense star field (this will show through to the front), and Coming Soon text, along with a few screen shots of Xymati. The Xymati web address is also included (I need to get that site updated).
Here is the abbreviated history of Xymati.
2005: The concept of the game was started. FraG and I bounced a lot of ideas back and forth, the basic game scenario was my idea, FraG came up with the multiple weapons and GFX to match.
...
MOST IMPORTANT QUESTION IN THE WORLD: Do the names of the music tracks have any formal/informal titles? Or have they always been referred to by their respective string of numbers (a legacy from development/coding)? I have grown fond of the numbers-as-titles (machines-creating-art-vibe), but, sadly, I can't always differentiate between the titles of the tracks until I listen to a bit of them. Ha! My poor brain.
MOST IMPORTANT QUESTION IN THE WORLD: Do the names of the music tracks have any formal/informal titles? Or have they always been referred to by their respective string of numbers (a legacy from development/coding)? I have grown fond of the numbers-as-titles (machines-creating-art-vibe), but, sadly, I can't always differentiate between the titles of the tracks until I listen to a bit of them. Ha! My poor brain.
They have titles: https://soundcloud.com/mindrec (that covers most of them, there may be a few left over tracks on https://soundcloud.com/btgarner)
That's interesting that they're actually using the word Eclipse when reporting the error, as they didn't seem to do that with Keranu when MSR had issues. But then again, the error reporting seems to be pretty hit/miss.
We could probably help straighten it out if you need.
Still awaiting that info from them. Apparently the person I have been dealing with takes a late lunch.
Still awaiting that info from them. Apparently the person I have been dealing with takes a late lunch.
Who's your duder.
Tell those f*ckers to lay off of the Lone Stars and speak plain English. :lol:
"Sending the physical masters straight to shop to cut metal. (no uploading)"
Um, okay, so we're back on?
Thanks for the links to the soundtracks on soundcloud, and the brief history lesson! Hope all goes well with the new pressing. I'll be ordering as soon as they are available. :D
That's what MSR went through also.
Tell them hell no on that option. The disc should be able to pass eclipse.
yeah. Did they ever give specific errors from Eclipse?
Have you asked specifically? It's really strange, given the MSR pressing issues.
They gave specific errors out when that occurred.
You're dealing with the Three Stooges over there.
I have no idea what this fee they're trying to pull on you is, it was never brought up to us during MSR,They're trying to sell him the check disc.
The game won't be produced correctly unless it has errors. But you have to confirm that it's only the expected ones. Even if you're up for a test disc, there's no point having one made until it sounds like they got it down to the correct format first. With Mysterious Song they said that a test disc must be purchased first, due to the unique format, or else they would not proceed. The salesman did drop the price though and a PCEFX forum raffle for the test disc (and a couple bonus prizes) covered the cost of it.
WTF? Really? Did you respond, "What happened to $195?"
Well, all is not lost ... not yet anyway. I have found another CD pressing house.. .yes they use Eclipse. However this one has one big difference, The owner is a 20+ year TurboDuo fan. I will be sending him a master tomorrow and working with him to figure out how to proceed.
Well, all is not lost ... not yet anyway. I have found another CD pressing house.. .yes they use Eclipse. However this one has one big difference, The owner is a 20+ year TurboDuo fan. I will be sending him a master tomorrow and working with him to figure out how to proceed.
It worked using Yahoo mail. Thanks!This http://turbo.mindrec.com/ is the site for subscribing, but I don't think the server is working properly because it sent me back a bunch of gibberish.
Use an email client that can send in plain text (the server is old and does nto know how to handle MIME encoded emails).
Send an email to turbo-list-request (at) mindrec.com
and place the word:
subscribe
in the subject line.
The server will send back an email with confirmation directions. Send another email to that same email addy with the confirmation command (in the reply you got) and you'll be on the list.
Any update on how this new CD pressing house deal is going?
BT are you taking pre-orders?
I am truly hoping this works out ... http://www.youtube.com/watch?v=AXiWznKO_Io, something else is already in the works.
I am truly hoping this works out ... http://www.youtube.com/watch?v=AXiWznKO_Io, something else is already in the works.
Well, all is not lost ... not yet anyway. I have found another CD pressing house.. .yes they use Eclipse. However this one has one big difference, The owner is a 20+ year TurboDuo fan. I will be sending him a master tomorrow and working with him to figure out how to proceed.
**** 6.2.11.6. Pre-gap ****
If a Data track is preceded by a different mode of track (such as an audio
track) or if the mode number of CD-ROM changes, this Data track starts with
an extended pre-gap. A pre-gap is placed at the head of a Data track, also
is belonging to the Data track. A pre-gap does not contain actual user data.
The pre-gap is encoded as "pause."
An extended pre-gap is divided into two parts. The first part of the
extended pre-gap has a minimum 1 second of data, and it is encoded according
to the data structure of previous track. The second part has a minimum 2
seconds data, and this data track is encoded according to the same data
structure as the other parts.
**** 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.
In the case of the pregap, it's 2+1 seconds (going by the recommended minimum), so 3 seconds of it as everyone would see when looking at a CUE file after ripping an original disc.
QuoteIn the case of the pregap, it's 2+1 seconds (going by the recommended minimum), so 3 seconds of it as everyone would see when looking at a CUE file after ripping an original disc.
Yep. 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 wonder how badly we can screw with them when we build a turbo cd with cd+g tracks :)
(Don't laugh. cdrecord will supposedly do it on a linux box. I've been playing with it, but haven't got that far...yet :)
QuoteIn the case of the pregap, it's 2+1 seconds (going by the recommended minimum), so 3 seconds of it as everyone would see when looking at a CUE file after ripping an original disc.
Yep. 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.)
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
FILE "02 Fighting Street (J).iso" BINARY
TRACK 02 MODE1/2048
INDEX 00 00:00:00
INDEX 01 00:03:00
POSTGAP 00:02:00
...does it really matter if that subcode data isn't changed to reflect a strict recommended *guideline* ??It wouldn't if it were just a recomendation. It's not. See iso/iec10149, section 20.
If I were to burn that and analyze it, I'd find that those 3 seconds of pregap will entirely belong to the data track (the subcode data would indicate track 2 and index 00). All the LBAs of every track thereafter will still match the original and the game will work just fine.
In such cases, and when dealing with pure audio discs (index 00 was for a pre announcement/intro before the song actually starts) you'd wanna preserve it when reading the track and that would result in something like this to burn it back:
....
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.
It doesn't matter, at least it shouldn't. The software shouldn't try to bother to accomplish exactly what the strict guideline is calling for. All the CD-Rs that were ever burned with a CUE file like my first example work fine on real NEC hardware.
Awesome! No more f*cking around with Nationwide, or whatever they're called? Sounds good to me!
I am convinced you guys all went to a different Nationwide Disc.I think it depends on the rep you get. I dealt with 2. The first guy was very tech oriented, and understood (or at least seemed to) that this was going to be "non standard." But once they got all the assets, I had to deal with a different person. A very nice person, but completely out of her league on the technical side.
Update on things.
I just heard back form the CD House. The owner took 2 of the 3 press samples they made and tried them on his Duo, and he says they worked flawlessly -- he apparently had a good time playing MB all weekend. So all 3 samples are en route to me, and I will have them on Wednesday.
The name of the company is OMM DVD (ommdvd.com), they are in Indianapolis.
since they were able to use the original Quark files (and not JPGs).
So how many hundreds of dollars did they charge you for each test disc?
Huhmmm. I sent NWD a bunch of high-res PSD files.
So how many hundreds of dollars did they charge you for each test disc?
It was part of the package deal, knowing that Eclipse would fail.
since they were able to use the original Quark files (and not JPGs).
Huhmmm. I sent NWD a bunch of high-res PSD files.
Yeah but, they supplied JPGs? Or did you?
JPGs seems like a bad idea.
Where do I get to order now? :) Mailing list didn't seem to work for me, so please make sure to let everyone know here too!
BTW - Turbograpx!? I thought you said the guy that worked there was a fan!?
Where do I get to order now? :) Mailing list didn't seem to work for me, so please make sure to let everyone know here too!
BTW - Turbograpx!? I thought you said the guy that worked there was a fan!?
Check Discs have arrived, and they all run on Duo hardware.
Just pre ordered mine!Ditto.
Where did you guys preorder?Through the mailing list. I received an email about it today.
Damn. I thought I subscribed last week, but didn't realize I had to reply with a confirmation code.Rookie. :P :wink:
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!^^^^^
Who wouldn't get the dual pack? That is a super deal!
Me, because I already had it...lol. Now I feel like I should have got an extra.
Paypal just sent me a shipping notice!D'oh! No shipping notice here yet. Damn me for living in Canada.
Paypal just sent me a shipping notice!D'oh! No shipping notice here yet. Damn me for living in Canada.
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.
Mine came yesterday! I forgot to mention this.
It wouldn't if it were just a recomendation. It's not. See iso/iec10149, section 20.
the PCE doesn't check tracks that closely (even to the point of ignoring data track checksums, iirc).
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.
Quote from: NightWolveSuch 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,
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.
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.
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.
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.
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.
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.)
**** 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.
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
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
Haven't followed all the thread but I'd like to order a copy. Any link?
it's such a minor thingNot 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....
Quick aside: There used to be an infamous problem with all those ISO/MP3/CUE image file setsI am initimately familiar with that problem. For more info, ask rover.
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.
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:There's only one problem with that. You may have either a pre-gap or a post-gap, but not both.
.....
TRACK 02 MODE1/2048
PREGAP 00:03:00
INDEX 01 00:00:00
POSTGAP 00:02:00
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.
What is a post-gap for one track is also the pre-gap for the next.
The guy who designed the original CD layout was a classical music buff.
Mine arrived today! Durham, NC!? I didn't know Mindrec was only an hour and a half away. Cool. :)
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.
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.
There is not a difference, other than the tray and insert.
Basically, the art format that the CD pressing house needed was one of the higher quality ones (Quark), and the original files were in that format. Not having access to Quark, nor wanting to shell out cash (or a further delay in the project) to update the files, I just let them go as is.
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.
There is not a difference, other than the tray and insert.
Basically, the art format that the CD pressing house needed was one of the higher quality ones (Quark), and the original files were in that format. Not having access to Quark, nor wanting to shell out cash (or a further delay in the project) to update the files, I just let them go as is.
As I said, it wasn't a complaint and your reasoning is valid. I did notice the "Dev/Sig Edition" and the 2013 mark on the title screen which is great. I'm assuming you used the Signature Edition insert too since it does differ from my original release insert.
Overall, everything is great and the inclusion of the 5th ship is cool too. Thanks for rereleasing it for us. Out of simple curiosity, was there any changes made to loop and implode on the disc?
I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."
Here are the numbers so far ....
I received about 50 pre-orders. (and the pre-order page will be open for a few more days). 70% have been shipped at this point -- I have tracking numbers, but felt it was more important to get more orders out than enter the numbers in paypal. Those numbers will be entered later, but you'll probably already have your CDs by then.
The last batch of domestic pre-orders (10) will go out on Monday or Tuesday, then the final batch of pre-orders (the international ones) will go out later in the week. The latter ones need to go to a real post office, and not a satellite branch like I have been using.
US orders have been from all over: CA and NC have the most (with 3 each). International orders have come from Canada, Spain and France. Once the pre0orders are taken care of, I will download all the orders and make a google map to show where the orders were shipped to. I will only use zip codes and not addresses.
I actually ran out of shipping envelopes, so 2 orders still have to be packaged up. When your order is packaged up you get the "In Process" notice.
I also had to up the shipping costs via paypal since they were basically at a break even point for some, and a losing point for others. Why it costs $2.75 for 2 CDs to ship, but $5.85 for 4 is beyond me. Oh well, just another discount that folks who ordered early got to take advantage of.
I also found a case of old MB cases (no CDs), so if anyone really wants a white tray to replace the clear one, they will be available soon.
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. 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.
Track structure of the Information Area
...
For the purpose of linking Information Tracks in the Information Area, these tracks may have:
a) Pause : A part of an Information Track on which only control information but no user data is recorded.
b) Pre-gap : A first part of a Digital Data Track not containing user data and encoded as a Pause. It is divided
into two intervals:
- first interval: at least 75 Sections (at least 1 s) coded as the preceding track, i.e. the Control field
(see 22.3.1) of the q-channel (see 22.3) and, in case of a preceding Digital Data Track, the setting
of the Sector Mode byte are identical with those of the previous Information Track;
- second interval: at least 150 Sections (at least 2 s) in which the Control field of the q-channel and
the setting of the Sector Mode byte are identical with those of the part of the track where user
data is recorded. In this interval of the Pre-gap the data is structured in Sectors.
c) Post-gap : A last part of a Digital Data Track, not containing user data, and structured in Sectors. It has the
length of at least 150 Sections (at least 2 s). The setting of the Control field of the q-channel and
the setting of the Sector Mode byte are identical with those of the part of the track where the user
data is recorded.
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).
22.3.3.2 INDEX field
This field contains an Index specifying the subdivisions of an Information Track.
Index 00
This value of the Index indicates that the Section is coded as a Pause. The total length of the Pause corresponds to the number of consecutive Sections with Index set to 00.
Index 01 to Index 99
These values specify the indexes of the subdivisions of that part of an Information Track that contains User Data. The first subdivision shall have Index 01. Consecutive subdivisions shall have consecutive Index values.
The Index field of the Lead-out Track shall be set to 01.
struct SUBCHANNEL_SUBQ_DESCRIPTOR {
BITS ADR : 4;
BITS CONTROL : 4;
BYTE TrackNumber; // Warning: CD Device inconsistency in returning Hex or BCD values
BYTE IndexNumber; // Coding must do BCD/HEX checks before determining data is invalid
BYTE Min;
BYTE Sec;
BYTE Frame;
BYTE ZERO;
BYTE AMIN;
BYTE ASEC;
BYTE AFRAME;
BYTE CRC1;
BYTE CRC2;
BYTE Reserved1;
BYTE Reserved2;
BYTE Reserved3;
BITS Reserved4 : 7;
BITS PSubCode : 1;
};I will send you an email with a text document explaining things as I see them. PM me your e-mail, please.
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.)
Not really. There is a reason the p-q bits have to be set that way....
I did not mean that the pce ignores the error correction
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.
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.
I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."
I received about 50 pre-orders.
Okay. I snagged the pdf, and will read over it very carefully. Maybe I can finally get a real explanation of what those p-q channel codes actually do.
From looking at a bios disassembly, I can tell you that the q code is how bios recognizes a data track. It will boot the first data track that it finds, but there may be more than 1 on a disc. It actually doesn't use the TOC to determine where to boot from.
(in seems a single data track may also have multiple indexes, afaik)
TRACK 5 MODE1/2352
INDEX 1 13:51:56
INDEX 2 13:58:45
INDEX 3 14:01:12
INDEX 4 16:12:59
INDEX 5 22:43:38
INDEX 6 28:16:20
INDEX 7 29:53:41
INDEX 8 34:04:26
INDEX 9 34:29:34
I don't remember much about actually trying to rip individual tracks, other than it usually kicked up an error. I believe it always occurred 2 sec before the data track started (which would be where q changes), but once I found out ripping as an entire image in raw mode worked, I quit trying other things :) <hey, I was young and impatient>
An interesting side note for you: Nero 6.0.1 appears to be able to set the p-q codes correctly; it recognizes the change from audio to data tracks correctly. Unfortunately, it has an off-standard way of using cue sheets...
And speaking of wastes of space.....the 8-14 encoding on cd and the other error correction stuff mean only about 1/2 of what it burned is actually real data. Granted, it allows great error correction; but it does remind me of something one of my professors once said: You can get nearly 100% error correction simply by sending the message 3 times. Two matches wins for any byte. Guess just duplicating the information twice would have been too easy :)
I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."
What better way than to look in the TOC for the first track flagged as type 'Data', obtain its LBA, move the laser to it and begin reading there to boot ??Except thats not what I'm seeing in the code. The cd electronics has a register the holds the pq-code for the current frame. Bios monitors that register (and &'s it with a mask ) looking for a particular bit to be turned on. Then it starts loading into memory, and starts executing code when the read finishes.... (it's a 1 sector read, the ipl)
Here are the numbers so far ....
I received about 50 pre-orders. (and the pre-order page will be open for a few more days). 70% have been shipped at this point -- I have tracking numbers, but felt it was more important to get more orders out than enter the numbers in paypal. Those numbers will be entered later, but you'll probably already have your CDs by then.
The last batch of domestic pre-orders (10) will go out on Monday or Tuesday, then the final batch of pre-orders (the international ones) will go out later in the week. The latter ones need to go to a real post office, and not a satellite branch like I have been using.
US orders have been from all over: CA and NC have the most (with 3 each). International orders have come from Canada, Spain and France. Once the pre0orders are taken care of, I will download all the orders and make a google map to show where the orders were shipped to. I will only use zip codes and not addresses.
I actually ran out of shipping envelopes, so 2 orders still have to be packaged up. When your order is packaged up you get the "In Process" notice.
I also had to up the shipping costs via paypal since they were basically at a break even point for some, and a losing point for others. Why it costs $2.75 for 2 CDs to ship, but $5.85 for 4 is beyond me. Oh well, just another discount that folks who ordered early got to take advantage of.
I also found a case of old MB cases (no CDs), so if anyone really wants a white tray to replace the clear one, they will be available soon.
3 from Cali huh? I wonder who the other 2 are, maybe 1 of them is Charlie MacDonald. I can't think of any other Californians I know of. There's one I use to know, Art Agressior or something like that, but I haven't talked to him in ages.
You can count me as one of those California orders. Southern California, to be exact. Still hasn't arrived yet though. ;)
.... the next effort: http://www.youtube.com/watch?v=1qO9rBNWGUw
.... the next effort: http://www.youtube.com/watch?v=1qO9rBNWGUw
Mmm, shewty. Sign me up! :mrgreen:
Mine arrived today but the packaging is the same as the original. How will I be able to distinguish them apart?clear cd tray versus white cd tray
Is the Implode mascot a distant relative of Monsieur Lemming, by any chance?
No idea -- he was completely the creation of the guy who did the packaging art. Contrary to popular belief, he shares no resemblance to me.
Mine arrived today but the packaging is the same as the original. How will I be able to distinguish them apart?
Yellowbook standard isn't applicable here. PCE cds predate that.
For the first few years of its existence, the CD was a medium used purely for audio. However, in 1985 the Yellow Book CD-ROM standard was established by Sony and Philips,
"the Yellow Book, created by Sony and Philips in 1988, was the first extension of Compact Disc Digital Audio."
Except thats not what I'm seeing in the code. The cd electronics has a register the holds the pq-code for the current frame. Bios monitors that register (and &'s it with a mask ) looking for a particular bit to be turned on. Then it starts loading into memory, and starts executing code when the read finishes.... (it's a 1 sector read, the ipl)
Please note, it is not requesting to read a particular sector. It checks the bit, and then starts reading....
As far as I can tell, it doesn't read the TOC until -after- it has checked for a bootable cd.
I'll keep looking into the bios, though. I haven't drilled all the way down into all of the routines to see what is going on.
Yellowbook is an extension to Redbook that was created in 1985Was going by dates in the ecma doc you posted. "High-Sierra" was 85, iso-9660 was 86, and yellowbook was 87. Not that there is that much difference, I suspect.
Again, that info is all right in the TOC, so why would you first blindly seek-scan the whole disc ??? Don't get lost in BIOS assembly, just think intuitively about it...Personally, I would use the TOC as well. But who know what the guys at NEC were thinking. I do wonder what exactly they thought of the ramifications of Section 20 in iso-10149 and emca-130. If you unravel the description, you will find that a cd isn't required to have a TOC - the lead-in area can be pure audio. Maybe they were thinking of how to deal with that.
So, simply put, that tells me that the BIOS read the TOCProbably. It may be doing the Q channel check on TOC data. I just don't see that in the bios code.
What I don't know is how seeking works exactly though, is it efficient or blindly linear,I don't understand seeks that well either. I suspect that a seek is a high-speed read, where only the timestamps and channel codes are decoded.
Not sure the easiest or fastest way to detect a data sector over an audio one, though.All you would need to do is monitor the Q channel bit. When it changes, you've hit a data sector. The Q bit is also encoded in the data stream, so it would be simple to check - at the hardware level. Maybe not so easy in packetized software, where you get a whole 2352 bytes at once.
Was going by dates in the ecma doc you posted. "High-Sierra" was 85, iso-9660 was 86, and yellowbook was 87. Not that there is that much difference, I suspect.
I did however mis-remember the sys 2.0 bios date. I thought it said 86, but in fact it says 89.
Given that it had to take time to develope and finalize everything, I could see them using high-sierra format for cds. It takes a while for production to catch up to the standards. So there could be minor differences, not that it matters
Again, that info is all right in the TOC, so why would you first blindly seek-scan the whole disc ??? Don't get lost in BIOS assembly, just think intuitively about it...
QuoteWas going by dates in the ecma doc you posted. "High-Sierra" was 85, iso-9660 was 86, and yellowbook was 87. Not that there is that much difference, I suspect.
Not sure what doc that is, but yeah.. yellow book format was defined before ISO-9660.
I doubt the sys card disassembly is going to get you much. It's at least one layer above the CD hardware. There's an embedded MCU (z80 based) with embedded ram that controls and interfaces with the CD (sony, last I checked) ICs. The 6280 communicates with this MCU device (hence the SCSI CD extension type command structure).
On a side note, the data in the sector on the disc isn't exactly stored in linear format (though I think that's already known here), even though it's accessed as such. It's interleaved with other bits on the disc.
BTW, love this discussion :D
The problem with calculating start/end based on time is that the gap times given in all the documents are minimum times. The gaps can be longer, and that's perfectly acceptable. Iirc, one of the early us cds had the data track aligned to a second boundary - which meant it's gap was 00:03:01. That's right, 1 extra frame there. Drove me nuts for a while... (Fighting Street, I think it was)
// ** Fighting Street (U) transition layout **
// Track 1, Index 01 = 0000 to 3364 (Actual Audio)
// Track 2, Index 00 = 3365 to 3444 (Marked as Audio)
// Track 2, Index 00 = 3445 to 3594 (Marked as Data) [3594-3365+1 = 230 sectors of pre-gap]
// Track 2, Index 01 = 3595 to 11330 (Actual Data)
// Track 3, Index 00 = 11331 to (Marked as Audio)
// errors at 11336
// 11337 continues
// Track 3, Index 01 = 11481 (Actual Audio)
Probably hear from arkhan about spending an hour replying to this, instead of bug-squashing :)
I suspect he read this part from the ECMA-130 PDF I posted earlier...Yep. The only one I really remember, though, was the High-sierra, which definately pre-dated them all.
the very first thing that a regular audio CD player traditionally does is load the TOC, well, I wouldn't expect dissimilar behavior here.I wouldn't expect it either. I just can't prove it. It's equally possible that having the scsi port connected alters the behavior of the CD drive. But I can't prove that one either.
Below, I traced TurboRip in VC++2005 with the newly (WIP) Q subcode detection code and I marked the LBA values when index 01 changes to index 00, along with track number changes etc.Cool. 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... )
- "Made in Canada" was added to the case back
The original had this too because the original CD-Rs were actually made in Canada.
| (http://farm6.staticflickr.com/5332/9067940088_47164e5858_o.jpg) | :mrgreen: Original Version Signature Edition New Version |
These were made in Indiana, which, as far as I know, has not been annexed by Canada.
These were made in Indiana, which, as far as I know, has not been annexed by Canada.Not yet. :) I'm sure you guys wouldn't miss it.
Cool. 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... )
Quick 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'm pretty sure they've always been in NC.