Necstasy

Hello, I've been doing some investigating, so I've updated my original post. Hopefully the edited title will be a little more eye-catching. Here is what I originally wrote, it's pretty dull, you might want to skip it:

>Hello, me again,
>
>I was wondering if anyone here an original copy of AV Tanjou (GECD)? If >anyone does, you could save me from having to buy the wretched thing >by answering a simple-ish question.
>
>Some background: I've sort of acquired three separate bin/cue images >of this game. They all have perfect TOCs. But, when I try to mount them >(daemon tools) and convert to an iso/wav, something weird happens to >the TOC (Track 1 goes a bit screwy). CDMage completes the extraction >but changes the TOC, whilst TurboRip has a freakout and crashes after >doing the first iso track. So I'm curious - does something similar happen >with an original disc?
>
>I know this seems pretty minor, but it has me intrigued because I haven't >come across any other game (bin/cue or original disc) that behaves this >way when I try to convert it. Could the game be mastered in a weird >way?
>
>So yeah, hopefully someone here can tell me what happens with an >original disc, before I go out and squander 30GBP on a game I'm not like >to ever play.
>
>Fingers crossed, anyway....
>
>Splendid

Anyway. It turns out that the problem lies with TOCFixer. When I rip the AV Tanjou bin/cue to iso/wav with CDMage, the TOC is still perfect with TOCReader. TOCFixer, however, wrongly reports the TOC as being invalid (it claims track 1 is the wrong size and wants to "fix" it). This, I think, explains why TurboRip chokes when I try to use that to rip the image - it presumably uses the same dodgy info that has been put into TOCFixer. As I understand it, the same TOC info has also been incorporated into Magic Engine, so it's possible that this would need changing too (although I can't imagine it'll cause any problems - it just won't display the disc title properly). Haven't checked this behaviour yet, will get round to it.

So yeah, I'm fairly certain this is what's happening, so I'm reporting it here in the hope that somebody can double-check this behaviour. If I'm right, I can report this on Nightwolve's forum (if he doesn't visit here already).

While I'm here though, it seems that isn't the only game that has incorrect information for it in TOCFixer. If you look at the NECstasy pages for the two V.5.0 variants of Mahou no Shoujo Silky Lip, you'll see that the sizes of track 2 are meant to be 261 210 112 Bytes [normal version] and 260 902 912 Bytes [alt version]. But have a look at what TOCFixer expects - both versions report 261,210,112 as being the correct size. Once again, this also means the game can't be ripped successfully with turborip - it gets confused when it hits the track with the "incorrect" length.

As usual, I'm sorry to be picking holes in the fine work you people do, hopefully this will help things to improve further, anyway. If you need any more info, just give me a shout.

Regards,

Splendid

Splendid a écrit :Anyway. It turns out that the problem lies with TOCFixer. When I rip the AV Tanjou bin/cue to iso/wav with CDMage, the TOC is still perfect with TOCReader. TOCFixer, however, wrongly reports the TOC as being invalid (it claims track 1 is the wrong size and wants to "fix" it).

OK, this problem is related to what Square just showed me. A non-standard gap size that TurboRip can't account for, nor does TocFixer know about.

This, I think, explains why TurboRip chokes when I try to use that to rip the image - it presumably uses the same dodgy info that has been put into TOCFixer.

I assume the problem occurs right when track ripping was about 99% complete? It's not related to TocFixer, though, because it doesn't work that way. TurboRip rips tracks using the disc's TOC that it just read. But, the problem is a postgap is supposed to be 2 seconds when going from data to audio. That assumption is what TurboRip uses to compute the ending sector of a track when there are track type transitions. With AV Tanjou, it appears the postgap is 3 seconds, so that would explain why TurboRip fails. Next version of TurboRip will start with the assumption of postgaps being 2 seconds, then try 3, 4, etc. to more properly determine the final sector of a track. That should take care of this issue.

While I'm here though, it seems that isn't the only game that has incorrect information for it in TOCFixer. If you look at the NECstasy pages for the two V.5.0 variants of Mahou no Shoujo Silky Lip, you'll see that the sizes of track 2 are meant to be 261 210 112 Bytes [normal version] and 260 902 912 Bytes [alt version]. But have a look at what TOCFixer expects - both versions report 261,210,112 as being the correct size. Once again, this also means the game can't be ripped successfully with turborip - it gets confused when it hits the track with the "incorrect" length.

(EDIT: Square explained in the next post why you've correctly identified a problem here. Thanks. TocFixer does need to be fixed because while the TOCs match, there's an extended postgap with the 'alt' version causing the data track to be shorter. I was unaware of this situation ever existing and TocFixer is designed to use only the TOC data, so a special consideration would have to be made to compensate for this particular ISO/WAV image file set.)

I didn't know there were two different discs with the same TOC. This will cause TurboRip to always select the base name without the 'alt' in it. In order to determine the difference between the two discs, the CRC32 of track 2 must be computed. I will have to add that to TurboRip someday to properly name these two discs should they ever be encountered. That's the only effect. Both discs will rip just fine, but one of them will be wrongly named, without the 'alt'.

There's no mistake with the alt version and if you look closer at the provided cue file you'll notice this :

