Redump Forum

EAC detects pre-emphasis for AITD trilogy CD2 (PC) audio tracks and sets flag in .cue
it's like this:

FILE "Track 05.wav" WAVE
  TRACK 05 AUDIO
    FLAGS PRE
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Track 06.wav" WAVE
  TRACK 06 AUDIO
    FLAGS PRE
    INDEX 00 00:00:00
    INDEX 01 00:02:00

i might not be able to add this cd - it's scrached and reads very slow but there may be others
does db support this at all? (checked, it doesn't - added information in comments)
.
.
.
it's in q-contrlol subcode: 1 for those tracks; 1 in data-audio gap, but 0 in audio-audio. ther's some data in gaps but it doesn't look any different from the rest of the track. on eac forum somebody said, if you'd playback such track skipping de-emphasis, it would sound strange, i don't know, they doesn't - they sound ok.

i've uploaded a small (200kb) track here:
http://www.mediafire.com/?ungg3vtyyzx

could somebody compare it with the same track from Vigi's versin, please?

AITD3 get:
FLAGS DCP
- copy permitted, for all tracks
in subcode it's q-control bit mask: ??1?
including all gaps this time

I've added DCP and PRE support. Cuesheets so far are generated without flags, I'll fix this later.

thank you very much

themabus wrote:i've uploaded a small (200kb) track here:
http://www.mediafire.com/?ungg3vtyyzx

could somebody compare it with the same track from Vigi's versin, please?

I don't think any of my AITD discs have PRE (only wipeout and some others, and I mentioned it each time in the comments).. I compared my aitd2 start to your file and they are different.. your dump has some data in the pregap and mine doesn't (also the data after the pregap starts with different bytes etc).

On another note, my alone in the dark dumps also come from a square black trilogy box (I also had a separate copy of AITD1 and it was identical).. I don't think the naming that you used is appropriate, because they should be identical to the normal versions (strangely enough your dumps don't match mine).. so my box just contained 3 jewel cases with the normal games with normal covers etc.. I'm not sure about yours.

And I don't know why these 2 https://redump.info/disc/2883/ + https://redump.info/disc/1706/ don't match.. could you upload a sample (.bin compressed in rar plz) of one of the audio tracks so I can compare?

I think we will run into this problem more often with IBM (same data track crc + different audio track crc's).. so maybe an "intelligent checksum" that only calculates the checksum of the data start and end is a better method for comparing audio tracks after all.

Also, it's possible that IBM discs have a +0 write offset on the data track but a different write offset on the audio tracks, so plz be sure to use the classic offset detection method!

thank you a lot

my trilogy, it was budget, i guess. got it from Australia. it's only a carton envelope holding 3 cds. homogenous artwork design. brief manuals on cds. so i named it as a set but i guess you're right.
other one is from the double pack Alone in the Dark + Shadow of the Comet, it's similar in design to this one:
http://www.mobygames.com/game/dos/telst … space-hulk
and had each game in it's own jc with full printed manuals.
uploaded track 03 here:
http://www.mediafire.com/?elm9umvje9e

for offsets i indeed did d8 on data and also i do not cut off gap but separate it to another file and count scrambled samples there. though only do this once but it matched with d8 always so far. but still both results are from the same drive so i guess i'll try different one, then.

The difference between alone in the dark 1 appears to be an offset difference of 3604 bytes (or +901 samples).. also, in my dump, because the track data is shifted forward compared to your dump, each track starts with data from the previous track in the pregap

Maybe our current methods just aren't able to detect the real write offset of these older IBM discs that show +0 write offset?

ps. do your AITD1 tracks also start with a click?

Also, I noticed that your trilogy dump has the same audio sizes as your budget dump.. have you compared the 2? It looks like for the trilogy one they just took the complete track of the original release, including the gaps and then just mastered them without any extra gaps..

I'm wondering what the best way would be to deal with these differences.. the 'intelligent checksum' comes to mind again... the disadvantage would of course be that we wouldn't be able to identify the real reference point (the position of the data before any mastering, like in PSX), but I doubt my original edition discs are the ones providing the real reference point, because your budget discs don't have data entering into the next track's pregap.

ps. do your AITD1 tracks also start with a click?

Also, I noticed that your trilogy dump has the same audio sizes as your budget dump.. have you compared the 2? It looks like for the trilogy one they just took the complete track of the original release, including the gaps and then just mastered them without any extra gaps..

no, thanks, i didn't notice. i'll try to check now all this

Telstar compared to Trilogy
Track | Telstar offset diff from LBA | Click Tel / Tri | Data diff (ignoring $00)
03      |-3920    | click / don't  | first 16 bytes differ
10      |-3908    | click  / click  | first 16 bytes differ
11      |-3948    | don't / don't | match
12      |-3912    | don't / click  | first 16 bytes differ
13      |-3916    | don't / don't | first 20 bytes differ
14      |-3900    | click  / don't | first 16 bytes differ

i removed gaps and to align audio data Telstar had to be corrected by the opposite amount of bytes given in 2nd column (Telstar is closer to 0 offset; i guess it means that Trilogy is maybe more similar to yours). though close, it's still different for every track. and then, when binary compared, still some bytes would differ. it's strange.
i hoped, there would be some similar audio tracks for SegaCD/PCE but for the same games they were different - remastered and quite a lot. but this is different, only a few bytes do not match.
it's a good thing you noticed clicking, it looks like it's in those 16 bytes. maybe they were trying to remove it or something; but then they still failed sometimes.
to be hones, i don't know what to think. i hope, this may be an exception, and rare one also.
...
ya, i checked offsets on other drive, they're still the same.
...
and i thought at first that this offset difference is maybe because EAC can't position correctly. but it's not. when Alcohol's .img is sliced in tracks and then compared to EAC, the difference - it's always the drive's offset, always the same.