FILE Track03.wav WAVE
TRACK 03 AUDIO
PREGAP 00:04:00
INDEX 01 00:00:00

As you can see it has a non standard pregap, hence why the data track is indeed shorter but the TOC still looks the same.
It's certainly a bad dump, but since this prototype never made it other than a cdr (afaik) i'm keeping it for reference only.

I might discard it in the future and only keep the non alt version.

Ahhh, I only looked at the TOCs. If there really is a postgap of 4 seconds (incorrectly represented as a 'pregap 00:04:00' with the following track as is commonly done by CDRWIN and others), the data track would be two seconds shorter. Well that explains that. Next version of TurboRip will correctly detect gaps, so it'll properly handle discs like that I hope.

Anyway, TocFixer has to be fixed if you keep it. Not a bid deal, really. I just have to remember to decrease the length for the data track of that disc and if ever I get a new TOC file set from you. I guess I wouldn't need to compute the CRC32 after all since there really is a difference, though not detectable from the TOC unfortunately.

Anyway, the only thing that'll happen with MagicEngine is it'll always report the game's title as 'Mahou no Shoujo Silky Lip' even when it's the 'alt' version.

Thanks for the replies.

Sadly, I'm sort of a dullard, but I think I'm following what's going on.

AV Tanjou is a weird game. Pretty much every PCECD game data track has a postgap of 150 frames. For reasons that still escape me (but I'm looking into) this is almost always expressed as a pregap of the following track. Because AVT uses a nonstandard 225 frame gap, but TOCFixer and TurboRip assume 150, TOCFixer miscalculates the file sizes and TurboRip thinks it has come across an error. And to answer your question NightWolve, TurboRip stops at the end of Track01. Here's what it says:

Ripping: Data Track 01 (4,200,448 Bytes)
Sector Range: 000000 to 002050 (2,051 Sectors)
File: AV Tanjou (J)-01.iso
Progress: 96.0%, LBA: 001944 to 001970
Read error: Illegal mode for this track

Hmm, actually I seem to be following this reasonably well at the moment. Hopefully you will mange an update to your software at some point (it would be much appreciated). Until then I guess people should use CDMage to rip any CDs with these non-standard gaps?

Uh-oh, here's where I start to get confused...

I'm thinking that the outcome of my Silky Lip query is basically the same, and it's all to with more nonstandard gaps?
I've had a look at a selection of other cuesheets, and the rule seems to be:

WAV Track -> ISO Track (3 second gap between them)
ISO Track -> WAV Track (2 second gap between them)

So the alt version is certainly exotic in having a 4 second gap between Tracks 2 and 3. Squaresoft, are you saying that these two extra seconds have been cut off from the iso track? This fits as 261,210,112 - (153,600 x 2) = 260,902,112. Yeah, I'm seeing why you call it a bad dump. Luckily, TOCFixer only detected the non-alt version - it would have been unfortunate if it had been fixing non-alt -> alt. I know you're not putting it up for a vote, but I'd certainly prefer to see the alt version removed from the database (except - bugger! - I can't find a dump of non-alt anywhere).

Oh well, looking back all this is certainly covered in your previous posts, but at least I think I understand it better now, hopefully my dumbed-down version will help some fellow newbies.

Cheerio....

Splendid a écrit :Because AVT uses a nonstandard 225 frame gap, but TOCFixer and TurboRip assume 150, TOCFixer miscalculates the file sizes and TurboRip thinks it has come across an error. And to answer your question NightWolve, TurboRip stops at the end of Track01. Here's what it says:

Ripping: Data Track 01 (4,200,448 Bytes)
Sector Range: 000000 to 002050 (2,051 Sectors)
File: AV Tanjou (J)-01.iso
Progress: 96.0%, LBA: 001944 to 001970
Read error: Illegal mode for this track

Yeah, it only subtracted off enough sectors to cover 2 seconds worth of postgap - An assumption I believed to be true for all PCE discs, until now of course. A postgap transition area is a minimum of 2 seconds (or 150 frames/sectors if you prefer) of unreadable/unburned sectors when transitioning from a data track to an audio track. That read error indicates an attempt was made to read unreadable/unburned sectors OR your CD reader can't read sectors right near the postgap area, so that error usually occurs at 98%, 96% in this case because 75 sectors needed to be subtracted off to know the true final sector.

Looking at the CUE sheet, I see PREGAP 03:00 instead of PREGAP 02:00, which yeah, I mentioned is an improper representation by CDRWIN for what will actually be created as a postgap. Anyway, the proper sector range should probably be between 000000 and 001976 and it looks like your CD reader can't handle reading near the postgap area, so it raises an illegal mode error. Attempting to read right into the postgap area would've been happening after reads were made above 001976, whereas in your case, it error'ed out at 001970, so it never made it to the postgap area. Anyway that's also been fixed in the next version, which will just write empty sectors to make up the difference. BUT, you can never compute the proper CRC32 with the drive you're using. It has the same problem as mine and others do, failing to read the last few sectors near the postgap area which are valid, legally readable sectors that are apart of the data track. With almost all PCE discs, these ending sectors are usually just padding, zeroes mostly, so the game will still work without them.